Identity Isn't Intent
The request was perfectly authenticated. A scoped token for the agent, a signed session for the human behind it, a delegation chain linking the two. Every credential checked out. And the action it carried, cancel the policy, move the funds, forward the file, was one nobody had asked for.
That gap is what the next few years of agentic architecture are about. We spent a decade making machine identity rigorous, and it mostly worked. Identity is close to a solved problem. Intent is not, and intent is where the attacks have moved.
The two things you can replace
Draw an honest picture of a mature agentic enterprise and two of the boxes turn out to be commodities.
The first is the caller. A web UI, an autonomous agent, a nightly batch job, a partner API, an internal system: draw them as peers, because that is what they are. The agent is one caller among many, not the system itself. The caller decides what should happen. It gets no privileged path to how. That is exactly what makes callers disposable. Swap the driver and the capability underneath does not move.
The second is the model. The frontier pool churns on a monthly cadence now, and any architecture diagram that names specific models is stale within a quarter. That is not a flaw in the diagram. It is the whole point. The models are the volatile layer. Whatever is durable in your stack is not one of them.
If the caller and the model are both replaceable, then the durable thing lives somewhere else. It lives in the governance, and good governance answers three questions in a strict order. Who runs it. Was it actually asked for. Is the effect allowed. Miss the middle one and the other two give you a false sense of safety.
Two control planes, and the seam between them
You cannot make a language model deterministic. So stop trying, and wrap it instead. Put a deterministic control plane in front of the model to govern how it thinks, and a second one behind it to govern what it does. The non-deterministic part sits in the middle, bracketed on both sides.
The design rule underneath both planes is the same. Enforce every guarantee below the caller, never inside the prompt. Anything a clever reword can undo was never a control. It was decoration.

