AI agent security: what changes when a model gets tools and credentials

AI agent security is the practice of protecting AI systems that can act, not just answer. An agent holds tools, credentials, and memory, so securing it means governing what it is permitted to invoke, what identity it carries, and what it does at runtime rather than what its model says.

That distinction sets the blast radius. A model that answers questions can be wrong. An agent that holds an API token, a mailbox, and a shell can be wrong and then act on it, at whatever reach its permissions allow. This page covers the agent-specific threat surface: the MITRE ATLAS agent technique family, tool poisoning, agent identity and inventory, documented incidents, and runtime detection. For the surrounding architecture, lifecycle, and governance of autonomous systems, including memory poisoning and the OWASP Top 10 for Agentic Applications, see our guide to agentic AI security.

What is AI agent security?

An AI agent is a language model wired to act. It plans, invokes tools, reads and writes memory, holds credentials, and increasingly coordinates with other agents. Every one of those capabilities is useful, and every one of them is also an interface an attacker can reach. That is the whole of the AI agent security risk: the model did not get more dangerous, the model got hands.

The clearest statement of the line comes from a standards body rather than a vendor. The OWASP Top 10 for LLM Applications 2026 scopes itself to the model-as-component case, meaning a model embedded inside an application and answering. Once the model becomes the actor, using tools, carrying memory across sessions, and causing downstream consequences, OWASP routes it to its agentic list instead. That is a standards body drawing precisely the boundary this page is about. The canonical source repository dates that edition to August 4, 2026, and it shows how far the boundary has moved: Excessive Agency now sits at LLM03, up from sixth place in the 2025 list.

The practical consequence is that AI agent security is a permissions and tooling problem before it is a model problem. Hardening a model does not shrink the blast radius of a tool that the agent is still allowed to call. This is where agent security separates from the wider AI security discipline, and it is why indirect prompt injection matters far more once an agent can act on what it reads.

The timing is the other half of the answer. Gartner forecasts that up to 40% of enterprise applications will include integrated task-specific agents by 2026, up from less than 5% in 2025. A 2025 survey of 353 organizations found that 80% said their AI agents had taken unintended actions. And Google's measurement of Common Crawl snapshots reported a relative increase of 32% in the malicious category between November 2025 and February 2026, meaning the untrusted content that agents read is itself getting worse. Adoption is running ahead of the controls, which is the recurring shape of every AI agent security challenge on this list.

The five places an agent can be attacked

Most current writing on this topic converges on the same five-layer model of the AI agent attack surface, and that convergence is a fair signal that the model is sound. It is table stakes rather than a differentiator, so it is worth stating once and then moving past.

‍

Table 1: The five layers of the AI agent attack surface and the failure each one introduces.

The rest of this page goes where that model does not: to the specific technique identifiers, the tool boundary, the identity registry, and the runtime signals.

How agent attacks map to MITRE ATLAS

MITRE ATLAS is MITRE's knowledge base of real-world adversary behavior against AI systems, and it is the agent-native framework for this problem. Its current release is v2026.07, published to GitHub on August 7, 2026. The release body states its own contents exactly: "This version of ATLAS data contains 1 matrix, 16 tactics, 101 techniques, 77 sub-techniques, 37 mitigations, and 68 case studies." That is 178 total technique definitions.

Of those 178, 29 entries are agent-specific: 13 parent techniques and 16 sub-techniques. Alongside them sit seven agent mitigations and four core agent case studies. The counting basis matters, so here it is: an entry qualifies when its full ATLAS display name contains "AI Agent" or "Agent", plus AML.T0034.002 Cost Harvesting: Agentic Resource Consumption, which is plainly agent-relevant but fails a strict word-boundary test on "Agent". Every identifier below is read from the release asset published in the ATLAS data repository.

The wider footprint is larger still. Across v2026.07, 48 of the 178 technique definitions (27.0%) mention "agent" in a name or description, along with 19 of 68 case studies (27.9%) and 14 of 37 mitigations. Roughly a quarter of the ATLAS corpus now touches agents in some way.

