What is an Agentic Control Plane?
An Agentic Control Plane (ACP) is the identity and control layer for AI agents. It ensures every agent action is **identified** (bound to a real user or agent identity), **authorized** (checked against policies), and **auditable** (logged with identity and context) — regardless of which framework, model, or client you use.
What problem does it solve?
AI agents are proliferating across every tool and framework, but most lack identity, enforced rules, and audit trails. Whether it's a human using an AI client, an agent calling a backend API, or an agent delegating to another agent — without a control layer, there's no way to verify who is acting, what they're allowed to do, or to hold anyone accountable. ACP provides that layer.
One specific manifestation is the **Three-Party Problem** — where identity is lost between the user, the LLM, and your backend. [Learn more about the Three-Party Problem →](/for-teams#problem)
How is this different from agent infrastructure?
Agent infrastructure platforms help you **build and run** agents — they provide frameworks, orchestration, and hosting. ACP is complementary: it provides the **identity and control** layer that sits across all your agent infrastructure. You can build agents with any framework (LangChain, CrewAI, AutoGen, custom code) and ACP controls them all uniformly.
Think of it this way: **ACP is to agents as IAM is to microservices.**
How is this different from an API gateway?
Traditional API gateways (Kong, Apigee, AWS API Gateway) handle HTTP traffic management — routing, TLS, basic rate limiting. They don't understand agent identity, delegation chains, or per-user tool authorization. An ACP handles the AI-specific control layer that API gateways weren't designed for. [Full comparison →](/comparison)
How is this different from an LLM gateway?
LLM gateways (Portkey, LiteLLM, OpenRouter) focus on model routing — choosing the cheapest or fastest provider, handling fallbacks, caching responses. They sit between your app and the LLM. An ACP sits between agents and your backend services. Different layer, different problem. [Full comparison →](/comparison)
I already run my agents in a sandbox — do I need an ACP?
Yes — they answer different questions. A sandbox (Docker, gVisor, a micro-VM, a cloud execution environment, or your harness's built-in one) is an OS boundary around where agent code runs. It cannot see whether an action made with valid credentials was one you wanted — the PR merged, the email sent, the cloud resource deleted with your own key, the $50 model loop. An ACP sits at the tool-call and model-call seam and decides each of those actions by policy, with every decision logged and every call priced. The sandbox bounds the unauthorized; the control plane decides the authorized. Use both: run the agent inside whatever sandbox you like, with the ACP in its call path. [Why they compose →](/blog/sandboxes-and-control-planes)
Can MCP servers inject ads or instructions into my agent's tool results?
Yes — tool responses flow from third-party servers straight into your agent's context, and the model reads them with the same authority as everything else there. Prompt injection is the adversarial version; sponsored content appended by ad SDKs is the commercial one, and both ride the same pipe. ACP filters tool results inline at the seams it already controls — the model proxy's tool-result rewrite and the MCP gateway's output scan. Sponsored matches are replaced with a loud placeholder ('[sponsored content removed by ACP]') rather than silently dropped, every removal is stamped on the request's audit row, and a one-toggle filter list (Policies → Patterns → 'Block sponsored content') covers known ad formats. PII found in the same pass is masked and never collected. [How the filter works →](/blog/ad-blocker-for-tool-responses)
Can agents call other agents through ACP?
Yes. ACP supports **agent-to-agent control** with delegation chains. When Agent A delegates to Agent B, ACP tracks the full chain of trust — who initiated the action, which agents were involved, and what permissions each had. Every hop is audited. Agents discover each other via standard well-known endpoints. [Agent-to-agent deep dive →](/agent-to-agent)
Can I create agents from the console?
Yes. ACP Cloud includes a web console where you can create agents, connect tools, set permissions, and monitor activity — all from your browser with no code required. Every agent created through the console gets identity, policy checks, and audit automatically. The console is the fastest on-ramp, but you can also create agents via the REST API or by pointing your own framework at ACP.
What is the Three-Party Problem?
The Three-Party Problem is a specific identity gap: the user authenticates with an LLM, but when the LLM calls your backend, it forwards a shared API key. Your backend can't tell who the request is for, what they're allowed to do, or who to hold accountable. This was the original problem ACP solved, and it remains a core use case — but ACP now addresses the broader problem: agent-to-agent delegation, console-based agent creation, and one control layer across every framework. [Full explainer →](/for-teams#problem)
Do I need to replace my existing infrastructure?
No. An ACP complements your existing API gateway, LLM gateway, and agent framework. It adds the control layer that none of them provide. You can adopt it incrementally — start with identity verification and add policy enforcement, rate limiting, and audit logging over time.
What is GatewayStack?
GatewayStack is the open-source reference implementation of the Agentic Control Plane pattern. It's built as six composable npm modules for Node.js/Express, each handling one concern: identity, content safety, policy, rate limits, routing, and audit. [Architecture →](/reference-architecture)
What identity providers are supported?
Any OIDC-compliant provider issuing RS256 access tokens: Auth0, Okta, Entra ID (Azure AD), Keycloak, Google, Firebase Auth, AWS Cognito, and others. The `identifiabl` module discovers JWKS endpoints automatically via the standard `.well-known/openid-configuration` URL. [Agent identity deep dive →](/agent-identity)
What agent frameworks does it work with?
Any framework. ACP provides two integration paths: an **MCP endpoint** for tool discovery and execution, and an **OpenAI-compatible proxy** for drop-in model routing. LangChain, CrewAI, AutoGen, Mastra, Vercel AI SDK, custom code — if it can make an HTTP call, ACP can control it. [See all integrations →](/integrations)
Does it work with MCP and OpenAI Apps SDK?
Yes. GatewayStack has native support for both the Model Context Protocol (MCP) and OpenAI's Apps SDK (ChatGPT Actions). The reference implementation includes MCP server and ChatGPT Action connectors.
Is it production-ready?
The open-source modules are published on npm and tested (135 tests across 17 files). For teams that need managed infrastructure, Agentic Control Plane Cloud provides a multi-tenant gateway with dashboard, integrations, and audit UI.
What's the license?
MIT. All six modules and the monorepo are MIT licensed. Use them freely in commercial and open-source projects.
What's the latency overhead?
The identity verification and policy enforcement pipeline adds 2-5ms per request in typical deployments. The heaviest operation is the JWKS fetch on cold start, which is cached after first use. PII detection adds ~1ms for regex-based scanning. Rate limit checks are in-memory and sub-millisecond.
Does this work with Python, Go, or only Node.js?
The GatewayStack modules are Node.js / TypeScript. However, the gateway runs as a standalone service — your backend can be written in any language. It receives the verified user identity via the `x-user-uid` HTTP header (and optionally the full token claims). If you need a non-Node control plane, the `-core` packages export pure functions you can use as reference implementations.
Can I deploy on-prem?
Yes. GatewayStack is open source and runs anywhere Node.js runs — Cloud Run, ECS, Kubernetes, bare metal, or your local machine. There are no external dependencies beyond your OIDC identity provider. For teams that need a managed option, [Agentic Control Plane Cloud](/product) provides a hosted multi-tenant gateway.
Is there AI in the decision path? Access control should be deterministic.
**Policies decide; AI only escalates or annotates.** Deterministic policy rules are the floor: identity, per-tool and per-tier permissions, rate and budget limits — evaluated the same way on every call, and an action a policy denies stays denied. Risk classification sits on top and can only tighten an outcome (turn an allow into a flag or an approval) or add context to the audit record. It can never widen access or overrule a deny, so a wrong classification costs one extra confirmation, never a new permission.
This is the same split Google's [Beyond Zero paper](https://arxiv.org/abs/2605.22985) (2026) describes for the enterprise: static rules as the floor, dynamic reasoning as the ceiling.