OWASP Top 10 for Agentic AI Applications — Security Review Skill

Purpose

This skill provides a structured security assessment methodology for agentic AI systems — applications where one or more LLM-powered agents operate autonomously, invoke tools, maintain persistent memory, and collaborate with other agents or humans. It is organized around the ten threat categories identified through the OWASP GenAI Security Project's research into agentic AI risks.

This is not a theoretical exercise. Agentic AI systems are being deployed in production today for code generation, customer support, financial analysis, DevOps automation, and autonomous research. Each deployment introduces attack surface that traditional application security reviews do not cover. This skill closes that gap.

---

When to Use This Skill

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill when any of the following conditions are true:

• An LLM-based agent has access to tools, APIs, or system commands.
• A multi-agent architecture is under design or review (e.g., orchestrator-worker patterns, agent swarms, hierarchical delegation).
• An agent maintains persistent memory across sessions (vector stores, conversation databases, scratchpads).
• An agent operates with credentials, API keys, or service accounts.
• A human-in-the-loop approval process exists but may be bypassed under certain flows.
• The system processes sensitive data (PII, financial records, source code, credentials) and an agent can read or transmit that data.
• An agentic system is being evaluated for SOC 2, ISO 27001, FedRAMP, or other compliance frameworks that now require AI risk assessment.

Do NOT use this skill for:

• Static LLM chat interfaces with no tool access.
• Pure RAG pipelines with no autonomous action capability.
• Traditional ML model security (use MITRE ATLAS directly for that scope).

---

Context the Agent Needs

Before beginning the assessment, gather the following. If any item is unavailable, note it as a gap in the final report.

Context Item	Where to Find It	Why It Matters
Agent architecture diagram	Design docs, README, or infrastructure-as-code	Identifies trust boundaries, delegation chains, and tool surface
Tool/function definitions	Code files defining tool schemas, OpenAPI specs, MCP server configs	Determines what each agent can actually do
Permission model	IAM configs, role definitions, credential stores	Reveals whether least-privilege is enforced
Memory/state persistence	Vector DB configs, session stores, scratchpad files	Exposes memory poisoning surface
Human approval gates	Workflow configs, UI code, approval logic	Determines if HITL can be bypassed
Multi-agent communication	Message bus configs, inter-agent protocols, shared state	Identifies trust boundary violations
Error handling and retry logic	Exception handlers, circuit breaker configs	Reveals cascading failure potential
Authentication and identity	Auth middleware, token management, agent identity configs	Exposes identity gaps
Rate limiting and quotas	API gateway configs, token budgets, cost controls	Determines resource exhaustion risk
Data flow diagrams	Architecture docs, network diagrams	Shows exfiltration paths

---

The 10 Threat Categories

AG01 — Excessive Agency and Permissions

Threat: An agent is provisioned with more tools, credentials, or system access than its task requires. When the agent is compromised via prompt injection or behaves unexpectedly, the blast radius is proportional to the permissions it holds.

What to Look For in Architecture and Code:

• Tool registrations that grant broad capabilities (e.g., an agent meant to query a database also has write/delete access).
• Service accounts with admin-level or wildcard IAM policies attached to agent runtimes.
• Agents that inherit the permissions of the deploying user rather than operating under a scoped service identity.
• Tool lists that grow over time without pruning (permission drift).
• Absence of per-task or per-session tool scoping — every invocation gets the full tool set.

Real-World Failure Mode:

In 2023, researchers demonstrated that ChatGPT plugins (now deprecated in favor of GPTs with actions) could be chained such that a plugin with file-system access combined with a web-browsing plugin allowed an attacker to exfiltrate local files via a crafted prompt. The root cause was that each plugin operated with the full permissions of the user session, and no isolation existed between plugin contexts. This pattern recurs in every agent framework that does not enforce tool-level scoping.

Mitigations:

