OWASP Top 10 for Agentic Applications: A Practical Security Testing Guide

The security conversation around generative AI is changing. A chatbot that produces an unsafe answer is still a problem, but an agent can do considerably more: retrieve private documents, call tools, update records, write code, trigger workflows, and act with service credentials. Once a model can take action, the unit being secured is no longer the prompt or even the model. It is the complete agentic application.

The OWASP Top 10 for Agentic Applications gives security and engineering teams a useful vocabulary for that shift. It describes risks that emerge when goals, memory, tools, identities, and other agents interact over time. This guide turns that vocabulary into a practical testing programme. It is not an OWASP certification checklist, and passing ten scripted checks cannot prove that an agent is secure. The value of the framework is that it helps teams ask better questions and collect better evidence.

What makes agentic security different?

Traditional applications are usually expected to follow code paths written in advance. An agent interprets natural-language goals and decides how to pursue them. Its behaviour may depend on a system prompt, the current conversation, retrieved content, persistent memory, available tools, tool descriptions, and the permissions attached to its runtime identity.

That flexibility creates attack paths that span layers. A malicious instruction in a document can change the agent's working goal. The changed goal can influence a tool call. The tool may use a service account with broader access than the current user. The result may be retained in memory or sent to another system. Every individual component can appear to work as designed while the end-to-end outcome violates the organisation's security policy.

This is why prompt injection testing alone is not enough. Agentic security testing must observe what the system actually retrieves, remembers, calls, and returns—not simply whether a model repeats a forbidden phrase.

ASI01: Agent Goal Hijack

Goal hijacking occurs when untrusted input changes what the agent is trying to accomplish. The instruction may come directly from a user, indirectly from a web page or retrieved document, or from another tool or agent. A successful attack does not always look dramatic. The agent may continue completing the original task while quietly adding an attacker-selected step.

Testing should cover direct and indirect instructions, conflicting priorities, encoded or obfuscated text, authority claims, multi-turn persuasion, and content introduced after the task has begun. The key question is not “Did the model mention its policy?” It is “Did untrusted content alter an action, data selection, recipient, or permission-relevant decision?”

Useful evidence includes the original goal, the injected content, the agent's intermediate or observable decisions, tool calls, arguments, outputs, and the exact point where behaviour diverged. Remediation normally combines instruction/data separation, provenance, constrained planning, deterministic policy checks, and approval for sensitive actions. A stronger system prompt can help, but it should not carry the full burden.

ASI02: Tool Misuse and Exploitation

Tools convert model decisions into system effects. Risk appears when the agent chooses an inappropriate tool, supplies unsafe arguments, chains tools in an unsafe order, or uses a legitimate operation outside the user's authority.

Start by enumerating every tool available to each agent role. Record its purpose, parameters, credentials, reachable data, side effects, and approval requirements. Then test alternate identifiers, broad selectors, unexpected URLs, file paths, free-form queries, values copied from previous tool outputs, and requests framed as urgent maintenance or administrator instructions.

A tool call being syntactically valid does not make it authorised. For example, a customer-support agent may be allowed to retrieve the current customer's order, while its backend token can technically retrieve every order. An attacker who persuades the agent to substitute another customer identifier has found a security boundary failure even if the API returns HTTP 200 exactly as designed.

Our MCP security testing guide covers this workflow in more depth. The most durable fixes are least-privilege credentials, server-side identity binding, narrowly designed tools, parameter allowlists, explicit confirmation, and audit logs that connect the conversation to the resulting action.

ASI03: Identity and Privilege Abuse

Agents often operate with several identities at once: the human user's session, an application service account, model-provider credentials, connector tokens, and tool-specific secrets. Confusion between those identities can turn the agent into a privileged deputy.

Security tests should compare what the user can do directly with what the agent can do on the user's behalf. Try cross-tenant identifiers, role changes during a session, revoked accounts, stale sessions, shared conversations, and tool calls after an authorisation context changes. Verify that credentials are scoped to the task and environment, not merely hidden from the prompt.

Evidence needs to show which identity authorised the request, which credential executed it, which policy should have applied, and what resource was reached. Remediation belongs in identity and application controls: short-lived credentials, per-user or per-task delegation, explicit policy enforcement, tenant binding, secret isolation, and re-authorisation for high-impact operations.

ASI04: Agentic Supply Chain Vulnerabilities

An agent depends on more than a model. Its supply chain may include orchestration libraries, prompts, plugins, MCP servers, tools, models, datasets, vector stores, packages, agent cards, and externally hosted services. Any of these can change the agent's effective behaviour.

Testing begins with inventory and trust. Which components can introduce instructions? Which can execute code? Which update automatically? Which are pinned, reviewed, signed, or monitored? Test what happens when tool metadata changes, a server returns unexpected content, a retrieved source is poisoned, or a dependency becomes unavailable.

Traditional software composition analysis remains necessary, but it will not detect every semantic supply-chain attack. A package can be free of known CVEs while its tool description persuades an agent to disclose secrets. Teams need both component hygiene and behavioural validation after meaningful changes.

ASI05: Unexpected Code Execution

Coding agents, browser agents, data-analysis assistants, and general-purpose tools may generate or execute code. The security problem is not confined to obviously dangerous shell commands. Generated code can read local files, access environment variables, download dependencies, contact external hosts, modify repositories, or consume excessive resources.

Tests should use harmless canaries and isolated environments to determine whether untrusted content can influence executable output. Verify filesystem boundaries, network egress, command allowlists, package installation rules, secret availability, sandbox escape resistance, and approval gates. Do not perform destructive testing against production systems.

