When AI Agents Take Real Actions, Who Controls What They're Allowed to Do?
Run agents? ACP lets you see, control, and price every tool call they make — allow/ask/deny policy, per-session cost, and a full audit log for Claude Code, Cursor, Codex, and OpenClaw, in one command:
curl -sf https://agenticcontrolplane.com/install.sh | bashGetting started → · see your first governed call → · free up to 5 agents · prefer fully on-device? add --local
Traditional web apps have two parties: a user and a backend. The user proves who they are; the backend enforces what they can do. AI apps add a third party — the LLM runtime — and that model breaks. The user authenticates with the LLM, but when the LLM calls your backend it does so with a shared API key. Your backend has no way to tell who the request is for.
For the past two years, most AI integrations were conversational — chatbots that answer questions, summarize documents, generate content. Backend risk was limited because the AI was only reading and writing text. That’s ending.
Agents are taking real actions
OpenAI’s Apps SDK lets ChatGPT call any HTTP endpoint on behalf of a user. Anthropic’s Model Context Protocol gives LLMs a standard way to discover and invoke tools. Every enterprise is building internal copilots that take actions, not just suggest them.
An AI assistant that queries patient records. A copilot that creates JIRA tickets. An agent that processes refunds, pulls credit reports, or modifies infrastructure. Real actions with real consequences, and most of them running without any governance layer.
The three-party problem
When the LLM calls your backend on that shared key, the backend receives the request but can’t answer:
- Who is this request actually for?
- What are they allowed to do?
- Whether this action complies with your policies?
This is the three-party problem, and it’s the reason agentic control planes will matter.
What goes wrong without one
The consequences are already visible:
Shadow AI. Teams integrate AI tools without security review. Shared API keys get passed around. Nobody knows which users are making which requests.
Data leakage. Patient records, financial data, and legal documents flow into LLM prompts with no PII detection or redaction. You’re sending sensitive data to third-party models without any filtering.
No audit trail. A compliance officer asks who accessed what through the AI assistant. Without identity binding at the gateway, the answer is: “We don’t know.”
Runaway costs. An agent loop fires thousands of API calls in minutes. Without per-user rate limits enforced at the gateway, the first sign of trouble is the invoice.
What an agentic control plane does
An agentic control plane sits between the LLM and your backend. It handles six concerns:
- Identity binding — verify OAuth tokens and attach verified user identity to every request
- Content safety — detect PII in prompts before they reach the model
- Policy enforcement — deny-by-default authorization based on user roles and scopes
- Usage governance — per-user rate limits, budget caps, and agent runaway detection
- Secure routing — route to backends with identity intact, SSRF protection
- Audit trails — log every action with user identity, policy decisions, and cost
In a regulated or multi-user environment, you need all six before agents touch production.
The timing
Three things are converging:
Platform support. MCP and the Apps SDK give LLMs a standard way to call tools. The protocol layer is ready.
Enterprise adoption. Every large company is deploying agent workflows. The demand is here.
Regulatory pressure. HIPAA, SOC 2, GDPR, and PCI all have implications for AI-mediated access to protected data.
The governance layer is what’s missing. Teams that build it into the stack now won’t have to bolt it on later.
Where to start
GatewayStack is the open-source reference implementation. Six composable npm modules, MIT licensed. Start with identifiabl for identity verification and add layers as your needs grow.