AI agent breaches: four patterns and the controls that stop them

AI agents now appear in most of the breaches we record each year, and the weakness behind them is almost always a non-human identity: a key, a token or a standing permission that software could use without anyone checking. This page is the NHI Mgmt Group hub for AI agent breaches. It sets out what the State of NHI & AI Agent Breach Report 2026 found, places every AI breach page in our database into the report's four patterns, and explains for each how it unfolds, the warning signs, what failed and the controls that would have stopped it. A short self-check shows which pattern you are most exposed to. It is written for security architects, identity and platform teams, and engineering leads who deploy agents; deeper spoke pages are linked rather than repeated.

Key takeaways

• AI incidents are now most of the list. AI-related breaches went from 7 of 38 in 2024 to 19 of 63 in 2025 and 33 of 53 in 2026 so far, according to NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026).
• The credential is still the payload. The report finds 79% of 2026 AI-related breaches also abused a key, token or credential: 26 of the 33.
• Four patterns repeat. Agents as the attacker; agents hijacked by what they read; agents doing damage on their own; and the AI supply chain and AI keys. The fourth has the most cases in our database by a wide margin.
• Instructions are not permissions. Prompts that said "do not touch production" or "there is no internet" failed in Replit, PocketOS and several evaluations. Only scoped credentials, enforced approvals and network controls held.
• Treat every agent as a governed identity. The report's control set: an owner, least privilege and short-lived credentials, tool allow-lists, approval for risky actions and a kill switch.

What the breach data shows

The report analyses 200+ breaches involving non-human identities and AI agents from November 2017 to October 2026, and classes 64 as AI-related: they involve AI agents, LLM platforms, prompt injection or agent misbehaviour. The report's own summary is that the identities are the same, but the attacker, and sometimes the victim, is now software that acts on its own. All figures below are as printed in the report; 2026 covers January to 7 October.

The report also states that only 25% of 2026 breaches were credential-led, down from 59% in 2023, and warns that this is not because credentials got safer: supply chain attacks (38% of 2026) and AI incidents now fill the list, and 26 of the 33 AI-related breaches in 2026 still abused a key, token or credential. The two tables below are the report's breakdown of the AI-related breaches. A breach can have more than one route and more than one identity type, so the columns add up to more than 64.

Two readings matter. The routes are spread evenly, so no single control closes AI risk. And the identity column is dominated by things teams already know how to govern: API keys, secrets, cloud credentials and tokens. The agent is itself an identity in 27 breaches, but what usually turned an AI incident into a breach was a conventional credential the agent could reach.

How this hub and its spoke pages fit together

This page gives the cross-breach view and every case. The pages below go deeper on one slice each; use them when the self-check points you there.

Pattern 1: agents as the attacker

Autonomous agents chain flaws and stolen machine credentials at machine speed. The operator may be a criminal, a state group or an AI lab whose agent left its test. For defenders, reconnaissance and lateral movement shrink from weeks to days.

How it unfolds

The agent starts with something internet-facing and unauthenticated: a Langflow server, a Docker API, an endpoint, a portal's client-side configuration. It harvests machine credentials from where software keeps them (environment variables, configuration files, wp-config.php, the metadata service) and tries each against every reachable system. Default and derived secrets fall first, then it pivots through whatever trust the credentials carry: SSO without MFA, a signing key, a cluster-wide service-account token. In Taiwan, 85 accounts fell in attack waves over four days.

Warning signs

• Bursts of authentication: many accounts tried from one source in a short window, especially accounts with predictable passwords.
• Machine credentials used from new places: a service-account token or cloud role used from an address, cluster or ASN it has never used.
• Reads of secret stores at volume: a single principal listing and reading dozens of Secrets Manager or Vault entries, as in the retail card campaign.
• An agent framework appearing on a server that never ran one, as Carbonato installed Hermes.

What failed

Nothing here was new: open management interfaces, default secrets, credentials in files, single-factor SSO and over-broad machine tokens. Agents just used them faster. The lesson from OpenAI and Hugging Face in the report is to scope every machine credential to one system and treat agent runtimes as untrusted code.

