OWASP Top 10 for Agentic Applications 2026: What API Gateway Teams Need to Know

AI agents are no longer just generating text. They're calling APIs, executing multi-step workflows, and making autonomous decisions that affect production systems. That shift from "AI that talks" to "AI that acts" is exactly why OWASP released the Top 10 for Agentic Applications for 2026 — a peer-reviewed security framework developed by over 100 industry experts that identifies the most critical risks facing autonomous AI systems.

If you're on an API team, this framework matters more than you might expect. At least half of the ten risks are directly mitigable at the API gateway layer, because every tool call an agent makes, every inter-agent message it sends, and every resource it accesses is ultimately an API request. Your gateway is already the enforcement point. The question is whether you're using it to its full potential.

This guide breaks down the OWASP Agentic Top 10, identifies which risks your API gateway can address, and provides practical implementation patterns you can apply today.

In this guide:

• What Is the OWASP Top 10 for Agentic Applications?
• The Five Risks API Gateways Can Mitigate
• From Least Privilege to Least Agency
• Practical Implementation: Securing Agentic APIs at the Gateway
• MCP-Specific Security Considerations
• Mapping the OWASP Agentic Top 10 to Your API Security Posture
• Getting Started

What Is the OWASP Top 10 for Agentic Applications?

The OWASP Top 10 for Agentic Applications is a companion to the existing OWASP Top 10 for LLMs, but with a fundamentally different focus. Where the LLM list addresses risks in model interactions — prompt injection, training data poisoning, hallucinations — the agentic list addresses risks in agent actions. It's about what happens when an AI system has the autonomy to call tools, access resources, and make decisions without human approval at every step.

The ten risks are:

• ASI01 — Agent Goal Hijack: Attackers alter an agent's objectives through malicious content embedded in emails, PDFs, or web pages. The agent can't distinguish instructions from data.
• ASI02 — Tool Misuse and Exploitation: Legitimate tools are exploited through manipulated inputs, causing agents to call APIs with destructive parameters or chain tools in unintended ways.
• ASI03 — Identity and Privilege Abuse: Agents inherit user or system credentials that get unintentionally reused or escalated across systems, leading to confused deputy attacks.
• ASI04 — Agentic Supply Chain Vulnerabilities: Tools, plugins, MCP servers, and model files fetched at runtime may be compromised, altering agent behavior or exposing data.
• ASI05 — Unexpected Code Execution: Agents generate or run code unsafely, including shell commands, scripts, and unsafe deserialization.
• ASI06 — Memory & Context Poisoning: Attackers corrupt RAG databases, embeddings, or shared memory to influence future agent decisions.
• ASI07 — Insecure Inter-Agent Communication: Multi-agent systems exchange messages without proper authentication or encryption, enabling spoofing and injection.
• ASI08 — Cascading Failures: Small errors propagate across planning, execution, and downstream systems, with a single poisoned state triggering destructive actions across multiple agents.
• ASI09 — Human-Agent Trust Exploitation: Users over-trust agent recommendations, allowing attackers to influence decisions through subtly manipulated outputs.
• ASI10 — Rogue Agents: Compromised or misaligned agents act harmfully while appearing legitimate, persisting across sessions or impersonating trusted systems.

The framework also introduces a foundational principle: Least Agency. Borrowed from the well-known principle of least privilege, least agency extends the concept to autonomous systems — only grant agents the minimum autonomy required to perform safe, bounded tasks. Autonomy should be earned through demonstrated safety, not granted by default.

The Five Risks API Gateways Can Mitigate

Not every risk on the list falls within an API team's scope. Goal hijack (ASI01), unexpected code execution (ASI05), memory poisoning (ASI06), and human-trust exploitation (ASI09) are primarily application-layer or model-layer concerns. But five of the ten risks map directly to capabilities that API gateways already provide.

ASI02 — Tool Misuse and Exploitation

When an agent calls a tool, it's making an API request. If the agent has been manipulated — through prompt injection, ambiguous instructions, or poisoned context — it may call tools with destructive parameters, invoke tools it shouldn't have access to, or chain tool calls in unintended sequences.

The API gateway is the natural enforcement point here. You can:

• Validate every tool call against a schema to reject malformed or out-of-bounds parameters before they reach your backend
• Scope tool access per consumer so that a compromised agent can only reach the endpoints its API key or token authorizes
• Apply per-route policies that enforce business rules on specific operations — for example, preventing a DELETE call unless a custom header confirms the action was human-approved

