OWASP Top 10 for Agentic Applications: What Security Teams Need To Know

What Is the OWASP Top 10 for Agentic Applications?

The OWASP Top 10 for Agentic Applications 2026 is a risk enumeration framework that catalogs the highest-impact security failures specific to autonomous and semi-autonomous AI agent systems. It extends the work of the OWASP LLM Top 10 but focuses specifically on agents. Agents are systems that plan, take actions, and use tools with some degree of autonomy.

The framework organizes risks under Agentic Identity Incidents (ASI) codes. Each risk describes a failure class rather than a single vulnerability. A single misconfigured agent deployment may expose you to multiple risks at once.

Unlike the LLM Top 10, which focuses on the model layer, the Agentic Top 10 addresses the full agent stack: the tools an agent uses, the memory it reads, the other agents it communicates with, and the identity it carries when taking action.

The OWASP Agentic Top 10 Risks

ASI01 — Agent Goal Hijack

An agent receives its objectives through natural language instructions. Examples include system prompts, user messages, retrieved documents, emails, and tool outputs. Goal hijacking is when an attacker embeds malicious instructions in any of that content, redirecting the agent to a different objective without the operator’s knowledge.

Goal hijacking does not require breaking into the agent. PDF files, web pages, and emails can all contain injected instructions. If the agent reads or processes such content and considers it authoritative, it will follow the attacker’s commands instead of the operator’s.

Practical mitigation:

• Treat all external content retrieved at runtime as untrusted input, not as operator-level instructions.
• Enforce a clear privilege boundary between the system prompt (operator-controlled) and agent-retrieved data.
• Require human approval before an agent materially changes its goal mid-task, especially for actions that cannot be reversed.
• Apply prompt injection filtering at ingestion points for external content.

Goal hijacking is the agentic equivalent of a phishing attack. It exploits the agent’s inability to reliably distinguish a legitimate instruction from a malicious one embedded in data.

ASI02 — Tool Misuse and Exploitation

Agents accomplish tasks using tools, such as code interpreters, file systems, APIs, databases, and email clients. Tool misuse occurs when an agent invokes a legitimate tool with harmful parameters: deleting files, exfiltrating data, or overwriting records because of an ambiguous prompt or manipulated input.

The attacker does not need to compromise the tool itself. Crafting the input so that the agent chooses destructive parameters is sufficient. A single poorly scoped tool permission can turn a retrieval agent into a data exfiltration path.

Practical mitigation:

• Scope tool permissions to the minimum the task demands. An agent that reads documents should not have write access.
• Validate tool arguments against an allow-list of safe parameter ranges before execution.
• Where possible, run tool invocations inside sandboxed environments to contain the blast radius from misuse.
• Log every tool call with its full argument set for audit and anomaly detection.

ASI03 — Identity and Privilege Abuse

This is one of the most structurally important risks on the list. Agents often operate with inherited or broadly scoped credentials: a service account token, an API key with organization-wide permissions, or a user-delegated OAuth token. When an agent passes those credentials to sub-agents, third-party tools, or other services, the privilege travels with them, regardless of whether the sub-agent actually needs it.

In multi-agent systems, credential sprawl is compounded: a high-privilege token minted for one agent gets passed through a chain of three more, each with no mechanism to scope it down. Traditional IAM systems were not designed for this pattern. Unlike when a human uses a credential, agents using each other’s credentials create an organizational attribution gap.

Practical mitigation:

• Issue agents task-scoped, short-lived credentials instead of long-lived service account keys.
• Apply least-privilege at the agent level: each agent identity should have the minimum permissions required for its specific function, not the function of the agent that spawned it.
• Use certificate-based authentication for agent identities rather than shared secrets or inherited tokens. Certificates issued per agent type (with short validity windows) prevent credential reuse across unrelated tasks.
• Enforce authorization on every action an agent takes, and do not assume the upstream agent already verified intent.

PKI-based agent identity is the most direct structural answer to ASI03. Each agent gets a certificate that defines what it is and what it can do — and that certificate cannot be silently passed to another agent without detection.

ASI04 — Agentic Supply Chain Vulnerabilities

Agentic systems assemble their capabilities at runtime. They pull Model Context Protocol (MCP) servers, plugins, tool descriptors, and sometimes model weights from registries that may not be under organizational control. Any component fetched at runtime is a potential supply chain attack vector.

A malicious or tampered tool descriptor fetched by an agent can silently alter its behavior, and the agent has no native mechanism to detect the change.

Practical mitigation:

