"We told the agent not to" and "we can prove it didn't" are two very different claims. Most teams only have the first one.
"AI agent governance" gets used to describe at least five different technical mechanisms, and in our conversations with teams evaluating Matimo Workbench, we keep running into the same pattern: a team believes they have governance because they have one of these five, and it's often the weakest one on the list. That's not a criticism. It's a genuinely confusing space, the vocabulary is new, and most of these mechanisms are useful. The problem shows up later, usually in front of a security reviewer or an auditor, when "governance" turns out to mean a sentence in a system prompt.
We think it's worth being precise about what each layer actually does, what it doesn't, and where the real gap tends to sit. We're not neutral here (Matimo is built around one of these layers specifically), but the taxonomy itself isn't a sales pitch. Every layer below has a real, legitimate role. The question that matters is which one your stack is missing.
The five layers
1. System prompts and instructions. The most common form of "governance" in production today, because it costs nothing to add: a line in the system prompt telling the model what not to do, or under what conditions to ask first. It's genuinely useful for shaping tone, style, and general behavior. What it isn't: an enforced control. It's a request to a probabilistic system. Prompt injection research over the last two years has repeatedly shown that instructions embedded in a system prompt can be overridden by adversarial content the model encounters mid-task: a malicious webpage, a poisoned document, a crafted email the agent is asked to summarize. Even without an adversary, models simply don't follow instructions with 100% reliability. There's no log that proves the instruction held. If an auditor asks "how do you know the agent didn't do X," a system prompt is not an answer.
2. Network and infrastructure containment. Firewalling egress traffic, VPC-scoped credentials, sandboxed execution environments, ephemeral containers. This layer is real engineering, and it matters: it's your blast-radius control if something does go wrong. But it's coarse-grained by design: it governs where an agent's process can reach and what it can technically touch, not what it's trying to do once it's there. A network policy that allows traffic to the Slack API can't distinguish an agent reading a public channel from one posting to #all-hands, because both are the same permitted destination. Infrastructure containment answers "how far could this have gone wrong," not "was this specific action supposed to happen."
3. Identity and access control (RBAC). Who (which user, which service account, which agent) is allowed to touch which systems at all. This is necessary and most mature engineering orgs already have some version of it. But it's typically provisioned once, at setup time, not evaluated per action. RBAC can tell you an agent is allowed to use the Gmail integration in general. It can't tell you whether this specific email, right now is a normal reply or a bulk send to your entire customer list: both are "using the Gmail integration" as far as RBAC is concerned.
4. Output and content filtering. Scanning what the agent produced (a message, a document, a generated file) for PII, toxicity, policy violations, before it's shown to a user or sent externally. Useful, and worth having. Structurally, though, it's after the fact: it catches a bad output once it exists. For anything that isn't reversible (an API call that already fired, a record that's already been deleted, a payment that's already gone out) filtering the output doesn't help. The action already happened before there was an output to filter.
5. Execution-time policy governance. This is the layer evaluated at the moment a tool call is about to run. Is this specific action, by this specific agent, right now, allowed under policy? And if it's high-risk, does a human need to approve it before it executes? Not a request to the model, not a perimeter around the environment, not a post-hoc scan. A gate, in the execution path, that can actually block. This is the layer that can answer the auditor's question. The answer isn't "we told it not to." It's "here is the policy that evaluated this exact call, here is who approved or denied it, and here is the timestamped log."
Why the gap matters more than it used to
None of the first four layers are wrong to have. Most serious deployments should run several of them together: network containment and RBAC as blast-radius limits, system prompts for behavior shaping, output filtering as a last-mile check. The mistake is treating any combination of those four as equivalent to the fifth. They're not redundant with execution-time governance; they're defense-in-depth around a gap that only execution-time governance actually closes.
That gap is also, increasingly, not optional. The EU AI Act's human-oversight requirements for high-risk systems were due to apply from August 2026, but the EU's Digital Omnibus (Regulation (EU) 2026/1744) pushed that date to December 2, 2027, with embedded high-risk systems now due August 2, 2028; the general-purpose AI provisions and the Article 5 prohibitions are already in force, unaffected by that delay [1]. California's SB-833 (a bill requiring human oversight of AI used in critical infrastructure) passed the state Senate 36–0 in 2025 and has been under Assembly committee review since [2]. Read either of those literally: "a human has to be able to intervene in what this system does." That's not a claim a system prompt can satisfy, and it's not a claim a firewall rule can satisfy either. It requires something evaluating the specific action, with a human able to step in before it completes.
Where Matimo sits across this stack
To be specific about our own claim rather than vague about it: execution-time governance ships in Matimo OSS, free and open source, in every Workbench install. That includes tool risk classification (low/medium/high/critical) and human-in-the-loop approval for anything above low risk. That's the baseline, and it's not gated behind a paid tier. A lot of platforms treat any form of policy enforcement as an enterprise add-on; we don't think the base layer of "can this action be blocked before it runs" should be a premium feature.
Matimo Governance is a paid package on top of that baseline, for teams that need the enterprise-specific controls. That includes agent-level policy gates (the full execution gate: agent identity, lifecycle status, spawn-depth limits, custom YAML policy rules), Shadow Mode (see what would be blocked before you ever block anything), Emergency Stop, one-click SOC2/HIPAA/GDPR compliance evidence exports, and SSO/SCIM identity federation. If Community-tier governance is "can this action be blocked," Enterprise is "can I run this at organizational scale, prove it to a regulator, and kill it instantly if something goes wrong."
The comparison, plainly
| Layer | What it controls | What it misses | Enforced or advisory? |
|---|---|---|---|
| System prompt / instructions | Model behavior, tone, stated intent | Can be overridden by adversarial input or simple model error; no proof it held | Advisory |
| Network / infrastructure containment | Where the agent's process can reach | Intent within an allowed destination | Enforced, but coarse |
| RBAC / identity | Who can use a system at all | Per-action risk within an authorized system | Enforced, but static |
| Output / content filtering | What the agent produced, after generation | Irreversible actions that already executed | Enforced, but after the fact |
| Execution-time policy governance | This specific action, by this agent, right now | None | Enforced, before execution, with an audit trail |
Where we'd push back on ourselves
None of this makes execution-time governance sufficient on its own. A policy engine that only evaluates tool calls still depends on network containment to limit what's reachable in the first place. It also still benefits from a well-written system prompt, which reduces how often something risky gets attempted at all. We'd rather say that plainly than imply Matimo replaces the other four layers. It doesn't, and a vendor claiming otherwise should get the same skepticism we'd apply to anyone else's marketing.
What we're confident about making the sharper claim on: if the only layers in your stack are the first four, you don't have a way to stop a specific bad action before it happens. And you don't have a record proving what your agents actually did versus what you told them to do. That's the layer worth checking for, whatever you end up building or buying to fill it.
If you want to see what execution-time governance looks like in practice, Matimo Workbench is generally available at matimo.ai. The policy engine and HITL approval are there from the free tier up. If you're further along and evaluating this for a team that needs the compliance and identity layer on top, Matimo Governance is the place to look, or contact us directly.
PS: We reused the regulatory citations from our last post on purpose rather than reaching for new numbers to sound more thorough. They're the same two data points, still accurate as of this writing, and we'd rather cite something twice correctly than cite something once loosely.