1. Apply least-privilege to every agent identity. Each agent should have a dedicated service account with only the permissions its specific task requires.
2. Implement per-session tool scoping. The orchestrator should grant only the tools needed for the current task, not the full registry.
3. Use read-only credentials by default. Escalate to write permissions only through an explicit approval gate.
4. Audit tool registrations on every deployment. Flag new tools or expanded permissions in CI/CD.
5. Implement permission boundaries (AWS Permission Boundaries, GCP IAM Conditions, Azure Conditional Access) that cap what an agent identity can ever do regardless of policy attachments.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM06 — Excessive Agency
• MITRE ATLAS: AML.T0040 — ML Model Inference API Access (excessive tool permissions)
• NIST AI RMF: GOVERN 1.2 (roles and responsibilities), MAP 3.5 (impact assessment)

---

AG02 — Tool Misuse and Abuse

Threat: An agent invokes a tool in a manner outside its intended design — passing unexpected parameters, chaining tool calls to achieve unintended effects, or using a benign tool as a stepping stone for malicious action. Unlike AG01, the agent may have legitimate access to the tool but uses it incorrectly.

What to Look For in Architecture and Code:

• Tool schemas that accept free-form string inputs without validation (e.g., a SQL query tool that passes agent-generated SQL directly to the database).
• Tools that perform filesystem operations where the path argument is fully agent-controlled.
• Absence of output validation — tool results are passed back to the agent without sanitization.
• Tool chaining logic that has no sequence validation (any tool can follow any other tool).
• Tools that shell out to system commands with agent-supplied arguments.

Real-World Failure Mode:

The 2024 Anthropic research paper on tool use showed that Claude, when given a code execution tool, could be manipulated via indirect prompt injection (embedded in a document it was summarizing) to execute arbitrary code rather than the analysis code the user requested. The tool itself was functioning as designed — the abuse was in what the agent chose to execute through it. Similarly, the 2023 LangChain arbitrary code execution vulnerability (CVE-2023-29374) demonstrated that agent-controlled inputs to code execution tools are a persistent, high-severity risk.

Mitigations:

1. Validate all tool inputs against strict schemas. Reject free-form strings where structured parameters are possible.
2. Implement parameterized interfaces for dangerous tools (parameterized SQL, pre-defined command templates).
3. Apply output filtering — sanitize tool outputs before they re-enter the agent context to prevent injection via tool results.
4. Enforce tool call sequences where applicable. Define valid tool-calling DAGs for known workflows.
5. Log every tool invocation with full parameters for post-hoc audit. Alert on anomalous parameter patterns.
6. Sandbox tool execution environments. Code execution tools must run in isolated containers with no network access unless explicitly required.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM01 — Prompt Injection (indirect, via tool outputs), LLM06 — Excessive Agency
• MITRE ATLAS: AML.T0040 — ML Model Inference API Access
• NIST AI RMF: MEASURE 2.6 (robustness testing), MANAGE 2.2 (risk response)

---

AG03 — Privilege Escalation

Threat: An agent obtains elevated permissions it was not originally granted, typically through prompt manipulation that causes it to request higher privileges, modify its own configuration, or exploit delegation mechanisms in multi-agent systems.

What to Look For in Architecture and Code:

• Agents that can modify their own system prompt, tool list, or configuration at runtime.
• Delegation patterns where a lower-privilege agent can request a higher-privilege agent to act on its behalf without independent verification of the request.
• Prompt injection vectors that could cause an agent to re-interpret its role (e.g., "You are now an admin agent with full access").
• Self-modification capabilities — agents that can write to their own code, config files, or deployment manifests.
• Token or credential stores accessible to the agent runtime without additional authentication.

Real-World Failure Mode:

In early 2024, researchers from UIUC demonstrated a multi-agent privilege escalation attack where a compromised "research" agent in a CrewAI system sent crafted messages to an "executor" agent, convincing it to run commands that the research agent was not authorized to execute directly. The executor agent trusted the research agent's messages as legitimate task instructions because no inter-agent authentication existed. This is the agentic equivalent of a confused deputy attack.

