AI agent attack techniques expand MITRE ATLAS beyond LLM threats

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Zenity's blog post: MITRE ATLAS now includes 14 agent-focused techniques and subtechniques that model how AI agents can be manipulated through context, memory, configuration, tools, and data access.

Why it matters: This matters because IAM, PAM, and NHI teams now have to treat AI agents as governed identities with reachable permissions, not as prompt-only interfaces.

Context

MITRE ATLAS was originally oriented around broader AI threats, but this update is about attack behaviour against AI agents that interact with real systems and data. In practical terms, that means the security boundary is no longer the model alone. It extends to the agent's context, memory, configuration, tools, and the data sources those tools can reach.

For identity teams, the important change is that agent security now overlaps with NHI governance, authorisation design, and lifecycle control. Once an agent can invoke tools, retrieve from RAG stores, or act on triggers, its attack surface looks much closer to a governed workload identity than to a standalone chatbot.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why do agentic systems create different identity risks from chatbots?

A: Agentic systems can act, sequence tasks, and reuse state. That means identity risk is not limited to authentication or prompt quality, because the software can carry delegated authority into later steps. The result is a broader attack surface where tool misuse, scope drift, and control bypass become operational concerns.

Q: What are the warning signs that an AI agent's access is too broad?

A: Look for agents that can discover many tools, read broad document sets, or write into business systems without a narrow task boundary. If the same agent can access sensitive data, activate on common triggers, and complete downstream actions without review, its effective privilege is already too large.

Q: What should teams do when a compromised agent starts using legitimate workflows for exfiltration?

A: Contain the downstream permissions first by disabling the agent's highest-risk tools, revoking exposed credentials, and separating the affected workflow from live systems. Then review which data sources, triggers, and configuration paths allowed the agent to act with that level of reach.

Technical breakdown

Context poisoning and memory persistence in AI agents

Context poisoning is the manipulation of an agent's working context so that its subsequent decisions or outputs are shaped by attacker-controlled instructions. Memory poisoning goes further by persisting that influence across sessions, while thread poisoning affects the current conversation lifecycle. These are not just prompt-injection variants. They matter because agent behaviour can be altered without touching the underlying model weights, simply by corrupting the state the agent uses to decide what to do next. For defenders, the architectural issue is state trust: the agent treats external context as operational input, even when that context is attacker-influenced.

Practical implication: separate trusted task state from untrusted conversational or retrieved content and treat persisted agent memory as a governed input source.

Tool and configuration discovery expand the attack surface

MITRE ATLAS now models how adversaries can discover an agent's configuration, embedded knowledge, available tools, and activation triggers. That matters because configuration often reveals the real permissions boundary for the agent, including which APIs, services, and datasets it can reach. Tool discovery is especially important in enterprise environments because the same agent can become a pathway to multiple systems. If attackers know which triggers wake the agent and which tools it can call, they can steer execution into data access or exfiltration paths without needing direct access to each downstream system.

Practical implication: inventory agent configuration, tool access, and trigger conditions as security-relevant assets, not implementation details.

RAG credential harvesting and data exfiltration through agent tools

The new techniques also cover retrieval from RAG databases, collection of credentials from internal documents, and exfiltration through tool invocation. This is a distinct pattern from classic model abuse because the attack targets the agent's access path into enterprise content. If the agent can query documents, inspect stored credentials, or write through approved tools, an adversary may use ordinary-looking prompts to move sensitive data out through legitimate channels. The control problem is therefore not just content filtering. It is governing what the agent can retrieve, what it can write, and how much damage one compromised execution path can create.

Practical implication: classify RAG stores, downstream APIs, and write-capable tools as part of the agent's privilege boundary and monitor them accordingly.

Threat narrative

Attacker objective: The attacker wants to turn the agent's legitimate access into a controlled path for credential collection, data theft, or unauthorized downstream actions.