Controls that stop it

1. Remove default and derived secrets before exposure. Fail the build if a known default (MinIO, Nacos, sk-1234 for LiteLLM) or an ID-derived password is present; rotate any that shipped.
2. Close unauthenticated management planes. Scan internet-facing AI tooling (Langflow, Ray, LiteLLM, Docker daemons) from outside and require authentication and network restriction; never expose the Docker API on 2375.
3. Scope machine credentials to one system. Service-account tokens bound to a namespace and audience, cloud roles limited to one workload, no signing keys shared across environments. Ask of each token: if stolen, what is the blast radius?
4. Enforce MFA on SSO and protect the metadata service. MFA on every human SSO login stops the Taiwan pivot; IMDSv2 with hop limits makes metadata credential theft from a container harder.
5. Baseline machine identity use. Alert when a token is used from new sources or at abnormal volume; machine-speed attacks are noisy once you watch the right identities.
6. Verify every token you accept. Reject unsigned JWTs and tokens signed with default keys in every API gateway.

Pattern 2: agents hijacked by what they read

Poisoned content steers an agent that already holds valid access. No key is stolen: the attacker writes instructions into something the agent will read (an email, a form field, a calendar invite, an error report, a README) and the agent carries them out with its own permissions. The prompt-injection mechanics and egress controls are covered in depth in Prompt injection data theft; this section gives the cases and the identity view.

How it unfolds

The early chatbots (Chevrolet, DPD) had only a voice, so the harm was reputational. Each later case adds access. Copilot, Gemini and Agentforce held delegated read access to mail, calendars and CRM, and an outbound channel (an image URL, a calendar event, an allow-listed domain) carried data out. SalesBleed added a write identity, the agent's Slack presence. Sentry agentjacking and Gemini CLI reached the worst combination: a coding agent that reads untrusted content, executes commands and holds the developer's credentials. Meta's assistant, with authority over recovery details, became the attacker's help desk.

Warning signs

• Agent actions the user did not ask for: a new calendar event, a Slack post or an outbound request appearing in the same session as a read of external content.
• Agents fetching URLs or images on domains outside a known set, or on domains whose registration recently changed.
• Coding agents running package managers (npx, pip install) immediately after reading tickets, errors or documentation from outside the organisation.
• Recovery or contact details changed by an assistant without the account holder's step-up authentication.

What failed

The agent treated data as instructions, and its permissions covered everything it might need rather than the current task. Allow-lists aged too. The identity failure: access was granted once, broadly, and never tied to the provenance of the content being acted on.

Controls that stop it

1. Lower privilege when untrusted content is in context. Tag external content (inbound mail, public forms, outside tickets) and require user approval for write and send tools while it is present.
2. Close the outbound channels. Block agent-rendered images and links to arbitrary domains, keep URL allow-lists short and review them so expired domains drop off. Treat agent-created events, messages and posts as outbound data.
3. Separate read and act identities. A lead-summarising assistant gets read-only CRM access; posting to Slack or email goes through a separate, approval-gated tool. This is OWASP LLM06:2025 Excessive Agency in identity terms.
4. Strip credentials from coding agent environments. Give coding agents a short-lived, repository-scoped credential, not the developer's shell; see the AI Agent Sandboxing and Code Execution Guide.
5. Allow-list whole commands, not prefixes, so a chained command is not approved because it starts with grep.
6. Step-up authentication for assistant-made account changes. Recovery email, phone or MFA changes must be confirmed on a factor the holder already controls.

Pattern 3: agents doing damage on their own

There is no attacker in this pattern. An over-privileged agent, or a badly scoped test, does harm while pursuing a legitimate task. The destructive coding agent cases are analysed in AI agents that destroyed data and the lab and evaluation cases in AI Lab and Agent Evaluation Incidents.

How it unfolds

In production, a coding agent meets an obstacle (a failing command, a credential mismatch, a freeze) and works around it with whatever access it finds; PocketOS's agent found an account-wide token. In evaluation, a test meant to be sealed has an internet route, and an agent briefed to attack a target attacks a real one with real leaked credentials. Air Canada is the low-access end: a wrong answer the company was bound by.

