Disclosure: BlueBear builds an AI agent control plane, so we have a commercial interest here. The architecture below is described generically; where a specific behaviour is quoted it is from our own gateway source and named as such, and it is offered as one worked implementation rather than as the only correct one.
The short answer: five responsibilities, each with its own boundary and its own record
A control plane — the layer that decides what an agent may do, kept separate from the runtime that does it — is often drawn as a single box labelled "governance". That is not useful for evaluating one. What is useful is the sequence a single agent step passes through, because each stage is a place where a decision is made, a boundary is enforced, and something has to be written down.
| Responsibility | The decision | Enforced where | What must be recorded |
|---|---|---|---|
| 1. Identity | Who is acting, and inside which boundary | At request admission, from the credential — never from a value the agent supplies | Actor, tenant, workspace, credential reference |
| 2. Policy | Is this capability permitted for this actor right now | Before the step, at the same boundary that will execute it | Policy identifier, inputs evaluated, decision, reason |
| 3. Planning | How the step will be carried out — which model, which connection, which constraints | In the control plane, with a bounded time budget | Plan, candidates considered, constraints applied, plan version |
| 4. Execution boundary | Supply the credential and perform the call | At the egress point, holding the credential the agent never sees | What actually ran, the outcome, and whether it matched the plan |
| 5. Evidence | What is retained, in what shape, for how long | Written as the step completes, not reconstructed later | A typed record with a schema version, linked to the run |
An architecture missing any one of these has a specific, predictable failure. No identity: nothing is attributable. No policy at the boundary: the constraint lives in prompt text and can be argued away. No planning record: you cannot explain why a choice was made. No execution record: you cannot tell what actually happened. No evidence contract: you have logs, and logs answer engineering questions, not authority questions.
1. Identity — established from the credential, never from the payload
The first decision is whose request this is. The only safe source is the credential presented at admission: an API key issued to a tenant, a token bound to a workspace. It must never be a field the caller supplies, because an agent that can name its own tenant can name someone else's.
Two properties are worth designing for from the start. First, keys should be issued per boundary rather than per platform, so revoking one customer's access is a local operation. Second, the boundary should travel with the request through every subsequent layer as data, not as an ambient variable that a later refactor can drop. In our gateway, tenant and workspace are explicit columns on the records rather than something derived at read time, which is the difference between "we can filter by customer" and "we can prove separation".
What AI agent identity is covers the plain-language version, and workload identity for AI agents goes deeper on replacing shared secrets.
2. Policy — evaluated at the boundary that executes, not stated in a prompt
This is the single most consequential architectural decision in the whole layer, and it is worth stating bluntly: a constraint written in a system prompt is not a control. The agent constructs its own steps from text, and text can be argued with. A constraint evaluated at the point where the call leaves your system holds regardless of what the agent was persuaded to attempt.
Concretely, that means the tool layer, not the agent, decides which operations are callable. The Model Context Protocol — the open standard for describing a connection and its named operations — makes this tractable, because it turns "the agent has CRM access" into an enumerated set of operations that a policy can be written against. Least privilege for AI agents covers the scoping design, and MCP token security covers why credentials must not pass through to the agent.
Policy evaluation should produce three things, not one: the decision, the reason, and the inputs that were evaluated. A recorded "denied" with no reason is nearly as unhelpful as no record — the reason is what turns an incident into a fix.
3. Planning — bounded in time, and separate from execution
Planning is where the control plane decides how a permitted step will be carried out: which model, which connection, under which constraints. Three design points matter more than the algorithm.
Separate eligibility from ranking from fallback. Eligibility is a governance decision — which candidates are permitted at all, given the residency, compliance and blocked-model boundaries. Ranking is an optimisation decision among the survivors. Fallback is exception handling when the chosen path fails. Collapsing all three into one opaque score makes incident reconstruction and policy review much harder, because you can no longer tell whether a candidate was excluded on policy grounds or simply scored badly.
Bound the decision in time. A control plane that becomes the latency problem has stopped being useful. In our gateway the route planner has a default budget of 750 ms; exceeding it produces a named reason on the record — route_plan_timeout — rather than a silent fall-through. The point is not the number, it is that the number exists and that hitting it is visible.
Make the mode explicit. Ours is off, shadow or active. In shadow, a plan is produced and recorded while execution is unchanged, which lets you evidence a policy change before making it. In active, the planned model is the model the runtime is told to run. Having a mode that records without acting is the single most useful safety property in this part of the design. Shadow-mode routing covers how to use it.
4. Execution boundary — the credential lives here, not in the agent
The execution boundary is the point where a call actually leaves your system. It holds the credential, performs the call, and reports what happened. The agent asks for an operation; it does not receive a secret.
This is what makes permissions revocable and actions attributable. If the agent holds the credential, then revocation is a redeploy, and any record of the action is produced by the same component that took it. If the boundary holds it, revocation is a configuration change and the record is produced by a component with no incentive to be flattering.
The boundary is also where plan and reality get compared. They diverge for ordinary reasons: a model is unavailable, a planner timed out, a fallback fired, a constraint could not be satisfied. A control plane that records only the plan will overstate how governed the system is; one that records only the execution cannot explain it. Record both and record whether they agreed.
5. Evidence — a typed record, written as it happens
The last responsibility is the one that determines whether any of the previous four can be demonstrated afterwards.
Two design decisions dominate. First, records should be typed and versioned rather than free text. A record with a declared contract can be validated at write time and migrated later; a log line can only be read by someone who already knows what to look for. Our own evidence records carry a schema version for exactly this reason — it is the difference between a store you can query in three years and an archive you can grep.
Second, evidence is written as the step completes, not assembled later. Anything reconstructed from provider invoices or application logs after the fact is missing the two fields that matter most: the authority under which the action was taken, and the business outcome it produced. Neither is recoverable, because neither was ever anywhere else.
Taken together, the five records form what is usually called an evidence chain: a linked record that runs from the identity of the requester through the policy, the plan, the approval, the execution and the outcome, with each link pointing at the next. The evidence chain explained walks that sequence properly, and audit trail vs. application logs covers why the logs you have do not substitute.
If you operate in a regulated industry
Specify the record before you specify the features. A useful procurement artefact is a table with one row per field you will need to produce on request — actor, authority, action, decision, artefact, outcome, retention — and a column for how the vendor supplies each. Vendors answer capability questions optimistically and field questions precisely. Security posture evidence for buyers lists the artefacts worth demanding.
If you resell this to customers
Identity and evidence both have to be tenant-scoped, and the second is the one that gets missed. A shared evidence store with a tenant column is adequate only if every read path filters on it and something tests that they do. Multi-tenant isolation for buyers covers the guarantees to ask about, and the enterprise reference architecture places the control plane in the wider picture.
An honest note on scale
Everything above describes implementation, not adoption. BlueBear is early: our platform's lifetime spend is measured in tens of dollars, and we are not going to dress that up as a scale claim. What is real is the machinery — the modes, the timeouts, the typed records, the boundaries — and that is what we think is worth evaluating. If a vendor in this category answers architecture questions with customer counts, that is worth noticing.
Do this next
Take the five-row table at the top of this article and fill in the last column for your own system: what is recorded, today, at each stage. The empty cells are your architecture backlog, in priority order, because a stage that records nothing cannot be governed. Then read what a trail must capture to survive review for the field-level specification, or the vocabulary disambiguation if you are still deciding which layer you are buying.
Questions people actually search for
- what does an ai agent control plane contain
Five responsibilities: identity, which establishes who is acting and inside which boundary; policy, which decides whether a step is permitted; planning, which chooses how the step will be carried out; an execution boundary, which supplies credentials and performs the call; and evidence, which writes a typed record of all of the above. Everything else a product offers is built on those five, and a layer missing any of them is not a control plane.
- how do you separate control plane from data plane in an agent system
By making the decision an input to the execution rather than a branch inside it. The control plane resolves identity, evaluates policy and produces a plan; the runtime receives that plan and carries it out; both events are recorded separately. The practical test is whether you can change a policy and see the behaviour change with no deploy of the thing that does the work, and whether the record shows both what was decided and what actually happened.
- where should authorization be enforced for ai agents
At the execution boundary - the point where the tool call or the model call actually leaves your system - and nowhere else as the sole control. Authorization stated in a system prompt is a suggestion, because the agent constructs its own steps and can be argued out of a suggestion. Authorization evaluated at the boundary holds regardless of what the agent was persuaded to attempt, which is the only property that survives contact with an adversarial input.
- what should a control plane record for each agent step
At minimum: the actor and the boundary it belongs to, the capability requested, the policy evaluated and its result, the plan produced, any approval and who gave it, what actually executed, the artefact produced, and the business outcome. Records should be typed with a schema version rather than free text, because a record with a contract can be validated and migrated, and a log line can only be read by a person who already knows what to look for.
- does a control plane add latency to ai agents
It can, and that is a design constraint rather than an accident. Any decision made before a call adds time to that call. The mitigation is to bound it explicitly: give the decision a timeout, decide in advance what happens when the timeout is hit, and record that it was hit. In our own gateway the route planner has a default 750 ms budget and a timeout produces a named reason on the record rather than a silent fallback, so the latency cost is visible rather than mysterious.