1. Entry occurs when an adversary gains access to an agent-facing conversation, trigger, configuration surface, or retrieved content path that the agent treats as valid input.
2. Credential or state access follows when the attacker manipulates context, memory, RAG content, or configuration to learn what tools, data sources, and embedded secrets the agent can reach.
3. Escalation happens when the attacker uses the agent's own tool permissions to retrieve sensitive data, write malicious content, or invoke downstream services under the agent's identity.
4. Impact is achieved when legitimate-looking agent actions move confidential information or malicious instructions across enterprise systems with reduced human visibility.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent attack coverage has crossed from model safety into identity governance. The ATLAS update matters because the adversary is no longer only targeting what the model says. It is targeting what the agent can reach, retrieve, or invoke. That moves the control conversation from prompt hygiene to governed access scope, tool boundaries, and execution context.

Agent identity is now a first-class attack surface, not a proxy for application risk. An AI agent that can call APIs, read RAG stores, and trigger actions behaves like a delegated non-human identity with changing runtime exposure. NHI governance becomes relevant because the real question is no longer whether the model is safe, but whether the agent's effective permissions are intelligible, bounded, and revocable.

Context poisoning is a named concept that security teams should treat as privilege manipulation by another route. The attacker does not need to break the model to change outcomes. If the agent accepts attacker-influenced context as operational truth, then the decision boundary is already compromised. Practitioners should treat the trusted context layer as part of the authorisation model, not as harmless input handling.

Tool discovery changes how least privilege must be enforced for AI agents. The moment an adversary can map available tools, activation triggers, and embedded knowledge, they can shape an attack around the highest-value path. That means security programmes need to know which agent capabilities exist before they can reason about blast radius. Control ownership should sit with identity and platform teams together, not with the model team alone.

RAG and tool invocation are where AI agent compromise becomes enterprise compromise. The new techniques show that the agent is often only the bridge into data and downstream systems. Once the bridge exists, the attack can use ordinary business workflows as exfiltration channels. Practitioners should therefore align agent security with access governance, data classification, and privileged workflow control rather than treating it as an isolated AI problem.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Agent attack matrices are becoming governance artefacts, not just research outputs. When an attacker can steer context, memory, or tool choice, the real boundary is the agent's effective permission set. That is why identity teams need a governed inventory of agent actions, not just a list of prompts or model versions.

Least privilege for AI agents is now about reachable enterprise actions, not just allowed APIs. Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey. That gap shows why authorisation must be designed around agent execution paths, not around model output alone.

For practitioners

• Map agent tool permissions to identity scope Document every API, data source, and write-capable service the agent can reach, then classify those permissions as part of the agent's governed access boundary.
• Inventory agent triggers and configuration surfaces Review the keywords, events, files, and workflow conditions that activate agents so unexpected execution paths can be governed and monitored.
• Separate trusted state from untrusted context Keep persistent memory, retrieved content, and conversation history under explicit trust controls so attacker-shaped input cannot silently steer decisions.
• Restrict write-capable tools by blast radius Limit which agents can send email, modify records, create documents, or update CRM data, and treat each write path as a distinct risk tier.
• Track agent credentials and embedded secrets Scan configuration files and connected services for credentials exposed to agent runtime paths, and revoke anything the agent should not inherit or reuse.

Key takeaways

• AI agent attack coverage has expanded from model manipulation into the permissions, context, and tools that let agents affect real systems.
• The article's core signal is that AI agents now need identity-style governance because their attack surface includes retrieved data, configuration, triggers, and downstream actions.
• Practitioners should inventory agent permissions, constrain write-capable tools, and treat persisted context as a security boundary.

Key terms

• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• RAG Credential Harvesting: RAG credential harvesting is the collection of secrets from retrieved enterprise content that an AI agent can access. It matters because documents, notes, and indexed sources can inadvertently become credential stores, turning ordinary retrieval into a path for sensitive data exposure.
• Agent Tool Specification: A description of when an AI agent may call a tool, what inputs it accepts, and what outputs or failures it can return. Clear tool specifications reduce invalid calls, improve evaluation consistency, and help teams control autonomous behavior in production workflows.
• Embedded Knowledge: Embedded knowledge is the data source or internal content an AI agent is configured to access as part of its tasking. When that knowledge is broad or poorly classified, it can expose sensitive material to both legitimate agent actions and adversary-driven abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.