Why does tool-output injection create risk even when input screening and action screening both pass?

Why the Gap Between Input Screening and Action Screening Still Matters

Tool-output injection is risky because it exploits the handoff between what the agent reads and what it is later allowed to do. A returned tool response can look harmless to content filters while still carrying instructions that shape the agent’s next step. For readers tracking control design, this is the same class of boundary problem that NIST Cybersecurity Framework 2.0 treats as a governance and control integration issue rather than a single-point filter problem. In practice, many security teams discover this only after they have tested each screen in isolation and assumed the whole agent loop was therefore safe.

How the Injection Works Across the Agent Loop

The core failure is temporal separation. Input screening evaluates the tool output as if it were ordinary text, so it looks for prohibited content, obvious prompts, or malformed instructions. Action screening evaluates the next tool invocation, so it checks whether the requested operation is permitted. Tool-output injection succeeds when the malicious payload is neither clearly disallowed content nor an obviously unauthorized action at the moment each control sees it.

That means the risky part is often not the text itself, but the interpretation that follows. If the agent treats retrieved content, logs, documents, or API responses as trustworthy context, the injected instruction can alter planning, prioritisation, or tool selection without tripping either screen. This is especially important when the agent has memory, multi-step planning, or delegated access to systems that accept broadly scoped requests.

Practically, the issue is not solved by making one screen stricter. If input checks become too aggressive, they can block legitimate tool results and reduce usefulness. If action checks are too narrow, they only validate the final call and miss the reasoning path that led there. A sound design therefore ties together provenance, context handling, and step-level policy enforcement so the agent does not treat untrusted output as privileged guidance.

• Screening the text and screening the next action answer different questions.
• Poisoned output can pass as data before it becomes a prompt influence problem.
• Policies need to evaluate provenance and context, not only the final tool call.

The guidance breaks down when the agent is allowed to chain untrusted outputs directly into decisions without an intermediate trust boundary.

When the Pattern Becomes an Edge Case Instead of a False Alarm

Tighter screening often increases friction, so organisations must balance resilience against false positives and workflow interruption. Not every suspicious tool result is an injection attempt, and not every agent workflow needs the same level of restriction. The practical distinction is whether the returned content can influence subsequent tool use, credentialed actions, or privileged data access. If it can, the concern is material; if it is merely displayed and never acted on, the risk is lower.

There is also a consensus gap in current agent security practice. Some teams treat prompt filtering as enough, while others require explicit provenance tags, allowlists for tool-derived context, and separation between retrieved content and executable instructions. The second approach is stronger when the agent can act autonomously or operate across multiple tools, because the attack surface sits in the handoff, not in either control alone.

Another edge case is delegated automation. When an agent is authorized to open tickets, query systems, or update records, a poisoned tool response can cause action selection that still appears policy-compliant at the final gate. That makes the failure harder to detect in review, because each control can truthfully report that it passed its own check.

Practitioner takeaway: treat tool-output injection as a composition problem, not a filter problem, because the real risk is the untrusted transition from reading to acting.

Risk and Threat Considerations

This pattern creates an integrity and privilege-abuse risk in autonomous workflows. The exposure is not limited to malicious text; it is the ability of untrusted output to shape later decisions, tool calls, or data access while still appearing compliant to isolated checks.

Failure mechanism: the attack succeeds through trust boundary confusion. A tool response is accepted as benign content, then reused as instruction-bearing context, so the agent’s planning state is influenced before the next authorization check. This is a recognised prompt-injection style mechanism in agentic systems.

Impact: the agent can be induced to retrieve sensitive data, perform unintended actions, or propagate misleading context into later steps. At scale, this can create repeated mis-execution across multiple sessions, especially where the same tool outputs are reused in memory or workflow chains.

Practitioner Guidance

What to prioritise: protect the transition between tool output and subsequent reasoning. The key control question is not whether each screen works alone, but whether the system preserves provenance and trust state across steps.

What to verify: confirm that tool results are separated from executable instructions, that untrusted content cannot silently become agent memory, and that final action checks can see the original source of the influence. If the architecture cannot show that chain, treat the control set as incomplete.

Common mistake: teams often tune the two screens independently and assume combined coverage. That leaves a blind spot where the output is permitted as data and then reused as direction. The safer design is to evaluate whether the agent is allowed to reason from that output at all, not just whether it may display it.

Practitioner takeaway: the strongest defence is a trust-boundary design that remembers where content came from and limits what that content is allowed to influence next.

Related resources from NHI Mgmt Group

• Why does Angular template injection create XSS risk even when input is HTML-encoded?
• Why do MCP tool pickers create governance risk even when users stay in control?
• Why does prompt injection create risk even when credentials are valid?
• Why do RAG systems create data exposure risk even without prompt injection?