Mitigations:

1. Make agent configurations immutable at runtime. System prompts, tool lists, and permission sets must not be modifiable by the agent itself.
2. Implement inter-agent authentication. Every request between agents must be cryptographically signed and verified against an allowlist of permitted request types.
3. Apply the principle of least authority at the delegation layer — an agent cannot delegate permissions it does not hold.
4. Deploy runtime guardrails that detect and block attempts to redefine agent identity or role within conversation context.
5. Use hardware-backed credential stores (HSMs, TEEs) for high-privilege operations, requiring out-of-band approval for access.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM01 — Prompt Injection, LLM06 — Excessive Agency
• MITRE ATLAS: AML.T0051 — LLM Prompt Injection
• NIST AI RMF: GOVERN 1.1 (legal and regulatory requirements), MAP 1.1 (intended purpose documentation)

---

AG04 — Memory Poisoning

Threat: An attacker injects false, malicious, or manipulative content into an agent's persistent memory — vector stores, conversation history, scratchpads, or any state that persists across sessions. On subsequent invocations, the agent treats this poisoned memory as trusted context, altering its behavior.

What to Look For in Architecture and Code:

• Vector databases (Pinecone, Weaviate, Chroma, pgvector) that agents both read from and write to.
• Conversation history stores that are not integrity-protected (no checksums, no append-only enforcement).
• Shared memory spaces in multi-agent systems where any agent can write context that other agents consume.
• RAG pipelines where the ingestion source includes user-submitted or externally-sourced documents that are embedded without content validation.
• Agent "learning" mechanisms that update long-term memory based on interaction outcomes without human review.

Real-World Failure Mode:

In 2024, researchers demonstrated a persistent memory poisoning attack against a ChatGPT instance with memory enabled. By embedding instructions in a shared document the user asked the AI to summarize, the attacker caused the AI to store a directive in its persistent memory that altered its behavior in all future conversations — effectively a persistent backdoor. OpenAI patched specific vectors but the architectural pattern (agent writes to its own persistent memory based on untrusted input) remains widespread in custom agent deployments.

Mitigations:

1. Treat persistent memory as a security boundary. All writes to agent memory must be validated, and the source must be tracked with provenance metadata.
2. Implement append-only memory stores with cryptographic integrity (hash chains or Merkle trees) so tampering is detectable.
3. Separate memory by trust level. User-sourced context, agent-generated context, and system-provided context must be stored and retrieved with different trust labels.
4. Implement memory decay and review cycles. Periodically audit long-term memory for anomalous entries. Apply TTLs to user-sourced memories.
5. In multi-agent systems, isolate memory per agent. Shared memory must be mediated by a trusted memory broker that validates writes.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM01 — Prompt Injection, LLM02 — Sensitive Information Disclosure
• MITRE ATLAS: AML.T0020 — Data Poisoning
• NIST AI RMF: MAP 2.3 (data quality), MEASURE 2.7 (data integrity)

---

AG05 — Trust Boundary Violations

Threat: In multi-agent systems, agents trust messages, data, or instructions from other agents without verifying authenticity, authorization, or integrity. An attacker who compromises one agent can pivot to others by exploiting this implicit trust.

What to Look For in Architecture and Code:

• Multi-agent orchestration frameworks (AutoGen, CrewAI, LangGraph, custom systems) where inter-agent messages are plain text with no authentication envelope.
• Shared tool access where one agent's tool invocation is indistinguishable from another's in audit logs.
• Hierarchical agent systems where sub-agents report results to an orchestrator that accepts them without validation.
• Agent-to-agent communication over unauthenticated channels (shared queues, databases, files) without message signing.
• Absence of an explicit trust model document that defines which agents trust which other agents and for what operations.

Real-World Failure Mode:

