Protecting AI Agents From Prompt Injection Through Tool Outputs

Tool outputs are one of the easiest ways to smuggle malicious instructions into an otherwise well-behaved agent.

The dangerous part is not the first tool call. It is the second one, when the model reads a web page, README, issue comment, or MCP tool description that says something like “ignore earlier instructions and run this command first.” If your agent treats tool output as trusted context, the attack has already crossed the boundary.

This is the pattern I would use instead: treat tool results as tainted data, reduce them before they reach planning, and keep write-capable actions behind a narrower trust lane.

Why this matters

Prompt injection is not just a chat problem. Modern developer agents can read repositories, call CLIs, open pull requests, and hit internal APIs. That means a poisoned tool response can quietly turn into file changes, secret access, or bogus external calls.

Recent security writeups and empirical work on MCP clients keep landing on the same theme: agent convenience grows faster than execution safety. The fix is not one regex. It is a workflow boundary.

Architecture or workflow overview

The key design choice is simple: tool output should not enter the same lane as system policy, task instructions, or approval state.

flowchart LR
    A[User task] --> B[Planner]
    B --> C[Tool call]
    C --> D[Raw tool output
marked tainted]
    D --> E[Sanitizer and reducer]
    E --> F[Evidence summary
read-only lane]
    F --> G[Planner refresh]
    G --> H{write or external action?}
    H -- no --> I[read-only follow-up]
    H -- yes --> J[policy checks and approval gate]
    J --> K[executor]

Implementation details

Tag tool output with a trust level

Do this before the model sees the result again. The planner should know whether a string came from a human instruction, a local invariant file, or an untrusted external artifact.

export type TrustLevel = 'trusted' | 'internal' | 'external-untrusted';

export interface ToolEnvelope {
  tool: string;
  trust: TrustLevel;
  source: string;
  content: string;
  truncated: boolean;
}

export function wrapToolResult(tool: string, source: string, content: string): ToolEnvelope {
  return {
    tool,
    source,
    content,
    truncated: content.length > 12000,
    trust: source.startsWith('https://') ? 'external-untrusted' : 'internal'
  };
}

This is intentionally dumb and early. Fancy classification later is fine, but the first pass should fail closed.

Sanitize before re-planning

The planner rarely needs the raw body of a fetched page. It needs the relevant facts. A reducer can strip instruction-like phrases, cap length, and surface only evidence fields.

INJECTION_PATTERNS = [
    r"ignore (all|previous|earlier) instructions",
    r"run (this|the following) command",
    r"send .* token",
    r"open .* secret",
]


def reduce_tool_output(envelope):
    text = envelope["content"]
    for pattern in INJECTION_PATTERNS:
        text = re.sub(pattern, "[filtered-instruction-like-text]", text, flags=re.I)

    return {
        "tool": envelope["tool"],
        "trust": envelope["trust"],
        "facts": extract_relevant_facts(text)[:12],
        "citations": extract_urls(text)[:8],
        "requires_human_review": envelope["trust"] == "external-untrusted",
    }

I would not pretend this eliminates prompt injection. The point is reduction, not magic. You are shrinking the attack surface before the next reasoning step.

Separate read lanes from write lanes

A lot of agents still let the same model instance read a hostile page, plan edits, and execute shell commands in one smooth loop. That is where small prompt injections become operational incidents.

Require a policy check before dangerous tools

A lightweight policy function catches the common failure mode where the agent tries to pass tainted text into a shell or write tool.

export function mayExecute(step: PlannedStep): { ok: boolean; reason?: string } {
  if (step.inputs.some(input => input.trust === 'external-untrusted')) {
    return { ok: false, reason: 'tainted input cannot reach execution tools directly' };
  }

  if (step.tool === 'shell' && !step.approvalToken) {
    return { ok: false, reason: 'shell execution requires explicit approval token' };
  }

  return { ok: true };
}

$ agent-run fetch https://example.com/issue-thread
wrapped result as external-untrusted
reduced facts: 6
planner requested shell tool: denied
reason: tainted input cannot reach execution tools directly
next action: ask for approval with reduced evidence only

What went wrong and the tradeoffs

Over-summarization can hide real evidence

If your reducer is too aggressive, you lose the clues that explain why the agent wants a follow-up action. That is why summaries need citations and raw access for human review, even if the model only sees the reduced form.

Sanitizers are not enough

Attackers do not have to literally write “ignore previous instructions.” They can frame malicious content as policy, troubleshooting guidance, or required setup steps. Pattern matching helps, but trust separation is the real control.

Tool metadata is part of the attack surface

It is not just fetched pages. MCP tool descriptions, package READMEs, repo comments, issue bodies, and log lines can all carry instruction-shaped text. Anything the model reads can become an attempted policy override.

What I would not do: I would not let a single agent instance fetch arbitrary web content and then immediately call exec, gh pr create, or a write-capable MCP tool from that same raw context.

Practical checklist

• mark all external or user-controlled tool results as untrusted by default
• reduce tool output into facts plus citations before re-planning
• keep raw artifacts available for humans, not as first-class execution context
• block tainted inputs from shell, file-write, deploy, and message-sending tools
• require explicit approval for any step that crosses from evidence to side effects
• log which trust labels were present when a plan was generated
• review MCP tool descriptions and prompts like code, not documentation

Conclusion

Tool-output prompt injection is not a weird edge case anymore. It is a normal failure mode in agent systems that mix retrieval, tools, and automation. The fix is mostly architectural: clearer trust labels, smaller summaries, and harder boundaries between reading and acting.