# Agentic Control Plane FAQ

FAQ on Agentic Control Planes: agent identity, control and audit, agent-to-agent delegation, open source, and deploying AI agents in production.

<!-- FAQPage schema mirrors the visible <details> Q&A below, 1:1.
     If you edit a question or answer on this page, update it here too
     (or the schema becomes invented content — a spam-policy risk). -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is an Agentic Control Plane?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What problem does it solve?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is this different from agent infrastructure?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is this different from an API gateway?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How is this different from an LLM gateway?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "I already run my agents in a sandbox — do I need an ACP?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Can MCP servers inject ads or instructions into my agent's tool results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Can agents call other agents through ACP?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Can I create agents from the console?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The console is where you see and control agents, not where you build them. ACP Cloud shows every agent's activity, cost, and declared tool surface, and lets you set rules, approve held calls, and manage the team from the browser. The agents themselves come from your harness (Claude Code, Codex, Cursor and the rest, via one install) or from your framework code via the SDKs and the REST API; either way they get identity, policy checks, and audit automatically."
      }
    },
    {
      "@type": "Question",
      "name": "What is the Three-Party Problem?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Do I need to replace my existing infrastructure?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Is ACP open source?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The harness plugins are: one repo per harness under github.com/agentic-control-plane, MIT licensed, published as @agenticcontrolplane/* on npm and acp-* on PyPI. The gateway and console run as Agentic Control Plane Cloud."
      }
    },
    {
      "@type": "Question",
      "name": "What identity providers are supported?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What agent frameworks does it work with?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Does it work with MCP servers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. The hook sees MCP tool calls the same way it sees the harness's built-in tools, and rules match them by server and tool name. OpenAI's Apps SDK (ChatGPT Actions) is not covered."
      }
    },
    {
      "@type": "Question",
      "name": "Is it production-ready?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What's the license?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "MIT for the enforcement modules and the harness plugins (one repo per harness under github.com/agentic-control-plane). The hosted control plane — console, policy engine, cost X-ray — is not open source."
      }
    },
    {
      "@type": "Question",
      "name": "What's the latency overhead?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Does this work with Python, Go, or only Node.js?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The gateway endpoint is HTTP, so the language of your agent does not matter. Harness plugins ship as npm or PyPI packages depending on the harness. Framework SDKs exist for Python (acp-crewai, acp-langchain, acp-pydantic-ai) and TypeScript (@agenticcontrolplane/governance)."
      }
    },
    {
      "@type": "Question",
      "name": "Can I deploy on-prem?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The hook can run without the cloud: install with --local and rules are evaluated on the machine, nothing is sent. The gateway and console are hosted as Agentic Control Plane Cloud; a self-hosted or VPC deployment of the full gateway is available on Enterprise, on request."
      }
    },
    {
      "@type": "Question",
      "name": "Is there AI in the decision path? Access control should be deterministic.",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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 (2026) describes for the enterprise: static rules as the floor, dynamic reasoning as the ceiling."
      }
    }
  ]
}
</script>

<h1>Frequently Asked Questions</h1>

<details>
<summary>What is an Agentic Control Plane?</summary>

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.

</details>

<details>
<summary>What problem does it solve?</summary>

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 &rarr;](/for-teams#problem)

</details>

<details>
<summary>How is this different from agent infrastructure?</summary>

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.**

</details>

<details>
<summary>How is this different from an API gateway?</summary>

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 &rarr;](/comparison)

</details>

<details>
<summary>How is this different from an LLM gateway?</summary>

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 &rarr;](/comparison)

</details>

<details>
<summary>I already run my agents in a sandbox — do I need an ACP?</summary>

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 &rarr;](/blog/sandboxes-and-control-planes)

</details>

<details>
<summary>Can MCP servers inject ads or instructions into my agent's tool results?</summary>

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 &rarr;](/blog/ad-blocker-for-tool-responses)

</details>

<details>
<summary>Can agents call other agents through ACP?</summary>

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 &rarr;](/agent-to-agent)

</details>

<details>
<summary>Can I create agents from the console?</summary>

The console is where you see and control agents, not where you build them. ACP Cloud shows every agent's activity, cost, and declared tool surface, and lets you set rules, approve held calls, and manage the team from the browser. The agents themselves come from your harness (Claude Code, Codex, Cursor and the rest, via one install) or from your framework code via the SDKs and the REST API; either way they get identity, policy checks, and audit automatically.

</details>

<details>
<summary>What is the Three-Party Problem?</summary>

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 &rarr;](/for-teams#problem)

</details>

<details>
<summary>Do I need to replace my existing infrastructure?</summary>

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.

</details>

<details>
<summary>Is ACP open source?</summary>

The harness plugins are: one repo per harness under [github.com/agentic-control-plane](https://github.com/agentic-control-plane), MIT licensed, published as `@agenticcontrolplane/*` on npm and `acp-*` on PyPI. The gateway and console run as [ACP Cloud](https://cloud.agenticcontrolplane.com). [Architecture &rarr;](/reference-architecture)

</details>

<details>
<summary>What identity providers are supported?</summary>

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 &rarr;](/agent-identity)

</details>

<details>
<summary>What agent frameworks does it work with?</summary>

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 &rarr;](/integrations)

</details>

<details>
<summary>Does it work with MCP servers?</summary>

Yes. The hook sees MCP tool calls the same way it sees the harness's built-in tools, and rules match them by server and tool name. OpenAI's Apps SDK (ChatGPT Actions) is not covered.

</details>

<details>
<summary>Is it production-ready?</summary>

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.

</details>

<details>
<summary>What's the license?</summary>

MIT for the enforcement modules and the harness plugins (one repo per harness under github.com/agentic-control-plane). The hosted control plane — console, policy engine, cost X-ray — is not open source.

</details>

<details>
<summary>What's the latency overhead?</summary>

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.

</details>

<details>
<summary>Does this work with Python, Go, or only Node.js?</summary>

The gateway endpoint is HTTP, so the language of your agent does not matter. Harness plugins ship as npm or PyPI packages depending on the harness. Framework SDKs exist for Python (`acp-crewai`, `acp-langchain`, `acp-pydantic-ai`) and TypeScript (`@agenticcontrolplane/governance`). [Frameworks &rarr;](/frameworks)

</details>

<details>
<summary>Can I deploy on-prem?</summary>

The hook can run without the cloud: install with `--local` and rules are evaluated on the machine, nothing is sent. The gateway and console are hosted as [Agentic Control Plane Cloud](/pricing); a self-hosted or VPC deployment of the full gateway is available on Enterprise, [on request](/pricing).

</details>

<details>
<summary>Is there AI in the decision path? Access control should be deterministic.</summary>

**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.

</details>