Agentic AI Security Risks: The OWASP Top 10 and How to Fix Them

The OWASP Top 10 for Agentic Applications for 2026, published by OWASP's Agentic Security Initiative on December 9, 2025, identifies the top security risks for autonomous AI agents, including Agent Goal Hijack and Tool Misuse. The taxonomy highlights that agentic AI breaks traditional security models because agents authenticate with non-human identities, decide their own paths, and can act on poisoned instructions, making identity controls central to mitigation.

Agentic AI Security Risks: The OWASP Top 10 and How to Fix Them An AI agent does not stop at an answer. It issues the refund, opens the pull request, and calls three other agents. Every step runs against a real system with real credentials. The old question was whether a model produced bad text. The live one is what an identity did with its access, and who owns it. What is agentic AI security? what-is-agentic-ai-security Agentic AI security is the practice of controlling what autonomous AI agents /glossary/agentic-ai can reach, do, and change inside an enterprise. It covers the agent's identity, the credentials it holds, the tools it calls, the data it touches, and the audit trail it leaves. That puts agentic AI security between two disciplines that rarely talk. One studies how models get manipulated: prompt injection, poisoned context, tool abuse. The other governs who holds access to what, the core of identity security /glossary/identity-security . An injected instruction is only as dangerous as the permissions behind it. This guide maps the landscape and the control for each risk. For an executive briefing on exposure and budget, read a CISO's guide to agentic AI /guides/a-cisos-guide-to-agentic-ai . For the architecture behind ephemeral agent identities, read agentic identity governance /guides/agentic-identity-governance . Why agentic AI breaks traditional security models why-agentic-ai-breaks-traditional-security-models Traditional application security asks whether a system produced the wrong output. Agentic systems move the question. An agent that summarizes a document badly wastes your time. An agent with a write-scoped token acting on a poisoned instruction issues refunds, deletes rows, or grants access. The exposure is the action, and the action runs on an identity. It holds a token, service account, or API key. There is no session to watch and no login tied to a person, which makes it a An agent /c1-academy/what-is-an-agent authenticates on its own. non-human identity /glossary/what-are-non-human-identities . An agent decides its own path. Static review assumes a known call graph. An agent picks which tool to call, in what order, based on input you do not control. An agent lives for minutes or for years. Some spin up per task and vanish. Some outlive the team that built them. Joiner-mover-leaver has no event for either. An agent talks to other agents. Permissions compound across the chain, and the identity that started the request disappears after the second hop. Your identity stack was built for humans /blog/identity-stack-built-for-humans , which is also why IAM, IGA, and PAM break in the agentic enterprise /blog/why-iam-iga-and-pam-break-in-the-agentic-enterprise . The OWASP Top 10 for Agentic Applications the-owasp-top-10-for-agentic-applications OWASP's Agentic Security Initiative published the OWASP Top 10 for Agentic Applications for 2026 https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ on December 9, 2025. It is the first threat taxonomy built for systems that plan and act rather than systems that only generate text. The ten categories map onto controls, and most of those controls are identity controls. ASI01: Agent Goal Hijack asi01-agent-goal-hijack An attacker rewrites the agent's objective by planting instructions in content it reads. A support agent opens a ticket attachment telling it to export the customer table and treats that as a task rather than as data. The model was not compromised. The objective was. Treat every retrieved document, page, and tool response as input that cannot issue instructions, and require explicit authorization for consequential actions /products/ai-agent-authorization . ASI02: Tool Misuse asi02-tool-misuse The agent uses a legitimate tool in a way nobody intended. A tool granted for reading logs runs a destructive query. An HTTP tool becomes an exfiltration path. Scope tools per agent and mediate calls through an AI access gateway /products/ai-access-gateway that evaluates policy at call time. If a contractor with the same token could not make that call, neither should the agent. ASI03: Identity and Privilege Abuse asi03-identity-and-privilege-abuse The agent runs as an identity carrying far more access than its task requires, usually a shared service account someone reused to make a pilot work. It inherits every entitlement that account collected, and the logs name the account rather than the agent. Give every agent its own identity, apply least privilege /glossary/least-privilege , replace standing access with zero standing privilege /glossary/zero-standing-privilege , and keep the requesting human's identity attached. ASI04: Agentic Supply Chain Vulnerabilities asi04-agentic-supply-chain-vulnerabilities Agents assemble themselves from parts you did not write: model endpoints, tool definitions, and MCP servers /glossary/mcp-server pulled from public registries. A tool description is an instruction the model reads, so an updated third-party server changes agent behavior. Catalog every component, pin versions, and prefer sources you control, because MCP ships no governance layer /blog/what-mcp-doesnt-include-governance . Treat a new MCP server like a new vendor with database access. ASI05: Unexpected Code Execution asi05-unexpected-code-execution Coding and analysis agents generate code and then run it. That path inherits whatever the runtime holds: environment variables, instance credentials, network reach. An agent asked to chart revenue writes a script that reads a credentials file and posts it outbound. Run generated code in a sandbox with no ambient credentials and controlled egress. Broker credentials for the run rather than leaving them in the environment. ASI06: Memory and Context Poisoning asi06-memory-and-context-poisoning Agents keep state. Vector stores, conversation memory, and shared knowledge bases persist across sessions, so one poisoned entry keeps working long after the attacker leaves. Plant a document naming an approver as authorized for production changes, and the agent keeps citing it as fact. Track provenance on memory writes, scope memory to one agent and tenant, expire entries, and gate writes from untrusted sources. ASI07: Insecure Inter-Agent Communication asi07-insecure-inter-agent-communication Multi-agent systems pass work over channels with no authentication and no integrity checking. An orchestrator accepts a worker agent's claim that the requester was already validated, and the original requester disappears after the first hop. Authenticate every agent to every other agent, sign messages, and carry the initiating identity and its scope through the chain. This is what cross-app access /glossary/what-is-cross-app-access-xaa solves between applications, applied to agents. ASI08: Cascading Failures asi08-cascading-failures One wrong action becomes twelve. An agent misclassifies accounts as inactive, a second agent opens tickets from that list, and an automation deprovisions them. Each system behaved correctly on the input it received. Bound the blast radius /glossary/what-is-blast-radius-in-cybersecurity deliberately: rate limits on writes, caps on how many records one run may change, and a human checkpoint before anything irreversible. ASI09: Human-Agent Trust Exploitation asi09-human-agent-trust-exploitation The weak link is often the approval. An agent presents a confident summary, the approver clicks yes on the summary rather than the action, and the scope of the grant never gets read. Ten approvals a day get scrutiny. Two hundred get pattern-matched. Show the approver the concrete action and its scope, not the agent's description of it. Keep approvals attributable to a named person. ASI10: Rogue Agents asi10-rogue-agents An agent operates outside your governance entirely. Someone built it for a pilot and left the company. It was never inventoried, its credentials never rotated, and it still runs nightly against production. Compromised agents land in the same category. The control is unglamorous: continuous discovery, a named owner for every agent, and a decommissioning process that fires. Unowned agents become orphaned accounts /glossary/orphaned-accounts with live credentials. What agentic AI risk looks like in reality what-agentic-ai-risk-looks-like-in-reality Adoption is ahead of control /blog/the-inevitable-ai-wave-modeling-the-ai-agent-explosion . Surveys from the past year put numbers on the gap: agents nobody inventoried, incidents nobody expected. The figures below come from IBM, Gartner, the Cloud Security Alliance, and Deloitte, and none of them are about model accuracy. Most organizations do not know what is running. The Cloud Security Alliance's April 2026 survey found 82% of enterprises have unknown AI agents in their IT infrastructure and only 21% have formal decommissioning processes. 65% reported an AI agent-related incident in the past 12 months. Of those, 61% reported data exposure, 43% operational disruption, and 35% financial losses. Access controls are the gap. IBM's Cost of a Data Breach Report 2025 found 13% of surveyed organizations experienced an attack that impacted their AI models or applications, and a further 8% did not know whether they had been compromised. Among breached organizations with an AI-related incident, 97% lacked proper AI access controls and 63% either had no AI governance policy or were still developing one. Breaches involving shadow AI cost $670,000 more on average, $4.63M against $3.96M. Weak controls are already killing projects. Gartner predicted in June 2025 that "Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls." The same forecast expects at least 15% of day-to-day work decisions to be made autonomously through agentic AI by 2028, up from 0% in 2024. Governance maturity is the outlier. Deloitte's January 2026 survey of 3,235 leaders across 24 countries found only 21% report a mature governance model for agentic AI, while 74% expect to use AI agents at least moderately by 2027. Why identity is the control plane for agentic AI security why-identity-is-the-control-plane-for-agentic-ai-security Every risk in the OWASP list ends the same way: an agent used access it should not have had, or used access nobody could attribute to an owner. Model-layer defenses reduce how often an agent is tricked. Identity controls decide what a tricked agent can actually reach. That is the durable layer. The reason is arithmetic. New injection techniques ship weekly, and each needs a new detection. Scope, ownership, and revocation apply to attacks that do not exist yet. An agent restricted to one read-only dataset with a credential that expires in an hour is contained however cleverly it was manipulated. Treating agents as identities gives you mechanics you already run. An identity has an owner, a lifecycle, a set of entitlements /glossary/what-are-entitlements someone approved, and a revocation path. None of that has to be invented for agents, only extended to them, which is the practical work of building an agentic enterprise /blog/defining-the-agentic-enterprise . Human versus non-human identities /c1-academy/human-vs-non-human-identities covers where the two populations differ. Agentic AI security belongs on the same identity security platform /products/identity-security-platform that governs employees, contractors, and service accounts. The data only helps if it is all in the same platform. The four layers of agentic AI security the-four-layers-of-agentic-ai-security Agentic AI security divides into four jobs, and most programs are strong at one and absent on the rest. Find what is already running. Get the credentials out of config files and under management. Decide what each agent may do at the moment it tries. Then keep finding and fixing the identity risk that remains. Discover what is running discover-what-is-running Discovery covers two surfaces: cloud and identity providers, where agents and service principals live, and developer endpoints, where AI tools, local MCP servers, and credential files accumulate. Shadow AI /guides/shadow-ai covers that surface, and shadow AI discovery /solutions/shadow-ai-discovery is where the inventory lands. Secure the credentials secure-the-credentials Agent credentials are the most concentrated risk in the stack: long-lived, over-scoped, often sitting in a config file on a laptop. Move them into managed storage, scope each to one agent, rotate on a schedule, and issue short-lived credentials. Securing AI agent credentials /guides/securing-ai-agent-credentials covers the model. Govern actions at runtime govern-actions-at-runtime Static permissions cannot express "this agent may read customer records but never export them." Runtime governance evaluates each tool call against policy as it happens, allows it, blocks it, or routes it for approval, and writes an audit event. AI agent runtime security /guides/ai-agent-runtime-security covers placement. Detect and remediate identity risk detect-and-remediate-identity-risk The first three layers leave residue: agents with no owner, service accounts misclassified as human, identities whose reach outgrew their purpose. This layer closes that gap through governed action rather than a dashboard, using the discipline in non-human identity management /guides/non-human-identity-management . How to build an agentic AI security program how-to-build-an-agentic-ai-security-program The sequence below works because each step produces what the next step needs: an inventory produces owners, owners produce scope decisions, scope decisions produce reviewable entitlements. Each step builds towards a better agentic AI security program. 1. Inventory every agent and agent identity 1-inventory-every-agent-and-agent-identity Enumerate platform-native agents, service principals, managed identities, app registrations, service accounts, and the MCP servers your developers wired up. Record what each runs as, what it reaches, and how old its credentials are. Fold the result into non-human identity governance /solutions/nhi-governance . 2. Assign an accountable owner to each one 2-assign-an-accountable-owner-to-each-one An agent without an owner cannot be reviewed, rescoped, or retired, so the default becomes leaving it alone. Expect to surface agents built for a pilot by someone who has since changed roles. 3. Right-size access against the actual task 3-right-size-access-against-the-actual-task Compare each agent's entitlements to what its job requires, then cut the difference. This is where most risk reduction happens, and where you learn which agents only worked because somebody granted admin for a demo. 4. Put policy in front of tool calls 4-put-policy-in-front-of-tool-calls Decide which actions an agent may take unattended, which need a human in the loop, and which are prohibited outright. Prohibited actions should fail closed and produce an audit event. 5. Review agents on a cadence 5-review-agents-on-a-cadence Add agents to your access review /products/access-reviews program with the same rigor as employees and shorter intervals. Agent scope changes with every prompt and tool update, so annual certification is a formality. Rehearse the compromise too: if an agent is manipulated tonight, who gets paged and which credential gets revoked? Agentic AI security best practices agentic-ai-security-best-practices These practices hold as agent frameworks change, because they attach to identities and permissions rather than to product names. Two of them do most of the work: one identity per agent, and no standing access an agent does not need right now. The rest keep the program honest between reviews. Give every agent its own identity. Shared service accounts destroy attribution and hand every agent the union of every entitlement the account collected. Eliminate standing access where the workload allows. Just-in-time access /glossary/What-is-Just-in-Time-Access removes the long-lived credential. An agent that holds nothing between runs leaks nothing between runs. Make irreversible actions require a person. Deletions, payments, permission grants, and production configuration changes are a small enough set to gate explicitly. Log the action as well as the prompt. Action logs tell you what happened to your systems. Auditors and responders need those. Set a decommissioning trigger. Every agent needs an end condition: project close, owner departure, a period of non-use. Only 21% of enterprises have this, and it is the cheapest control here. What to evaluate in an agentic AI security solution what-to-evaluate-in-an-agentic-ai-security-solution Products in this space split into two camps. One inspects models and prompts. The other governs identities and access. Ask any vendor to show both, and press on what is easy to demo and hard to operate: ownership attribution, remediation that closes the loop, and evidence an auditor accepts. Discovery across both surfaces. Cloud, SaaS, and identity providers plus developer endpoints. Most cover the first and stop, leaving local MCP servers and on-disk credentials untouched. Ask which agent platforms are enumerated natively rather than inferred from cloud logs. Ownership attribution. Every discovered agent should resolve to a named person or team. A machine name is not an owner. One graph for human and non-human identities. Separate inventories cannot answer what an agent reaches and who is accountable. Remediation that closes the loop. Ask which finding types and which remediation actions are supported today versus on a roadmap. Integration with the tools your team runs. Findings should route into your existing automations, ticketing, and on-call systems with the audit trail intact. Category boundaries. ISPM, ITDR, and identity intelligence products each cover part of this problem. Map what you buy against what you own. How can C1 help with agentic AI security? how-can-c1-help-with-agentic-ai-security C1's agentic security and intelligence capability sits in the fourth layer: the identity risk left after discovery, vaulting, and runtime guardrails. It runs on the same graph, approvals, and audit trail as your access reviews, so a finding about an agent gets handled like a finding about an employee. C1 brings human and non-human identities into one intelligence graph. Open any identity and trace its reach. C1 raises a finding when an identity is unowned, a service account is misclassified, an account has a lookalike match, or a monitored signal fires such as a decoy credential being used. The launch set of finding types is deliberately narrow and expanding. A finding becomes a governed fix. Reassign an owner, revoke, right-size, or certify, running through the same approval and audit trail as your access reviews and just-in-time access. The available remediation actions are expanding. Findings that need action route into your own , and on into ServiceNow, Jira, or PagerDuty, with the audit trail still attached. automations /products/automations , functions, or webhooks Coverage follows the connectors. Entra, Okta, GCP, GitHub, Snowflake, Active Directory, and more, with agent platforms such as Salesforce Agentforce and AWS Bedrock AgentCore. The four capabilities work as one stack: discover unsanctioned AI, secure agent credentials, govern tool calls at runtime, detect and remediate the identity risk that remains. Together they are the Agentic Control Plane, with general availability rolling out following launch. See AI agent security /solutions/ai-agent-security and AI access management /products/ai-access-management , or talk to our team /lp/request-demo . Frequently asked questions frequently-asked-questions What is agentic AI security? what-is-agentic-ai-security-1 Agentic AI security is the practice of controlling what autonomous AI agents can reach, do, and change. It covers the agent's identity, its credentials, the tools it calls, and the trail it leaves. Because agents act, it governs actions rather than outputs. What are the biggest risks of AI agents? what-are-the-biggest-risks-of-ai-agents Four account for most exposure: over-permissioned identities inherited from shared service accounts; unowned agents that outlive their projects with live credentials; goal hijack through instructions injected into content the agent reads; and cascading actions across chained agents. All four are access problems. What is the OWASP Top 10 for Agentic Applications? what-is-the-owasp-top-10-for-agentic-applications It is a threat taxonomy for agentic systems, published by OWASP's Agentic Security Initiative on December 9, 2025 as the 2026 edition. The ten categories, ASI01 through ASI10, cover goal hijack and tool misuse, identity and privilege abuse, supply chain and code execution risks, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. Most of the controls behind them are identity controls. How do you prevent prompt injection in AI agents? how-do-you-prevent-prompt-injection-in-ai-agents Assume you will not prevent it, and limit what it accomplishes. Keep instructions and retrieved data in separate channels so a document cannot issue commands. Scope each agent's tools to its task. Require human approval for irreversible actions. Cut the agent's outbound network path so injected instructions have nowhere to send data. What is the difference between AI security and AI agent security? what-is-the-difference-between-ai-security-and-ai-agent-security AI security covers models and their data: training integrity, model theft, inference abuse. AI agent security covers what an agent does with its access, because an agent authenticates, calls tools, and changes systems. The first is a model problem. The second is an authorization problem. How does zero trust apply to AI agents? how-does-zero-trust-apply-to-ai-agents Directly, once you treat the agent as a principal. Every tool call gets authenticated and authorized, no network position implies trust, permissions match the task, and access expires. Delegation is the wrinkle: an agent acting for a person carries that person's identity forward. See least privilege access versus zero trust /glossary/least-privilege-access-vs-zero-trust . How do you detect if an AI agent has been compromised or manipulated? how-do-you-detect-if-an-ai-agent-has-been-compromised-or-manipulated Watch behavior against baseline rather than for malicious code. Useful signals: tool calls outside the agent's normal set, access to systems it has never touched, a spike in write actions, and data volumes that do not match the task. Action logs make this possible. How do you manage agentic AI identity and access? how-do-you-manage-agentic-ai-identity-and-access Give each agent its own identity with a named owner. Scope entitlements to the task and remove standing access. Broker credentials rather than embedding them. Evaluate policy at tool-call time. Review on a short cadence, and define a decommissioning trigger up front. What is agentic identity? what-is-agentic-identity Agentic identity is the identity an AI agent authenticates and acts as: its credentials, its entitlements, its owner, and its lifecycle. It differs from a service account because an agent's behavior changes with its prompts and tools, and it usually acts for a specific human. The AI identity problem /c1-academy/the-ai-identity-problem covers why directories struggle with it.