• Pin tool versions and verify integrity through signed manifests before loading any runtime component.
• Curate an internal registry of approved MCP servers and tool descriptors. Do not allow agents to fetch from arbitrary public registries in production.
• Implement a kill switch mechanism for any runtime component. This enables you to immediately revoke or quarantine a compromised tool or plugin upon discovery.
• Verify tool publisher identity through code signing. The SecureW2 Dynamic Cloud PKI platform can issue the signing certificates that establish a tamper-evident chain back to your organization.

ASI05 — Unexpected Code Execution

Some agents can generate and execute code as part of their task. They write and run scripts, invoke shell commands, deserialize structured data, or call interpreters directly. When attacker-controlled content reaches those code paths, the result is arbitrary code execution within the agent’s operating environment.

This is not a theoretical concern. Security researchers have demonstrated that prompt injection into a code-generating agent can produce shell commands that are executed in the same context as the agent process (with whatever file system and network access the process holds).

Practical mitigation:

• Do not allow agents to directly evaluate or execute generated code without a review or preview step.
• If code execution is a required capability, isolate it in a hardened sandbox without access to production secrets, credentials, or network paths to sensitive systems.
• Apply input validation to all data that reaches code generation paths.
• Treat generated code the same way you treat untrusted third-party code: scan it before execution, not after.

ASI06 — Memory and Context Poisoning

Long-running agents maintain persistent memory, embedding stores, RAG databases, conversation summaries, and key-value context. If an attacker can write malicious content into any of those memory systems, future agent behavior can be shaped without any further access.

Unlike goal hijacking (which affects a single session), memory poisoning can persist across sessions. An agent that retrieves poisoned embeddings weeks after the initial attack will behave as the attacker intended, with no visible sign of manipulated context.

Practical mitigation:

• Segment memory by sensitivity and source. Do not allow agent-retrieved external content to overwrite or contaminate memory derived from verified organizational sources.
• Filter all content before it is written to persistent memory stores, applying the same injection detection used at the prompt level.
• Track provenance for memory entries. Know where each stored fact came from and flag retrievals from unverified external sources.
• Expire and re-validate memory entries on a schedule rather than treating stored context as permanently trustworthy.

ASI07 — Insecure Inter-Agent Communication

Multi-agent systems route messages, task handoffs, and context between agents — often over HTTP or message queues that lack authentication, integrity protection, or semantic validation. An attacker who can intercept or inject into those channels can redirect task execution, forge agent-to-agent instructions, or escalate privileges across the agent network.

The Agent2Agent (A2A) protocol and MCP both define communication patterns for multi-agent systems. But the protocols themselves do not automatically provide transport security. Implementers must configure mutual TLS, signed payloads, and authenticated discovery. In practice, 53% of MCP servers use static API keys or personal access tokens rather than OAuth or certificate-based auth, and many agent-to-agent communication paths are unauthenticated.

Practical mitigation:

• Implement mutual TLS (mTLS) for all agent-to-agent communication. Each agent presents a certificate; the receiving agent verifies it before processing the message.
• Use signed message payloads in addition to transport security so that message integrity can be verified end-to-end even if transport is compromised.
• Enforce authenticated discovery for agent endpoints. An agent should not accept instructions from a caller that it cannot cryptographically identify.
• Add anti-replay protections (nonces or timestamps) to prevent recorded messages from being re-injected.

mTLS and PKI-issued agent certificates directly address ASI07. When every agent in a network has a verifiable identity anchored to a certificate authority your organization controls, inter-agent trust becomes explicit and auditable rather than assumed.

ASI08 — Cascading Failures

Agentic systems are increasingly composed of many agents, each with its own tools, memory, and sub-agents. An error in one agent can propagate through the entire system before any human notices. These errors include a misrouted message, a bad tool call, or a corrupted memory entry. Because agents act autonomously, a single fault may trigger a chain of downstream actions that compound the original error at scale.

Cascading failures are amplified by two patterns common in agent architectures: tight coupling between agents (where one agent’s output is another’s input with no validation step) and agents that retry failed operations aggressively without bounded backoff.

Practical mitigation:

• Establish isolation boundaries between agent components. This ensures that a failure in one does not automatically propagate to adjacent systems.
• Enforce rate limits and circuit breakers on agent-to-agent calls. An agent that receives no response should not continue retrying indefinitely.
• Test multi-step agent plans in a staging environment before deploying to production, specifically looking for failure propagation paths.
• Define and enforce rollback procedures for any irreversible action an agent can take.