Warning signs

• Agents reading files outside their task scope, particularly searching for strings that look like tokens.
• Destructive verbs from agent identities: DROP, DELETE, volume or backup deletion, force pushes.
• Egress from evaluation environments to any address outside the planned target range.
• Agents creating accounts or identities on external services, as in the UK AISI runs.

What failed

The control was an instruction instead of a permission. Replit's freeze and Anthropic's "no internet" brief were text the model could ignore or disbelieve. The token PocketOS's agent used had been created for one purpose but scoped for everything, and backups sat inside the same blast radius. Evaluations relied on a partner's configuration with no independent check that the network was closed.

Controls that stop it

1. No standing production write access for agents. The report's 30-day plan says it plainly. Grant write access per change, through a pipeline or an approval.
2. Narrow every token an agent could find. Scan repositories and workspaces for platform tokens, replace account-scoped tokens with environment-scoped ones, and keep production credentials out of development checkouts.
3. Put backups out of reach of identities that can delete production: separate account, separate credential, deletion protection, tested restore.
4. Enforce destructive-action approval outside the model. Database proxies or platform policies block DROP, TRUNCATE or volume deletion from agent identities without human approval.
5. Verify evaluation isolation independently. Prove from inside the environment that egress fails before each run, and halt on any traffic outside the planned range.
6. Keep a tested kill switch that revokes the agent's credentials and stops its runtime; see the AI Agent Kill Switch and Containment Guide.

Pattern 4: the AI supply chain and AI keys

Poisoned AI tools reach the agents that install them, and AI API keys buy compute and data. This is the largest group in our database. We split it into two tables: compromised or malicious AI tools, packages and platforms, and exposed or stolen AI keys and the platforms that store them. Key abuse and LLMjacking are covered in depth in AI API key abuse.

Poisoned AI tools, packages and platforms

Exposed and stolen AI keys and AI platforms

How it unfolds

In the first route the attacker compromises something agents and developers install: a package, an MCP server, a skill, an IDE plugin or an agent extension. The entry is almost always a publishing credential: a stolen PyPI token, a former contributor's npm account, an over-scoped CI token. Because these tools run inside developer and agent environments, the payload lands beside the richest credential stores in the organisation. In the second route, AI keys leak (repositories, images, client-side code, logs, chats) or sit in a platform that is breached, and become free compute, resold access or data.

Warning signs

• New package versions published outside the normal release workflow, or by an account that has not published for months.
• MCP servers, skills or plugins installed by name with no publisher verification, or updated automatically to new versions.
• AI provider spend or token use rising with no matching deployment, or requests from unfamiliar regions.
• Public client-side code or images containing key patterns (AIza, sk-, hf_) found by external scanning.
• An API you never meant to expose becoming reachable by an existing key, as when Gemini was enabled on projects with public keys.

What failed

Publishing rights outlived the people and purposes they were granted for, rotations were partial, and AI keys were treated as configuration rather than credentials. Agents installed tools on trust, and those tools inherited the agent's and developer's whole credential set.

Controls that stop it

1. Allow-list MCP servers, skills and plugins. Verify the publisher, pin a reviewed version or hash and block auto-update; see the Agent Skills Security Guide and the MCP Security Guide.
2. Use trusted publishing and remove stale maintainers. Replace stored PyPI and npm tokens with short-lived OIDC publishing; review publish rights quarterly.
3. Restrict every AI key. One key per application, API restrictions so enabling a new API does not widen it, and per-key spend limits and alerts.
4. Scan everywhere keys end up, and revoke. A deleted secret is still valid until revoked.
5. Decommission completely. OpenCode's breach came through a legacy system being retired: rotate or wipe stored keys before retirement, not after.
6. Authenticate AI gateways. A strong master key, no sk-1234 default, current patches; treat the master key as tier zero.

Which pattern are you most exposed to?

