The worked example has two rows that are only compatible under one implementation:
| Action |
Gateway Decision |
Reason |
npm install |
Allow |
Balanced profile allows shell in cwd |
Read ~/.ssh/id_rsa |
Deny |
Out-of-bounds secret read |
npm install runs lifecycle scripts from every package in the tree. Those scripts are arbitrary code running as the user, and they read files and open sockets without asking anyone. If mediation happens at the agent's tool call boundary, the deny on ~/.ssh/id_rsa only fires when the agent asks to read it through a mediated tool. A postinstall script reading the same file never crosses the gateway at all.
So the table is accurate if enforcement sits below the agent in the kernel, and misleading if it does not. This is the practical consequence of the unnamed interception mechanism, and it is worth stating in the document either way, because it changes what a reader thinks they are getting.
The same applies to the network row. Denying egress to unknown-site.com is a real guarantee if egress is filtered per process tree. It is advisory if it depends on the agent choosing to route its request through the gateway.
Two honest resolutions:
- Kernel enforcement. State that allowed commands run inside a restricted process tree, and that the restriction is inherited by children. This is the strong version and it is what makes the table true.
- Tool boundary mediation. Keep it, and add "descendants of an allowed shell command" to the out of scope list alongside host OS container escapes. A reader can then reason about the residual risk instead of assuming it is covered.
There is also a middle option worth considering for v1: treat the shell layer as coarse and put the effort into making an allowed command run under a tighter sandbox than the agent itself, rather than trying to reason about what the command will do.
What would help: a sentence under the worked example saying which layer catches a child process of an allowed command, and a matching line in the threat model.
Raised during the public review window (closes 2026-09-19).
The worked example has two rows that are only compatible under one implementation:
npm install~/.ssh/id_rsanpm installruns lifecycle scripts from every package in the tree. Those scripts are arbitrary code running as the user, and they read files and open sockets without asking anyone. If mediation happens at the agent's tool call boundary, the deny on~/.ssh/id_rsaonly fires when the agent asks to read it through a mediated tool. A postinstall script reading the same file never crosses the gateway at all.So the table is accurate if enforcement sits below the agent in the kernel, and misleading if it does not. This is the practical consequence of the unnamed interception mechanism, and it is worth stating in the document either way, because it changes what a reader thinks they are getting.
The same applies to the network row. Denying egress to
unknown-site.comis a real guarantee if egress is filtered per process tree. It is advisory if it depends on the agent choosing to route its request through the gateway.Two honest resolutions:
There is also a middle option worth considering for v1: treat the shell layer as coarse and put the effort into making an allowed command run under a tighter sandbox than the agent itself, rather than trying to reason about what the command will do.
What would help: a sentence under the worked example saying which layer catches a child process of an allowed command, and a matching line in the threat model.
Raised during the public review window (closes 2026-09-19).