What is an agent control plane?

An agent control plane is another name for an agentic control plane — the governance layer that sits between AI agents (LLMs, copilots, MCP clients) and your backend services. It verifies user identity, enforces access policies, detects sensitive data, applies per-user rate limits, and produces audit logs for every AI-initiated action. The terms 'agent control plane' and 'agentic control plane' refer to the same architectural pattern.

How is an Agentic Control Plane different from an API gateway?

API gateways like Kong and Apigee manage HTTP traffic — TLS, load balancing, global rate limits. They operate in a two-party model where the caller is the user. An ACP is designed for the multi-party model where the caller is an LLM or subagent acting on behalf of a user. The ACP propagates verified human identity through the agent layer, enforces tool-level authorization, and produces compliance-grade audit trails. Most teams use both.

How is an Agentic Control Plane different from an LLM gateway?

LLM gateways (Portkey, LiteLLM, OpenRouter) sit between your application and the model provider, optimizing model selection, cost routing, and failover. An Agentic Control Plane sits on the opposite side — between the model and your backend services. They solve different problems at different points in the request flow. An LLM gateway picks which model answers the question. An ACP decides whether the user is allowed to ask it and whether the data is safe.

How is an Agentic Control Plane different from an agent framework?

Agent frameworks (LangChain, CrewAI, AutoGen) provide the orchestration layer — tool chains, memory management, reasoning loops, multi-step planning. They determine what actions an agent should take. An Agentic Control Plane determines whether those actions are permitted, and enforces that across every hop in a delegation chain.

When do I need an Agentic Control Plane?

The clearest signal is the transition from AI pilot to production. Pilots work with shared API keys and test users. Production requires knowing which person triggered each request, enforcing different access levels per role, protecting sensitive data from reaching third-party models, capping spend per user, and maintaining audit trails that satisfy HIPAA, SOC 2, and GDPR. If your AI agents are taking real actions — not just generating text — governance becomes a prerequisite.

How does an Agentic Control Plane handle agent-to-agent communication?

When agents delegate to other agents, the ACP propagates the original user's identity through the entire delegation chain. Each agent receives a scoped, time-limited credential derived from the originating identity. Trust boundaries are enforced at every hop — a downstream agent can only access what the upstream agent is authorized to delegate. The full chain is recorded in the audit trail.

What identity providers work with an Agentic Control Plane?

Any provider that supports OpenID Connect and issues RS256-signed JWTs with a discoverable JWKS endpoint. This covers Auth0, Okta, Microsoft Entra ID, Firebase Auth, AWS Cognito, Keycloak, PingIdentity, and Google. The ACP verifies tokens against the provider's public keys — protocol-level compatibility, not vendor-specific integration.

Do I need an agent control plane for MCP?

Yes. The Model Context Protocol defines how LLMs discover and call tools, but has no built-in user identity or access control. An agent control plane adds the missing governance layer — verifying who is calling each MCP tool, enforcing per-user permissions, scanning for PII, and logging every tool call with identity attribution.

What Is an Agentic Control Plane?

Q: What is an Agentic Control Plane?

An Agentic Control Plane is the identity and governance layer for AI agents and the agents they call. Every tool call across every delegation chain is identified, authorized, and auditable — via OAuth/JWT identity, role-based access policy, PII detection, per-user spend limits, identity-propagating routing, and immutable audit. It governs the trust boundary regardless of framework, model, or client.

An Agentic Control Plane (ACP) — also called an agent control plane — is the identity and governance layer for AI agents and the agents they call. It sits between your AI clients (ChatGPT, Claude Code, Cursor, CrewAI, LangGraph) and your backend services, so every tool call across every delegation chain is identified, authorized, and audited.

Think of it as the IAM layer for agents.

AI doesn’t make calls. It makes chains of calls.

A user asks Claude Code to review a PR. Claude delegates to a security subagent. The subagent runs a SAST scan. At depth three, a tool call hits your repo. Without governance across the chain, identity is dropped at the first hop, scopes widen, and your audit log is a row that says api_key=sk-shared.

That’s what an ACP fixes — governance that survives the graph.

● Human

Alice

github.* · slack.* · jira.*
budget $5.00

◆ Agent

PR Reviewer

github.pr.*
budget $5.00 (narrowed)

◆ Subagent

Security Scanner

secrets.scan
budget $1.00 (narrowed)

■ Tool

sast.run

x-user-uid: alice
ALLOW · 2.3s · $0.14

CHAIN · d=3 · root=auth0|alice · tool=sast.run SCOPE NARROWED 3× · ROOT IDENTITY PRESERVED

Each hop inherits a narrower slice of the user’s permission. Every call carries verified root identity all the way to the tool. Audit reconstructs the whole chain.

What an ACP does: six gates, every call

Every call in the delegation chain — no matter how deep — passes through all six governance gates, in order. None skip.

