Once an adversary can steer an AI agent, every tool that agent holds becomes the adversary's tool, used with the agent's credentials and often with access the adversary could never get directly. MITRE ATLAS tracks this as AML.T0053 AI Agent Tool Invocation and places it in three tactics at once: Execution (AML.TA0005), Privilege Escalation (AML.TA0012) and Lateral Movement (AML.TA0015). This page explains what each of those means for an agent, what ATLAS case studies show, how to authorise tool calls one by one, and which logs reveal abuse. Tool and plugin hardening in general is covered in the AI Agent Tool and Plugin Security Guide, and the exfiltration case in MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation. It is written for teams that build, approve or monitor agents with access to business systems, code execution or MCP servers.
Source note: technique, tactic, mitigation and case study details on this page are from MITRE ATLAS release 2026.10 (ATLAS data modified 28 October 2026). Confirm against the official text before relying on it.
Key takeaways
- One technique, three tactics. ATLAS maps AML.T0053 to Execution, Privilege Escalation and Lateral Movement, because a tool call can run code, use rights the attacker lacks, and reach systems beyond the agent.
- Treat every model-chosen argument as attacker input. In ATLAS case AML.CS0062 a search tool's filter argument reached a code evaluation path in an agent framework; the model behaved as designed and the tool trusted its input.
- Authorise each call, not the agent once. ATLAS maps thirteen mitigations to this technique, and four of them (AML.M0026 to AML.M0029) are about who the tool acts as and who approves it.
- Untrusted content in context should lower what the agent may do. AML.M0030 recommends blocking automatic tool calls, or requiring confirmation, once untrusted data enters the model's context.
- Log the tool call with its arguments and identity. AML.M0024 maps directly to this technique: "Log AI agent tool invocations to detect malicious calls."
What ATLAS says AML.T0053 is
ATLAS describes adversaries using their access to an AI agent to invoke the tools it has: integrations with other applications, public or private data sources, and code execution. That can let the adversary call APIs of integrated services with increased privileges, pull sensitive data from connected sources, or run arbitrary instructions through an interpreter tool. ATLAS adds two details that are easy to overlook. Agents may invoke applications indirectly through operating system mechanisms such as deep links, app-intent URIs, universal links or redirect chains, which can open an installed application that was never a declared agent tool and may avoid normal confirmation steps. And agents may hold tools users cannot reach directly, so hijacking the agent gives access to tools the adversary otherwise could not use.
The technique is in the "Agentic AI" platform, rated "Demonstrated", created in October 2023 and last modified in October 2026. It almost always follows AML.T0051 LLM Prompt Injection (see the MITRE ATLAS AML.T0051 LLM Prompt Injection Guide), which is how the adversary gains the access, or a poisoned tool or configuration.
The three tactics in agent terms
| ATLAS tactic | What the tool call achieves | ATLAS case study example |
|---|---|---|
| Execution (AML.TA0005) | Code or commands run through an interpreter, shell, terminal or computer-use tool | AML.CS0016 MathGPT: an LLM connected to a Python interpreter ran code the prompt induced it to write. AML.CS0045: an injected prompt reached Cursor's terminal tool through a scraped web page. AML.CS0046: a computer-use agent ran a destructive command through its bash tool |
| Privilege Escalation (AML.TA0012) | The tool acts with rights the adversary does not hold: the user's delegated access or the agent's service identity | AML.CS0039: a malicious support ticket caused Atlassian MCP tools to be invoked with an internal engineer's access to the service desk. AML.CS0048: prompting an exposed assistant led its bash skill to run as root in its container |
| Lateral Movement (AML.TA0015) | The tool reaches another system, service or user the adversary could not reach | AML.CS0063: instructions in a calendar invitation caused an assistant to use calendar tools, smart home controls and app links on the victim's connected services. AML.CS0066: an email assistant was made to send the prompt on to collected contacts |
Two further cases show the boundary problems that matter most. In AML.CS0067, a CI agent processing untrusted GitHub content was directed to its built-in Read tool on the process environment; ATLAS records that the Read tool did not run inside the sandbox and scrubbed environment applied to Bash subprocesses. Sandboxing one tool while another tool can reach the same secrets is not a boundary. In AML.CS0062, the Microsoft Security blog described framework flaws where a model-controlled filter string reached Python eval() and a file download function was exposed as a callable tool; the post's lesson is that the LLM is not a security boundary and every tool parameter the model can influence is attacker-controlled input. The framework maintainer fixed both issues in later releases.
The Sentry MCP agentjacking research is a recent example from outside ATLAS: a fake error report read through an MCP server led coding agents to run an install command with the developer's own privileges. The lesson for the customer side is the same: tool output that someone else can write is an instruction channel.
Authorising tool calls one by one
The OWASP Top 10 for LLM Applications 2025 entry LLM06 Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. Those map cleanly onto the three questions a policy enforcement point should answer for every tool call.
| Question | Control | ATLAS mitigation |
|---|---|---|
| Should this agent have this tool at all? | Per-agent tool allowlist; remove tools trialled and dropped; split read and write tools; expose narrow functions rather than open-ended shells | AML.M0026 Manage AI Agent Service Access |
| As whom does the tool act? | Delegated access from the requesting user, never more than the user holds; for shared tools, the identity and restrictions of the calling agent | AML.M0027 Manage User-Delegated AI Agent Access; AML.M0028 Enforce Access Controls for AI Agent Tools |
| Are these arguments acceptable now? | Schema validation, allowlisted destinations and paths, canonicalisation, no dynamic evaluation of model output | AML.M0033 Input and Output Validation for AI Agent Components |
| Does the context allow automatic execution? | Drop to read-only or require confirmation once untrusted data is in context | AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data |
| Does a person need to approve? | Approval scaled to consequence, showing the full arguments | AML.M0029 Human In-the-Loop for AI Agent Actions |
| What can the tool reach if all else fails? | Containers or VMs for code execution, restricted file system and network, rate limits, clean environment per run | AML.M0032 Segmentation of AI Agent Components |
ATLAS also maps AML.M0020 Generative AI Guardrails, AML.M0021 Generative AI Guidelines, AML.M0022 Generative AI Model Alignment, AML.M0024 AI Telemetry Logging and Monitoring, AML.M0035 AI Red Team and AML.M0038 AI Agent Scope Drift Detection to AML.T0053. Guardrails and alignment reduce how often the model chooses a harmful call; the controls in the table decide what happens when it does.
Where to enforce
- In the tool or MCP server: the MCP specification (version 2025-11-25) says servers MUST validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitise tool outputs. This is the only point that sees the final arguments and the downstream identity together.
- In the agent host or client: the same specification says clients SHOULD prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing them to the LLM, apply timeouts and log tool usage. It also says there SHOULD always be a human in the loop able to deny tool invocations.
- At the gateway: an AI or MCP gateway can apply allowlists and log every call across agents; see the AI Gateway and LLM Gateway Guide.
- In the downstream system: the API the tool calls still enforces its own authorisation against the token it receives. The MCP security best practices forbid token passthrough: servers MUST NOT accept tokens not explicitly issued for them.
Do not rely on tool metadata for these decisions. The MCP specification states that clients MUST treat tool annotations, such as hints that a tool is read-only or destructive, as untrusted unless they come from trusted servers. Classify tools yourself.
Choosing how much approval to require
AML.M0029 notes that approval has an operational cost and should follow the consequence of the task. The tiers below are our recommendation for applying it alongside AML.M0030.
| Tool class | Examples | Clean context | Untrusted content in context |
|---|---|---|---|
| Read, own scope | Search the user's own files, read a ticket assigned to them | Automatic | Automatic, logged |
| Read, broad scope | Enterprise search, CRM queries across accounts | Automatic, logged | Automatic for read, but block any later write in the same turn without approval |
| Write, internal and reversible | Draft a document, update a ticket field | Automatic or batched approval | Approval |
| Write, external or irreversible | Send email, post to an external channel, payments, delete, change permissions | Approval with full arguments | Approval with full arguments, or blocked |
| Code and command execution | Shell, interpreter, terminal, computer use, package install | Sandboxed, approval for network or install actions | Blocked or approval per command in a sandbox |
A small team using a hosted assistant mostly sets this through product settings: which connectors are on, which actions require confirmation, and whether the assistant may act on email or web content without asking. A larger organisation running its own agents should implement the matrix as policy in a gateway or agent runtime so it applies to every agent the same way. The AI Agent Permission Matrix Template gives a starting format, and the Human-in-the-Loop for AI Agents Guide covers approval design, including approval fatigue.
Rolling it out
- Inventory tools per agent. List every tool, MCP server, plugin and connector each agent can call, with the identity each uses and whether it reads, writes or executes. Include indirect paths such as URL opening and app links.
- Turn on tool-call logging first. Record tool name, full arguments, result status, identity, the session and whether untrusted content was in context (AML.M0024). Run in log-only mode for two to four weeks to learn normal patterns.
- Remove what is not needed. Drop unused tools and split broad tools into narrow ones. This is the cheapest control and needs no approval workflow.
- Move identities to delegated access. Replace shared service credentials behind user-facing agents with on-behalf-of tokens scoped to the user (AML.M0027, AML.M0028). See OAuth Token Exchange and Delegation Guide.
- Add argument validation and the untrusted-context rule. Enforce schemas and allowlists, then apply AML.M0030 in warn mode, review what would have been blocked, and switch to enforce.
- Add approval for the top tiers and sandbox execution. Pilot with one team, measure approval volume and denial rate, then extend.
- Roll back safely. Keep each policy behind a flag per agent so a blocking rule can return to warn mode without removing logging.
Detection
| Data source | What to look for |
|---|---|
| Agent trace and tool-call log | A tool call that does not match the user's request; a write or execute call in the same turn as retrieval of external content; tools the agent has never used before; repeated failed or rejected calls |
| MCP server and gateway logs | New servers, tool list changes (notifications/tools/list_changed) after approval, calls to tools outside the agent's allowlist, unusual argument sizes or encoded strings |
| Endpoint telemetry on agent hosts | The agent process spawning shells, package managers or network tools; writes to startup or persistence locations; reads of credential files |
| Downstream application audit logs | Actions under a user's delegated identity at times or volumes unlike that user; permission changes or deletions performed by an agent identity |
| Mobile and desktop platforms | Application launches through deep links or app-intent URIs initiated by an assistant |
Behavioural baselines per agent make the first row workable at scale; see the AI Agent Behaviour Baselining and Anomaly Detection Guide.
Metrics
- Tool inventory coverage: share of production agents with a current tool list, identity per tool and tier.
- Delegation rate: share of user-facing agent tools that act with delegated user access rather than a shared credential.
- Untrusted-context enforcement: share of agents where AML.M0030 is in enforce mode.
- Approval quality: denial rate and median approval time for top-tier calls; a denial rate near zero can mean rubber-stamping.
- Red-team result: share of tests that selected an unauthorised tool, passed unsafe arguments or chained tools, and were blocked or detected.
Testing
ATLAS gives AML.M0035 AI Red Team specific guidance for this technique: attempt to select unauthorised tools, supply unsafe arguments, exceed user privileges, or chain tools into harmful actions, then correct permissions, argument validation, sandboxing, action controls and approval requirements. Run tests from each content channel the agent reads, using harmless canary actions such as a call to an endpoint you own. Check whether a tool outside the sandbox can reach what the sandbox protects, which is the gap AML.CS0067 exposed. The MCP Security Testing Guide covers server-side tests.
Where identity fits
Tool invocation is privilege escalation only because the tool's identity holds more than the adversary does. ATLAS AML.M0027 states that an agent acting for a user should not be granted permissions that user would not have. In practice that means per-user delegated tokens with narrow scopes, separate identities per agent rather than one shared service account, and short lifetimes, so that a hijacked call is limited to one user's access for minutes rather than a whole tenant indefinitely. See the AI Agent Authorisation Guide and Delegation Chains and Attenuated Authority for AI Agents.
Framework mapping
| Framework | Entry | Relationship |
|---|---|---|
| MITRE ATLAS | AML.T0053 (AML.TA0005, AML.TA0012, AML.TA0015) | Source technique |
| MITRE ATLAS | AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.T0098 AI Agent Tool Credential Harvesting | Specific outcomes of tool invocation with their own technique pages |
| MITRE ATT&CK v20 | T1059 Command and Scripting Interpreter | Where the tool is a shell or interpreter, the resulting execution is ordinary T1059 activity on the host; see the MITRE ATLAS AML.T0050 Command and Scripting Interpreter Guide, and for agents launched by the adversary the MITRE ATLAS AML.T0103 Deploy AI Agent Guide |
| OWASP Top 10 for LLM Applications 2025 | LLM06:2025 Excessive Agency | Root causes: excessive functionality, permissions and autonomy |
| OWASP Top 10 for Agentic Applications | ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse | See the OWASP Agentic Top 10 ASI02 Guide and OWASP Agentic Top 10 ASI03 Guide |
| Model Context Protocol 2025-11-25 | Tools: Security Considerations; Security Best Practices | Server and client requirements for validation, access control, confirmation and logging |
Common failure patterns
- A shared, over-privileged service account behind a user-facing agent. Every user, and every injected prompt, gets the account's full reach. This is the privilege escalation path in AML.CS0039.
- Sandboxing the shell but not the other tools. AML.CS0067 shows a file read tool reaching secrets that the Bash sandbox had scrubbed.
- Approval dialogs that hide arguments. If the approver sees "send email" but not the recipient and body, approval adds friction without control.
- Trusting tool metadata. Tool descriptions and annotations come from the server; the MCP specification says to treat annotations as untrusted unless the server is trusted.
- Dynamic evaluation of model output in tools. Passing model-generated strings to
eval, shell commands or file paths without allowlists is the root of AML.CS0062. - Ignoring indirect invocation. ATLAS notes deep links and redirect chains can launch applications that were never declared tools; mobile and desktop assistants need the same controls on URL handling.
Practitioner checklist
- Inventory every tool, MCP server and connector per agent, with identity, read/write/execute class and indirect launch paths.
- Log every tool call with full arguments, identity, session and untrusted-context flag (AML.M0024).
- Remove unused and over-broad tools; split read and write functions (AML.M0026).
- Use delegated user access or calling-agent identity for tools, never more than the user holds (AML.M0027, AML.M0028).
- Validate arguments with schemas and allowlists in the tool or MCP server; no dynamic evaluation (AML.M0033).
- Restrict automatic tool calls once untrusted content enters context (AML.M0030).
- Require approval with full arguments for external, irreversible and execution tools (AML.M0029).
- Run code execution in isolated, clean environments with restricted network and file access, and check other tools cannot bypass it (AML.M0032).
- Red-team tool selection, arguments, privilege and chaining per agent (AML.M0035).
Standards and references
- MITRE ATLAS: AML.T0053 AI Agent Tool Invocation
- MITRE ATLAS: AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data
- MITRE ATLAS: AML.CS0067 Claude Code GitHub Action Secret Exposure
- Model Context Protocol: Tools specification
- Model Context Protocol: Security Best Practices
- OWASP: LLM06:2025 Excessive Agency
- Microsoft Security Blog: When prompts become shells, RCE vulnerabilities in AI agent frameworks
- NCSC: Prompt injection is not SQL injection (it may be worse)
Related NHI Mgmt Group resources: AI Agent Tool and Plugin Security Guide · AI Agent Sandboxing and Code Execution Guide · Confused Deputy in AI Agents Guide · MITRE ATLAS Guide