Here is the differentiator, stated precisely rather than loosely. It is not true that nobody has mapped ATLAS to agents. What is true is that every public attempt is built on a superseded ATLAS version and covers at most 2 of the 29 current agent entries. Two such public mappings exist, and neither is a page that ranks for this topic, which is why the ranking corpus itself censuses zero ATLAS identifiers. One of the two cites ATLAS v5.4.0 and names seven technique identifiers. The other cites a technique that has since been retired. For the framework overview itself, see our explainer on the MITRE ATLAS framework; what follows is the agent-specific surface.

A note on the other MITRE framework: ATT&CK is the wrong primary lens here. It matters post-compromise, once an agent's credentials or host are abused as a conventional foothold, but it has no agent-native technique family. The current release is ATT&CK v19.2, shipped on August 6, 2026. Adversarial testing of agents against these techniques belongs to AI red teaming, and ATLAS v2026.07 formalized that too, adding AML.M0035 AI Red Team as a mitigation.

Table 2: The 29 agent-specific technique entries in MITRE ATLAS v2026.07, grouped by parent technique. Identifiers and names are read from the release asset; the practice column is our plain-language gloss, not ATLAS description text.

Table 3: The seven agent-specific mitigations in MITRE ATLAS v2026.07.

Tool poisoning and the tool boundary

A tool definition is not configuration. It is text the model reads and obeys, which makes it an instruction surface. Tool poisoning is the attack that follows from that fact, and MITRE ATLAS tracks it as AML.T0110 AI Agent Tool Poisoning.

Keep three things apart, because they are routinely conflated. Prompt injection is the delivery mechanism. Memory poisoning corrupts what the agent remembers, and it is covered in depth in our guide to agentic AI security. Tool poisoning corrupts the tool itself, and prompt injection is frequently how it is delivered.

Three places a tool can be poisoned

ATLAS v2026.07 added three sub-techniques under AML.T0110, and they are useful precisely because they separate three different defensive problems. The parent technique predates this release and was updated in it; the three children are new.

‍

Table 4: The three sub-techniques of AI agent tool poisoning in MITRE ATLAS v2026.07.

The implementation column has a documented case. In September 2025, a widely used npm package shipping an email-sending tool for agents was backdoored. Koi Security's disclosure of the postmark-mcp backdoor records the shape plainly: "For 15 versions, FIFTEEN, the tool worked flawlessly," and then version 1.0.16 quietly added a blind copy of every message to an attacker address. The frequently repeated figure of about 300 affected organizations is not a measurement. It is the researchers' own estimate, applying a "maybe 20% are actively in use" assumption to a baseline of 1,500 downloads per week. Treat it as an assumption, because that is what its authors did. ATLAS carries the incident as case study AML.CS0053.

MCP as an attack surface

The Model Context Protocol (MCP) is the dominant way tools are exposed to agents, which makes an MCP server a supply-chain dependency holding production authority. Gartner's analysis puts it in similar terms, noting that MCP "was built for interoperability, ease of use and flexibility first, so security mistakes can manifest without continuous oversight for agentic AI." The same forecast expects 25% of enterprise generative AI applications to experience at least five minor security incidents per year by 2028, up from 9% in 2025.

The Model Context Protocol specification, at its dated release revision of 2026-07-28, carries a normative requirement worth quoting exactly: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." That sentence sits in the mitigation for token passthrough in the specification's security best practices document, which names eleven attack and mitigation subsections: Confused Deputy Problem, Token Passthrough, Server-Side Request Forgery, State Handle Hijacking, Local MCP Server Compromise, OAuth Authorization URL Validation, stdio Transport Security in Proxy Scenarios, Mix-Up Attacks, Localhost Redirect URI Impersonation, CIMD Trust Policies, and Scope Minimization.

Two corrections are worth carrying, because both errors are common. First, tool poisoning, line jumping, tool shadowing, and rug pull are not MCP specification concepts. They come from OWASP and from community research. Anyone citing "the MCP spec's tool-poisoning section" is describing something that does not exist. Second, "Session Hijacking" has been superseded by "State Handle Hijacking": MCP is now stateless with no protocol-level sessions, so content citing MCP session hijacking as a current specification section is working from a superseded revision.

