AI agents are no longer limited to answering questions. They can search company knowledge, call APIs, create code, update customer records, move files and trigger business workflows. That ability changes the security question from “Can the model produce a bad answer?” to “Can manipulated instructions cause an unauthorized action?”
The OWASP Top 10 for Agentic Applications 2026 gives security and engineering teams a shared vocabulary for that problem. It describes risks that emerge when a model is given goals, memory, tools, identities and the freedom to act over multiple steps. For enterprises deploying copilots or autonomous workflows, the list is a practical starting point—but it is not a substitute for threat modelling and hands-on testing.
This guide explains each risk in operational language, shows what testers should examine and turns the framework into an actionable security programme.
Why agentic applications require a different security model
A conventional web application receives a request and follows code written by developers. An agent interprets natural language, builds a plan and may choose tools dynamically. Its path can change when a document, email, web page, memory record or tool response changes the model’s context.
That does not make conventional controls obsolete. Authentication, authorization, input validation, secure coding, logging and dependency management remain essential. The difference is that these controls now surround a probabilistic decision-maker. The model must never become the final authority for access or high-impact actions.
An enterprise agent commonly includes several trust boundaries:
- A user interface that accepts requests and attachments.
- A system prompt and policy layer that shape behaviour.
- Retrieval systems that bring external or internal content into context.
- Long-term memory that can influence later sessions.
- Tools and APIs that read or change business data.
- A service identity, OAuth token or API key used to call those tools.
- Logs, traces and evaluation platforms that may store sensitive prompts.
A useful assessment follows data and authority across this entire path. Testing only the chat response can miss a successful unauthorized tool call hidden behind a polite message.
ASI01: Agent Goal Hijack
Agent goal hijack happens when malicious or conflicting instructions redirect the agent from its intended objective. The payload may arrive directly from a user or indirectly through a document, ticket, webpage, email or retrieved record.
Consider a procurement assistant that reads supplier documents. A hidden instruction inside an uploaded PDF asks the agent to ignore the buyer’s request, locate confidential pricing and send it to an external address. A prompt-only defence may fail because the document is part of the same model context as the trusted policy.
Controls should separate instructions from untrusted data, label provenance, limit tool authority and require an out-of-band approval for sensitive actions. Testing should include indirect injections in every format the agent consumes and verify the actual tool outcome, not just the final wording.
ASI02: Tool Misuse and Exploitation
A legitimate tool can be dangerous when called with the wrong arguments, at the wrong time or on behalf of the wrong user. An agent that can “send email” may be manipulated into sending confidential information. A “run report” tool may accept an unvalidated query that exposes another tenant’s data.
Tools need narrow schemas, allowlisted operations, server-side validation, rate limits and explicit business rules. Separate read and write capabilities. High-impact operations—payments, account changes, production deployments or bulk exports—should require deterministic approval outside the model.
During testing, modify identifiers, replay calls, supply unexpected data types, chain harmless tools into a harmful workflow and check whether the API independently authorizes the user, resource and action.
ASI03: Identity and Privilege Abuse
Agents frequently operate through non-human identities such as service accounts, API keys and OAuth tokens. Giving an agent a broad shared credential is convenient during a pilot, but it creates a large and poorly understood blast radius.
The application should preserve the requesting user’s identity through every downstream call. Permissions should be short-lived, scoped to the task and evaluated server-side. Security teams need an owner, inventory, rotation process and emergency revocation path for every agent identity.
Test horizontal access between users and tenants, vertical escalation from ordinary to administrative actions, token replay, stale permissions and behaviour after access is revoked. Our related guide to zero trust for AI agents explains how identity and runtime controls work together.
ASI04: Agentic Supply Chain Vulnerabilities
An agent depends on models, frameworks, packages, prompts, skills, plugins, MCP servers, vector databases and external APIs. A compromised component can alter instructions, steal credentials or introduce unsafe actions without changing the main application code.
Maintain an approved inventory and pin versions where possible. Verify package provenance, review tool definitions, monitor changes and restrict installation sources. Treat prompts, skills and tool descriptions as executable security-relevant assets. They need ownership, review and rollback just like code.
Testing should examine installation workflows, update channels, dependency confusion, unsigned artifacts, hidden instructions and what happens when a trusted component changes after approval. See the existing software supply chain security testing guide for the broader programme.
ASI05: Unexpected Code Execution
Coding agents and automation agents may generate or execute commands. Untrusted instructions can turn that feature into remote code execution, destructive file operations or credential theft. The risk increases when an agent runs with a developer’s full workstation or cloud permissions.
Use isolated environments, restricted filesystems, egress controls, allowlisted commands and short-lived credentials. Separate code generation from execution. Require review for dependency installation, production access and destructive operations. Generated code and commands must be treated as untrusted until validated.
Test command injection through prompts, repository files, issue text, tool output and package metadata. Confirm that secrets, SSH keys and cloud metadata remain inaccessible even if the agent attempts an unexpected command.
ASI06: Memory and Context Poisoning
Agent memory can preserve preferences, summaries and facts across sessions. If an attacker can seed false or malicious content, the agent may behave incorrectly long after the original interaction has ended. Retrieval indexes can create a similar persistence problem.
Store provenance, tenant and ownership metadata with every memory record. Validate writes, limit retention, isolate tenants and provide deletion and review workflows. Security-sensitive instructions should not be learned automatically from ordinary conversation.
Test whether one user can influence another user’s memory, whether deleted content remains retrievable, whether untrusted documents can create durable rules and whether poisoned context survives a reset. Monitor unusual memory changes as carefully as unusual tool calls.
ASI07: Insecure Inter-Agent Communication
Multi-agent systems delegate tasks between planners, researchers, coders and reviewers. Messages between agents can be spoofed, altered or interpreted with more trust than they deserve. A low-trust research agent should not be able to impersonate an approval agent.
Authenticate agent-to-agent messages, bind them to a workflow and verify integrity. Define which agent may request each action and what evidence must accompany the request. Avoid passing unrestricted natural language into privileged execution contexts.
Testing should alter sender identity, replay old messages, inject instructions into delegated results and attempt to bypass an approval step by claiming that another agent already approved it.
ASI08: Cascading Failures
One incorrect output can become the input to several downstream actions. An inaccurate risk score may block customers; a mistaken configuration change may propagate across environments; repeated agent retries may exhaust resources.
Design bounded workflows with transaction limits, timeouts, circuit breakers and rollback. Validate critical intermediate results and prevent a single agent from both proposing and approving the same high-impact change. Observability should connect the original request to every subsequent action.
Red-team tests should examine loops, duplicated events, partial failures, conflicting agents and recovery after an upstream system supplies false information.
ASI09: Human-Agent Trust Exploitation
People can over-trust confident output, especially when an agent presents a polished explanation or claims that a check has already been completed. Attackers may exploit that trust to obtain approval for a harmful action.
Interfaces should clearly distinguish facts, assumptions, external content and proposed actions. Show the exact resource, scope and effect before approval. High-risk confirmations should occur outside content that the model can manipulate.
Test misleading summaries, hidden side effects, ambiguous button labels and approval fatigue. A reviewer should be able to understand what will happen without reading a long conversational history.
ASI10: Rogue Agents
A rogue agent operates outside its intended goals or governance boundaries. The cause may be malicious manipulation, configuration drift, compromised dependencies or poorly constrained autonomy rather than science-fiction-style intent.
Every agent needs clear operational limits, an owner, monitoring and a kill switch. Deny by default when identity, policy or context is uncertain. Separate duties, cap resource use and require approval for irreversible actions.
Testing should verify that the agent cannot disable its own monitoring, create unapproved identities, expand its permissions, hide actions or continue operating after revocation.
Turning the OWASP list into an assessment plan
Framework adoption often fails when teams turn the ten categories into a checkbox. A better approach maps each risk to the organisation’s actual agent architecture and business outcomes.
1. Inventory agents and capabilities
Record owner, purpose, users, model, prompts, tools, data sources, memory, identities, environments and business impact. Include pilots and department-built agents. Unknown agents cannot be governed or tested.
2. Map the action path
Diagram the route from user to model, retrieval, memory, tool gateway and target system. Mark trust boundaries and the points where authentication, authorization, validation, approval and logging occur.
3. Write business abuse cases
Use scenarios such as “a support user asks the agent to export another customer’s records” or “a poisoned document attempts to initiate a payment.” Business language exposes impact more clearly than a generic jailbreak list.
4. Build an evidence-based test matrix
For every abuse case, identify test identities, inputs, expected controls, observed tool calls and acceptance criteria. Use synthetic records and a representative staging environment. Capture server-side evidence without performing destructive actions.
5. Retest after remediation
Models, prompts, tools and permissions change frequently. Convert confirmed findings into regression tests and rerun them after material changes. An annual assessment alone is not enough for an agent that changes every week.
Enterprise control checklist
Before production deployment, confirm that:
- Every agent and tool has a named business and technical owner.
- Tools are allowlisted and use least-privilege, short-lived credentials.
- APIs authorize every user, action, tenant and object independently.
- Untrusted content cannot become privileged instructions.
- Memory and retrieval are tenant-isolated and support deletion.
- High-impact actions require deterministic approval.
- Generated code and tool arguments are validated before execution.
- Agent, skill, plugin and MCP changes are reviewed and monitored.
- Logs connect prompts, policy decisions, tool calls and outcomes.
- Tokens can be revoked and agents can be stopped quickly.
- Resource limits prevent runaway loops and cascading failures.
- A repeatable adversarial regression suite runs before releases.
Where penetration testing adds value
Architecture reviews identify intended controls; penetration testing checks whether those controls survive realistic abuse. A scoped penetration testing service can combine application and API testing with agent-specific scenarios such as indirect prompt injection, tool misuse, memory poisoning and identity abuse.
Detox’s AI agent red teaming checklist provides practical test cases, while the MCP security guide covers connected tool servers in greater depth.
The goal is not to collect dramatic prompts. It is to demonstrate whether a manipulated agent can cause an unauthorized business outcome and whether defenders can detect, contain and recover from it.
Frequently asked questions
Is the OWASP Agentic Top 10 a compliance standard?
No. It is a risk-awareness and guidance framework. Organisations should map it to their architecture, regulatory obligations and existing security programme rather than treating it as a certificate.
Is agentic AI security testing the same as an LLM jailbreak test?
No. Jailbreak testing focuses mainly on model behaviour. Agentic testing also covers identities, permissions, tools, APIs, memory, retrieval, supply chain, monitoring and real downstream actions.
When should an AI agent be tested?
Test before production and after material changes to models, system prompts, tools, permissions, memory, retrieval sources or external providers. Run smaller regression tests continuously between independent assessments.
Can an agent be secure if prompt injection cannot be eliminated completely?
Yes, if architecture limits the consequence. Treat model output as untrusted, enforce authorization in deterministic systems, constrain tools and require approval for high-impact operations. The objective is preventing unauthorized outcomes, not claiming that every malicious phrase will be recognised.
What should be tested first?
Start with the agent’s highest-impact tool and broadest credential. Verify who can invoke it, which records it can access, whether arguments are validated and how access is revoked. Then test indirect prompt injection through the content the agent routinely reads.
Conclusion
The OWASP Top 10 for Agentic Applications 2026 captures a fundamental shift: AI systems are becoming operational actors. Their security depends on much more than model alignment or a carefully written prompt.
Strong programmes combine least privilege, deterministic authorization, untrusted-content handling, constrained tools, protected memory, supply-chain governance, human approval and end-to-end monitoring. Security testing validates whether those controls hold when an attacker manipulates the same documents, identities and integrations the agent uses every day.
Choose one production-bound agent, map every action it can take and test the paths that could affect data, money, access or infrastructure. That focused exercise will produce more useful risk reduction than a generic list of jailbreak prompts—and it creates the foundation for safely scaling agentic AI.