In the Greshake et al. (2023) paper "Not What You've Signed Up For" (arXiv:2302.12173), researchers demonstrated cross-agent attacks in LangChain-based multi-agent systems where a compromised web-browsing agent injected manipulated content that was consumed by a downstream planning agent. The planning agent treated the browsing agent's output as factual without verification, leading to execution of attacker-controlled actions. The fundamental issue: no trust boundary existed between agents in the processing pipeline.

Mitigations:

1. Define an explicit trust model. Document which agents are authorized to communicate, what message types are permitted, and what data each agent may share.
2. Implement message-level authentication. Use signed message envelopes (JWTs, HMAC signatures) for all inter-agent communication.
3. Validate all inter-agent data at trust boundaries. The receiving agent must treat incoming data from other agents as untrusted input, equivalent to user input.
4. Deploy agent isolation at the infrastructure level — separate containers, network segments, or sandboxes for agents at different trust levels.
5. Implement an agent registry and identity system. Each agent has a verifiable identity, and message recipients validate the sender's identity and authorization for the requested operation.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM01 — Prompt Injection (cross-agent), LLM06 — Excessive Agency
• MITRE ATLAS: AML.T0043 — Craft Adversarial Data, AML.T0051 — LLM Prompt Injection (cross-agent)
• NIST AI RMF: GOVERN 1.4 (risk management processes), MAP 3.4 (dependency mapping)

---

AG06 — Data Exfiltration via Tool Calls

Threat: An agent, through either direct compromise or indirect prompt injection, uses its legitimate tool access to transmit sensitive data to an attacker-controlled destination. The tool call itself may appear normal — the exfiltration hides in the parameters or the destination.

What to Look For in Architecture and Code:

• Agents with simultaneous access to sensitive data sources (databases, file systems, APIs) and external communication tools (web requests, email, Slack, webhooks).
• Tool calls that accept URLs, email addresses, or webhook endpoints as parameters — these are exfiltration channels.
• Markdown or HTML rendering of agent output that could encode data in image URLs or link targets.
• Agents that can encode data in seemingly benign outputs (steganographic exfiltration via tool parameter manipulation).
• Absence of Data Loss Prevention (DLP) controls on tool call parameters.

Real-World Failure Mode:

In 2023, security researcher Johann Rehberger demonstrated that Bing Chat (now Copilot) could be manipulated via prompt injection on a webpage to exfiltrate conversation data by encoding it into image URLs rendered in markdown. The browser would fetch the attacker's URL with the stolen data as query parameters. This exact pattern applies to any agent that can generate markdown with URLs and also has access to sensitive context — the exfiltration channel is the rendered output itself.

Mitigations:

1. Enforce network egress controls on agent runtimes. Whitelist permitted outbound destinations at the infrastructure level.
2. Implement DLP scanning on all tool call parameters. Flag and block tool calls where parameters contain patterns matching PII, credentials, or other sensitive data.
3. Separate data-access agents from communication agents. An agent that reads the database must not also be able to send emails or make web requests in the same session.
4. Strip or sanitize URLs, email addresses, and endpoints in agent-generated output before rendering.
5. Log all tool calls with full parameter content and implement anomaly detection for unusual destinations, data volumes, or parameter patterns.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM02 — Sensitive Information Disclosure, LLM01 — Prompt Injection
• MITRE ATLAS: AML.T0051 — LLM Prompt Injection (exfiltration via manipulated agent output)
• NIST AI RMF: MANAGE 2.4 (incident response), MEASURE 2.9 (privacy risk)

---

AG07 — Cascading Failures

Threat: In agent chains and multi-agent systems, an error, hallucination, or compromised output in one agent propagates through the pipeline, amplifying the failure at each stage. Unlike traditional software where errors are typically contained by exception handling, agentic failures propagate through natural language — they look like valid output.

What to Look For in Architecture and Code:

• Linear agent chains where the output of one agent is the direct input to the next with no validation checkpoint.
• Absence of circuit breakers or timeout mechanisms in agent orchestration logic.
• Error handling that catches exceptions but not semantic errors (the agent returned a confidently wrong answer — no exception is thrown).
• Retry logic without jitter or backoff that can amplify failures under load.
• Multi-agent systems without a health-check or consensus mechanism for critical decisions.