With Zuplo, the Request Validation policy validates incoming requests against your OpenAPI schema definitions automatically. Every parameter, request body, and header is checked before the request touches your backend. And because Zuplo's MCP Server Handler re-invokes configured routes within the gateway, tool calls made through MCP go through the full policy pipeline — including validation — just like any other API request.

ASI03 — Identity and Privilege Abuse

Agents often inherit credentials from the user who launched them — OAuth tokens, API keys, session cookies. Without careful scoping, those credentials can get reused across unrelated services or escalated to access resources the agent was never intended to reach. OWASP calls this a "confused deputy" scenario: the agent acts with the user's full authority, even when the task only requires a fraction of it.

The gateway can enforce identity boundaries that the agent itself cannot:

• Authenticate every request with API key or OAuth/JWT policies that validate credentials on every call, not just at session start
• Assign scoped API keys per agent so each agent identity has access only to the routes it needs, with metadata tracking which agent or workflow is making the call
• Use short-lived, task-scoped tokens rather than long-lived credentials that persist across sessions

Zuplo's MCP Server Handler supports OAuth authentication natively. You can attach an OAuth inbound policy to your MCP server route and enable oAuthResourceMetadataEnabled so that MCP clients perform proper OAuth flows against your authorization server. Each tool call is then authenticated individually through the gateway's policy pipeline, and the request.user object is available to downstream policies for fine-grained authorization decisions.

ASI04 — Agentic Supply Chain Vulnerabilities

Agents assemble their capabilities at runtime by loading tools, plugins, prompt templates, and MCP servers dynamically. Any compromised component in that supply chain — a poisoned MCP server, a tampered plugin, a malicious model file — can alter the agent's behavior or exfiltrate data.

The API gateway can act as a supply chain checkpoint:

• Proxy all tool integrations through the gateway so every external tool call is subject to authentication, rate limiting, and logging regardless of where the tool is hosted
• Maintain an allowlist of approved tool endpoints at the gateway level, rejecting calls to unregistered services
• Log every tool invocation for audit and forensic analysis

When you use Zuplo's MCP Server Handler, your MCP tools are defined in your gateway's route configuration — not dynamically fetched from external sources. The operations array in the handler configuration explicitly references specific OpenAPI operations, which means the set of available tools is version-controlled, code-reviewed, and deployed through your normal CI/CD pipeline. An agent can only call tools that your team has explicitly exposed.

ASI07 — Insecure Inter-Agent Communication

In multi-agent architectures, agents exchange messages across networks without proper authentication, encryption, or integrity verification. Attackers can spoof agent identities, inject instructions into agent-to-agent channels, or replay previous messages to trigger unintended actions.

The gateway provides the transport-layer security that agent frameworks often lack:

• Enforce mutual TLS and encryption on all inter-agent traffic passing through the gateway
• Authenticate agent-to-agent calls using the same API key or JWT policies you'd use for any consumer
• Apply rate limiting and circuit breakers to inter-agent channels to prevent message flooding or replay attacks

Zuplo's edge-native deployment runs across 300+ data centers worldwide, meaning inter-agent traffic is encrypted and validated at the edge before it reaches your backend. Combining this with per-route authentication policies ensures that even in a multi-agent system, every message is verified.

For teams building with both MCP and the Agent-to-Agent (A2A) protocol, the gateway serves as the unified enforcement point for both tool-calling traffic and agent-to-agent communication.

ASI10 — Rogue Agents

A rogue agent is one that has been compromised, misconfigured, or subtly misaligned — and it continues to operate while appearing legitimate. It might make excessive API calls, access resources outside its intended scope, or persist across sessions by maintaining stolen credentials.

The gateway can detect and contain rogue behavior:

• Rate limit per agent identity to cap how many requests any single agent can make in a given time window, preventing runaway consumption
• Set quotas per consumer to enforce hard usage boundaries that trigger alerts or blocks when exceeded
• Monitor traffic patterns for anomalies — sudden spikes in request volume, access to unusual endpoints, or requests outside normal hours

Zuplo's Rate Limiting policy supports limiting by user, IP, or custom function — which lets you implement API key-based or any other custom limiting logic. You can create different rate limits for different agent tiers, and the policy returns standard 429 Too Many Requests responses with retry headers when limits are hit. For more sophisticated detection, you can write custom policies in TypeScript that inspect request patterns and flag suspicious behavior.