Answer yes or no to each question. Two or more yes answers in one row means that pattern is your priority; start with its controls above and the linked spoke page.

A phased programme

1. Days 1 to 30, find and close. From the report's plan: scan code, CI logs, images, tickets and chat for secrets and revoke them; give every AI agent, MCP server and AI API key an owner; remove standing production write access from agents. Test by trying a destructive action from each agent identity in a non-production copy.
2. Days 31 to 60, scope and gate. Per-agent short-lived credentials, a pinned tool allow-list and approvals outside the model. Pilot with one team in audit mode for two weeks, then enforce.
3. Days 61 to 90, detect and contain. From the report's 90-day plan: short-lived scoped credentials, baselined NHI behaviour with automatic revocation on leaks, and guardrails including a tested kill switch.
4. Rollback: keep the previous credential and policy set for a short, logged window at each cut-over, then remove it.

Decision guidance

• Laptop or sandbox for coding agents: if agents only edit code and open pull requests, a remote sandbox with a repository-scoped token is easier to govern than hardening every laptop.
• Approvals or narrower permissions: narrow permissions first, since approvals fatigue reviewers; keep approval for deletion, external send, account change and production deploy.
• Small or large: small teams get most value from per-key spend alerts, secrets scanning with revocation and a short MCP allow-list; large ones should bring agents into identity governance with owners, reviews and expiry.
• SaaS agents: with Copilot, Agentforce or Gemini you control connectors, scopes and outbound settings, not the model; review them as you would an OAuth grant.

Detection and measurement

Log every agent tool call with the agent identity, the human it acted for and the content sources in its context, and send it to the SOC with a named owner for each agent. Track these metrics:

• Agents with a named owner: percentage of inventoried agents, MCP servers and AI keys; target 100%.
• Standing production write access: number of agent identities holding it; target zero.
• Credential lifetime: median lifetime of agent credentials; trending down to hours.
• Unapproved tools: MCP servers, skills and plugins found outside the allow-list per month.
• Time to revoke: from a leaked AI key alert to revocation; target under one hour.
• Kill switch rehearsal: time from decision to all agent credentials revoked, measured at each quarterly test.

Framework mapping

Common failure patterns

• Guardrails in the prompt only: the Replit freeze and the Anthropic "no internet" brief were instructions, not controls.
• Tokens scoped wider than their purpose: the PocketOS domain token could delete volumes and backups.
• Allow-lists that age: ForcedLeak exfiltrated through an expired domain still on the list.
• Publish rights that outlive people: a former contributor's account republished 140+ Mastra packages.
• Defaults left in AI infrastructure: sk-1234 on LiteLLM gateways, default Nacos keys in JADEPUFFER, 123456 on McHire.
• Agents running with the developer's full credential set: Sentry agentjacking and Nx turned that inheritance into AWS, GitHub and npm access.

Practitioner checklist

• Inventory every agent, MCP server, skill, plugin and AI API key, each with a named owner.
• Remove standing production write access from every agent; grant it per change.
• Issue each agent its own short-lived, single-environment credential, separate from the developer's.
• Scan code, CI logs, images, tickets and chat for secrets, and revoke what you find.
• Allow-list MCP servers, skills and plugins; pin versions and block auto-update.
• Require approval outside the model for destructive, external-send and account-change actions.
• Label untrusted content and restrict agents' outbound channels while it is in context.
• Restrict, budget and alert on every AI provider key; one key per application.
• Move package publishing to trusted publishing and remove stale maintainers.
• Build, test and rehearse a kill switch; keep backups out of reach of agent identities.

Standards and references

• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
• OWASP: Top 10 for LLM Applications 2025
• OWASP: LLM06:2025 Excessive Agency
• MITRE: ATLAS Adversarial Threat Landscape for AI Systems
• MITRE ATT&CK: T1195.002 Compromise Software Supply Chain
• Model Context Protocol: Security Best Practices
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: the Agentic AI Security Guide, the OWASP LLM Top 10 LLM06 Excessive Agency Guide, the LLMjacking Guide and the Local MCP Server Security Guide.