What a Governance Toolkit Cannot Do (From Its Own Docs)
A runtime governance layer, like Microsoft's open-source Agent Governance Toolkit, is one of the most useful things to appear in the agent stack. It intercepts every tool call, decides against a written policy whether the action may fire, and records the verdict in a tamper-evident log. To its real credit, the project also publishes an honest list of what it does not do. That list is worth more than any review, because it defines the work that is still yours.
However, the moment a governance layer is in place, it invites a dangerous assumption: that the threat model is now covered. It is not. A governance layer is necessary and not sufficient, and treating "necessary" as "sufficient" is how a well-defended-looking system leaves its real gaps open.
The mistake is to buy a lock for the front door and stop thinking about the windows.
It governs actions, not intent
A tool-call gate sees the action, not the reasoning behind it. So it will not catch a hallucinated fact once that fact is passed into an action the agent was allowed to take. It will not reliably stop a malicious instruction that was smuggled in, hidden inside content the agent was told to read. And it cannot see that ten individually harmless actions, each correctly allowed on its own, add up to one harmful plan.
Those are not bugs. They are the boundary of what a per-call gate can do. Catching them needs different layers: a taint boundary that keeps untrusted input from ever becoming a privileged instruction, a dual-model pattern that separates the component reading untrusted content from the one allowed to act, and workflow-level analysis that looks at the sequence, not just the step.
It runs inside the same trust boundary as the agent
By design, an application-level governance layer lives in the same process as the agent it polices. Which means an attacker who fully compromises the agent can, in principle, walk straight past the guard.
That is the correct place for policy enforcement, and it is also why policy enforcement is not the same as isolation. Real containment needs a boundary the agent cannot reach around: least-privilege identities per agent, short-lived credentials with nothing static to steal, sandboxed execution, and an egress allow-list. The gate decides what is permitted. The sandbox decides what is possible even when the gate is bypassed.
Default-allow is a configuration cliff
Switched on with no policies loaded, the default action is to allow everything. Run it in a permissive mode without realizing it, and every agent is effectively ungoverned while the dashboard looks green.
This is the failure that passes a change board. The layer is present, the box is ticked, and the rulebook is empty. Governance that defaults to allow is governance you have to actively earn, every time, with policy that someone wrote on purpose and tests that prove it is loaded.
It logs what it was handed, raw
The audit system records tool-call parameters as it receives them. If a call carries personal data, a credential, or a token as an argument, that value can land in the log verbatim. A tamper-evident record of your secrets is still a record of your secrets.
Redaction, classification, and a data path that keeps regulated material out of the log are not the toolkit's job. They are yours, and in a regulated environment they are not optional.
The audit records the attempt, not the outcome
The log captures that an action was permitted and passed to the outside world. It does not verify that the action succeeded, and it cannot tell you whether permitting it was right. It is evidence of a decision, not evidence of a good decision. The judgment behind the policy, and the accountability for the result, sit outside the record entirely.
Necessary, and not sufficient
Put the limitations together and the shape of the real system becomes clear. A governance layer is one control among several, and the ones it cannot provide are exactly the ones that separate a demo from a system a regulator will accept.
| The layer gives you | You still need |
|---|---|
| Per-call policy verdicts | A taint boundary and dual-model isolation for injection and hallucination |
| Enforcement in-process | A sandbox and least-privilege identity for real containment |
| An audit trail | Redaction and a data path that keeps secrets out of it |
| A record that an action was permitted | A human accountable for whether permitting it was right |
So the question to bring to your next architecture review is not "do we have a runtime governance layer?" Have one. It is which of its stated limitations are we covering with another layer, and which are we quietly hoping will not matter? The honest answer to that question is your actual security posture. The toolkit told you where its edges are. Whether you build past them is the whole job.
If you want to map a governance layer to the layers that have to surround it, book a meeting.