How should security teams handle tool output when an AI agent can read free text from external users?

Treat tool output as untrusted whenever an outsider can write to any free-text field the agent reads. The tool name is not the trust boundary. Ticket bodies, CRM notes, pull request descriptions, and form-backed rows are all injection channels if they return outsider-authored text into the agent context. Label fields by writer, then prioritize agents that combine untrusted fields with state-changing tools.

Why Free-Text Tool Output Becomes an Agent Trust Problem

When an AI agent reads external free text through a tool, the key issue is not whether the text came from a “safe” system, but whether an outsider could shape what the agent sees. Ticket bodies, CRM notes, pull request descriptions, and form-backed records can all carry attacker-controlled instructions, prompts, or misleading context. OWASP’s agentic guidance is relevant here because it treats tool-derived content as part of the agent’s attack surface, not as inherently trusted application data.

Security teams often misclassify this as a user-interface or sanitisation issue, when the real problem is trust transference into the model context. If the agent can also take action, the free-text channel becomes more than an input concern: it can influence decisions, approvals, lookups, or state changes. The practical question is who wrote the field, whether the agent can distinguish writer trust, and whether the downstream tool can alter systems of record. In practice, many teams discover the problem only after an externally written note has already altered an agent’s interpretation of a later action.

For related guidance on agentic application risk patterns, see OWASP Agentic AI Top 10.

How to Treat Free Text as Untrusted Without Breaking the Workflow

The safest operational model is to separate field provenance from field content. A tool response can be perfectly legitimate and still be unsafe for the agent if it contains outsider-authored text. That means teams should label fields by writer identity or source class, not by application name alone. A CRM record written by a customer, a support ticket updated by a supplier, and a pull request description entered by an external contributor all deserve different handling, even if they arrive through the same API.

In practice, the control point is the agent’s context construction. Teams should decide which fields may be read, which may influence reasoning, and which are suitable only for retrieval or display. If the agent must read user-authored text, it should do so with constrained expectations: the content may describe facts, but it should not be allowed to define policy, request actions, or reframe authority. This is especially important where a tool can both surface text and trigger a state-changing follow-up, because the combination creates a classic confused-deputy condition.

Classify each field by writer: internal system, authenticated employee, external user, or mixed provenance.
Separate read-only context from action-bearing context so untrusted text cannot directly drive tool calls.
Mark state-changing tools as higher risk when they consume content from free-text fields.
Keep provenance visible to the agent orchestration layer so trust does not depend on naming conventions.

For broader AI risk management context, the NIST AI Risk Management Framework is useful when teams need to connect this behaviour to governance, measurement, and oversight. Where teams cannot reliably distinguish writer trust from application trust, the guidance breaks down and the agent should not be allowed to act on those fields automatically.

Where This Pattern Breaks Down in Real Systems

Tighter control over tool output often increases operational friction, because many business workflows were built assuming that “internal system” means “trusted.” That assumption fails when external users can write into fields that later return inside agent context. The hardest edge case is mixed provenance: records that start as external text, get edited by staff, then become partially trusted. In those cases, the safe answer is not to relabel the whole field as trusted, but to preserve writer lineage and treat the least-trusted contribution as still relevant.

Another common exception is summarised output. A summary is not automatically safer than the original text, because it can still carry the attacker’s framing if the summarisation step does not enforce source boundaries. There is also a governance difference between reading free text for search and reading it as justification for action. Those two uses should not share the same trust policy, even if they use the same tool.

When the workflow depends on external free text, the most important question is not “can the agent read it?” but “can the agent act on it as if it were authoritative?” If the answer is yes, the organisation has already crossed a trust boundary it may not have meant to cross.

Risk and Threat Considerations

The material risk is prompt injection through trusted-looking tool output. An outsider does not need direct access to the agent prompt if they can influence a field the agent later reads as context. That makes free-text channels a practical injection path whenever the agent can interpret instructions, extract intent, or use the content to justify actions.

Failure mechanism: the attacker places malicious or misleading text into an externally writable field, the tool returns that text to the agent, and the agent treats it as context rather than as adversarial input. The risk becomes more serious when the agent can chain that interpretation into a state-changing action, because the injected text can influence what the agent fetches, approves, edits, or forwards.

Impact: the organisation can see incorrect agent decisions, unauthorised actions, polluted records, or leakage of sensitive context into subsequent tool calls. At scale, the exposure is systemic because any field with outsider write access can become a reusable injection surface.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and MITRE ATLAS address the attack surface, NIST AI RMF and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A1 — Prompt Injection	External free-text tool output can inject instructions into agent context.
	A2 — Tool Misuse	State-changing tools become riskier when driven by untrusted text in context.
Recommendation — Treat outsider-authored tool text as untrusted input and block it from steering agent actions. Restrict state-changing tools from consuming untrusted context without explicit human review.
NIST AI RMF	GOVERN — Govern	The issue needs governance over provenance, trust boundaries, and oversight.
	MAP — Map	Teams must identify where external text enters the AI system and how it is used.
Recommendation — Define provenance rules that separate untrusted text from decision-authoritative context. Map each free-text source to its writer class and downstream decision use.
MITRE ATLAS	AML.TA0002 — Prompt Injection	The pattern matches adversarial manipulation of model context via text.
Recommendation — Hunt for text fields that can alter agent instructions or redirect tool use.
ISO/IEC 42001:2023	7.5 — Documented Information	Provenance labeling and retention of source context are governance concerns.
Recommendation — Document which text sources are trusted, mixed, or external before agents can act on them.
CIS Controls v8	6 — Access Control Management	Least privilege should limit which tools an agent can reach from untrusted input.
Recommendation — Constrain agent tool access so untrusted text cannot reach privileged actions.

Practitioner Guidance

What to prioritise: start by inventorying which tool-returned fields can be written by outsiders, then rank them by whether the agent can use them to make or trigger decisions. The highest-risk combination is untrusted free text plus a tool that can change state.

What to verify: confirm that provenance survives every transformation step, including summaries, enrichments, and ticketing workflows. If a field can be edited by multiple parties, verify that the agent can still tell which parts came from outside the trust boundary.

Decision rule: if a free-text field can be written by an external user, treat its return value as untrusted regardless of the system that stores it. If the agent must consume it, constrain it to retrieval, not authority.

Practitioner takeaway: the real control is not “sanitize the tool,” but “prevent outsider-authored text from becoming agent authority.” Once that distinction is lost, trust has already been handed to the attacker.