Tool Output

Text returned by a tool into an AI agent’s context after a call. It is trusted or untrusted based on who can write the underlying field, not on the reputation of the system that delivered it. Free-text fields such as ticket bodies, PR descriptions, and CRM notes are common injection channels.

Expanded Definition

Tool output is the content an AI agent receives after calling a tool, and its security meaning depends on who can influence the source field behind it. A response can be trustworthy, partially trustworthy, or hostile input disguised as ordinary data. The key boundary is that delivery mechanism does not confer trust.

In agentic systems, tool output often includes retrieval results, ticket text, CRM notes, issue comments, or database records. Those sources may be operationally useful but still unsafe to treat as instructions. That distinction matters because the agent may merge tool output into planning, prompt context, or downstream actions without a human validating what the text is meant to do.

This term is closely related to prompt injection, but it is broader: the issue is not only malicious wording, but any untrusted field that enters the agent’s reasoning context. A common misunderstanding is to trust “internal” or “system-delivered” text by default. From a governance perspective, the writeability of the underlying field is what determines trust, not the reputation of the application that returned it.

Examples and Use Cases

Tool output appears in many ordinary workflows, especially where an agent reads business systems and then acts on what it finds. The same pattern can be safe or dangerous depending on how the agent treats the returned text.

• A support agent reads ticket body text and drafts a reply. The ticket is useful context, but the free-text body is still attacker-controlled if external users can write to it.
• An engineering agent retrieves PR descriptions and issue comments. Those fields may contain instructions for the model even though they were meant for collaboration, not execution.
• A sales or CRM agent ingests account notes. If many users can edit notes, the agent may absorb untrusted text as if it were authoritative account context.
• A knowledge-retrieval agent pulls documents from a shared workspace. A poisoned document can influence summarisation, classification, or next-step recommendations.

The practical trade-off is that richer context usually improves automation, but every additional writable source expands the injection surface. The safest interpretation is to treat tool output as data unless a specific control proves it is also instruction-safe.

Security Implications

Misclassifying tool output as trusted can let attacker-written text steer an agent’s behaviour, even when the upstream application is legitimate. The failure is often subtle: the agent does not need to be “hacked” in the classic sense if it is merely persuaded to follow untrusted instructions embedded in a field it was allowed to read.

Consequences include incorrect decisions, unsafe follow-on actions, disclosure of sensitive context, and policy bypass through indirect prompt injection. In workflow-heavy environments, the blast radius can extend beyond one answer because the agent may create tickets, change records, send messages, or trigger other tools based on the poisoned output.

A common practitioner observation is that the first sign is not an obvious breach but unexpected agent confidence around content that should have been treated as narrative, not command. Once tool output is allowed to compete with system intent, it becomes difficult to separate genuine task context from adversarial or low-integrity text.

Domain and Governance Relevance

Tool output matters most in agentic AI and identity-adjacent workflows because the agent’s execution authority can turn low-trust text into high-impact action. In NHI terms, the risk is not only what the agent reads, but what it can do after reading it. If an autonomous actor can act on behalf of a service identity, then poisoned tool output may influence a real identity-bearing workflow rather than a harmless draft.

That changes governance in two ways. First, organisations must define which source fields are instruction-bearing, which are data-only, and which require sanitisation or isolation before reaching the agent context. Second, owners of business systems must recognise that “internal” does not mean “safe for agent consumption” when writable fields are exposed to external users or broad internal populations.

OWASP Non-Human Identity Top 10 is useful here because the same trust boundary problem appears whenever machine identities and autonomous systems consume untrusted operational data.

Risk and Threat Considerations

Tool output creates a material indirect prompt injection risk when attacker-writable fields are fed into an AI agent’s context. The core exposure is trust abuse: the agent may treat untrusted text as task guidance, especially when the content arrives from a system the operator assumes is authoritative.

Failure mechanism: A malicious or compromised writer places instructions, framing, or hidden control text into a tool-accessible field such as a ticket, note, document, or issue comment. The agent ingests that text, fails to distinguish data from instruction, and follows the injected direction during planning or tool use.

Impact: The agent may leak context, produce incorrect outputs, override intended workflow constraints, or trigger downstream actions with real operational consequences. In identity-linked environments, this can extend to misuse of service credentials, unauthorized changes, or persistence of poisoned context across repeated runs.

Practitioner Guidance

What to watch for: Treat any field that external users or broad internal users can write as untrusted, even when it comes back from a tool you own. The critical judgement is whether the field can influence the agent’s instructions, not whether the application is “trusted” in a general sense.

Governance implication: Assign explicit ownership for source-field trust rules, because the team running the agent is often not the team that owns the underlying system. If that ownership is unclear, the environment tends to accumulate quietly dangerous read paths.

Practitioner takeaway: The useful boundary is writeability, not provenance branding. If a field can be edited by someone other than the agent operator, assume it can be used to steer the agent until proven otherwise.

Related resources from NHI Mgmt Group

• How do you know if an agent design tool is actually improving output quality?
• What breaks when output redaction and tool blocking are missing from agent security controls?
• What is the difference between SARIF output and native tool findings in a vulnerability management pipeline?
• Should organisations prioritise tool gating or output filtering for agentic AI?