Restricting agent tool calls after retrieving untrusted data

Once an agent has read untrusted text, such as a retrieved document, web page or email, it should not be able to call tools freely. ATLAS recommends blocking automatic tool calls or requiring user confirmation at that point, and always requiring confirmation for high consequence actions.

The risk in one sentence

ATLAS says untrusted data can contain prompt injections that invoke an agent's tools, which can cause confidentiality, integrity or availability violations. The tool invocation technique in ATLAS notes that adversaries can use an agent to call tools it has access to, including integrations, data sources and code execution, and that agents may hold tools users cannot reach directly.

So the question is not "will the model resist?" but "what happens if it does not?"

A decision guide

Rate each tool by what a wrong call would cost, then pick a control.

• Read only, low sensitivity (Search public docs): Allow, log
• Read sensitive data (Query a customer record): Allow only within the user's own permissions, log, consider confirmation
• Write, reversible (Create a draft): Confirm with the user
• Write, outward or irreversible (Send email, change access, delete data): Always require human approval
• Code or command execution (Run a script): Isolated sandbox, plus approval

This table is a starting point built from the ATLAS guidance, which says the degree of restriction may depend on the consequence of the action.

Implementing the switch

The control needs to know that untrusted data has entered context. Two practical ways:

Taint the context. Mark each chunk with its source trust level at retrieval. If any untrusted chunk is in the prompt, the session switches to a restricted tool set for that turn.

Gate in code. The check lives in the tool-calling layer, not in the prompt. ATLAS says input and output validation for agent components should be performed external to the agent, and its authority expansion mitigation says such controls should not rely on system prompts or on the agent recognising an action is out of scope.

Human approval that people actually use

ATLAS notes that human approval has operational cost, and that approval should follow the consequence of the task. Minor repetitive tasks need little oversight, while high consequence ones may need approval from several stakeholders.

To avoid approval fatigue:

• Show what the agent wants to do in plain words, with the exact arguments.
• Show which content triggered the request.
• Do not batch unrelated actions into one approval.
• Keep a record of who approved what.

What to test

1. Put an instruction in a retrieved document that tells the agent to send data to an outside address. Confirm the call is blocked or held.
2. Try the same through an email, a web page and a file attachment.
3. Test chained actions, where each step looks harmless but the sequence is not.

For test planning, use the RAG red team checklist.

Quick check

Sources

• MITRE ATLAS data repository (mitre-atlas/atlas-data), techniques AML.T0053 and mitigations AML.M0029, M0030, M0033, M0037 in the 2026.09 release.

Last reviewed: 19 October 2026.