How an Agentic Control Plane Addresses Every OWASP Agentic Top 10 Risk
A compromised MCP server called postmark-mcp silently BCC’d every outgoing email to an attacker-controlled address. It ran undetected for weeks. Trend Micro later found 492 exposed MCP servers with zero authentication. The first malicious MCP package had already shipped before anyone thought to check.
OWASP looked at this landscape and published the Top 10 for Agentic Applications in December 2025 — peer-reviewed by over 100 researchers from NIST, the European Commission, and the Alan Turing Institute. It is the most rigorous enumeration of agentic AI risks published to date.
What nobody has done is map those ten risks, one by one, to specific control plane capabilities that mitigate them. Not at the model layer. Not at the framework layer. At the governance layer — the Agentic Control Plane sitting between every agent and every backend.
This post is that mapping.
The compliance reality
OWASP compliance is becoming a procurement checkbox. Enterprise security teams already use the OWASP Top 10 for web applications as a baseline requirement in vendor assessments. The agentic version is following the same trajectory. If your AI agent infrastructure can’t demonstrate coverage against these ten risks, the conversation with the CISO ends early.
The numbers back this up. Gravitee’s State of AI Agent Security report found that only 14.4% of organizations report their AI agents go live with full security approval. 88% of organizations reported AI agent security incidents. 45.6% still rely on shared API keys for agent-to-agent authentication.
Those aren’t edge cases. That’s the industry baseline. OWASP didn’t publish this list because agentic security is a theoretical concern. They published it because the incidents are already happening and the controls are absent.
ASI-01: Agent Goal Hijack
The risk: Prompt injection alters an agent’s objectives mid-execution. An attacker embeds instructions in a document, email, or database record that the agent processes. The agent’s goal shifts from “summarize this report” to “exfiltrate this data.” The user sees a normal response. The backend sees a compromised request chain.
Control plane mitigation: Treat all natural language input as untrusted data — but enforcement can’t live inside the agent. An agent that decides whether its own input is malicious is an agent that can be convinced its malicious input is fine.
The control plane enforces this at the trust boundary:
- Deny-by-default policy enforcement restricts which tools the agent can invoke regardless of what it’s been told to do. Even if a prompt injection succeeds in changing the agent’s intent, the agent still can’t call tools outside its granted scopes.
- Scope inheritance with restriction ensures the agent’s permissions are a strict subset of the delegating user’s permissions. Goal hijack can redirect intent but cannot escalate privilege.
- Human-in-the-loop confirmation workflows require explicit approval for high-consequence actions — goal changes, data exports, write operations to sensitive systems. The agent can want to exfiltrate data. The control plane requires a human to approve it first.
- Identity-attributed audit logging records every tool call with the originating user’s verified identity, the policy decision, and the action attempted. If a goal hijack occurs, the forensic chain is already captured.
Prompt injection is a model-layer problem. The blast radius of prompt injection is a control plane problem.
ASI-02: Tool Misuse and Exploitation
The risk: Agents use tools unsafely — calling APIs with overprivileged credentials, passing unvalidated arguments, or invoking tools in sequences that produce unintended side effects. The agent isn’t malicious. It’s doing what the LLM decided was helpful, with access it should never have had.
Control plane mitigation: This is where deny-by-default earns its keep. Every tool invocation is a policy decision, evaluated at the gateway before the call reaches your backend.
policies:
- role: analyst
allow:
- tool:crm:read
- tool:reports:generate
deny:
- tool:crm:write
- tool:crm:delete
- tool:admin:*
rate_limit:
max_calls: 100
window: 60s
- Connector-level permission scoping defines exactly which operations each tool connector exposes. A CRM connector can expose
readwithout exposingwrite,delete, oradmin. The agent never sees the operations it isn’t allowed to use. - Per-call policy evaluation checks every invocation against current policy — not session-level, not role-at-login-time, but per call. An agent making 200 tool calls gets 200 authorization decisions.
- Budget and rate limiting caps both request volume and estimated cost. An agent stuck in a retry loop or chaining expensive operations hits a hard ceiling, not a soft warning.
“The agent shouldn’t do that” is a hope. Per-call policy evaluation is enforcement.
ASI-03: Identity and Privilege Abuse
The risk: Agents inherit high-privilege credentials that are reused across requests, sessions, and users. Machine identities now outnumber human identities in enterprise environments — and most of them authenticate with shared API keys or long-lived service account tokens. An agent acting for an intern uses the same credentials as an agent acting for the CFO.
Control plane mitigation: Identity binding at the gateway, built on JWT verification and RFC 8693 token exchange.
import { identifiabl } from "@gatewaystack/identifiabl";
app.use(identifiabl({
issuer: process.env.OAUTH_ISSUER!,
audience: process.env.OAUTH_AUDIENCE!,
}));
// Every agent request now carries verified identity:
// req.user.sub → "auth0|8f3a2b1c"
// req.user.scope → "tool:crm:read"
// req.user.org_id → "org_acme_corp"
- JWT-based identity binding ties every agent request to the originating user’s verified identity — not a shared key, not a service account. The three-party problem is solved by propagating user identity through the agent layer to the backend.
- Scope inheritance with restriction means the agent’s permissions are always a strict subset of the delegating user’s. The intern’s agent gets intern-level access. The CFO’s agent gets CFO-level access minus the escalation margin that autonomous operation warrants.
- Short-lived, task-scoped credentials replace long-lived tokens. Agent tokens expire. They carry only the scopes needed for the current task. Revocation is per-agent, not per-user.
45.6% of organizations still use shared API keys for agent auth. That’s not identity management. That’s credential sharing with extra steps.
ASI-04: Agentic Supply Chain Vulnerabilities
The risk: Tools, plugins, and MCP servers are fetched dynamically at runtime. The dependency graph isn’t static — it changes every time an agent discovers a new tool or a plugin registry updates. The postmark-mcp incident demonstrated that malicious packages reach production before anyone audits them. Snyk found 12% of published skills on ClawHub were compromised.
Control plane mitigation: The control plane doesn’t trust the supply chain. It treats every tool connector as potentially compromised and enforces governance regardless.
- Deny-by-default tool scoping means a new or unknown tool has zero permissions until explicitly granted. A compromised MCP server that appears on the registry doesn’t automatically gain access to your backend.
- Connector-level permission scoping restricts each tool to the specific operations it’s allowed to perform. Even if a tool is legitimate, it only gets the capabilities your policy explicitly allows.
- Sandboxed execution isolates tool calls so a compromised connector can’t pivot to other systems.
- Identity-attributed audit logging records which tools were invoked, by which agent, for which user. If a supply chain compromise occurs, the blast radius is immediately queryable — not a six-week forensic exercise.
The supply chain is a data plane concern. The blast radius of a supply chain compromise is a control plane concern.
ASI-05: Unexpected Code Execution
The risk: Agents generate and run code without adequate sandboxing. A model decides it needs to execute a script, calls eval() or exec(), and runs arbitrary code with the agent’s full permissions. Natural language becomes a code execution vector.
Control plane mitigation: The control plane treats code execution as a tool invocation — subject to the same policy enforcement as every other action.
- Deny-by-default means code execution tools (
exec,eval, shell access) are blocked unless explicitly granted by policy. Most agents don’t need code execution. The ones that do get it in a sandboxed, scoped, audited context. - Per-call policy evaluation examines every invocation. An agent that’s allowed to run a Python calculation is not automatically allowed to run a shell command.
- Budget controls limit the resources a code execution can consume — time, compute, network access.
- Audit logging captures the code that was generated, the tool that executed it, and the outcome. If unexpected code runs, the full chain is recorded.
Treat generated code the way you treat user input in a web application: as untrusted data passing through a validation layer. The control plane is that validation layer.
ASI-06: Memory and Context Poisoning
The risk: Attackers poison RAG databases, embedding stores, and agent memory. A single malicious document in a vector database can alter agent behavior across every future interaction that retrieves it. Trend Micro found 492 exposed MCP servers with zero authentication — any of which could serve poisoned context.
Control plane mitigation: Memory and context are data flows. Data flows pass through the control plane.
- Tenant isolation segments memory and context by organization. One tenant’s poisoned embedding store cannot affect another tenant’s agents. Cross-tenant data leakage is architecturally prevented, not policy-prevented.
- PII detection and redaction scans content flowing through the control plane before it reaches the model or the backend. Poisoned content that contains sensitive data triggers content safety rules.
- Identity-attributed audit logging tracks provenance — which user, which session, which tool provided the context that influenced the agent’s behavior. When memory poisoning is detected, the source is traceable.
If your RAG pipeline doesn’t have a governance layer between the vector store and the model, you have an unvalidated data path running directly into your agent’s decision-making. That’s not an architecture. That’s a vulnerability.
ASI-07: Insecure Inter-Agent Communication
The risk: Multi-agent systems pass messages between agents without authentication, integrity verification, or authorization checks. Agent A tells Agent B to perform an action. Agent B complies. Nobody verified that Agent A was authorized to make that request or that the message wasn’t tampered with in transit.
Control plane mitigation: Inter-agent communication is just another tool call — and the control plane governs all tool calls.
- JWT-based identity binding applies to agent-to-agent requests. When Agent A calls Agent B, the request carries the originating user’s verified identity. Agent B’s control plane evaluates the request against its own policy before executing.
- Per-call policy evaluation means every inter-agent message triggers an authorization check. Agent A having permission to call Agent B for CRM reads doesn’t mean it has permission to call Agent B for CRM writes.
- Identity-attributed audit logging captures the full multi-agent chain: user to Agent A to Agent B to tool to outcome. Attribution survives every hop.
The pattern is the same as user-to-agent communication. Authenticated, authorized, audited. The number of hops doesn’t change the governance model.
ASI-08: Cascading Failures
The risk: Small errors propagate across interconnected agent systems. An incorrect output from one agent becomes the input to another. A retry loop in one agent triggers rate limits across shared infrastructure. A single point of failure takes down a multi-agent workflow that spans six backend systems.
Control plane mitigation: The control plane enforces isolation boundaries and usage limits that prevent cascading failures.
- Budget and rate limiting caps both per-agent and per-user resource consumption. An agent in a retry loop hits its rate limit before it can cascade cost or errors to downstream systems. This isn’t a soft warning — it’s a hard stop.
- Tenant isolation ensures one tenant’s runaway agent can’t consume resources allocated to another tenant. Failure is contained within blast radius boundaries.
- Per-call policy evaluation means each step in a multi-agent chain is independently authorized. A cascading error doesn’t inherit the authorization of the step that preceded it — each action is evaluated on its own merits.
Circuit breakers belong at the infrastructure layer, not inside the agent’s prompt. The control plane is that infrastructure layer.
ASI-09: Human-Agent Trust Exploitation
The risk: Users over-trust agent recommendations. An agent presents a confident, well-formatted recommendation. The user approves it without scrutiny. The recommendation was based on poisoned context, hallucinated data, or a compromised tool output. The agent wasn’t wrong on purpose — it was convincingly wrong by accident.
Control plane mitigation: Trust exploitation is a human factors problem. The control plane addresses it with forced friction and immutable evidence.
- Human-in-the-loop confirmation workflows require explicit user approval for high-consequence actions. The agent can recommend. The control plane requires the user to confirm before execution. Not a “click OK to continue” dialog — a structured approval that’s logged as part of the audit trail.
- Identity-attributed audit logging creates an immutable record of what the agent recommended, what the user approved, and what was executed. If a user approves a harmful action based on a confident agent recommendation, the audit trail shows the decision chain — not just the outcome.
- PII detection and redaction adds a content safety signal. If the agent’s recommendation involves sensitive data, the control plane flags it before the user sees it.
An agent that can autonomously execute high-consequence actions without human confirmation isn’t an assistant. It’s an autonomous system with no oversight. The EU AI Act’s Article 14 requires human oversight of high-risk AI systems. The control plane implements it.
ASI-10: Rogue Agents
The risk: A compromised agent acts harmfully while appearing legitimate. It passes authentication. It produces normal-looking outputs. It subtly exfiltrates data, escalates privileges, or manipulates outcomes. Detection is hard because the agent looks like every other agent — until you examine its behavior at scale.
Control plane mitigation: Rogue agent detection requires governance infrastructure that operates independently of the agent itself.
- Deny-by-default policy enforcement limits the rogue agent’s blast radius. Even a compromised agent can only do what its policy allows. If the policy grants
tool:crm:readand nothing else, the rogue agent can read CRM data for authorized users — but it can’t write, delete, escalate, or exfiltrate through unauthorized channels. - Identity-attributed audit logging produces the behavioral record needed for detection. A rogue agent’s behavior diverges from legitimate patterns — unusual tool call frequency, access to tools outside its normal pattern, requests outside business hours. These patterns are detectable in structured audit data.
- Budget controls cap resource consumption. A rogue agent mining your LLM budget or generating excessive API calls hits hard limits before the cost becomes catastrophic.
- Runtime identity verification ensures the agent’s credentials are valid on every call, not just at session start. Revocation is immediate and per-agent.
“We’ll detect it in the logs” assumes you have the right logs. Generic API logs won’t surface rogue agent behavior. Identity-attributed audit trails with policy decisions, content safety events, and usage data will.
The principle underneath: Least Agency
OWASP’s core recommendation is “Least Agency” — the minimum autonomy required for safe, bounded tasks. This is distinct from least privilege. Least privilege is about access — which resources can a principal read or write. Least agency is about autonomy — how many decisions can an agent make without human oversight, and how far-reaching are those decisions.
OAuth scopes alone are insufficient. A scope grants permission to access a resource. It doesn’t govern how many times, in what sequence, at what cost, or with what human oversight that access occurs. Least agency requires runtime authorization evaluated continuously — per-call, deny-by-default, identity-bound.
The control plane is the enforcement mechanism for least agency. It doesn’t just check “can this agent access this tool?” It checks “should this agent, acting for this user, at this point in this session, within this budget, with this behavioral pattern, be allowed to perform this specific action right now?”
That’s not a permission check. That’s continuous trust validation.
The mapping at a glance
| OWASP Risk | Primary Control Plane Capability |
|---|---|
| ASI-01: Agent Goal Hijack | Deny-by-default scoping, human-in-the-loop, audit logging |
| ASI-02: Tool Misuse | Per-call policy evaluation, connector-level scoping, rate limits |
| ASI-03: Identity & Privilege Abuse | JWT identity binding (RFC 8693), scope inheritance, short-lived credentials |
| ASI-04: Supply Chain | Deny-by-default for unknown tools, sandboxed execution, audit trails |
| ASI-05: Code Execution | Tool-level policy enforcement, sandboxing, budget controls |
| ASI-06: Memory Poisoning | Tenant isolation, PII detection, provenance tracking |
| ASI-07: Insecure Inter-Agent Comms | JWT propagation across hops, per-call auth, chain-of-custody logging |
| ASI-08: Cascading Failures | Rate limiting, budget caps, tenant isolation, per-call evaluation |
| ASI-09: Trust Exploitation | Human-in-the-loop workflows, immutable audit logs, PII flagging |
| ASI-10: Rogue Agents | Behavioral audit trails, budget controls, runtime identity verification |
Every row maps to infrastructure that exists today. Not a roadmap. Not a whitepaper. Working governance at the trust boundary.
Where to start
If OWASP compliance is on your roadmap — and increasingly, it’s on your procurement team’s checklist — start with the three capabilities that cover the most risks:
-
Identity binding. Solve ASI-01, ASI-03, ASI-07, and ASI-10 by ensuring every agent request carries a verified user identity. If your agents authenticate with shared API keys, start here. Understand the identity gap.
-
Deny-by-default policy enforcement. Solve ASI-01, ASI-02, ASI-04, ASI-05, and ASI-10 by ensuring agents have zero permissions until explicitly granted. If your agents inherit the user’s full role, start here. See how runtime authorization works.
-
Identity-attributed audit logging. Solve ASI-06, ASI-09, and ASI-10 by producing compliance-ready evidence on every action. If your logs show
service_account: POST /api 200, start here. What CISOs actually need.
GatewayStack is one implementation of the Agentic Control Plane pattern — built to address every risk on this list at the infrastructure layer. It’s not the only way to achieve OWASP Agentic compliance, but it’s a working implementation with a published mapping against every ASI risk.
Get started free · Reference architecture · Data plane vs control plane
Ten risks. One governance layer. Zero excuses.