Agent Threats and Attacks Guide: How AI Agents Are Attacked and Abused

An AI agent that can read untrusted content, hold credentials and call tools can be turned against the organisation that runs it, and the attacker never needs to touch the agent's code. Agent threats differ from classic application threats because the control channel and the data channel are the same: instructions arrive inside the emails, web pages, tool results and memories the agent processes. This pillar page is the defender's overview of the whole category: how agents are attacked and abused, the concepts and taxonomies to use, the main threat classes, controls in maturity order, who owns them and how they map to OWASP, MITRE ATLAS and NIST. It is written for security architects, AppSec and detection teams, and it links to every NHI Mgmt Group guide in the category for depth. It describes threats at the level needed to defend against them and contains no attack procedures.

Key takeaways

• Agent attacks target actions, not answers. The damage comes from what a manipulated agent does with its tools and identity: sending data out, changing records, running code or spending money.
• Prompt injection is the root, not the whole tree. Indirect injection is the usual entry point, but memory poisoning, malicious tools, inter-agent spoofing, credential theft and runaway behaviour are distinct threats with distinct controls.
• The model cannot be the security boundary. The UK NCSC argues LLMs do not separate instructions from data and that prompt injection may never be fully mitigated, so deterministic controls outside the model carry the load.
• Attackers retry. NIST CAISI found that running each attack 25 times raised average success from 57% to 80% in its evaluation, so single-attempt testing understates risk.
• Blast radius is an identity decision. Least agency, task-scoped credentials and gated high-impact actions decide whether a successful hijack is an incident or a near miss.

What the field covers

Agent threats and attacks covers every way an agentic system can be made to act against its owner's intent, whether by an outside attacker, a malicious component or the agent's own failure. It spans:

• Manipulation of goals and instructions: direct and indirect prompt injection that redirects the agent. See the AI Agent Goal Hijacking Guide and the Prompt Injection Guide.
• Corruption of state: poisoning of long-term memory, RAG stores and shared context. See the AI Agent Memory Poisoning Guide.
• Abuse of tools and integrations: legitimate tools used harmfully, and malicious or tampered tools, MCP servers and skills. See the AI Agent Tool and Plugin Security Guide.
• Identity and credential abuse: theft of agent credentials and escalation through delegation. See the Agent Identity and Access Guide.
• Special interfaces: browser and computer-use agents, voice agents and coding agents, each with its own input channels.
• Agent failure and resource abuse: rogue and runaway agents, cascading failures and denial-of-wallet.

Runtime guardrails and monitoring as a discipline are covered in the Agent Controls and Monitoring Guide; model-level attacks such as training data poisoning and model theft sit in the AI Threats and Model Security Guide.

Core concepts

• The confusable deputy: the NCSC frames prompt injection as an "inherently confusable deputy" problem: a privileged component that can be tricked into acting for whoever supplied the content it reads. The practical consequence is its advice that when an LLM processes a party's content, its privileges should drop to that party's level.
• Agent hijacking: NIST CAISI defines agent hijacking as a form of indirect prompt injection in which instructions hidden in data the agent processes make it perform a different, potentially harmful task.
• Least agency: OWASP's principle that an agent should not have autonomy, tools or reach beyond what its task needs, because each unnecessary capability is attack surface.
• Trust boundaries in an agent: system prompt and configuration (trusted, change-controlled), user input (semi-trusted), and everything retrieved at runtime, including tool outputs, documents, web pages, peer agent messages and memory (untrusted).
• Lethal combination: an agent that reads untrusted content, can reach sensitive data and can communicate externally is the highest-risk configuration; removing any one of the three sharply reduces exfiltration risk.

Taxonomies to use

Main threats

The table groups agent threats by what the attacker manipulates. ATLAS IDs are from ATLAS 5.6.0; OWASP IDs are from the agentic and LLM lists.

Protocol-level threats in MCP

The MCP Security Best Practices document lists attacks that sit below the model: confused deputy through MCP proxy servers that use a static client ID with dynamic client registration and consent cookies; token passthrough, which the authorisation specification forbids; SSRF through OAuth metadata URLs that a malicious server can point at internal addresses or cloud metadata endpoints (169.254.0.0/16); session hijacking where session IDs are used for authentication; and local MCP server compromise through malicious startup commands. Its mitigations are specific: per-client consent, exact redirect URI matching, single-use state values, no sessions for authentication, blocking private ranges during discovery and showing users the exact command before a local server is configured. See the MCP Gateway and MCP Server Governance Guide.

How threat classes chain in real incidents

Agent incidents rarely involve one threat class. The typical chain has three links, and each link is a separate place to break it:

1. Entry: untrusted content reaches the agent's context through an email, a document, a web page, a tool result, a peer agent or a poisoned memory. Controls here reduce likelihood but cannot remove it, which is the NCSC's central point.
2. Leverage: the manipulated agent uses whatever it holds: tools, credentials, delegated user authority and network reach. This is where least agency, task-scoped tokens and tool gating decide the outcome.
3. Impact: data leaves through a legitimate channel, a record or payment is changed, code runs, or spend climbs. Egress allowlists, approval gates, budgets and sandboxing contain it here.

Defenders get the best return from the second and third links, because they are deterministic and do not depend on recognising the attack. A detector that catches the entry is valuable as a signal, not as the boundary.

Where identity fits

Almost every damaging agent incident turns on what the agent's identity allowed. A hijacked agent with a read-only, single-audience token that expires in minutes can leak little; the same agent holding a developer's cloud keys or an account-wide API token can destroy production. Agent credentials are also targets in their own right, harvested from configuration files and tool responses. Treat credential scope, delegation and revocation as threat controls, not only as IAM hygiene. See the Credential Vaulting for AI Agents Guide and the AI Agent Authorisation Guide.

