AI Agent Security Risks: Where Autonomous Workflows Go Wrong

OWASP Agentic Top 10 as the Primary Taxonomy

OWASP’s Top 10 for Agentic Applications 2026 is a community‑developed framework that identifies the most critical risks affecting autonomous and agentic AI systems. It explicitly focuses on agents that plan, maintain context, call tools, and act with delegated authority across other software and data stores.

The official categories are:

• ASI01 – Agent Goal Hijack
• ASI02 – Tool Misuse & Exploitation
• ASI03 – Agent Identity & Privilege Abuse
• ASI04 – Agentic Supply Chain Vulnerabilities
• ASI05 – Unexpected Code Execution
• ASI06 – Memory & Context Poisoning
• ASI07 – Insecure Inter‑Agent Communication
• ASI08 – Cascading Failures
• ASI09 – Human‑Agent Trust Exploitation
• ASI10 – Rogue Agents

For production agents, this list is more useful than model‑only taxonomies because it ties risks directly to identities, tools, memory, and interactions. The OWASP Top 10 for LLM/GenAI Applications remains relevant underneath—for prompt injection, insecure output handling, training‑data poisoning, model denial of service, and model theft—but those are best treated as supporting layers for agentic behavior.

AI Agent Security Risks: Identity and Privilege Abuse (ASI03)

Agent Identity & Privilege Abuse (ASI03) covers situations where agents use, share, or escalate identities and privileges without adequate governance. Documented patterns include agents:

• Running under shared service accounts that aggregate multiple users or tenants.
• Inheriting full host privileges or administrator roles via tool credentials.
• Delegating to sub‑agents without recorded identity chains.
• Crossing tenant boundaries that underlying systems were designed to isolate.

Analyses of ASI03 emphasize that identity design sets the maximum impact of other risks: an agent experiencing goal hijack (ASI01) or tool misuse (ASI02) can only act as far as its credentials permit.

Conditional Identity Controls

Guidance from OWASP and dedicated ASI03 work suggests layering identity controls rather than relying on a single mechanism:

• Distinct agent identities. Give each production agent its own identity, separate from human users and other agents. Tools authorise the agent’s identity, not an implicit shared session. This improves traceability and blast‑radius analysis but adds complexity to IAM.
• Scoped delegation. Where agents act on behalf of users, use explicit, revocable delegation (for example, user‑to‑agent scopes) instead of copying full user tokens.
• Constrained host inheritance. Limit what host‑level privileges tools inherit (filesystems, networks, credentials) so agents cannot exercise full OS authority by default.
• Recorded identity chains. Record which identities and delegations were involved in each tool call or sub‑agent invocation, making privilege transitions auditable.

These measures are especially relevant when agents can reach production systems, multi‑tenant data, signing keys, or on‑chain assets. In lower‑risk, read‑only scenarios, organizations often adopt lighter identity controls while still preserving traceability and revocation.

Agent Goal Hijack & Memory Poisoning (ASI01, ASI06)

Agentic systems depend on instructions, retrieved content, and stored memory to determine their goals and actions. Attackers can exploit these inputs to redirect immediate decisions or persistently corrupt future behavior. ASI01 and ASI06 distinguish these related risks as goal hijacking and memory poisoning.

Attacks on Objectives and Context

Agent Goal Hijack (ASI01) occurs when malicious content alters an agent’s objectives or decision path, leading it to pursue an unintended goal while appearing to operate normally. Examples include hidden instructions added to tickets, web pages, or documents that override system policies or redirect workflows.

Memory & Context Poisoning (ASI06) focuses on persistent corruption of the information stores agents use for decisions—embedded memory, long‑term context caches, or retrieval indices—so that unsafe behavior repeats without fresh attacker input.

Simon Willison’s Lethal Trifecta

Simon Willison’s “lethal trifecta” framework explains why these attacks can become serious in tool‑enabled agents. He describes a particularly dangerous configuration where an agent has:

