Sit in on a security review for a team shipping its third or fourth agentic feature and you'll hear a version of the same question. It is rarely hostile. It is usually just a person whose job is to know things asking to be shown something simple.
"Walk me through every place one of these agents can take an action in a production system. And for each one, show me what's checking it before it goes out."
The room gets quiet, but not for the reason you'd expect. The team isn't worried about whether the agents work. They work. The problem is the answer to the question, which is some version of: it depends which feature you're asking about.
The refund agent guards itself from the inside: a budget check wired directly into the function that issues the refund. The ticketing agent, shipped six weeks later by a different engineer, puts its limits in the framework — a human-in-the-loop interrupt that pauses for approval on the two or three actions someone thought to flag. The contract agent has the thinnest cover of all: a couple of conditionals inside send_for_signature(), plus a line in the system prompt — always get human sign-off above $50k — which is not a check at all. It is a request, made to a model that decides, run to run, whether to honor it. Each path out to the world was built by whoever needed it, in the shape the deadline allowed.
There is no single place to stand and watch. There are a dozen places, and each one is governed exactly as well as the person who wrote it happened to make it that day.
A dozen doors is the same as no door
The instinct, when you've shipped a few of these, is to harden each integration. Add the budget check to the refund path. Add the external-domain block to the email path. Add the human approval step to the contract path. This feels like progress, and locally it is.
But step back and look at the property you actually want. You don't want most agent actions to be checked. You want a guarantee that no action reaches a production system without passing through evaluation. Those are very different claims, and the gap between them is exactly the surface a security review is trying to measure.
Scattered checks can never produce that guarantee. They produce coverage that is high on a good day and unknowable on any day. The honest answer to "is every action governed" becomes "every action we remembered to govern is governed," which is not an answer a CISO can take to an auditor, and not an answer that survives the next feature shipped under deadline by someone who didn't know the convention.
A dozen doors, each with its own lock and its own diligence, is functionally the same as no door at all. The blast radius of your agents is defined by the weakest path, not the average one.
"Choke point" sounds like friction. It is the opposite.
The word is unfortunate, because to an engineer "choke point" sounds like a bottleneck — the thing you spend your career designing around. For throughput, that instinct is right. For governance, it is exactly backwards.
A governance choke point is the single, mandatory place every action passes through on its way out. Not a place actions can pass through. A place they must, with no alternative route, because there is no code path from "the agent decided" to "the external system changed" that does not go through it first.
This is the oldest move in infrastructure. An API gateway works because backend services stop implementing their own auth and rate limiting — the gateway absorbs work that was otherwise duplicated and inconsistent everywhere. An identity provider works because there is one place that answers "who is this," instead of a login form per application. The value isn't the feature. The value is the singularity: one place that does the work, so the rest of the system can stop pretending to.
Agent actions need that same singularity, and they need it more than a traditional API client ever did — because of who is on the other side.
The caller is the reason scattered checks fail
You could argue, fairly, that point-to-point integrations have always been governed by inline checks and the world hasn't ended. Deterministic clients have run that way for years.
That instinct is half-right, and worth taking seriously. The difference is the caller.
A deterministic API client calls the endpoints a human wrote, in the order the human wrote them, with arguments the human chose. Its blast radius is the code. If you've reviewed the code, you've reviewed the behavior.
An agent is none of those things. It decides what to call, when, and with what arguments, and those decisions drift with the prompt, the model version, the tool descriptions, and the last thing a user said. Two runs of the "same" agent are not the same run. Which means it will, eventually, find the path you didn't think to harden — the integration that shipped before the convention existed, the edge that the inline guard didn't anticipate. The agent isn't malicious. It's just exploring a space larger than the one you checked.
Scattered governance assumes you can enumerate the paths that matter. A non-deterministic caller is precisely the thing that violates that assumption.
A tool gateway is not yet a governance one
The ecosystem is already reaching for the singularity, and it's worth being precise about how far it reaches. Teams putting MCP gateways in front of their tool servers have the right instinct: one place that decides which tools an agent is allowed to see. That is real progress, and it is the correct shape.
But filtering the tool list answers a narrower question than the one a security review is asking. It governs which capabilities exist for this agent — an authorization question, settled once, at connect time. It does not govern whether this specific action, with these specific arguments, should happen right now — and that question only has an answer at the moment of the call, when the amount, the counterparty, the running total for the month, and the reversibility of the thing are finally known.
What one mandatory step actually buys you
Collapse the dozen doors into one and the security review stops being a survey and starts being a single question with a single answer.
Every action is evaluated exactly once, against the same four orthogonal questions: who is asking and in what context, what does this specific action mean, can the organization afford the consequence, and how bad is it if this goes wrong. Identity, semantic, fiscal, risk. All four must pass; none compensates for another's failure. There is no fast path that skips the evaluation, because the evaluation is the kernel of the system, not middleware layered politely on top.
When an action is too risky to allow outright, the same step pauses it and routes it to a human — not as a separate workflow bolted onto one integration, but as a state every action can enter. Approval isn't a feature of the refund path. It's a property of the boundary.
And every one of those decisions — the intent, the verdict, which rules fired, what executed — is written once to an append-only record that is never altered. When the auditor asks "show me every action and what checked it," there is one ledger to read, not a dozen log formats to reconcile.
Most quietly: when the rule changes — a new spending limit, a new restricted counterparty, a new approval threshold — you change it in one place and it governs every agent and every action at once. With scattered checks, a policy change is a migration across every integration that happened to implement the old rule, and a silent gap everywhere one didn't.
The honest version of the thesis
You cannot govern a probabilistic actor with code review and good intentions distributed across a dozen integrations. Code review governs the code. The agent is the part that isn't the code.
Governance has to be a place — one mandatory step between intent and consequence, that every action passes through, that evaluates before it permits, that can stop and ask a human, and that writes down what it did. Not the strongest of your dozen doors. The only door.
That is what a choke point is, when the word is used correctly: not the thing that slows the system down, but the one place disciplined enough that everything above it gets to be loose. It is the difference between "every action we remembered to check" and "every action," and only one of those is a sentence you can say to a regulator.
The boundary is going to need that single step in every serious agentic system. We are building it.
Key takeaways
- You don't want most agent actions checked — you want a guarantee that none reach production unchecked. Scattered checks can only ever deliver the first.
- A non-deterministic caller will eventually find the path you didn't think to harden, which is exactly why governance can't be enumerated path by path.
- One mandatory step — evaluate once on four axes, pause for a human when risky, record it immutably, change the rule in one place — turns a survey into a single answer.