Common failure patterns

• Trusted and untrusted content in the same context. EchoLeak (CVE-2025-32711) let one crafted email steer Microsoft 365 Copilot into placing internal data in a link or image that was fetched automatically. Microsoft fixed it server-side and says no customers were affected.
• Tool output treated as instructions. In the Sentry MCP agentjacking research, a fake error report retrieved through the Sentry MCP server led coding agents to run a suggested command with the developer's own privileges. The researchers' test package was benign and no real-world exploitation has been reported.
• Installing tools on name alone. The look-alike postmark-mcp server behaved normally for fifteen versions before version 1.0.16 added a hidden blind copy to every email agents sent.
• Destructive actions without a gate. The PocketOS database deletion combined an over-privileged token the agent found with an API that deleted a volume and its backups immediately, with no approval step.
• Relying on detectors or deny-lists. Phrase lists are easily rephrased around, and injection classifiers report rather than block unless the application acts on the result.
• Testing once. Single-attempt red team results understate a probabilistic system's risk; CAISI recommends multiple attempts and per-task analysis.

Key controls by maturity

How to implement

1. Threat model each agent: record the untrusted inputs it reads, the sensitive data it can reach, its external channels and its most damaging action. See the AI Agent Threat Modelling Guide and the AI Agent Threat Model Template.
2. Cut capability first: remove tools and permissions the task does not need; this is cheaper and more reliable than detection.
3. Instrument in monitor mode: log task, plan, every tool call and every egress attempt, and baseline normal behaviour for two to four weeks before enforcing.
4. Gate high-impact actions: introduce approval and policy checks on one agent as a pilot; tune so approvals stay rare enough to be read. Roll back by switching the gate to log-only, not by widening permissions.
5. Harden the supply chain: allowlist MCP servers, pin versions, scan for look-alikes and re-review on change.
6. Test adversarially: run red team exercises per injection task with repeated attempts, and retest after every model or tool change. See the AI Agent Security Testing Checklist and Red Teaming AI Agents for Identity Abuse.
7. Prepare to respond: a tested kill switch, credential revocation and memory rollback. See the AI Agent Incident Response Playbook.

Decision guidance

• Agent reads untrusted content and can act externally: use a constraining architecture (plan then execute, dual model or action selector) rather than relying on filters; the AI Agent Goal Hijacking Guide compares the patterns.
• Agent only reads trusted internal data: focus on identity, tool scoping and runaway limits; injection risk is lower but insider-planted content still counts as untrusted.
• Coding and computer-use agents: sandbox by default; these agents inherit every credential in the environment. See the Browser and Computer-Use Agent Guide.
• Small teams: fewer tools, approval on every external send and a hosted platform's sandbox get most of the benefit. Large estates need a tool gateway, central policy and SOC detections.

Detection and measurement

The NCSC recommends logging inputs, outputs, tool use and API calls, and notes that failed tool or API calls may show an attacker refining an approach. Useful signals: tool calls not explained by the user's request, outbound requests outside the allowlist or URLs carrying encoded data, plan changes after untrusted content was read, new or changed tool descriptions, and spend or call-rate spikes.

Roles and ownership

For executive framing, the Top 10 AI Agent Security Risks for CISOs summarises the same ground for leadership.

Standards and frameworks

OWASP is expanding each agentic risk into its own guidance; NHI Mgmt Group covers each entry in the OWASP Agentic Top 10 ASI01 Guide through the OWASP Agentic Top 10 ASI10 Guide, and the OWASP Top 10 for LLM Applications Guide covers the model layer.

Where to go next (all guides in this category)

Taxonomy

• OWASP Top 10 for Agentic Applications Guide: each ASI risk explained with its controls and LLM Top 10 mapping.

Manipulation of goals and state

• AI Agent Goal Hijacking Guide: how agents get redirected, design patterns that resist it and detection signals.
• AI Agent Memory Poisoning Guide: poisoning of long-term memory and RAG, with detection and rollback.
• AI Agent Memory Security Guide: memory types, cross-user leakage, isolation, retention and secret handling.

Interfaces with special exposure

• Browser and Computer-Use Agent Guide: agents that browse and operate desktops, and the controls they need.
• Voice AI Agent Security and Fraud Guide: deepfakes, vishing and controls for voice agents.

Agent failure and resource abuse

• Rogue and Runaway AI Agent Detection Guide: signals of agents acting outside scope and how to respond.
• Denial-of-Wallet and AI Agent Cost Runaway Guide: spend limits, quotas and detection of cost abuse.

Practitioner checklist

• Threat model every production agent: untrusted inputs, reachable data, external channels and worst action.
• Remove tools, scopes and autonomy the task does not need before adding any detection.
• Treat tool outputs, retrieved documents, peer agent messages and memory as untrusted input.
• Gate destructive, financial and external-send actions with a policy check and, where needed, human approval.
• Sandbox all code execution and restrict agent egress to an allowlist.
• Allowlist and pin MCP servers and tools; re-review whenever a tool description or version changes.
• Log task, plan, tool calls and egress per session and alert on off-task actions.
• Red team per injection task with repeated attempts, and retest after model or tool changes.
• Exercise a kill switch, credential revocation and memory rollback at least twice a year.

Standards and references

• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATLAS: LLM Prompt Injection
• MITRE ATLAS: Exfiltration via AI Agent Tool Invocation
• Model Context Protocol: Security Best Practices
• NIST CAISI: Strengthening AI Agent Hijacking Evaluations
• NCSC: Prompt injection is not SQL injection
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Agent Identity and Access Guide · Agent Controls and Monitoring Guide · Prompt Injection Guide · MCP Security Guide · AI Agent Incident Response Playbook