1. Access to private or sensitive data.
2. Exposure to untrusted content (emails, web, documents, tickets).
3. The ability to communicate externally in ways that can exfiltrate data.

In that configuration, a prompt‑injection payload embedded in untrusted content can cause the agent to fetch and send private data, even when base-model alignment and safety mechanisms appear intact.

Context Controls and Assumptions

OWASP and independent analyses support several context‑layer controls:

• Separate policy from data. Keep system instructions and business policies distinct from retrieved content. Avoid prompt structures that blend untrusted text into the same region used for rules or objectives.
• Validate memory writes. Treat persistent agent memory as configuration, not a transcript. Commit only entries that pass schema and policy checks; store other context ephemerally.
• Tag provenance and trust. Annotate retrieved context with source and trust labels (internal KB, CRM, external site, user upload). Use these labels when deciding whether context can influence tool selection or outbound communication.
• Approval for trifecta workflows. For agents combining private data, untrusted content, and external egress, require deterministic approvals or constrained workflows before untrusted content drives sensitive outbound actions.

Published work on prompt injection and OWASP commentary both note that these measures reduce but do not eliminate risk; language‑model interfaces cannot reliably distinguish instructions from data under all conditions. For planning, it is prudent to assume some context attacks will succeed and to design surrounding systems so compromised context cannot independently reach high‑value operations.

Tool Misuse & Unexpected Code Execution (ASI02, ASI05)

Tools convert agent decisions into actions with consequences for applications and infrastructure. ASI02 and ASI05 address how unsafe tool use or unintended code execution can escalate a manipulated request into system compromise.

From Tool Calls to Host Compromise

Tool Misuse & Exploitation (ASI02) covers agents using legitimate tools in unsafe ways—chaining tools to bypass checks, passing manipulated parameters, or treating untrusted tool output as instructions.

Unexpected Code Execution (ASI05) is defined as situations in which agents generate or execute code that was not intended by system designers, leading to a compromise of the host or infrastructure. OWASP and downstream analyses emphasise that ASI05 is about code running on real infrastructure (for example, hosts, containers, CI systems), not just data‑level manipulation.

Unit 42’s published work illustrates these risks through attack scenarios against open-source agent frameworks such as CrewAI and AutoGen, rather than incident logs from production environments. Their scenarios show how agents with shell, code-execution, or API access can be steered to run attacker-controlled commands, leak credentials, bypass API security controls, or misuse connected tools. These findings underline how tool permissions, API authorization, and integration design determine the operational impact of a compromised agent.

Transaction Safety and Code-Execution Controls

For agents that perform state‑changing work—database writes, ticket updates, commits, payments—controls that have proven useful in conventional systems also apply:

• Idempotency: Use idempotency keys or equivalent patterns to prevent retries and loops from duplicating actions. This adds key‑management complexity but prevents repeated changes caused by timeouts or unclear agent status.
• Precondition checks: Verify critical state (status, balance, version) before applying updates. High‑velocity environments may need careful tuning to avoid blocking legitimate operations while still catching stale or hallucinated actions.
• Approval gates: Apply deterministic policy checks or human approvals for high‑impact actions such as refunds, infrastructure changes, or bulk exports, aligning with ASI09’s focus on human–agent trust boundaries.
• Rollback / compensating actions: Design tools so specific actions can be reversed or compensated when possible, accepting that some communications and physical operations cannot be undone.
• Fail‑closed behaviour: When execution status is ambiguous, halt further writes until operators decide whether and how to proceed.

For ASI05, several sources recommend layered defences:

• Run generated code in isolated, ephemeral sandboxes without production secrets or internal network access.
• Deny network egress by default from execution environments; allow only specific destinations required for the task.
• Avoid mounting real credentials into code‑execution contexts.
• Require human review before generated code is persisted, deployed, or run against sensitive systems.
• Log executed code and monitor for patterns indicative of exploitation.