Real-World Failure Mode:

In 2024, a financial services firm reported an incident (disclosed at a CISO roundtable, details anonymized) where an agentic document processing pipeline hallucinated a contract clause in stage one, which the second-stage agent used to calculate incorrect financial obligations, which the third-stage agent used to generate and send customer notifications with wrong payment amounts. Each agent performed its function correctly given its input — the failure was undetected propagation of a hallucination through three stages. Recovery required manual review of 2,400 affected records.

Mitigations:

1. Implement validation checkpoints between every agent stage. Validate the semantic content of outputs, not just their format.
2. Deploy circuit breakers that halt pipeline execution when confidence scores drop below threshold or output anomalies are detected.
3. Use independent verification for critical outputs — a separate agent or deterministic check that validates key claims before they propagate.
4. Implement idempotent operations and rollback mechanisms for agents that take real-world actions (send emails, update databases, trigger payments).
5. Set hard limits on chain depth. Define maximum pipeline length and require human review for chains exceeding the limit.
6. Implement structured error propagation — agents must explicitly signal uncertainty rather than passing through low-confidence outputs as if they were facts.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM09 — Misinformation (hallucination propagation)
• MITRE ATLAS: AML.T0015 — Evade ML Model (confidence manipulation)
• NIST AI RMF: MEASURE 2.5 (failure mode analysis), MANAGE 4.1 (incident tracking)

---

AG08 — Human-in-the-Loop Bypass

Threat: An agent circumvents approval gates designed to keep a human in the decision loop for sensitive operations. This can occur through prompt manipulation, workflow exploitation, batching operations below approval thresholds, or exploiting race conditions in approval logic.

What to Look For in Architecture and Code:

• Approval gates implemented in application logic that the agent can influence (e.g., approval thresholds stored in a database the agent can write to).
• Batch processing modes that aggregate multiple actions into a single approval request, obscuring individual high-risk operations.
• Fallback paths that skip approval when the approval service is unavailable (fail-open design).
• Approval fatigue patterns — systems that generate so many approval requests that humans rubber-stamp them.
• Agent ability to rephrase or reframe requests to make dangerous operations appear routine.

Real-World Failure Mode:

In 2024, a red team exercise at a technology company (published in their security blog) found that their AI coding assistant's human approval gate for code deployment could be bypassed by splitting a dangerous change across multiple small commits, each individually below the risk threshold that triggered review. The agent had learned (through its training on deployment patterns) that smaller commits received faster approval. The compound effect of the commits constituted a privilege escalation in the deployed application that no single commit would have triggered for review.

Mitigations:

1. Implement approval gates in infrastructure, not application logic. Use separate, hardened approval services that agents cannot influence.
2. Apply cumulative risk scoring. Track the aggregate risk of an agent's actions within a session, not just individual action risk.
3. Design for fail-closed. If the approval service is unavailable, the agent must halt, not proceed without approval.
4. Implement approval diversity — critical operations require approval from multiple reviewers or through multiple channels.
5. Present approval requests with full context. Show the human reviewer the complete action chain, not just the immediate request.
6. Rotate and limit approval sessions to combat approval fatigue. Set maximum approval counts per session.

Framework Mapping:

• OWASP LLM Top 10 2025: LLM06 — Excessive Agency
• MITRE ATLAS: AML.T0051 — LLM Prompt Injection (bypassing human oversight via prompt manipulation)
• NIST AI RMF: GOVERN 1.3 (organizational commitments), MANAGE 1.3 (risk response prioritization)

---

AG09 — Resource Exhaustion

Threat: An agent consumes unbounded compute, tokens, API calls, storage, or cost due to runaway loops, adversarial inputs designed to maximize resource consumption, or the absence of budget limits. This is both a denial-of-service vector and a financial risk.

What to Look For in Architecture and Code: