Skip to content
Agentic Control Plane

What Is an Agentic Control Plane (ACP)?

An Agentic Control Plane (ACP) — also called an agent control plane, and what some teams still call agent governance — is the layer that sits in the call path between an AI agent and the tools it uses. Every tool call the agent makes is checked against your rules before it runs, priced, and recorded, across every harness and framework you run: Claude Code, Codex, Cursor, CrewAI, LangGraph and the rest.

See this on your own agents in about a minute — one command adds it to Claude Code, Codex, Cursor, and the other harnesses you run:

curl -sf https://agenticcontrolplane.com/install.sh | bash

No account? Add --local and every decision stays on your machine. Full getting-started guide →

Think of it as the permission system your agents would have if they all shared one.

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 control 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 — control 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: record, learn, control

Three things, on every call, in every harness.

/ 01
Record
Every tool and model call, in order, with its cost, latency, the decision, and the identity behind it. Audit-only by default: everything runs and is logged until you write a rule.
/ 02
Learn
Any row becomes a standing rule in one click. Agents propose rules from the denials they hit; you confirm them. New workspaces start in shadow, so nothing blocks until you switch to enforce.
/ 03
Control
Allow, ask, or deny per tool, per tier (interactive, subagent, background), per person. Budget caps that halt a run. Each agent's declared tool surface, one click to deny what it never uses.

Underneath those three: identity (a workspace key for coding agents; the end user’s IdP token on the framework path), PII detection on every call, rate and budget limits, and a structured, queryable audit log. Every hop in a delegation chain passes through the same checks.

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
Record · Learn · Control
→
Your Backend
APIs · DBs · tools

For coding agents the plane is a hook inside the harness plus the gateway it reports to; for framework agents it is an SDK wrapper around your tools plus a proxy in front of the model. Same rules, same audit trail, one console.

  • 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 flows on the framework path

When your agent runs inside an app you built — CrewAI, LangGraph, the Anthropic or OpenAI SDKs — ACP can verify the end user’s token and carry it through to your backend, so a tool call is attributed to a person rather than a shared key. Coding agents on a laptop don’t need any of this: they are identified by their workspace key and agent identity. For the framework path, the flow is:

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 run a coding agent for hours a day and can’t say what it did, what it could have done, or what it cost
  • You’re about to let an agent run unattended, and the checks you rely on live in a prompt
  • Your agents take real actions: create tickets, modify records, push code, process transactions
  • Every team ships in a different harness or framework and there is no one set of rules across them
  • Your model spend surprises you, and per-key limits can’t tell you which agent or which step
  • You’re in a regulated industry and need an identity-attributed record of every call

Get started

One-line install →
One curl registers the hook in Claude Code, Codex, Cursor and the other harnesses you have. Free up to 5 agents; your first audit row in about a minute.
Run it on-device →
Add --local: no account, decisions on your machine, every call logged to a file. What each mode writes, file by file.
Framework SDKs →
Wrap your tools with one decorator in CrewAI, LangGraph, the OpenAI or Anthropic SDKs; init() prices the model calls.
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 control 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 control 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 control](/agent-to-agent) and [agent delegation chains](/what-is-an-agent-delegation-chain).

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