OWASP has given tool poisoning an ordinal of its own, MCP03:2025, in the OWASP MCP Top 10. Status discipline matters here: that is an OWASP incubator project at v0.1, currently at Phase 3, beta release and pilot testing. Its final release carries no date, and the next release is scheduled for October 2026. It does not carry the authority of the LLM Top 10 and should not be cited as though it does.

Government guidance is further along. The NSA cybersecurity information sheet on the Model Context Protocol, a 17-page document at Version 1.0 dated May 2026 and issued by NSA alone, sets out nine MCP recommendations. Two are worth quoting exactly, because both are routinely paraphrased into something weaker: "Choose supported MCP projects when possible" and "Track and patch MCP related vulnerabilities."

One boundary condition is worth naming once and leaving alone: a leading analyst firm now advises treating as a no-go zone any use case that combines agent access to sensitive data, ingestion of untrusted content, and the ability to communicate externally. That combination is covered on our agentic AI security page. Tool supply chains also overlap with conventional dependency risk, which MITRE ATLAS names directly as AML.T0010.005 AI Supply Chain Compromise: AI Agent Tool.

Agent identity, inventory, and the registry problem

Traditional identity and access management assumes a principal with predictable access patterns, a human owner, and a session you can reason about. An agent breaks all three. Its access pattern is non-deterministic because the model decides what to call. Its authority arrives through a delegation chain rather than a login. And it is structurally a confused deputy, holding more authority than whoever is asking it to act. That last point is not theoretical framing: the confused deputy problem is the first named attack in the MCP specification's own security document.

The first control is therefore not a control at all. It is an inventory. Three independent pages in this market assert that agent discovery matters, and none of them explains the method. The method is a registry, reconciled against observed behavior. Anything invoking tools that does not appear in the registry is a shadow agent, and that reconciliation is the only reliable way to measure agent sprawl.

Table 5: Fields an agent registry record should carry, and the consequence of omitting each.

On vocabulary, two terms describe the same underlying thing. A machine identity and a non-human identity (NHI) both mean a principal with credentials and permissions that is not a person, covering service accounts, API keys, workloads, and now agents. Honest caveat: the difference between these terms may be a genuine gap in the market's language, or the market may simply have settled on "non-human identity". The evidence does not distinguish those. Where agent identity overlaps with detecting misuse of any non-human principal, that ground belongs to identity threat detection and response.

The portable-standard layer is the weak point, and it is worth being blunt about. SPIFFE and SPIRE, the CNCF projects for issuing cryptographic workload identity, have been Graduated since September 20, 2022, so anyone describing them as emerging is four years out of date. Above that layer, the picture is thinner than the volume of activity suggests. There are 165 active IETF drafts on AI agent identity or authorization. All 165 are individual submissions. Zero are working-group adopted. The agent-identity standards layer is a proposal explosion, not a standards layer. Two counterexamples are worth naming: the OAuth Client ID Metadata Document is a genuine working-group document that the MCP specification references directly, and the OpenID AuthZEN working group has a draft binding authorization to MCP, with the AuthZEN Access Request and Approval Profile reaching Draft 1 on August 20, 2026. Meanwhile the WIMSE working group has produced six active documents and zero RFCs in roughly 33 months chartered, and RFC 8693 remains a Proposed Standard with zero updates and zero obsoletes across all 120 of its relation rows, meaning nothing has superseded it for agent delegation. Sources for the above sit in the IETF datatracker.

The practical read: you cannot buy portable agent identity yet, so scope, sponsor, and expiry are the controls actually available to you. NCSC guidance on adopting agentic AI reaches a similar conclusion from the governance side. Zero trust principles apply cleanly to agents, with one adjustment: the principal being continuously verified is not a person, so the verification signal has to come from behavior rather than from a login event.

What documented AI agent incidents show

The incidents that exist are more useful than the projections, because each one shows where the boundary actually failed.

Table 6: Documented AI agent security incidents with their primary sources and ATLAS case study identifiers where one exists.

Amazon Q Developer. A malicious contribution reached the shipped extension. AWS security bulletin AWS-2025-015 states the outcome exactly: "AWS Security has inspected the code and determined the malicious code was distributed with the extension but was unsuccessful in executing due to a syntax error." The destructive instruction was fully formed. A typo is what stopped it. On CVE-2025-8217, both scores, CVSS v4.0 5.1 MEDIUM and v3.1 4.0 MEDIUM, are Secondary and were assigned by AWS as the CNA. NVD published no Primary score of its own and the record status is Deferred.

