An agent authenticates cleanly, sends a prompt with no PII and no injection patterns, calls a tool it’s legitimately connected to, and exfiltrates compensation data on its way out. Three control planes signed off. Each was individually correct. The combined outcome was still wrong because the three planes never compared notes.
The three-control-plane taxonomy for AI security is converging across the field: content inspection between client and model, tool brokering between agents and the MCP ecosystem, runtime authorization between agents and privileged actions. That map is now widely shared. The question worth asking is no longer what the three categories are. It’s whether, in your stack, they ship as one decision path or as three vendors stitched together with dashboards. If you can’t answer that confidently, this post is a checklist for figuring it out.
What each plane sees on its own
Quickly, because the field already knows this:
- The content plane sees the prompt and the completion. Not the identity chain, not the entitlement, not the sequence of actions across a session.
- The tool plane sees the connection between agent and tool. Not which records inside the tool the agent’s role should expose.
- The authorization plane sees the request and the actor. In isolation, not what the content plane just detected, and not which tools the broker has currently sanctioned.
These views are individually accurate. The compensation-exfil case is what happens when three accurate views sum to a wrong call.
Multiple vendor products stiched together
Three failure modes when the planes are three vendors
Most enterprise AI security architectures will end up with three control planes from three vendors integrated through some mix of dashboards, webhooks, and batch syncs. The integration breaks in the same three places regardless of which vendors you pick. Each one is worth auditing in your own stack right now.
1. Identity reconciliation. All three planes need to agree on who the agent is, who the agent acts on behalf of, and what the delegation chain looks like at this hop. If identity is canonicalized differently across the products, different URI shapes, different freshness semantics, different ways of representing delegation, the reconciliation logic between them is where attacks find purchase. An identity context that is true in plane A and stale in plane B is a vulnerability dressed as a feature.
Audit question for your stack: is the agent’s full identity (URI, delegation chain, scope at this hop) byte-for-byte identical across all three planes at the same point in time, or do the planes each resolve identity separately? If the answer involves dashboards, it’s the second one.
2. Detection signal hand-off. When the content plane flags a prompt injection at 14:32:01.243, the authorization plane should see that as elevated risk on the decision it makes at 14:32:01.418 in the same session. Two products with two separate event buses means the authz plane is making decisions blind to half the context that just arrived. The “shared telemetry plane” pattern most vendors propose is fine for forensics. It is not fast enough for the next request.
Audit question: are content-plane detections available as policy inputs (Cedar attributes, OPA inputs, whatever your engine consumes) on the next request in the same session, without an out-of-band callout? If detections show up only in a dashboard, the policy engine is blind.
3. Policy state drift. Policies evaluate over entities: the agent, the tool, the sanctioned tool registry, the user the agent acts for. If the tool registry lives in one product and the policy engine lives in another, the engine is evaluating yesterday’s view of the world. A tool that got delisted at 09:00 is still callable until the next sync at 09:15.
Audit question: when an admin disables a sanctioned tool, what is the time-to-deny at the policy engine? Anything other than “the next request” is a window where the policy engine and the tool registry disagree, and attackers learn that window.
The hard case: multi-hop delegation
This is where three-vendor architectures fail most visibly, and where the architectural shape, one fabric or three boxes, materially decides the outcome.
An orchestrator agent delegates to a sub-agent which delegates to a tool-calling agent which invokes a privileged API. Each hop is individually valid. By the time the privileged call happens, the token’s lineage may be technically correct but contextually over-privileged: the accumulated scope across the chain exceeds anything the original principal was authorized for.
If identity, policy, and detection live in three products, the chain context loses fidelity at each integration boundary. Tokens get re-issued, scopes get widened to “make things work,” lineage stops being queryable two hops back. By hop four nobody can reconstruct what the original user actually consented to. Every published agentic-security incident analysis you’ll read in the next twelve months will land somewhere on this curve.
Scope enforcement integration across steps
The architectural properties that actually fix it are concrete and worth demanding regardless of which vendor you buy:
- Scope intersection enforced at the issuer, not advisory at the policy decision point. At every hop, the sub-agent’s granted scopes must be the intersection of what it requested, what its parent was granted, and what its own policy permits. If intersection is “checked later by the authz layer,” it can be skipped under pressure.
- One identity context shared across all three planes. Detection signal, tool registry state, and authorization decisions evaluated against the same canonical agent identity, with the same view of the delegation chain.
- Queryable lineage. You can ask the identity service “show me the full chain that produced this token” and get an answer, not stitch it together from four log sources after an incident.
- Mission-scoped revocation. When you find an over-permissioned chain, you can kill the whole tree from one call, not chase JTIs across four products.
Use those as a vendor-question checklist. If your current stack can’t deliver them, that’s the architecture conversation worth having before the next agent ships.
Existence proof
This shape is buildable. At Highflame we ship it as the Agent Control Fabric (content and runtime authorization in one Cedar policy engine), MCP Gateway (tool brokering against the same policy engine and identity context), and ZeroID (the identity backbone, RFC 8693 token exchange with scope intersection enforced at every hop, mission-scoped cascade revocation, queryable delegation graph). ZeroID is Apache 2.0; the chain-of-custody properties are something you can verify by reading the integration tests rather than trusting a data sheet. The product is one example of the architecture, not the point of the post.
Three questions for your own stack
- When the content plane flags a risk on request N, does the authorization plane see it on request N+1, in the same session, without an out-of-band integration?
- When an agent’s token gets re-issued at hop two of a delegation chain, is scope intersection enforced at the issuer, or is it advisory at the policy decision point?
- When you need to revoke an over-permissioned chain, can you revoke it by mission, or do you have to chase JTIs across four products?
If the answer to any of those is “we coordinate that through a dashboard,” the architecture is a three-vendor stack pretending to be a fabric. The pretense is what attackers learn to navigate first.
