# What a gateway can actually enforce: intent, side effects, and where the tool call really runs

A common objection to putting a control plane in front of an agent is that a gateway only sees what the model intended, not the side effect, because the tool runs inside your own process. That is right about observability and wrong about enforcement. Here is what each enforcement point can stop, and what it cannot.

# 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.

---

*Related: [The three planes](/three-planes) · [What is runtime authorization?](/what-is-runtime-authorization) · [Agent identity vs. agent control](/identity-plane-vs-control-plane) · [What is an Agentic Control Plane?](/what-is-an-agentic-control-plane)*