The Agentic Control Plane

Why Securing the Model Is No Longer Enough

For the last few years, most of the conversation around AI security has focused on the model itself: can we prevent prompt injection, filter harmful output before it reaches a user, stop sensitive data from leaking into a response, get the model to behave the way we designed it to. Those are legitimate questions and a lot of good engineering has gone into answering them.

Agents change what's actually at stake. A language model that produces a bad answer is a contained problem: the damage stops at the chat window. A model that can call APIs, invoke MCP tools, modify infrastructure, send messages, create identities, update databases, or trigger downstream workflows is a different animal. The blast radius stopped being a wrong sentence and became whatever the agent happens to be plugged into. The security boundary moved, and a lot of our tooling hasn't caught up with it yet.

A Safe Model Doesn't Guarantee a Safe System

Take a simple agent wired up to a handful of legitimate tools: search_documents(), create_ticket(), send_email(), update_record(). Every one of those tools can be properly authenticated. Every API call can be valid. Every individual action can look completely reasonable on its own, and the outcome can still be wrong. The agent retrieves the right document, pulls out genuinely sensitive information, and emails it to the wrong person. Nothing failed at the API layer. The model didn't generate anything malicious. Every tool did exactly what it was built to do. What failed was the composition of those calls, the order and context they happened in, and that's the part almost nobody is watching for yet.

Agent security stopped being a property of the model somewhere in the last couple of years. It's now a property of the entire execution path: user, agent, model, gateway, tool, API, system. Every hop in that chain adds its own context, its own identity, its own permissions, and often its own trust boundary that the previous hop knew nothing about.

Authentication Is Only the Beginning

Traditional application security is built around one question: can this identity perform this operation? Agentic systems force a second question alongside it: should this operation happen, right now, in this specific context? Those sound similar. They are not the same question at all.

Picture an agent that holds a valid, properly scoped permission to call delete_resource(). From an IAM standpoint there's nothing to flag. The agent authenticated correctly, the tool exists, the identity has the permission attached to it, and the API will happily accept the request. None of that tells you whether deleting this particular resource, because of this particular instruction, on behalf of this particular user, was actually what anyone intended to happen. Authentication answers who can act. Authorization answers what they're allowed to touch. What's missing is a layer that looks at the specific action, in the specific moment, and decides whether it should actually go through.

Layer	Question it answers	In practice
Authentication	Is this really the identity it claims to be?	A signed token verifies the calling agent
Authorization	What is this identity allowed to touch?	The agent's role permits calling delete_resource()
Runtime policy	Should this specific action happen right now?	Deleting this resource, in this context, for this user, matches intent

Building the Control Plane Between Reasoning and Execution

As agents stop being chat interfaces and start acting as genuine participants in your infrastructure, you need a control layer sitting between reasoning and execution. Intent flows from the agent through an agent gateway, into MCP servers and APIs, and only then into infrastructure that actually changes state.

That control plane needs real context to make a decision. Who initiated the action, and which agent is carrying it out. Which tool is being invoked, and which identity is being delegated to make the call. What resource is about to change, and whether this is a read or a write. What the blast radius looks like if the action goes wrong, and whether it still matches the intent the user actually expressed. Whether it needs a human to approve it before anything happens at all.

This is a fundamentally different exercise from inspecting a prompt for bad phrasing. The model can reason about what it wants to do. The tool can execute what it's told. Policy has to govern the transition between the two, and it has to do that with information a prompt filter never sees.

Discovery Has to Come First

There's another piece of this that doesn't get nearly enough attention, and it sits earlier in the chain than any of the policy questions above. Before an agent can safely invoke anything, it needs to know what it's actually talking to. That sounds trivial until you notice how much of agent discovery today is just another LLM guess: the model reads a description, decides a tool looks right, and calls it. Discovery can't stay a probabilistic decision made inside the reasoning loop. I've written before about why security invariants can't live inside a system that's fundamentally stochastic, and discovery is the same argument one layer earlier. Networks solved this decades ago with deterministic mechanisms for finding infrastructure and services. Agentic systems need the same thing: deterministic discovery, deterministic identity, and trust that doesn't depend on the model getting lucky.

Reasoning can stay probabilistic. Discovery shouldn't be. Once an agent has deterministically discovered a service or a tool, the gateway and policy layers downstream can actually reason about what interactions to permit, because they're reasoning about something real instead of something the model believes is real.

Put the pieces next to each other and a shape starts to form. Discovery establishes what exists and where to find it. Identity establishes who's actually involved in the exchange. Authorization establishes what that identity is allowed to touch. Runtime policy establishes what should happen in this specific instance. Observability tells you afterward what happened and why. None of that reads like a feature you bolt onto a model. It reads like infrastructure, because that's what it is.

The Security Model Is Moving Down the Stack

The question the industry has been asking is whether the model is safe. The question that actually matters is whether the agentic system built around it is safe, and that's a much harder thing to answer, because the answer was never sitting inside the LLM to begin with. It's distributed across identity, discovery, gateways, MCP servers, APIs, policy engines, infrastructure, and the specific context in which an action occurs.

None of the next generation of AI security gets solved with a better system prompt, and it doesn't get solved by wrapping another filter around the model either. What it needs is infrastructure that accepts reasoning will always be probabilistic and makes sure execution never is. The model gets to reason freely about what it wants to do. The agent gets to act on that reasoning. But it's the infrastructure underneath both of them that decides what's actually allowed to change, and that's where the real agent security boundary is forming right now.

---

We think about this exact boundary at VeloSecurity AI, the layer between an agent's reasoning and the infrastructure it's allowed to touch. If your team is building agent systems and trying to work out where policy enforcement actually belongs, get in touch.