postmark-mcp. Covered above, and it belongs here too, because a poisoned agent tool is a dependency that inherits the agent's production authority. The reasoning that governs any supply chain attack applies, with a much shorter path to consequence.

Claude Code GitHub Action. A single unsandboxed tool was the entire attack path, reachable from an ordinary GitHub issue. GMO Flatt Security's technical write-up records a CVSS v4.0 score of 7.8 assigned by the vendor, a bounty of $4,800, and the core bypass fixed in claude-code-action v1.0.94. Partial sandboxing of an agent is a full bypass.

The July 2026 agent-driven intrusion. An AI platform provider disclosed that an autonomous agent framework drove an end-to-end intrusion of its internal systems. Its technical timeline is the forensic record: "Our forensic reconstruction covers ~17,600 attacker actions that we were able to recover, grouped into ~6,280 clusters, between 2026-07-09 02:28 UTC and 2026-07-13 14:14 UTC." Those roughly 6,280 are activity clusters rather than compute clusters, and the window is roughly four and a half days. The same document records that "the agent read the cluster's secret objects, including a production object holding 136 keys." The provider's incident disclosure describes "unauthorized access to a limited set of internal datasets and to several credentials" and states that assessment of partner and customer impact was still under way. It does not name the other party, and neither should any summary of it.

The detection detail is the part worth keeping. The signals did fire. In the provider's own words, they "were correlated by our AI-based security agent stack and resolved into a coherent attack signal. However, it failed to correctly raise the alert's criticality and trigger the on-call team, costing precious time in the response."

EchoLeak. Private data access, untrusted content ingestion, and an outbound channel, observed in production against Microsoft 365 Copilot. Carry both scores honestly: CVE-2025-32711 is scored CVSS 9.3 CRITICAL by Microsoft acting as CNA, while NVD's independent NIST analysis scores it 7.5 HIGH, with CWE-74. A 9.8 figure circulating in some coverage has no basis in either source. EchoLeak and related agentic incidents are covered on our agentic AI security page.

The cyber-evaluation incidents. A model provider disclosed that "after reviewing 141,006 evaluation runs where Claude could have obtained internet access," it identified three incidents in which its models reached third-party organizations during security testing. Two of the three organizations have since been contacted. Three out of 141,006 is not a base rate and must never be rendered as a percentage: the disclosure describes an investigation, not a measurement of incidence. Its own root-cause framing is the cleanest statement of this page's thesis: "We believe these incidents to be closer to a harness and operational failure than a model alignment failure."

Two 2026 CVEs on shipping agent products round out the picture. CVE-2026-62830 in Azure SRE Agent is scored CVSS v3.1 9.9 CRITICAL with CWE-862, and CVE-2026-59118 in Copilot Cowork is scored 9.3 CRITICAL with CWE-285. Both were published on August 6, 2026, and both scores are CNA-assigned with no independent NVD analysis. That pattern is the norm on AI agent products rather than the exception, which is why any CVE table on this topic has to say whose score it is showing. Neither appears in the CISA exploited-vulnerabilities catalog, so neither should be described as exploited.

The common thread is that not one of these traces to a model being wrong. Almost all trace to an indirect prompt injection reaching a tool, or to a permission broader than the task required. The July 2026 case is the instructive exception, because there the agent was the attacker rather than the victim. Our own research on AI agent communities and the illusion of harmlessness reaches the same conclusion from the agent-to-agent direction.

Detecting and containing a compromised AI agent

Start with the honest statement, because it sets the requirement. There are two documented failure modes, and they are different problems.

The first is silence. In the ZombieAgent case, no traditional control detected the exfiltration. Not secure web gateways, not endpoint tooling, not firewalls, and no alert reached the user. The OECD AI Incidents and Hazards Monitor record is the neutral registry entry for it. Researchers describe it as a zero-click indirect prompt injection, which is their framing and worth attributing as such, since the user still has to converse with the assistant normally for the payload to fire.

The second is noise scored wrong. In the July 2026 intrusion, signals fired from several layers at once and were correlated into a coherent attack signal. The system then failed to raise the alert's criticality. Silence and mis-scored criticality both end in the same place, and neither is fixed by a better model.

