What a gateway can actually enforce

There is a specific objection to putting a control plane in front of an agent, and it is worth answering directly because it is the reason many teams decide to build their own.

Stated plainly, it goes: the irreversible action happens inside your process after the model returns, so a gateway sees the model’s intent, not the side effect, and therefore cannot stop anything.

The premise is accurate. The conclusion does not follow.

A tool call is a message before it is an action

Every agent framework works the same way underneath. The model returns a response containing a structured block that names a tool and its arguments. Your loop reads that block and dispatches it. The Anthropic API calls it tool_use. The OpenAI API calls it tool_calls. Your code turns it into a function call, an HTTP request, a database write.

The important part is the order. The refund is not issued when the model decides to issue it. It is issued when your dispatch code runs, several steps later, after a message has crossed the network.

That gap is where enforcement happens. A proxy in the request path reads the response before your loop does, removes the offending block, and forwards the rest. Your dispatch code is never handed the call, so there is nothing for it to execute. The gateway did not observe a refund and disapprove of it. It removed the instruction while the instruction was still just text.

This is the difference between a proxy that observes and a proxy that enforces. Both sit in the same place. Only one is permitted to change what comes back.

What each enforcement point covers

Two places can decide, and they fail in different directions.

At the model boundary. Every call the model asks for passes through, regardless of which framework or harness the agent runs in. It works where the agent exposes no hook at all, and it cannot be disabled from inside the agent, because the agent is not the thing making the decision. What it cannot see is anything the model was never asked about.

At your dispatch point. An in-process check sits where your code turns a decision into an effect, so it also covers calls your application makes on its own, retries in your own loop, and paths the model never touched. What it gives up is independence. It runs inside the process it is controlling, which means it can be bypassed by whoever controls that process.

Neither is a superset of the other. A team that only wants to stop the model from doing something reckless can use one. A team whose auditor asks whether the control can be switched off from inside the application needs to think about both.

The honest limits

A control plane at the model boundary controls what flows through it. Anything routed around it is not covered, and no page should claim otherwise. In practice that means three things worth checking in your own deployment.

Coverage is a deployment property, not a promise. If some agents call the model API directly and others go through the proxy, only the second group is covered. The gap is silent unless something is watching for it, which is why coverage belongs on a dashboard rather than in a design document.

A decision layer is software, and software has defects. Any layer that classifies commands can be presented with an input it classifies wrongly. Treat a policy layer as one control among several, not as a boundary that makes other controls unnecessary.

Enforcement and approval are different problems. Stopping a call is straightforward. Holding a run open while a human decides, then resuming it hours later in a different process, is the genuinely hard part, and it is where most teams that build their own spend their time. Be skeptical of any tool, ours included, that treats the second problem as a footnote to the first.

Why this keeps coming up

The confusion is reasonable, because the word gateway covers two products that do opposite things.

Most LLM gateways are cost and routing layers. They exist to fail over between providers, cache responses, and attribute spend. They read the traffic and pass it along unchanged, by design, because altering a response would be a bug in that product. If that is the category you have in mind, the objection is exactly right: those gateways see intent and prevent nothing.

A control plane is in the same position on the wire and has the opposite mandate. It is there to decide. The position was never the limitation.

Does an LLM gateway only see the model's intent, not the actual side effect?

It sees the intent, and that is enough to stop the side effect, because the side effect has not happened yet. A tool call starts life as a tool_use block in the model’s response. A proxy that removes that block before the response reaches your agent loop means your dispatch code never receives the call, so it never runs. The gateway does not need to see the refund to prevent the refund; it needs to see the instruction to refund, in flight, before your code acts on it.

Then why do people say a gateway cannot enforce?

Because it is true of a gateway that only observes. An LLM proxy used for logging, cost tracking, or tracing reads the response and forwards it unchanged, so it records intent after the fact and prevents nothing. The difference is not where the gateway sits, it is whether it is permitted to alter the response. Enforcement requires the proxy to be in the request path and to modify what comes back.

What can a model proxy not see?

Anything the model did not ask for. Code paths your application executes on its own, background jobs, retries in your own dispatch layer, and any tool a second agent invokes through a different route are all invisible to a proxy on one model API. That is the real limit, and it is the reason an in-process check exists alongside it.

Do I need both the proxy and an in-process check?

They cover different gaps. The proxy controls every call the model asks for, including in harnesses that expose no hook, and cannot be turned off by a flag inside the agent. An in-process check sits at your own dispatch point, so it also covers calls your code makes without asking the model. Deployments that need both run both, and the audit trail is the same either way.

Run agents? ACP lets you see, control, and price every tool call they make — allow/ask/deny policy, per-session cost, and a full audit log for Claude Code, Cursor, Codex, and OpenClaw, in one command:

curl -sf https://agenticcontrolplane.com/install.sh | bash

Getting started → · see your first governed call → · free up to 5 agents · prefer fully on-device? add --local