From Least Privilege to Least Agency

The principle of least privilege has been a security cornerstone for decades: give users and services the minimum permissions they need. OWASP's principle of least agency extends this to autonomous systems, and the distinction matters.

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?

For API teams, implementing least agency means:

• Scope tool access narrowly. Don't expose your entire API surface as MCP tools. Select only the operations an agent legitimately needs, and configure separate MCP servers for different agent workflows so each one gets a tailored set of tools.
• Require confirmation for destructive operations. Use gateway policies to block DELETE, PUT, or other state-changing operations unless a specific confirmation header or parameter is present — forcing a human-in-the-loop for high-risk actions.
• Set conservative rate limits. An agent that can make 10,000 requests per minute has far more agency than one limited to 100. Start with tight limits and expand based on demonstrated safety.
• Use tiered API keys. Assign different API keys to different agent capabilities. A read-only key for data retrieval, a scoped key for specific write operations, and no key at all for administrative endpoints.
• Log everything. Agency without observability is invisible risk. Every tool call, every authentication event, and every policy decision should be logged and auditable.

If you've already built AI governance patterns for your API layer, least agency is a natural extension of that framework.

Practical Implementation: Securing Agentic APIs at the Gateway

Here's a concrete example of how you'd configure a Zuplo gateway to enforce agentic security policies. This configuration protects a set of API routes exposed as MCP tools with authentication, rate limiting, and request validation.

First, define your policies:

{
  "policies": [
    {
      "name": "agent-api-key-auth",
      "policyType": "api-key-inbound",
      "handler": {
        "export": "ApiKeyInboundPolicy",
        "module": "$import(@zuplo/runtime)",
        "options": {
          "allowUnauthenticatedRequests": false
        }
      }
    },
    {
      "name": "agent-rate-limit",
      "policyType": "rate-limit-inbound",
      "handler": {
        "export": "RateLimitInboundPolicy",
        "module": "$import(@zuplo/runtime)",
        "options": {
          "rateLimitBy": "function",
          "requestsAllowed": 200,
          "timeWindowMinutes": 1,
          "identifier": {
            "module": "$import(./modules/rate-limiter)",
            "export": "rateLimitKey"
          }
        }
      }
    },
    {
      "name": "agent-request-validation",
      "policyType": "request-validation-inbound",
      "handler": {
        "export": "RequestValidationInboundPolicy",
        "module": "$import(@zuplo/runtime)",
        "options": {
          "validateBody": "reject-and-log",
          "validateQueryParameters": "reject-and-log"
        }
      }
    }
  ]
}

Then apply them to your routes. Each route that will be exposed as an MCP tool gets the full policy pipeline:

{
  "paths": {
    "/v1/orders": {
      "get": {
        "x-zuplo-route": {
          "handler": {
            "export": "urlForwardHandler",
            "module": "$import(@zuplo/runtime)"
          },
          "policies": {
            "inbound": [
              "agent-api-key-auth",
              "agent-rate-limit",
              "agent-request-validation"
            ]
          }
        }
      }
    }
  }
}

When these routes are configured as tools in the MCP Server Handler, the handler re-invokes them within the gateway. That means a single MCP tool call passes through two policy pipelines in sequence: the MCP server route's inbound policies first, then the tool route's inbound policies, then the tool route's outbound policies, and finally the MCP server route's outbound policies. Every tool call gets double the protection without any extra configuration.

MCP-Specific Security Considerations

The Model Context Protocol is becoming the standard way agents discover and invoke tools. If you're exposing APIs as MCP tools, there are specific security considerations that map directly to the OWASP agentic risks.

Authenticate Every MCP Endpoint

Never expose an MCP server without authentication. Zuplo supports two approaches:

• OAuth/JWT authentication — Attach an OAuth inbound policy to your MCP server route and configure oAuthResourceMetadataEnabled: true so MCP clients can discover and complete the OAuth flow automatically.
• API key authentication — Use the Query Parameter to Header policy to transform an apiKey query parameter into an Authorization: Bearer header, then validate it with the API Key Authentication policy. This approach works well with MCP clients that support URL-based authentication.

Validate Tool Inputs at the Schema Level

Every MCP tool call includes arguments that map to your API's request parameters. Because these arguments originate from an LLM — which may have been manipulated — they should be treated as untrusted input. The Request Validation policy ensures that every argument conforms to the schema defined in your OpenAPI spec before the request reaches your handler.