Five runtime signals are worth building detections around:

1. Instruction-following anomalies: actions with no plausible link to the task.
2. Tool call sequences that break the expected workflow topology.
3. Exfiltration through low-bandwidth channels the agent legitimately holds.
4. Credential and secret access outside the current task scope.
5. Memory-write anomalies that persist dormant instructions across sessions.

SignalWhat it looks like in telemetryATLAS techniqueConstraining mitigationInstruction-following anomalyTool calls with no parent task or user requestAML.T0080AML.M0030Tool call topology breakA call sequence crossing a workflow boundaryAML.T0053AML.M0028Low-bandwidth exfiltrationSmall, repeated outbound writes via a permitted toolAML.T0086AML.M0033Out-of-scope credential accessSecret reads unrelated to the running taskAML.T0098AML.M0026Memory-write anomalyWrites to persistent memory outside a user turnAML.T0080.000AML.M0029

Table 7: Five runtime detection signals for a compromised AI agent, mapped to the ATLAS technique each observes and the mitigation that constrains it.

Anchor detection to mitigations rather than to product capabilities, because mitigations will still be true in a year. AML.M0033 Input and Output Validation for AI Agent Components and AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data are the two that generate the most detection-relevant telemetry. And note that human-in-the-loop is not a soft recommendation here: it is AML.M0029 Human In-the-Loop for AI Agent Actions, a named mitigation, echoed by a dedicated section in the OWASP AI Agent Security Cheat Sheet and a human-in-the-loop subsection in the joint government guide.

For measurement, a research lab has proposed the only agent-native metric set anyone has published, and no vendor has picked it up: "coverage (the fraction of traffic monitored), recall (the fraction of misaligned behaviors caught), and time-to-response." The same work argues for treating untrusted AI agents as potential "insider threats", which is the correct posture. Adopting those three metrics gives you something to report that is not an alert count. Genuine agent runtime observability, meaning tool invocations logged as first-class events rather than prompts logged as text, is the prerequisite, and it sits alongside the wider practice of security observability.

The strongest argument for runtime detection is exploitation data. As of catalog version 2026.08.24, released on August 24, 2026, the CISA Known Exploited Vulnerabilities catalog held 1,675 entries, of which 11 touch the AI and agent stack: six Langflow entries, two LiteLLM entries, and one each for MLflow, n8n, and Ray. That six-of-eleven concentration in a single agent-workflow platform is itself worth noting. More useful still is the timing spread. The Ray entry, CVE-2025-62593, was published at NVD on November 26, 2025 and added to the catalog on August 17, 2026, a gap of 264 days. By contrast, MLflow's CVE-2026-64849 was published on August 17, 2026, added on August 19, 2026, and carries a remediation due date of September 2, 2026, a two-day lag. If a known-exploited flaw in your agent stack can sit for nine months before anyone tells you it is being exploited, patch cadence cannot be the only control. Something has to watch behavior in the interval.

Volume gives the same message from the other end. OWASP's own tracking, using an April 2026 snapshot of monitored GitHub repositories, records advisory counts of 57 for n8n, 22 for Claude Code, 15 for AutoGPT, 13 for Dify, and 11 for Roo-Code. These are counts per monitored repository, not a census of agentic projects. Adversarial testing of your own agents belongs to AI red teaming, and the model-layer half of the problem sits with GenAI security.

Frameworks, government guidance, and regulation

Agent-specific control catalogs are being written right now, which makes dating every framework reference correctly a visible quality signal rather than pedantry.

Table 8: Framework and regulatory crosswalk for AI agent security, with the edition and date of each instrument.

Joint guidance on the careful adoption of agentic AI services is the densest agent-specific control guidance published to date. Its 29 pages organize the problem into five risk categories, and it is worth using the guide's own wording rather than the paraphrase that circulates in coverage: Privilege risks (page 7), Design and configuration risks (page 9), Behaviour risks (page 9), Structural risks (page 11), and Accountability risks (page 12). Its best-practice content is organized as a four-phase lifecycle covering designing, developing, deploying, and operating secure agents. Six agencies across five countries co-authored it: the Australian Signals Directorate's ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK.

