Scope. Enforce. The Two Primitives of Runtime Governance
In June, we named the mandate: Governance by Design. We said the fix has two moving parts — embedding controls into the agent’s action surface, and enforcing them at runtime. That was correct. It was also missing something a CIO or AI leader could say out loud in a meeting.
Here’s the version that sticks:
Scope. Enforce.
Two words. Scope and Enforce are two primitives, already proven, already non-negotiable — the starting point for governing what an agent actually does, not a whitepaper or a maturity model to roll out over a quarter.
Cloud infrastructure eventually earned a shared, well-architected vocabulary for what “done right” looks like — a decade of hyper scalar operating data bought that clarity. Agent governance doesn’t have a decade. It has these two primitives instead, and they’re enough to act on now.
Worth naming where this is heading: the direction is prevention, not detection. You cannot review your way through what’s coming. You can only decide, in advance, what’s allowed to happen at all. Scope and Enforce are the two primitives underneath that shift.
Everything else in agent governance — identity, guardrails, audit, compliance mapping — either feeds into scoping the action surface or feeds into enforcing it at runtime. That’s what makes these primitives instead of features.
Scope
Scope is not a policy document. It’s a way to bound trust, safety, and authorization before an agent ever acts.
Concretely, it means defining the full set of actions an agent is permitted to take — its action surface — and shrinking that surface until it excludes everything the agent shouldn’t be able to reach, regardless of what it’s told or how it reasons.
Scope does one more thing that matters as much as the boundary itself: it classifies. Every action gets tagged — tool, risk level, compliance regime, reversibility — before runtime. That classification is the input a policy engine needs to make a call without judgment, without waiting on a person, without re-litigating intent in the moment.
Scope doesn’t just restrain. It produces the fact that Enforce acts on.
Enforce
Enforce is the runtime check that holds the boundary on every action, automatically, independent of what the model reasoned its way into.
It looks at what Scope already classified and returns one of three verdicts: ALLOW, BLOCK, or ESCALATE. Decided in the moment. Based only on what was already scoped. No re-evaluation of the model’s reasoning — because the model’s reasoning was never the thing being governed.
Why the model is the structural problem
Guardrails are necessary. Enterprises expect them, and they should — identity checks, permission scoping, data controls, prompt-injection defenses. All of it belongs on the model side of the line.
It’s also not enough on its own, and the reason isn’t a failure of any particular guardrail. It’s structural. The model is not infallible. Instructions can be ignored. Instructions can be weaponized. Guardrails that live inside the model’s own reasoning can be talked around, because the thing doing the talking-around is the same reasoning the guardrail is supposed to be checking.
And the same property that makes a model useful — its capacity to find a path to a goal — is the property that lets it find a path nobody authorized. You don’t get the upside of agency without the downside of excessive agency. Both come from the same fact: the model was never going to be infallible, and architecting as if it might be was always the actual risk.
PocketOS showed the first half of that — an autonomous coding agent, an over-scoped token, a production volume and its backups gone in seconds. Codex showed the second half — no sudo access, and a helper agent that found a local Docker group socket anyway and used it to escalate to root. Different failure, same structure: the model did something nobody authorized, because nothing outside the model’s own reasoning was checking.
There will be more agent incidents. That’s not pessimism. It’s the design assumption everything downstream of this post depends on.
The math that makes Enforce non-negotiable
IBM puts next year’s average enterprise agent count above 1,600. Assume a conservative 10 actions a day per agent. That’s 16,000 agent actions a day, at one company, every day.
There is no team, no shift rotation, no dashboard-watching headcount that reviews 16,000 decisions a day. That’s not a warning. It’s a division problem you can do right now, and it has exactly one answer: the check has to be a machine, running at runtime, every time.
What this looks like end to end
(See diagram)
An agent proposes an action. The model reasoned its way there — inside whatever guardrails were wrapped around it: identity, permissions, data, prompt. Whatever comes back, clean or weaponized, routes through the same door.
That action then hits Scope, which already classified it, and Enforce, which checks that classification against policy and returns a verdict — allow, block, or escalate — without re-opening the model’s reasoning.
Guardrails govern the model. Scope and Enforce govern the action. One is necessary. Only one is deterministic.
That’s the difference enterprises are actually asking for. They don’t extend trust to a wire transfer, a contract signature, or a production deploy on faith — every one of those runs through an approval chain and an audit trail. Agents are being asked to meet the same bar already required of employees: not “we trust you,” but “we know exactly what you can and cannot do, and we can prove it after the fact.”
Where this goes next
Governance by Design named the mandate. Scope and Enforce are how you execute it — the first two primitives, not the last two.
This is the first post in a series on what runtime governance actually requires. More primitives, more of the architecture, coming next.
LangGuard.AI — Runtime Governance for Autonomous Agents