The agent never called a tool you had blocked. It wrote a small helper script, ran it through the shell tool you do allow, and the helper opened a socket to an address nobody had approved. Your guardrail reads tool calls, and a socket opened by a grandchild of the shell is not a tool call. You go looking for what leaked and find nothing: the connection was refused before it left the machine, by something the agent had no way to talk to. Then you go looking for the rules that something was enforcing, and realise you have never once read them.

The interlocking does not hear the argument

An old signal box is a room with a row of levers and a man who decides which to pull. Underneath the floor sits a second machine he does not operate: bars and locks, cut so that certain levers cannot move while certain others are over. He can be right, tired, or told something untrue down the telephone, and the answer is the same — the lever for a signal onto an occupied road does not move. The locking does not weigh his reasoning. It is not at his level.

A guardrail written in eBPF sits below the agent in that same sense. It runs in the kernel and watches events the harness never sees: a process starting, a file opening, a socket reaching for the network. Rules attach to those events rather than to the shape of a tool call, so they cover the whole process tree — the helper the agent wrote, and whatever that helper starts in turn. An agent with real agency can always find indirection: a subprocess, a wrapper, a name your parser does not recognise. None of that is an argument the kernel is in a position to hear.

Editing the rule beats defeating the rule

There is a cheaper way past a control than getting around it, which is to change it. Take the ordinary case. The agent works inside a repository, and somewhere in that repository is text instructing it to add a hook to the project’s settings file — code that will run at the next start. Nothing here is exotic. The repository is writable, the file sits in the workspace, and writing files is what the agent does all day. Once that hook lands, an injection has become persistence, and the next session opens with someone else’s code already trusted.

The invariant that stops it is dull and strict: the harness’s own configuration — hooks, skills, MCP servers, instruction files, permission policy — is not writable by the agent, wherever it happens to live. Most systems protect paths outside the workspace and leave the ones inside it, which is where the interesting files now are. An enterprise denylist that a local allowlist or approval can override is a suggestion, not a rule. And a sandbox covering only the shell, while hook execution, file edits and MCP startup happen outside the boundary, has drawn its line around the least interesting part of the run. Egress stays default-deny inside that boundary, with a fresh approval per exception, and credentials arrive task-scoped from a broker.

The proof travels with the decision

One question is still open, and it is the one nobody asks: how do you know the guard is enforcing the rules you wrote. Interlocking gets altered — a new siding, a changed layout — and the work is not finished when the fitter goes home. It is finished when a tester walks the locking table combination by combination, proves that every lock still holds, and seals the frame. The ceremony exists because a filed-down locking dog changes nothing you can see. The levers move as sweetly as before, and the box now permits two routes at once without anything in the room telling you so.

An attested channel is that ceremony, made continuous. The link between the enforcement point and the control plane carries proof of which component is speaking and what state it is in, so a decision arriving upstream is evidence rather than a claim, so a swapped or replayed sensor cannot report success on behalf of one that is gone. Two failures are common enough to name. Gathering kernel telemetry and calling it enforcement, with no rule ever wired to block anything, leaves you an excellent record of what happened to you. And writing rules so broad that legitimate work trips over them ends, every time, with somebody switching the guard off. That is the environment doing the work, and it only holds while the environment is the one you think it is.

A control the agent cannot argue with is not enough. You also have to prove it is the control you wrote.