A Governor You Can Import Is Not a Boundary

Agent governance is shipping as libraries you load into the agent's own process. That is the one place a control cannot live.

The wedge

Agent governance is arriving as something you pip install. Wrap the agent in a library, hand it a rules file, and every action runs through a validator before it fires. The ergonomics are good and the instinct is right. Agents need a check before they act. But the shape is wrong in a way that decides everything, because the validator runs inside the same process as the agent it is checking. The thing being governed is running the governor. A control the subject can reach is not a control.

We already know this

Security settled this question decades ago and gave it a name. A reference monitor, the component that decides whether an action is allowed, must be three things: always invoked, small enough to verify, and tamper-proof against the subject it governs. The third property is the one that in-process wrappers quietly drop. When the enforcement code shares memory with the code it polices, the subject can rewrite the rule, swallow the verdict, or never reach the check at all. The oldest failure in this family has a name too. The confused deputy is a program tricked into misusing authority it legitimately holds. A governor running inside the agent is a deputy holding the keys in the same room as whatever is trying to take them.

Enterprise governance made the same category error in a different place. Master data management put the authoritative record in a copy and let the copy drift from the world it was meant to describe. The authority lived somewhere it could rot. The lesson learned the hard way was that authority has to be resolved from live sources, not held in a copy the truth moves away from. The imported governor is that mistake pointed the other way. The authority lives somewhere the subject controls.

Why agents make it fatal

For ordinary software the isolation requirement was good practice you could sometimes bend. The subject was deterministic. It did what it was written to do, so a check it could technically bypass usually went uncalled, because nothing in the program tried. Agents remove that assumption. The subject is a model whose behavior is shaped by whatever enters its context, and the two most common failure modes both live inside the process. A prompt injection turns the agent against its own instructions. A compromised tool executes in the same runtime. In both cases the attacker is now on the same side of the boundary as the governor. A wrapper cannot referee a fight it is standing inside.

This is why the recent wave of runtime authorization work pays off only with placement. The field has proved that agent authority has to be decided at the action, against live state, rather than granted once and assumed. That is correct, and on its own it is not enough. A per-action verdict computed inside the agent's process is a per-action verdict the agent's process can forge. Getting the timing right does not help if the decision sits in the wrong place.

The principle: the enforcement boundary

Enforcement is only enforcement if the thing being governed cannot reach the mechanism that governs it. That is the enforcement boundary, and it has a physical meaning. The verdict is computed out of process, in a component the agent does not run and cannot modify, at the point where the action crosses into a real system. The agent proposes. Something the agent cannot touch decides.

Two corollaries fall straight out of it, and both are visible in the tools shipping today. Identity has to be proven rather than asserted. An agent named in a local file, carrying a shared secret, is an identity the process can claim for itself, so the record proves what the process wrote, not which agent acted. Enforcement across a boundary needs a signature the agent cannot mint on another's behalf. The second corollary is that the decision has to run against live state rather than a rules file read at startup. A policy loaded once at boot stops matching the world the moment the world moves, which drops you back into the stale-authority problem that runtime authorization was supposed to close.

What to take from it

For builders, a wrapper is fine as ergonomics and useless as a control. If the honest answer to "can the agent's process bypass this" is yes, the layer is documentation. Put the decision where the agent cannot rewrite it, and let the wrapper be the client that calls out to it, not the place the verdict lives.

For buyers, one question separates a governance layer from a governance library. Where does the decision run relative to the agent, and can a compromised agent process get around it. If the check imports into the same runtime as the agent, a bad prompt or a bad tool is already past it before it runs. Ask for the boundary, not the feature list.

Governance for agents will keep shipping as libraries, because libraries are easy to adopt and easy to demo. Adoption was never the test. The test is whether the thing you are governing can reach the thing that governs it.

A control the subject can reach is not a control. Enforcement lives outside the thing it governs, or it does not live at all.

Cross-link: this piece is the third essay in the runtime-authorization arc, following N° 029 (Detection Is Downstream of Authorization) on the timing requirement and N° 032 (The Authorization Gap Has a Literature Now) on the academic backing for it. Where N° 029 argued that authorization has to be at the action rather than after, and N° 032 named the research that proved it, this piece coins "the enforcement boundary" and argues that timing is necessary but not sufficient: the verdict also has to be computed outside the agent's own process. Extends the placement argument from N° 020 (The Authorization Gap), where the second control point was named. Companion in spirit to N° 030 (A Signature Is Not a Premise) on the signed-record failure mode when the signer supplies the premises. The reference-monitor requirement (always invoked, small enough to verify, tamper-proof) is the standard formulation traceable to Anderson (1972) and Saltzer and Schroeder (1975); the confused deputy problem is from Hardy (1988). No project or specific library is named in this essay; the argument is against the in-process-governance pattern rather than any one implementation. Reciprocal: FederatedIQ enforces the boundary out of process, in a component the agent cannot reach, at federatediq.ai.