ASI09 — Human-Agent Trust Exploitation

As agents become more capable and more embedded in business workflows, users begin to trust their recommendations, sometimes without scrutiny. Attackers exploit this trust by crafting scenarios where an agent presents a harmful recommendation, manipulated output, or a phishing interaction in the trusted context of a productivity tool that the user relies on daily.

This risk operates at the intersection of social engineering and AI capability. An agent that has access to a user’s calendar, email, and document history can generate highly personalized persuasion that no generic phishing message could match.

Practical mitigation:

• Require explicit human confirmation for any action that has financial, reputational, or data-access consequences above a defined threshold.
• Maintain immutable audit logs of agent recommendations and actions so that users can review an agent’s activities.
• Display clear risk indicators when an agent is about to take an irreversible action.
• Train users to understand that agent confidence does not equal agent accuracy; agents can be wrong or manipulated.

ASI10 — Rogue Agents

A rogue agent is one that has been compromised, misaligned, or that has drifted from its intended behavior, but continues to operate within the system while appearing legitimate. Rogue agents can persist across sessions, continue accumulating credentials and context, and act against organizational interests despite passing routine monitoring checks.

The risk is compounded by the difficulty of defining “normal” agent behavior. Unlike a compromised server (which behaves differently from a baseline), an agent’s behavior is inherently variable; it is designed to handle novel inputs in novel ways. Detecting rogue agent behavior requires governance infrastructure most organizations have not yet built.

Practical mitigation:

• Enforce strict governance for agent identity: agents should have defined behavioral scopes and be re-authorized when they change roles or expand permissions.
• Implement behavioral monitoring that tracks the types of actions, tools, and data sources an agent accesses over time, and alerts to deviations from established patterns.
• Establish kill switches, which enable immediate revocation of an agent’s credentials and halting of its operations without manual intervention for every deployed agent.
• Use sandboxing to limit what a potentially rogue agent can access even before you detect the problem.

How the 10 Risks Connect

These risks do not occur in isolation. A single compromised agent deployment can expose you to several simultaneously. The table below shows how each risk maps to the primary security control that addresses it.

Four of the 10 risks (ASI03, ASI04, ASI07, and ASI10) have certificate-based identity and PKI as a direct, structural mitigation. Addressing those four alone eliminates a large portion of the attack surface in multi-agent deployments.

Why Agent Identity Is the Foundational Control

A pattern runs through this list. Roughly half of the 10 risks trace back to the same root problem: agents do not have verifiable, scoped identities that other systems can check at the time of the action.

When an agent carries a shared service account key, there is no way to guarantee that only that specific agent uses it, that it is only used for the task it was issued for, or that it has not been passed to a sub-agent with different permissions. When agent-to-agent communication is unauthenticated, it’s impossible to confirm the origin of a message.

Certificate-based agent identity addresses these problems structurally:

• Each agent receives a digital certificate that identifies it by type, task scope, and organizational unit.
• Certificates can carry attributes that define what the agent is authorized to do — scoped to specific tools, data sources, or peer agents.
• mTLS using those certificates makes agent-to-agent communication cryptographically authenticated and tamper-evident.
• Short certificate validity windows (hours to days, not years) limit the window of exposure from a compromised agent identity.
• Certificate revocation provides an immediate kill switch when an agent is found to be compromised.

This is not a new concept. It is the same PKI model used for machine identity in enterprise network security, applied to a new category of workload.

How SecureW2 Supports Agentic AI Security

SecureW2 builds cloud-native PKI and certificate management infrastructure that security teams use today for network authentication. The same capabilities that secure machine identities on enterprise networks apply directly to AI agent identity.

The SecureW2 JoinNow Cloud RADIUS and Dynamic PKI platform can issue, manage, and revoke digital certificates for non-human identities. For security teams building agentic AI infrastructure, this means:

• Agent certificates issued from your organization’s managed PKI, not from a shared secret that could be exfiltrated.
• mTLS-ready certificates that enable cryptographic agent-to-agent authentication for ASI07 mitigations.
• Short-lived certificate issuance with automated renewal, so agent credentials expire frequently without manual rotation.
• Certificate revocation that takes effect immediately across the network — the kill switch that ASI10 requires.
• Centralized visibility into which agents have active credentials and what they are authorized to access.

The industry is still building AI-native security tooling for agentic systems. PKI-based identity is available today and addresses some of the most significant gaps the OWASP framework identifies.

See how certificate-based identity can close the gaps in your agentic AI deployment.

Schedule a demo