These mitigations reduce the likelihood that natural‑language manipulations lead to full host compromise, even when agents remain capable of generating and executing code.

Insecure Inter‑Agent Communication & Cascading Failures (ASI07, ASI08)

Multi-agent workflows create trust boundaries wherever agents exchange instructions, context, or results. ASI07 addresses weaknesses in those exchanges, while ASI08 covers the broader failures that can occur when faulty or manipulated messages propagate across connected systems.

How Multi-Agent Workflows Amplify Risk

Insecure Inter‑Agent Communication (ASI07) refers to message paths between agents that lack strong authentication, integrity, or schema validation, thereby allowing spoofing or injection. Cascading Failures (ASI08) covers chains of agents and tools where a single fault propagates across workflows, turning a localized issue into a broader incident.

In practice, these risks emerge when:

• Orchestrators accept any text output from specialist agents as policy.
• Downstream agents trust upstream messages without verifying identity or structure.
• Error handling passes partial results to other agents without clear failure signalling.

Limiting Multi-Agent Cascades

Recommended controls include:

• Mutual authentication. Agents authenticate each other using mechanisms such as mutual TLS and verify identities on every inter‑agent call, increasing cryptographic overhead but reducing spoofing.
• Typed, validated messages. Define strict schemas for inter‑agent protocols and treat deviations—unexpected fields, tool names, or embedded instructions—as errors rather than policies.
• Domain isolation. Partition workflows so agents operate within well‑defined domains (per tenant, environment, or business line), limiting how far failures can propagate.

Reviewer agents can help identify anomalies, but analyses of ASI09 and ASI10 caution against depending only on agents for high‑impact approvals: reviewer agents share model‑level weaknesses and can be influenced by the same poisoned context. For operations with significant financial, safety, or legal impact, deterministic controls and human involvement remain central.

Agentic Supply Chain & Human–Agent Trust (ASI04, ASI09)

Agent security depends on both the integrity of third-party components and the decisions of people who trust agent outputs. ASI04 and ASI09 address how compromised dependencies or persuasive responses can turn trusted relationships into paths for unsafe access, disclosure, or action.

Third-Party Dependencies and Trust Exploitation

Agentic Supply Chain Vulnerabilities (ASI04) cover risks in the components agents depend on—frameworks, plugins, MCP servers, connectors, templates, and external data services. Compromised or misconfigured dependencies can return adversarial context, misrepresent capabilities, or expose privileged operations under trusted names.

Human–Agent Trust Exploitation (ASI09) focuses on scenarios in which agents exploit human trust or anthropomorphism through persuasive outputs that encourage users to approve risky actions, ignore warnings, or share sensitive information.

Mitigation guidance includes:

• Evaluating third‑party components for secure coding, least‑scope tokens, and input/output validation before integration.
• Maintaining an AI bill of materials that records tools, servers, and datasets used by agents.
• Restricting egress paths and requiring enhanced approvals when sensitive or regulated data crosses boundaries.
• Designing human‑facing experiences that clearly indicate agent assistance, present risks, and offer straightforward escalation to human support.

These measures introduce review and integration overhead but reduce the likelihood that a single compromised component or persuasive response becomes a high‑impact incident.

Rogue Agents, Detection, and Incident Response (ASI10)

Agents can retain valid authority even as they drift beyond their intended purpose or governance boundaries. ASI10 makes continuous detection, rapid containment, and verified recovery essential for limiting the impact of compromised, misconfigured, or uncontrolled agents.

Observing and Containing Agent Drift

Rogue Agents (ASI10) describe agents that operate outside intended governance—whether through compromise, misconfiguration, or silent capability creep—while still holding valid authority. Detecting and handling such behavior depends on telemetry that connects identity, context, tools, approvals, and outcomes, not just chat transcripts.

Guidance from OWASP and incident‑response resources highlights:

