An Agentic Control Plane occupies a distinct layer in the AI stack. It complements — not replaces — your existing infrastructure.
Tools like Portkey, LiteLLM, and OpenRouter focus on model selection and load balancing — routing prompts to the cheapest or fastest LLM provider.
An ACP doesn't choose which model to use. It sits between the LLM and your backend to enforce who can use it, what they're allowed to do, and whether the request complies with your policies. LLM gateways optimize cost and latency. An ACP enforces trust and control.
Use both: Route through your LLM gateway for model selection, then through your ACP for identity, policy, and audit.
LangChain, CrewAI, AutoGen, and similar frameworks help you build agents — defining tool chains, memory, reasoning loops, and orchestration.
An ACP doesn't build agents. It governs them. When your LangChain agent calls a tool, the ACP verifies the user's identity, checks authorization policies, enforces rate limits, and logs the action. The agent framework decides what to do. The ACP decides whether it's allowed.
Use both: Build your agent with any framework. Route its tool calls through your ACP for control.
Kong, Apigee, and AWS API Gateway handle HTTP traffic management — routing, rate limiting, TLS termination, and basic auth.
Traditional API gateways don't understand the three-party problem. They can verify a token, but they can't bind LLM-forwarded requests to the originating user. They can rate-limit by IP, but not by verified user identity. They can log requests, but not attribute AI actions to specific people with policy context.
Use both: Your API gateway handles TLS, global rate limits, and routing. Your ACP handles identity binding, per-user policies, and AI-specific control.
Sandboxes — Docker and gVisor, micro-VMs, cloud execution environments, and the sandboxes built into coding harnesses — contain where agent code runs: an OS boundary around files, processes, and network on one host.
A sandbox has no opinion about actions made with valid credentials through legitimate channels. The agent that merges the wrong PR, emails the wrong customer, or deletes cloud resources with your own key does all of it through channels the sandbox correctly lets through. An ACP sits at the tool-call and model-call seam and decides each action by policy — allow, ask, or deny — with the decision logged and the cost metered.
Use both: the sandbox bounds the unauthorized — exploits, runaway code, filesystem blast radius. The ACP decides the authorized. Run the agent inside whatever sandbox you like, with the control plane in its call path. Why they compose →
Okta, Auth0, and Entra now issue identities and credentials to AI agents — agent SSO, short-lived scoped tokens brokered at connection time, discovery and revocation of agents across the enterprise.
That layer decides whether an agent should hold a credential. It never sees the tool call the credential is used for — a routine update and a prompt-injected destructive write carry the same valid token, in the same granted scope. An ACP sits one layer later, on the runtime call path, and decides each action by policy — allow, ask, or deny, on the tool and its arguments — with the decision logged. Its audit trail records actions, not authentications.
Use both: Your IdP establishes who the agent is; that identity flows into the ACP as the verified principal on every call. One issues the badge, the other watches the hands. Where the identity plane ends →
Some platforms bundle control into a single model provider's ecosystem — identity, policy, and audit that only work with their models.
An ACP gives you one control layer for all of them — OpenAI, Anthropic, Google, Mistral, open-source, or your own fine-tune. Same identity binding, same policies, same audit trails, regardless of which model is behind the agent. Deploy in minutes, not months, with no vendor-specific deployment team required.
Why it matters: Your team already uses multiple models. Your control shouldn't break when you add another one.
You can build identity and control yourself. Here's what that looks like compared to using your IdP's built-in features or adopting an Agentic Control Plane.
| Capability | DIY (roll your own) | IdP only (Auth0 Actions, etc.) | Enterprise agent platform | Agentic Control Plane |
|---|---|---|---|---|
| JWT verification | Manual JWKS setup | Built-in | Built-in (single vendor) | Built-in |
| Per-tool scope enforcement | Custom middleware | Limited | Built-in (single vendor) | Declarative allowlists |
| User context injection | Manual header mapping | Not available | Built-in (single vendor) | Automatic |
| PII detection & redaction | Not included | Not included | Varies | Built-in — detection on Free, redaction as a policy you enable |
| Budget & rate limiting | DIY Redis | Not included | Platform-scoped | Per-user, cost-aware |
| Audit trail | Custom logging | Auth logs only | Built-in (single vendor) | Structured, per-request |
| Time to production | Days to weeks | Hours | Months | Minutes |
| Capability | LLM gateway | Agent framework | API gateway | Enterprise agent platform | Agentic Control Plane |
|---|---|---|---|---|---|
| Model routing & fallback | Yes | No | No | No | No |
| Agent orchestration | No | Yes | No | Single vendor only | No |
| TLS & global rate limiting | Some | No | Yes | Platform-managed | No |
| Three-party identity binding | No | No | No | Single vendor only | Yes |
| Per-user policy enforcement | No | No | Limited | Single vendor only | Yes |
| PII detection & redaction | No | No | No | Varies | Yes |
| Per-user budget & spend caps | No | No | No | Platform-scoped | Yes |
| Agent runaway prevention | No | Some | No | Single vendor only | Yes |
| Identity-attributed audit trails | No | No | Generic logs | Single vendor only | Yes |
| MCP / Apps SDK native support | No | Partial | No | Proprietary SDK | Yes |
| Model-agnostic control | No | No | No | No | Yes |
| Self-serve setup | No | Yes | Yes | No | Yes |
ACP is a hook in the agent harness plus a gateway that records every tool call and applies your rules before it runs. The harness plugins are open source, MIT licensed.