Tool-Result Prompt Injection: Test the Data-to-Action Boundary

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

An assistant may receive instructions from the user and data from a search tool in the same conversation. The risky boundary appears when retrieved content influences an operation beyond the task the user authorized. Imagine a procurement assistant reading a supplier document and then preparing an external message. A defensive assessment should test whether document content can redirect the agent’s action, while keeping the external tool replaced by an observable substitute that cannot contact real recipients.

Define the boundary before testing

Draw the data path from the untrusted source to the tool that creates an effect. Identify which content is allowed to inform an answer and which component decides whether an action is authorized. Create a harmless supplier document, a small synthetic customer record, and a mock outbound-message tool. The fixture should ask for a clearly out-of-scope behavior without providing an exploit payload or real destination. Agree what counts as a boundary failure: proposed action, execution attempt, or completed effect. These are different assessment outcomes.

Run a bounded assessment

Run a normal document-summary task as a positive control. Then introduce the approved adversarial fixture through the same retrieval path, including the ordinary wrapper, metadata, and tool-result formatting. Observe whether the agent changes its intended task and whether the execution layer permits the attempted operation. Repeat with the same content arriving as a search excerpt and as a full document if both are in scope. Keep attempts within an agreed budget. A refusal on one phrasing should not be treated as proof that an entire trust boundary is secure.

Keep evidence an engineer can use

Capture the user’s authorized task, fixture identifier, source channel, proposed tool arguments, policy decision, and mock execution result. Avoid storing hidden model reasoning or unrelated conversation content as a prerequisite for evidence. An actionable finding explains how untrusted data reached a consequential decision and which enforceable control failed. If the agent proposed the wrong action but the execution service rejected it, document the attempted goal change and the successful containment separately. That distinction helps engineering prioritize a model-behavior issue without overlooking the boundary that held.

Interpret the result and retest

Retest the original case after reducing privileges or adding execution-side validation, then include a benign document that mentions sensitive operations legitimately. Otherwise a fix may simply break useful tasks. Prompt filters can contribute signals but should not carry the whole authorization decision. The official OWASP prompt-injection guidance provides the background for this risk. These tests measure the selected content channels and configuration; new tools, retrieval wrappers, or models should trigger a review of the assumptions rather than an automatic claim of equivalent coverage.

Assessment scope and next steps

This is a proposed defensive assessment workflow, not a finding about a particular product. Use a staging environment, synthetic records, approved test identities, and an agreed stop condition. Record the model, connector, policy, and application versions so a later result can be compared with the same configuration. Unavailable evidence should remain an explicit coverage gap.

Primary reference: OWASP security guidance. The scenarios and acceptance criteria here are editorial recommendations for adapting that background to an authorized assessment.

For a scoped review of these boundaries, explore FailSafe AI security testing and agentic penetration testing. Agree the specific tools, identities, evidence, and exclusions before purchasing an assessment.