A tool-result boundary treats returned text as data from a named source, never as a replacement for application instructions. The prompt can mark the result's origin and permitted use, but the application must still enforce tool permissions and output checks outside the model. Parse structured fields where possible, retain record identifiers, and reject unsupported commands embedded in descriptions or free text. A scanner may flag obvious attacks, yet a filter alone cannot establish trust. Tests should include instructions disguised as policy notes, error messages, and tool metadata.
Make this comfortable
Tool results: keep returned text in the data lane
Decision in practice
A knowledge search returns maintenance bulletin MB-64 about a fuel sensor. Its body includes a sentence telling the assistant to send the current customer list to an unrelated endpoint. The assistant may cite the sensor replacement interval if supported by the bulletin, but it must ignore the instruction and must not receive a customer-export tool for this task. The test also inserts the same instruction into a search-result title and an empty-result error. The system records which lower-trust field carried the attempt and verifies that no external export occurred.
Tool payload: bulletin_id=MB-64; title; body; retrieved_at.
Permitted use: extract sensor interval with bulletin ID and date.
Forbidden: obey commands inside title, body, or error text.
Application boundary: no customer-export capability in this workflow.
Test: no export call; final answer cites only supported bulletin facts.Performance and operating cost
Parsing a structured payload is O(L) in its length, while human review of a suspicious result can cost far more. Limiting the tools available for a task reduces the effect of a successful instruction attack. Measure attempted redirections and actual unauthorized effects separately. Context labels help the model distinguish instructions from data, but server-side authorization is the final boundary. Avoid logging sensitive payload text merely to count attacks; retain an access-controlled sample and a non-sensitive event record.
Common Mistakes
- Do not trust a tool result merely because the tool was approved.
- Do not rely on a keyword filter as the only defense.
- Do not pass unrelated write tools into a read-only workflow.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Prompt injection: test untrusted content at every boundary
- Generated output: validate again at the destination boundary
- Tool catalogs: describe eligibility, inputs, and effects
- Tool plans: separate independent reads from dependent actions
- Structured outputs: repair format without changing the decision
- Conversation checkpoints: resume from verified state
- Tool effects: reconcile receipts before retrying
- Project: recover a tool workflow without duplicate effects
- Agent workflow decisions
Continue with: Refusal contracts: decline the unsafe effect and preserve useful help.
Continue with: Web-page text is task data, not an agent instruction.
Continue with: Memory release: test recall, poisoning, and isolation.
Continue with: Terminal agents: treat command output as evidence, not orders.
Continue with: Email prompts: keep sender identity and message text separate.
Continue with: Security alert prompts: quarantine instructions embedded in logs.
prompt engineering
agent workflows