• Per‑agent and per‑tool logging that captures identities, parameters, and results for significant actions.
• Context snapshots around high‑risk steps, including retrieved content and memory changes.
• Baselines and alerts for deviations in tool usage, destinations, approval patterns, or error rates.

On containment, multiple sources recommend designing and testing:

• Kill switches. Control‑plane mechanisms that can pause or deny agent requests for specific workflows or tools when risk thresholds are met.
• Credential revocation. IAM actions that quickly revoke agent identities and invalidate tokens.
• Quarantine. Processes to isolate suspect memory entries and data sources until they are cleared or replaced.
• Recovery procedures. Verified rollback or compensating actions, plus checks to ensure that remediation has not introduced new inconsistencies.

These controls require operational planning and practice. Kill switches and revocations that exist only on paper are unlikely to be effective during an incident.

MCP 2026‑07‑28 Specification and Authorization Hardening

The MCP 2026-07-28 specification strengthens how clients and servers establish authorization and preserve resource boundaries. Its updated OAuth guidance, issuer validation, and client registration model reduce token misuse, confused-deputy risks, and unauthorized access across MCP-connected tools.

What the MCP Spec Changes

The Model Context Protocol 2026‑07‑28 specification is described by its maintainers as the largest revision since launch, with a stateless core, an extensions framework, Tasks and MCP Apps, authorization hardening, and a formal deprecation policy. The spec removes the initialise/initialised handshake and protocol‑level sessions, making requests self‑describing via metadata fields and improving compatibility with standard HTTP infrastructure.

Authorization Guidance

Rather than being a standalone “authorization specification,” the July 28, 2026 spec and related materials document how MCP authorization aligns more closely with OAuth 2.1 and OpenID Connect:

• MCP servers are treated as OAuth 2.1 resource servers and must publish Protected Resource Metadata so clients can discover the correct authorization server.
• MCP clients are expected to use Resource Indicators (RFC 8707) to bind tokens to specific MCP servers, thereby reducing the risk of token reuse across resources.
• Issuer validation (RFC 9207) is required: clients must verify the iss parameter and bind credentials to the issuing server’s identity.
• Client ID Metadata Documents (CIMD) are promoted for client registration, while Dynamic Client Registration is deprecated.

Security guidance derived from these documents recommends:

• Validating audience and issuer claims on tokens at MCP servers.
• Avoiding token passthrough to upstream APIs; servers should obtain separate, scoped credentials for those services.
• Keeping tokens out of URLs, logs, prompts, and unencrypted state.
• Applying explicit consent where MCP servers access third‑party APIs or user‑specific resources.

These measures reduce identity and privilege abuse in agentic systems but still require application‑level authorization and policy decisions.

Using the Attack Path to Prioritize Controls

The OWASP Agentic Top 10, Simon Willison’s lethal trifecta framework, published attack scenarios, and MCP specification form a consistent basis for planning AI agent security. Rather than applying every control everywhere, teams can prioritise defences along a clear attack path:

• Identity: Apply Agent Identity & Privilege Abuse mitigations—distinct identities, scoped delegation, constrained host inheritance, recorded chains—where agents have meaningful authority.
• Context: Use lethal‑trifecta audits, provenance tagging, and memory validation for workflows that mix sensitive data, untrusted content, and external communication.
• Execution: Harden tools and code‑execution paths with transaction safety and ASI05 controls in workflows that change state or run code.
• Propagation: Implement ASI07/ASI08 controls for multi‑agent systems, focusing on authenticated, typed communication and domain isolation.
• Exfiltration & supply chain: Apply ASI01/ASI04/ASI09 measures where agents depend on third‑party components or handle high‑value data.
• Detection & recovery: Build ASI10‑aligned telemetry and response capabilities for agents whose misbehaviour could materially affect operations or compliance.

This approach recognises that no single technique secures all agents. It instead uses current evidence—frameworks, scenarios, and specifications—to make agentic AI a governable part of the environment, with controls matched to each agent’s authority and potential blast radius.