Limit the Tool Surface Area

When you map REST APIs to MCP tools, be deliberate about which operations you expose. The MCP Server Handler's operations array lets you select specific OpenAPI operations by ID, so you can expose read operations while keeping write operations behind a separate, more restricted MCP server — or not exposing them at all.

Monitor and Log MCP Traffic

Every MCP interaction that flows through the gateway is logged with the same detail as any other API request. Use this data to track which agents are calling which tools, how often, and with what parameters. Anomalies in MCP traffic — unusual tool combinations, high error rates, or unexpected parameter patterns — can indicate a compromised agent or a prompt injection attack in progress.

Mapping the OWASP Agentic Top 10 to Your API Security Posture

The following checklist summarizes all ten risks with their primary mitigation layers. For detailed implementation guidance on the five gateway-mitigable risks, see The Five Risks API Gateways Can Mitigate above.

Use this checklist to evaluate your current API gateway configuration against each of the ten risks.

ASI01 — Agent Goal Hijack

Primary mitigation layer: Application/Model

The gateway can help by logging all tool calls for forensic analysis and applying strict input validation to catch anomalous request patterns, but preventing goal hijack is primarily an application-layer concern involving prompt filtering and instruction isolation.

ASI02 — Tool Misuse and Exploitation

Primary mitigation layer: API Gateway

• Request validation against OpenAPI schemas on every route
• Per-route policy enforcement with scoped access controls
• Separate read and write operations with different authentication requirements

ASI03 — Identity and Privilege Abuse

Primary mitigation layer: API Gateway + Identity Provider

• API key or OAuth authentication on every request
• Scoped, per-agent API keys with minimal permissions
• Short-lived tokens instead of persistent credentials
• request.user metadata for downstream authorization logic

ASI04 — Supply Chain Vulnerabilities

Primary mitigation layer: API Gateway + CI/CD

• Version-controlled tool definitions in gateway route configuration
• Allowlisted tool endpoints — no dynamic tool discovery from untrusted sources
• Full audit logging of every tool invocation

ASI05 — Unexpected Code Execution

Primary mitigation layer: Application/Runtime

Not directly mitigable at the gateway layer. Use sandboxed execution environments and treat all AI-generated code as untrusted.

ASI06 — Memory & Context Poisoning

Primary mitigation layer: Application/Data

Not directly mitigable at the gateway layer. Implement memory segmentation, provenance tracking, and input validation in your RAG pipeline.

ASI07 — Insecure Inter-Agent Communication

Primary mitigation layer: API Gateway

• TLS encryption on all inter-agent traffic
• Authentication policies on every agent-to-agent endpoint
• Rate limiting and circuit breakers on inter-agent channels

ASI08 — Cascading Failures

Primary mitigation layer: API Gateway + Infrastructure

• Rate limiting and quotas to contain blast radius
• Circuit breaker patterns to stop error propagation
• Isolated policy pipelines per route to prevent cross-contamination

ASI09 — Human-Agent Trust Exploitation

Primary mitigation layer: Application/UX

Not directly mitigable at the gateway layer. Implement forced confirmation dialogs, immutable audit logs, and clear attribution of AI-generated recommendations in your application UI.

ASI10 — Rogue Agents

Primary mitigation layer: API Gateway

• Per-agent rate limits and quotas
• Behavioral monitoring through traffic analysis
• Ability to revoke API keys instantly to shut down compromised agents

Getting Started

The OWASP Top 10 for Agentic Applications is a signal that the industry recognizes agentic AI as a distinct security domain — not just an extension of LLM safety. For API teams, the good news is that many of the recommended mitigations are capabilities you already have or can add with straightforward gateway configuration.

Start with the highest-impact changes: authenticate every agent-facing endpoint, validate every request against a schema, and set rate limits that reflect your least agency posture. From there, expand to per-agent API keys, scoped tool surfaces, and comprehensive audit logging.

If you're already running an API gateway, you're better positioned than most to secure agentic traffic. The patterns aren't new — authentication, rate limiting, input validation, and access control have been API security fundamentals for years. What's new is the context in which they're applied: autonomous systems that make decisions and take actions at machine speed.

The gateway is your control plane. Use it.

Ready to secure your agentic APIs? Create an MCP server from your OpenAPI spec with built-in gateway policies, or explore the MCP Server Handler documentation to see how Zuplo enforces authentication, validation, and rate limiting on every tool call.