Plane 1 governs the thinking
The first plane is the AI gateway. It sits between your applications and the model providers, and it answers the first question: who runs it.
Its job is unglamorous and essential. Route each request to the cheapest model that can do the job, weighing capability, latency, risk, and data residency. Enforce guardrails against prompt injection and data leakage on the way in. Govern tokens and cache aggressively, because semantic caching is the single largest cost lever you have. One 2026 engineering reference puts disciplined routing at a 40 to 85 percent cut in spend. Attribute cost, observe everything, and fail over across providers when one degrades.
This is the first trust boundary. The model runs inside the gateway and cannot reach past it. That containment is the point. A plane that only routes and caches is useful, but do not confuse it with governance of the action. It has not looked at the action yet.
Plane 1.5 is the seam nobody draws
Here is the layer the common gateway picture leaves out, and it is the current frontier.
Machine identity is largely handled. You have standards for the human principal, scoped tokens for the agent application, and signed delegation chains that link them. The problem is that identity is not intent. Tools validate credentials. They do not validate whether a human ever asked for this specific action. A prompt injection can produce a request where every token is valid, every scope is correct, the delegation chain is intact, and still nobody asked. Security writers have started calling this the confused deputy problem after the identity fix, and the Cloud Security Alliance now treats it as a first-class class of attack on autonomous agents.
The seam is where you close that gap, and it enforces four things.
Two identities per request. Every call carries the human principal and the agent application, not one standing in for the other. You lose the whole game the moment the agent becomes an anonymous superuser acting on vague authority. I wrote about that failure mode in Who Issued the Agent?
Intersection permissions. The effective permission is the user set intersected with the agent set, never the union. The union is the confused deputy hole, the exact place where an agent with broad scopes acts for a user who lacks them. The intersection rule is simple to state and easy to violate under deadline. It is the same lesson as When Everything Is Privileged, Nothing Is, applied to a second identity.
Purpose binding and action classification. Bind the action to a declared purpose, then classify it. Read or write. Reversible or irreversible. Which value tier. A read against a catalog and an irreversible transfer of funds should not clear the same gate.
Continuous authorization with tamper-evident receipts. Re-check at the moment of action, not once at session start, and emit a verifiable record of the decision. A recent arXiv paper on deterministic pre-action authorization intercepts every tool call before execution and evaluates it against declared policy in a median of 53 milliseconds. Under permissive policy, social-engineering attacks in its test set succeeded 74.6 percent of the time. Under a restrictive pre-action policy, the reported success rate was zero across 879 attempts. The seam is cheap. Skipping it is not.
Plane 2 governs the doing
The second plane is the stable business asset: a capability, expressed as a process API. Something like cancel_policy(...), reachable as an MCP tool, a REST endpoint, or an event, which are three renderings of one underlying capability, not three separate integrations.
The capability runs mostly deterministic steps, with judgment scoped to the single step where the business allows discretion, a retention offer, say, and nowhere else. Beneath it sits a bar of non-negotiable invariants: authorization, idempotency, state integrity, compensation through sagas, and an audit trail. Agents retry chains, so every side-effecting action has to be idempotent. Multi-system processes fail partially, so they have to be compensable.
This is the second trust boundary, and it is the one that lets you sleep. The invariants sit below every caller. A jailbroken model, a hallucinating agent, a malformed partner request: none of them can cross the bar, because the bar does not care who is calling. It answers the third question, is the effect allowed, in code that no prompt can talk its way around.
The injection crosses the seam
Prompt injection is the one genuinely novel attack surface in agentic systems, and OWASP ranks it first for a reason. Its damage mechanism is the hand-off between planes.
An instruction absorbed in Plane 1, where the model reasons over whatever text it was fed, becomes a fully authorized tool call in Plane 2, where actions execute. It inherits the operator’s authority on the way down. Any channel the agent reads is a vector: an inbox, a support ticket, a retrieved document, the output of another tool. Worse, it compounds. A compromised agent can seed instructions into artifacts, a package, a repo, a shared note, that later poison other agents, crossing organizational boundaries with no human in the loop at each hop. The arXiv work on authorization propagation in multi-agent systems makes the case plainly: identity governance has to be treated as infrastructure, evaluated continuously and enforced at every interaction boundary, not checked once and trusted thereafter.
This is why the two planes cannot be governed in isolation. Plane 1 guardrails and Plane 2 invariants have to share purpose and threat context, and the seam between them is where the chain breaks. It is the one place you can ask, deterministically and at the tool-call boundary, whether anyone actually asked for this. A human-shaped approval gate will not do it, for reasons I got into in The Gate Was Built for a Human.
Where most enterprises land
Locate yourself honestly. The ladder has five rungs.
Level 0. Applications call model SDKs directly. No plane, no governance, nothing to answer.
Level 1. A proxy or gateway gives you one API, failover, and spend tracking. That is integration, not governance.
Level 2. Routing on cost and quality, semantic caching, observability. This is the clean AI gateway diagram everyone draws, and it is where most enterprises sit today.
Level 3. Governed identity: standardized human and agent identity, per-agent credentials, intersection permissions, injection guardrails. Now you can answer who.
Level 4. Purpose-bound and dual-plane: pre-action authorization, tamper-evident receipts, and invariants shared across both planes. Now you can answer whether anyone asked.
Almost no one ships Level 4. That is not a gap to be embarrassed about. It is the reason Level 4 is worth building.
The part you can’t pip install
Here is the strategic turn. The gateway itself is commoditizing. LiteLLM, Portkey, Bifrost and others are open source and largely interchangeable, and the distinction between an AI gateway and an MCP gateway is already becoming a checklist item rather than a moat. So the durable advantage is not the gateway product, and it is not governance in the generic sense of routing, caching, and logging. All of that is a dependency you install.
The moat is the purpose-bound authorization policy, the evaluations that keep it honest, and the enforced invariants that answer whether anyone asked for this action. Encoded once, below every caller, and shared across both planes. That is the part you cannot pull from a package registry, because it encodes your specific business, your risk appetite, and your regulatory posture. It survives every monthly model release and every gateway swap, which is precisely what a commodity layer cannot claim. It is the same argument I keep coming back to in You’re Renting the Model. Own the Harness.
What I don’t have a clean answer for
I am not going to pretend Level 4 is a solved recipe, because it is not, and the honest part is where it gets hard.
Intersection permissions are clean math. You take two sets and you keep the overlap. Purpose binding is not clean math. A declared purpose is, in the end, a string the caller supplies, and a good injection can supply a plausible one. Classifying actions by reversibility and value tier is straightforward until you hit the actions that are cheap individually and catastrophic in aggregate. And the evaluations that are supposed to keep an authorization policy honest are, industry-wide, immature. I have not shipped a full Level 4 stack, and I do not know anyone who has. What I am confident about is the shape of the problem and the order of the three questions. The seam belongs on the diagram whether or not any of us has perfected what goes inside it.
Do not buy a moat. Encode one. The caller is replaceable and the model is replaceable, but the governance that answers who ran it, whether anyone asked, and whether the effect is allowed is the one asset that compounds while everything around it churns.
If this resonated, read Judgment Is the New Moat, on why discernment is the durable advantage when execution gets cheap, and Banks Don’t Need Another Agent. They Need a Context Layer., on the other half of what regulated institutions own.
Find me on X @orestesgarcia or LinkedIn /in/setsero.