The Control Plane for AI Agents: The Architecture Behind the Hype

‍Key Takeaways

• "Control plane for AI agents" has become a catch-all that every vendor bends toward whatever they already sell. Underneath the noise is a real architecture: the part of the system that decides, kept separate from the part that moves.
• Governing agents in production is three control problems, not one: identity (who is acting, with what authority, on whose behalf), observability (what happened, and whether it was any good), and security (what is allowed, and stopping what isn't).
• Enforcement attaches to live traffic at the agent gateway, the one point in the request path that can hold, redact, or block a call. You cannot enforce a policy on a request you never saw.
• The three planes only become a control plane when they run as one loop over a shared, identity-keyed record. Three separate tools won't reconcile at the one moment it matters, an audit or an incident.
• The layer that judges and attests to agent behavior cannot belong to the vendor that builds and runs the agents. Regulators have called self-certification insufficient for more than a decade.

Section I: Defining the Control Plane

Enterprises are putting AI agents into production faster than the controls around them are maturing. This guide is about the architecture that closes that gap: the AI control plane. We will cover what a control plane actually means, where it comes from, and the agent gateway, the one point in the request path where control physically attaches.

Chapter 1: Everyone is Claiming the Control Plane

Sometime in the last year, "the control plane for AI agents" went from a phrase nobody said out loud to one on nearly every vendor's keynote slide. Microsoft ships Agent 365 and calls it a control plane [1]. GitHub previews one inside its enterprise product [2]. Databricks points at Unity Catalog [3]. Forrester made it an official market category in December 2025 [4]. When a term catches on this fast, it has usually stopped meaning anything specific. That is what happened here, and it matters, because there is a real architecture underneath the phrase and it is getting buried under the marketing.

The trouble is that "control plane" already means something precise in the tradition it is borrowed from: the part of a system that decides, kept apart from the part that moves. Vendors bolt the phrase onto whatever they were already selling, a registry, an identity broker, an orchestration runtime, a telemetry dashboard, and it quietly swells to mean "governance, broadly." When "control plane" can describe any product, it no longer tells you what to build or what to buy.

So this guide defines it narrowly: governing agents in production is not one control problem. It is three.

What is allowed, and how do we stop what isn't?

Each plane has decades of prior art behind it, and each one breaks in a new and specific way the moment the actor is a probabilistic agent and the payload is natural language. On its own, not one of the three governs anything.

None of the interesting engineering lives inside any single plane. It lives in the shared record of the three planes write to and the loop that ties them to the request path. 

This guide also builds toward a second, sharper argument: the part of the architecture that judges whether an agent behaved acceptably, and signs its name to that judgment, cannot belong to the same vendor that builds and runs the agents. Not for competitive reasons. Because the regulators who matter have said for more than a decade, in writing, that certifying a model you built and profit from does not count as certifying it at all [5].

Identity without enforcement is a login page for an attacker. Observability without identity is an anonymous crash log. Enforcement without observability is a firewall with the lights off.

Chapter 2: Where The Term Comes From and Where It Breaks

The phrase “control plane” comes from networking. In a router, the control plane is the software that decides where each packet should go; the data plane is the hardware that forwards packets at full speed once the decision is made. Keeping the two apart is the whole point of the design: the deciding layer can be complex and slow, because the moving layer stays simple and fast.

When cloud software took over in the Kubernetes era, it inherited the same split, and the service mesh made it explicit. In Istio, the most widely used mesh, a central brain called istiod works out identity, policy, and configuration, while a fleet of proxies called Envoy sits in the request path and carries those decisions out [6]. The proxies never decide anything. The control plane decides; the data plane binds that decision to live traffic.

The timing rhymes too. Docker made containers trivial in 2014, sprawl hit by 2016, and Kubernetes imposed order. Agents are on the same road, faster: Gartner predicts an average Fortune 500 enterprise will have over 150,000 agents in use by 2028, up from fewer than 15 in 2025 [7]. You build the control plane before the sprawl gets away from you.

Where The Analogy Breaks 

Envoy's decision is a lookup: is this connection allowed, yes or no. The agent gateway's decision is a judgment: was the model's answer faithful to the source document, does this tool call quietly leak data, is the instruction the model is about to obey from the user or from a poisoned web page it just read? The traffic is language, the agent doesn't behave the same way twice, and none of it can be written into a rules table ahead of time. That one difference is why evaluation and scoring, a whole discipline of its own, has to live inside the control plane. It is also what eventually forces part of the control plane to be independent.

How Analysts Define the Control Plane

Forrester splits the agentic stack into a build plane, an orchestration plane, and a control plane that inventories, governs, and assures agents across vendors [4]. "Assures" is the verb that matters: governing and enforcing are things you do to your own agents, while assuring means proving to someone else, a regulator or an auditor, that an agent behaved acceptably. That is the hardest job in the stack. Futurum puts the division of labor even more crisply: agents decide, control planes govern, execution environments enforce, systems generate evidence [8]. The short version: the control plane is where the enterprise decides who may act, judges whether the action was acceptable, and keeps the proof. Everything downstream either follows those decisions or is measured against them.

Chapter 3: The Agent Gateway: Where Control Attaches

The gateway is the proxy that all of your agents' model and tool calls pass through. The first generation of these products, the LLM routers of 2024, did three useful things: they spoke a common API format so you could swap model providers, they spread load across those providers, and they tracked spend. All of that is table stakes now, and none of it is a control plane.

From LLM Router to Agent Gateway

A gateway that can act as a control point needs four capabilities the router never had:

1. Speaks the agent protocols (the Model Context Protocol, or MCP, for tools; A2A for agent-to-agent) deeply enough to inspect them
2. Enforces tool-permission decisions on the routed path, not in an advisory log
3. Emits agent-shaped telemetry to an OpenTelemetry collector, not proprietary logs
4. Is independent enough of the model provider to sit in judgment of the model's output

By early 2026, companies running agents at scale had converged on the gateway as the control point. Uber routes tens of thousands of agent executions a week through an MCP gateway that scrubs PII before anything reaches an external model [9]. That scrubbing step is the giveaway: once you're stripping sensitive data before it leaves your systems, the gateway is no longer just routing traffic. It has become the place where data-governance policy actually gets enforced. Amazon, Docker, Kong, and Solo.io all built their gateways to the same design without coordinating, which is usually a sign the design is right.

Three Ways Into the Request Path

How the gateway enters the request path decides what the control plane can ever see:

What the Gateway Doesn’t See: Raw Tool Traffic

A gateway watching model traffic sees the model decide to call a tool, and it sees the text the model wrote. What it does not automatically see is the tool channel itself. That channel carries the actual call sent over MCP, the full list of parameters that went with it, and the unvetted content the tool hands back. Several of the ugliest attacks live there, and covering it is real engineering work, not a configuration setting. Any vendor claiming total coverage while only watching model outputs is overclaiming. The honest claim is narrower. Model outputs are covered today, the raw tool channel is next, and here is the plan to get there.

You cannot enforce a policy on a request you never saw. The gateway is the physical precondition for everything else.

Section II: The Three Planes: Identity, Observability, and Security

With the gateway in place, the question becomes what runs on top of it. The next three chapters walk through the three planes. Each covers what the plane does, where it comes from, and how it breaks once the actor is an unpredictable agent working in natural language.

Chapter 4: Plane One: Identity - Who Is Acting, With What Authority, On Whose Behalf

Identity is plane one because the other two planes depend on it. A record of what happened is worthless if you can't say who did it. A decision to block an action is meaningless if you can't say whose authority it was checked against.

The scale of the problem is easy to put numbers on:

• Machine identities, the service accounts, API keys, and workload credentials that software runs under, already outnumber human ones by 109 to 1 — yet only 15% of organizations count a machine identity with sensitive access as "privileged" [13].
• OWASP, the group that catalogs the industry's most common security risks, published a Non-Human Identity Top 10 in 2025 because the failures had become predictable, including overprivileged identities, long-lived secrets, and sloppy offboarding [14].
• One study found tens of millions of leaked machine credentials sitting in public code repositories, and most of the older ones still worked [15].

Agents inherit all of these problems, then create three new ones that existing identity systems were never designed to handle:

This is what agents change about identity. A request now has two actors behind it, permissions have to shrink as work moves down a chain, and an agent's name proves nothing on its own. An identity system built for agents has to answer each of these directly. It gives every agent a credential of its own, one that can be revoked and narrowed, separate from any human's. It records both the human and the agent on every request. It shrinks permissions at each handoff instead of passing the full set down. It ties the agent's claimed identity to a signed proof of what was deployed, not a name it gives itself. And it carries the governance context, the real chain of who authorized what and why, across every handoff, so the other two planes have something to attach their records and decisions to.

The standards are filling in fast, which is encouraging and also a warning that nothing here is settled. MCP now uses OAuth 2.1 to authenticate remote tool servers [17]. A2A, the protocol agents use to verify each other, hit a stable 1.0, with agent identities that are cryptographically signed rather than just claimed, and now sits under the Linux Foundation [18]. And in March 2026 the Coalition for Secure AI published a design for agent identity and access management that the industry will likely rally around [19]. Portable agent identity is coming, but anyone claiming they've solved it today is selling a snapshot of a moving target.

Chapter 5: Plane Two: Observability - What Happened, and Was It Any Good

There are two questions hiding inside the word "observability," and running them together is the most common architecture mistake. The first, what happened, is finally getting standardized. For years, every agent framework recorded the same events in its own format, and no two could be searched together. OpenTelemetry, the open standard for software telemetry, started a generative AI group in April 2024 and defined a common shape for agent records: a tree of spans, one timed record for the agent's run and one for each model and tool call, all carrying the same standard fields, like the model's name and the tokens it used [20].

Build on those conventions, with two caveats that keep it honest. The agent-level spans, the ones that describe the multi-step reasoning you actually want to see, are still experimental and off by default. And capturing content is off by default too, for good reason. Turn it on and your records start carrying the actual text of every prompt and response, customer data, PII, and proprietary context included, and your monitoring system inherits a data-governance problem nobody planned for. The fix is to strip the sensitive text before it's stored. But notice what that quietly implies. Someone in your telemetry pipeline is now judging which content is sensitive. Observability has already started bleeding into evaluation, and we haven't even gotten to the second question yet.

OpenTelemetry records that a model returned 1,200 tokens in 850 milliseconds. It has no way to record that those 1,200 tokens contradicted the source document the agent was supposed to be summarizing.

The second question is judging whether what happened was any good. Was the answer faithful to the source document? Did it invent a number? Did it leak something it shouldn't have? Did it obey the user, or an instruction planted in a document it read? Telemetry can't answer any of these, because they aren't measurements. They are judgments about content. Telemetry is observability's data plane. It records what happened and moves on. Evaluation is the layer on top that makes the judgments, and it is the part you actually govern with.

One constraint turns evaluation from a product feature into an architectural requirement. In a regulated environment, scoring has to run where the data already lives. The obvious approach is to send everything to an external judge, meaning the prompt, the documents the agent read, and the response all go out to another model, which sends a score back. 

In a bank, a payer, or an insurer, those prompts and responses carry some of the most sensitive information the company holds, like customer financial records, health histories, and claim details. Sending that to a third party to be scored creates the same exposure the evaluation was supposed to prevent. So the scoring models sit next to the data instead, never phoning home. That requirement is the line between an evaluation architecture a regulated enterprise can deploy and one it legally can't, and it's what the "just send us the data" hyperscalers struggle to offer.

Two more practical problems come with running AI agent observability at scale:

• Volume: A single request to a multi-agent system can throw off hundreds of spans, far too many to keep them all. The working pattern is to keep every error and every slow response and sample the routine successes. Record everything instead, and the observability bill starts governing you.
• Cost: One request fans out across models and tools that each charge differently, so the operational records alone can't tell you what a given agent run cost.

Both are solvable operations problems. The decision that actually shapes the architecture is the boundary, and which side of it you can afford to hand to someone else.

Chapter 6: Plane Three: Security - Deciding What's Allowed and Stopping What Isn't

The threats agents face are not the threats web applications face. OWASP's classic Top 10 catalogs attacks on the web layer, like injection, broken access control, and misconfiguration. Its LLM Top 10 catalogs attacks on territory the old list never imagined, inside the model's reasoning, the documents it retrieves, and the tools it can call [21]. Prompt injection rhymes with SQL injection, and excessive agency with broken access control, but they attack a different part of the system entirely.

Three risks matter most for agents:

• Prompt injection: This is number one on OWASP's 2025 LLM list [21]. The model follows whatever instructions it finds, and those instructions can now hide in images, audio, and files. There is no clean fix, because following instructions is the one thing the model exists to do.
• Indirect injection: The hostile instruction isn't typed by an attacker at all. It sits inside a document the agent retrieves or a result a tool hands back, and the agent trusts everything it reads equally.
• Excessive agency: A confused or compromised agent takes a consequential action because it was handed more authority than the task needed.

These risks stop being abstract the moment agents start using tools. Security researchers have documented at least nine distinct ways to attack an agent through MCP [22], [23]:

• Malicious server code: The tool server itself is hostile from the start.
• Tool-description poisoning: Instructions hidden in a tool's description, which the model reads and the human rarely does.
• Full-schema poisoning: The same trick, hidden deeper in the tool's definition, like its parameter names and field descriptions.
• Output poisoning: Instructions hidden in what the tool sends back.
• Indirect injection through tool results: Hostile content from a third party, like a web page or document, carried back to the model by an honest tool.
• Rug-pull updates: A tool behaves well until you approve it, then turns malicious in a later update.
• Cross-server tool shadowing: A tool on one server impersonates or overrides a tool from another.
• Confused-deputy attacks: The agent is tricked into spending its legitimate authority on an attacker's behalf.
• Session hijacking: An attacker takes over an agent's live session.

Most of these attacks are quiet. In a tool-description poisoning attack, the model reads the hidden instructions and obeys them, while the human who approved the tool saw only a friendly summary. And MCP itself defends against almost none of it. The protocol defines how clients and servers talk, and the locks are left to whoever deploys it.

The way through all of this is a single principle. Enforce your controls outside the model, so they hold no matter what the prompt says. Prompt hardening, telling the model to refuse bad instructions, is a mitigation, not a control, because the model is the thing under attack. The real controls bind at the gateway: filtering inputs before the prompt reaches the model, checking outputs before they reach a user, an authorization layer that decides whether a tool call is allowed independent of anything the model "decided," and human approval gates on the actions that matter most.

Most organizations aren't there yet. In Darktrace's 2026 survey, only 14% let automated defenses act on their own to stop a threat [24]. The rest watch it land after the fact, and that gap is the whole difference between an observability tool and a control plane. If your enforcement is a dashboard alert, the agent has already sent the email.

Section III: From Three Planes to One Control Plane

Identity, observability, and security each come apart once the actor is an unpredictable agent, and on their own they don't govern anything. This section covers how the three planes work as one loop, why the layer that judges agent behavior can't belong to your agent vendor, and the regulation that turns agentic AI governance into a deadline.

Chapter 7: Why The Three Planes Have To Be One Loop

You can buy an identity provider, a tracing tool, and a guardrail product from three vendors and wire them together. Each will see its own slice of the truth, and at an audit or an incident, the slices won't line up. Identity lives in Okta, activity records live in one vendor's system, safety verdicts live in another's, and you end up with three databases holding three different ideas of what "the request" even was.

Who acted, what happened, and whether it was allowed only mean something when they're recorded together, as parts of the same event, tied to the same identity, in one shared record. That record is the spine. "We have observability, identity, and security" is a shopping list. A control plane is what you get when all three work off the same spine.

The connection between the planes also runs in both directions, which makes this a loop rather than a pipeline:

This is why wiring three separate tools together fails. Each tool can produce a perfectly plausible report on its own, and you still can't answer an examiner's question, because the three sets of records don't share an identity and their timestamps don't agree. On one shared spine, the identity, the score, the decision, and the outcome are the same row in the same record.

Chapter 8: Why Assurance Can't Be Self-Owned

Self-certification is a problem much older than AI. Whenever one party builds a thing and also certifies it safe, the builder knows more about the flaws than they disclose, and their incentives point toward shipping. Every industry that learned this lesson responded the same way, with an independent check: the financial audit, the drug trial, aircraft certification. The auditor doesn't work for the CFO.

US banking regulators wrote this into model-risk guidance more than a decade ago. Models must be validated independently of the team that developed them [5]. "Effective challenge" means review by people with the competence, authority, and incentive to find what the builders missed. The April 2026 refresh modernized the mechanics and left the independence requirement untouched [25].

Now map that onto agents. The platform vendors converging on "control plane" own the model, the orchestration runtime, the identity broker, or all three. Their agents make them money, and their evaluators are built by the same org, measured against the same internal targets, shipped on the same release train. So when that vendor's evaluation layer scores that vendor's agent as safe, it produces the one thing regulators spent a decade calling insufficient: a producer grading its own product. The score might even be right. It just carries no independent weight, and independent weight is the whole point once the verdict has to satisfy an examiner, survive discovery, or convince a risk committee whose members are personally on the hook.

This is the problem with the hyperscaler pitch. A company that hands you your model, your orchestration, your identity plane, and your evaluation layer is a bank whose model developers also staff its independent validation function, the exact setup the banking guidance forbids. Size, good intentions, and engineering excellence don't fix it. What makes validation independent is organizational separation from the team that builds and profits, and internal separation, however sincere, isn't that.

The tempting objection is "we bought the model from someone else, so our monitoring of it is already independent." Regulators shut that door years ago. A purchased model still has to be independently validated; buying a component doesn't buy your way out of checking it [5]. The independence that matters isn't between you and the model's original author. It's between whoever asserts the agent behaved acceptably and whoever runs and profits from the agent. If those are the same organization, it's self-attestation, no matter how many vendors sit upstream. In every other regulated industry, this job goes to a third party.

Independent in governance, in-environment in execution. Those two constraints are the entire requirement, and they're why this one layer resists the consolidation every other layer invites.

None of this makes a hyperscaler's offering worthless. The identity plane, the orchestration, the gateway, and the telemetry are real and valuable, and much of it is best built by whoever owns the platform. The claim is narrower. Attesting that an agent behaved acceptably is the one job the agent's operator can't do and have the verdict keep its value. And regulated industries are only where this lands first. The moment any company's agents take consequential action at scale, "who independently verified this?" becomes the question that decides whether the deployment survives its first incident.

Chapter 9: Regulation Is the Deadline

Good architecture doesn't create urgency. Deadlines do. The reason the control plane is moving from the whiteboard to the budget line in regulated enterprises right now is that a stack of overlapping regulations has landed on the same demand. Enterprises must show, with evidence, that their AI systems are governed.

EU AI Act

The EU amended its timeline in mid-2026 [26]. The deadlines now run:

• August 2026: Disclosure requirements for chatbots that interact directly with people.
• December 2026: Transparency and watermarking rules for AI-generated content.
• December 2027: Obligations for high-risk uses, like credit scoring, insurance underwriting, hiring, and essential services.
• August 2028: High-risk AI embedded in already-regulated products.

But none of the core obligations changed. Risk management, technical documentation, event logging, human oversight, post-market monitoring, and conformity assessment all survived untouched. The one to watch is conformity assessment. It's a claim about how a system was governed across its operating life, and it assumes the evidence already exists for the period under review. Start building the evidence layer in late 2027 and there's no operating history to point to. The extra time is for building the instrumentation, not for waiting.

US Banking Supervision 

The April 2026 model-risk refresh kept independent validation and pointedly left generative and agentic AI out of scope, with a request for input [25]. The regulators didn't say agentic AI is unregulated. They said the existing framework doesn't fit it yet and they're writing one, which means the rules are being drafted right now by institutions with a ten-year record of demanding independence and evidence. The safe assumption is that the new framework will demand both.

The Rest of the Stack 

DORA, HIPAA, ISO, and NIST push the same demands from different angles. DORA, the EU's rules for technology risk in financial services, holds firms accountable for third-party systems, the AI in critical operations included [27]. HIPAA and OCR enforcement make health-information exposure a direct liability, which is exactly why the in-environment requirement from Chapter 8 isn't optional in healthcare [28]. ISO/IEC 42001 offers a certifiable AI management system, and NIST's AI risk framework gives procurement and audit teams the vocabulary they increasingly speak [29], [30]. None of these is satisfied by documentation and good intentions. Boil each one down to what an assessor will actually ask for and it comes out the same: who was acting, what did they do, was it acceptable, what did you stop, and can you prove all of it after the fact.

Every obligation maps onto the plane that produces its evidence, and none of that evidence can be pieced together after the fact from three disconnected tools. Each row assumes the shared spine, written in a regulator's words:

Chapter 10: The Reference Architecture: Build vs. Buy at Each Layer

Once all the pieces come together into one buildable stack, the question becomes build versus buy. From the bottom up, you have:

• Your agents, and the models and tools they call
• The gateway, sitting in the request path, the one place enforcement can physically happen
• The three planes, reading and writing the shared spine, with policy flowing down to the gateway and evidence flowing back up
• The independent assurance layer, cutting across everything, running inside your environment

Chapter 11: The Control Plane Is An Architecture, Not A Vendor

Every company that owns a piece of your stack will keep printing "the control plane for AI agents" on its slides, each meaning the piece it already sells. But the control plane isn't a product you buy from whoever owns your infrastructure. It's an architecture.

Identity breaks because the actor is now a machine working on a human's behalf, through delegation chains that leak authority. Observability breaks because telemetry can say what happened but never whether it was any good. Security breaks because you can't enforce a policy by asking the model to comply. Planes that don't share one record hand an examiner three plausible reports and no answer. And the one function that judges and attests to agent behavior can't belong to the party that profits from the agents.

The practical program, in priority order:

1. Put a gateway in the request path: You can't govern traffic you never see. Enforcement that isn't inline is advice.
2. Unify telemetry on one shared spine: Adopting the open standards now is cheap. Retrofitting them at 150,000 agents is not. 
3. Put the evaluation layer above the telemetry, in your environment: "What happened" should always arrive with "was it acceptable," and neither the data nor the verdict leaves your perimeter.
4. Get the attestation from an independent party: The deadlines will not accept a producer certifying its own product.

Build the planes, share the spine, close the loop, and hold the boundary. The vendors telling you to consolidate everything are right about three-quarters of the stack and wrong about the quarter where consolidation destroys the thing you were buying.

The agents are already in production, and the sprawl has started. The rules are written or being written, by people with a long habit of demanding evidence tied to identity, produced continuously, and signed by someone with no stake in the answer. The teams that treat the control plane as an architecture to build will have an answer when the question comes. Everyone else will have a drawer full of dashboards.