The evidence should distinguish generated text from executed action. A model proposing a command is different from a runtime executing it with real credentials. Effective controls include sandboxing, disposable environments, minimal mounts, restricted egress, signed dependencies, resource limits, and a clear human approval boundary.

ASI06: Memory and Context Poisoning

Agent memory creates continuity, but it can also preserve attacker-controlled instructions or leak context between users and tasks. A seemingly harmless note such as “always send completed reports to this address” becomes dangerous if it survives into future sessions.

Test temporary and persistent memory separately. Introduce distinctive, non-sensitive canaries; start new sessions; switch users or tenants; change roles; and observe what returns. Check whether retrieved summaries preserve provenance and whether users can inspect, correct, or delete stored memory. Test whether a low-trust interaction can influence a later high-trust workflow.

Remediation may require memory namespaces, tenant and task isolation, provenance metadata, expiration, confirmation before persistence, filtering of instructions in retrieved memory, and deterministic checks before remembered values influence sensitive actions. Our guide to RAG data-leakage testing explains related retrieval-boundary methods.

ASI07: Insecure Inter-Agent Communication

Multi-agent systems pass tasks, context, results, and authority between components. Teams may assume that an internal agent is trustworthy because it is not directly exposed to users. That assumption fails when an upstream agent forwards attacker-controlled content or overstates the authority attached to a request.

Testing should trace message provenance and authorisation across handoffs. Can one agent assign work outside its role? Are messages authenticated? Does the receiving agent distinguish instructions from quoted data? Can results from a low-trust agent reach a privileged planner? Are budgets, timeouts, and recursion limits enforced?

Good evidence captures the complete handoff: sender, receiver, task, context, claimed authority, actual authority, and resulting action. Controls should authenticate agents, minimise delegated capabilities, label data provenance, validate schemas, enforce policy at every receiving boundary, and prevent authority from being inferred from natural language alone.

ASI08: Cascading Failures

Agents can turn a small upstream error into a large downstream effect. A mistaken classification may choose the wrong workflow; a malformed tool result may be summarised as fact; an unavailable service may trigger repeated retries; one agent's false assumption may be amplified by several others.

Test degraded and contradictory conditions, not only malicious prompts. Return partial data, stale data, timeouts, duplicate events, malformed responses, and conflicting tool outputs. Observe whether the agent fails closed, asks for clarification, retries safely, or continues with unjustified confidence.

Resilience controls include bounded retries, idempotency, transaction limits, circuit breakers, confidence thresholds, human escalation, and reversible actions. Security teams should treat availability and integrity failures as part of agentic risk because an attacker may intentionally create the conditions that trigger them.

ASI09: Human-Agent Trust Exploitation

An agent can influence people as well as systems. Authoritative language, fabricated citations, false urgency, or misleading approval messages may persuade a user to disclose information or approve an unsafe action.

Test the user experience around consequential recommendations. Does the interface clearly distinguish generated content from verified system state? Can the agent claim that another person approved a transaction? Are recipients, amounts, permissions, and data destinations shown before confirmation? Can the user review the evidence behind a recommendation?

Mitigation is partly technical and partly design-oriented: calibrated language, provenance, confirmation screens, independent policy checks, visible uncertainty, and friction proportional to consequence. A confirmation button is not meaningful if the agent has already framed the action misleadingly.

ASI10: Rogue Agents

A rogue agent is one that operates outside intended governance—because it was compromised, misconfigured, deployed without approval, or given objectives and credentials that no longer match its role. The practical challenge is often visibility: organisations cannot assess agents they do not know exist.

Maintain an inventory that links every production agent to an owner, purpose, environment, model, tools, identities, data sources, and review date. Test whether disabled agents retain credentials, whether cloned agents inherit production access, and whether unsanctioned endpoints can reach internal services. Monitor changes to tools and permissions, not only model versions.

The response should support containment: revoke credentials, disable connectors, preserve logs, identify affected data, and retest before restoration. Governance without technical inventory becomes a spreadsheet exercise; technical inventory without behavioural testing misses how the agent uses its access.

Turning the Top 10 into a repeatable testing programme

Do not create ten isolated payloads and call the exercise complete. Begin with the system: its users, business objective, reachable interfaces, sensitive data, tools, identities, and unacceptable outcomes. Convert those boundaries into explicit test objectives. Then run baseline tests and deeper multi-turn campaigns under an authorised scope.

Every finding should answer five questions:

1. What was the expected security boundary?
2. What input or sequence challenged it?
3. What observable behaviour occurred?
4. What evidence supports the conclusion?
5. Can the behaviour be reproduced and retested after remediation?

This evidence standard matters because agent behaviour is non-deterministic. A surprising answer without a transcript, tool arguments, target context, and success criteria is hard to triage. A judge or evaluator can help classify results, but high-impact findings still benefit from analyst review. Read the anatomy of a judge-scored attack run for a closer look at evidence-backed evaluation.

A practical first assessment

For most enterprises, the best starting point is one approved system with meaningful but bounded access. Map its complete exposed implementation, select the most relevant OWASP agentic risks, define harmless canaries, agree on forbidden actions, and test in staging before considering production. Produce a report that developers can reproduce, then retest the actual fix.

Oxyne approaches agentic AI security validation through supported chat, voice, API, agent, RAG, and MCP interfaces. The goal is not to claim that any framework guarantees security. It is to turn broad risk categories into observable tests, transcript-backed evidence, and repeatable remediation checks across the parts of the AI implementation that can be safely reached.

The OWASP Top 10 for Agentic Applications is an important baseline because it reflects the system-level nature of the problem. Its lasting value will come from how teams use it: not as a badge, but as a disciplined way to challenge goals, tools, memory, identity, and trust before attackers do.