/ 01

Identity

RS256 JWT verified against your IdP's JWKS on every hop.

/ 02

Safety

PII scan and secret redaction on input and output.

/ 03

Policy

Deny by default. Scopes and ABAC per call, narrowed per hop.

/ 04

Usage

Rate and budget caps per user, per workspace, per tier.

/ 05

Routing

x-user-uid propagated. SSRF guard on outbound calls.

/ 06

Audit

Structured, immutable log. Streams to your SIEM or ours.

What goes wrong without one

Shadow AI

Shared API keys passed around Slack. No idea which user made which request. When something breaks, no way to trace it.

Data leakage

SSNs, PHI, and access tokens flow into LLM prompts unchecked — straight to a third-party model with no record.

No audit trail

"Who accessed patient data through the AI last Tuesday?" If the answer is "we don't know," SOC 2 fails.

Runaway cost

One agent loop, 10,000 calls, a month's budget gone overnight. Request counting isn't cost control.

Where it fits in your stack

User

SSO / OAuth

→

LLM Runtime

ChatGPT, Claude, agent framework, MCP

→

Agentic Control Plane

Identity · Safety · Policy · Limits · Routing · Audit

→

Your Backend

APIs · DBs · tools

Not an LLM gateway. Portkey, LiteLLM, and OpenRouter choose which model answers. An ACP decides whether the user is allowed to ask.
Not an agent framework. LangChain, CrewAI, AutoGen decide what an agent does. An ACP decides whether it’s allowed.
Not an API gateway. Kong and Apigee manage HTTP traffic. An ACP propagates verified human identity through the AI layer and produces identity-attributed audit trails.

Use all of them. They solve different problems at different points in the request flow. Full comparison →

How identity actually flows

The user authenticates with your IdP (Auth0, Okta, Entra ID, Firebase — any OIDC provider) and receives an RS256-signed JWT:

{
  "sub": "auth0|8f3a2b1c9d4e5f6a",
  "aud": "https://api.yourapp.com",
  "scope": "tool:crm:read tool:jira:write",
  "org_id": "org_acme_corp",
  "exp": 1739145600
}

The ACP verifies the signature against your IdP’s JWKS, extracts the user, checks scope, scans for PII, enforces budget, and routes to your backend with identity injected.

Without an ACP, your backend gets:

POST /api/crm/contacts
Authorization: Bearer sk-shared-api-key-for-everyone

No user identity. No scopes. No way to filter per user.

With an ACP, your backend gets:

POST /api/crm/contacts
x-user-uid: auth0|8f3a2b1c9d4e5f6a
x-user-scope: tool:crm:read
x-user-org: org_acme_corp
x-request-id: req_7f8a9b0c
x-chain-depth: 3
x-chain-root: auth0|8f3a2b1c9d4e5f6a

Verified identity. Scoped permissions. Tenant context. Full chain provenance. SELECT * WHERE org_id = $1 works again.

When you need one

You’re moving an AI pilot to production and shared API keys aren’t going to cut it
You’re in healthcare, finance, legal, or government — and audit is a legal requirement
Your agents take real actions: create tickets, modify records, process transactions
You use multiple AI clients (ChatGPT, Claude Code, Cursor) and need one consistent governance layer across them
Your LLM spend is surprising you, and per-API-key limits aren’t enough

Get started

Create an agent in the console →

Fastest path. Sign in, create a workspace, build your first governed agent from the browser.

One-line install →

Install the ACP hook into Claude Code, Cursor, or Codex CLI in 30 seconds.

Self-host the full pipeline →

All six governance layers as MIT-licensed npm modules. Deploy anywhere, no account required.

Background: where this category started — the three-party problem

Traditional web apps have two parties: a user and a backend. Authentication is solved. Access control follows. AI apps introduced a third party — the LLM runtime. The user authenticates with the LLM, the LLM calls your backend with a shared API key, and the backend has no idea *who* made the request. Identity is severed. Every governance failure in production AI systems traces back to this. We call this the **three-party problem**: user, LLM, backend — and identity has to flow across all three. It's the clearest framing for *why* the governance layer needs to exist. The delegation-chain framing above is the same idea, extended: when an agent calls another agent, identity has to flow across every hop, not just the first one. Three-party trust is the foundation; delegation chains are how it scales. For the longer write-ups, see [agent-to-agent governance](/agent-to-agent) and [agent delegation chains](/what-is-an-agent-delegation-chain).

Agent delegation chains — the authorization primitive behind chain-of-calls governance
Agentic data plane — the execution layer, distinct from the governance layer
MCP control plane — the MCP-specific specialization
Agent identity — how individual agents are identified
Three-axis governance — tool / agent / user ABAC model
Reference architecture — the six composable modules in detail

Get started → · Agent-to-agent governance → · Reference architecture → · GitHub →