On regulation, the dates changed and much of the published guidance has not caught up. Regulation (EU) 2026/1744 was adopted on 8 July 2026, published in the Official Journal on 24 July 2026, and entered into force on 27 July 2026. It will apply standalone Annex III high-risk obligations from 2 December 2027 and embedded Annex I high-risk obligations from 2 August 2028. Only the Article 50 transparency obligations applied from 2 August 2026. An enterprise agent that makes or materially informs decisions in an Annex III domain is a high-risk AI system, so December 2027 is the operative planning horizon, while Article 50 disclosure already applies to customer-facing agents today.

What is coming is worth watching but not overstating. NIST's control overlays for securing AI systems include two named agent use cases, "Using AI Agent Systems (AI Agents) – Single Agent" and "Using AI Agent Systems (AI Agents) – Multi-Agent". Both are planned and neither has been drafted: only a concept paper and an annotated outline for the predictive AI use case exist. Separately, the NIST AI Agent Standards Initiative, announced on 17 February 2026, sets out three pillars including agent security and identity research.

Two sourcing notes save real errors here. The 2026 LLM list is the first edition weighted by incident data, and its preface records a corpus of 7,714 real incidents, 6,639 of them carrying enough detail to classify, with the community vote carrying three-quarters of the weight and the incident data the remaining quarter. Read those figures and the ordinals from the source repository rather than from a landing page. Likewise, read the version from the PDF cover of OWASP Agentic AI Threats and Mitigations v1.1 rather than from its page date, and note that the CSA AI Controls Matrix v1.1 carries 247 control objectives while the unsuffixed URL still serves the older 243. The application-layer companion to all of this is GenAI security, and the agentic architecture layer is covered under OWASP Top 10 for Agentic Applications.

Modern approaches to AI agent security

Tooling for enterprise AI agent security is arriving quickly, and it is currently sorting itself into six categories rather than one.

• Agent discovery and inventory. Finding agents nobody registered, and reconciling them against a registry.
• Per-agent risk assessment. Scoring an agent by the reach of its tools and credentials rather than by its model.
• Tool and MCP access control. Governing which tools an agent may invoke, and under what conditions.
• Agent action control. Approving, constraining, or blocking a specific action at runtime.
• Runtime behavioral detection. Observing what the agent actually does and alerting on deviation.
• Identity and delegation controls for non-human principals. Scoped credentials, delegation chains, and revocation.

Four questions separate AI agent security solutions that will hold up from ones that will not. Does it enumerate agents you did not register, or only inventory the ones you told it about? Does it see tool invocations, or only prompts? Does it map findings to a public technique taxonomy you can audit? And can it constrain a single tool without disabling the agent, which is the difference between a control and an off switch?

Where the market is going is reasonably clear. Agent identity is being folded into existing identity-security categories rather than becoming a standalone one, and the control catalogs are being written now rather than being mature. Note also that several vendors prominent in this space changed hands between December 2025 and June 2026, so independence should be checked rather than assumed. Agent-based and agentless deployment models are a separate question entirely, covered under cybersecurity solutions.

How Vectra AI thinks about AI agent security

An AI agent is a new kind of identity operating on the same network as everything else, so the same assume-compromise question applies to it. If an agent's credentials are used to do something that agent was never meant to do, does anything in your environment see it? Vectra AI's position is that agent behavior has to be observed where the agent acts, across network, identity, and cloud, rather than inferred from the prompt that started it. That is the same Attack Signal Intelligence™ approach we apply to any compromised principal: watch what it does, not what it claims to be. The wider AI security picture sets the context for that position.

Conclusion

The question that separates AI agent security from AI security generally is not "is the model safe". It is "what is this agent allowed to do, and would anyone notice if it did something else". Every documented incident so far answers the first half badly and the second half worse. The work in front of most security teams is unglamorous and sequential: enumerate the agents, name a sponsor for each, scope the tools rather than the model, and get tool invocations into telemetry where a detection can reach them. MITRE ATLAS v2026.07 gives you 29 technique identifiers and seven mitigations to anchor that work to a public taxonomy.

If you are working through the surrounding architecture, lifecycle, and governance questions, our guide to agentic AI security picks up where this page stops.

‍