Bedrock guardrails don't inspect tool results or arguments, leaving agents open to injection

rahulladumor · reddit · 2026-11-03

A close reading of AWS Bedrock Guardrails docs reveals a critical blind spot: in Converse API tool use, guardrails only evaluate the user prompt and the model's text response. Three fields get no guardrail filtering at all — including prompt attack detection: tool results returned by your code (toolResult), tool definitions (toolSpec description/inputSchema), and the model-generated tool call arguments (toolUse.input). The docs state plainly: "The prompt attack filter does not evaluate tool results."

Mapped against MITRE ATLAS, indirect prompt injection (AML.T0051.001) arrives through exactly the channel the guardrail skips — tool results carrying content from tickets, mail, or web pages — while the exfiltration path (AML.T0086, writing via tool parameters, e.g. sending email) sits in toolUse.input. Both entry and exit are invisible to the guardrail.

Recommended mitigations:

Treat every tool result as untrusted text
Move controls outside the model: deterministic rules on tool arguments before execution (recipient allow-lists, record-ownership checks, amount caps), citing OWASP's excessive agency guidance and AgentCore Policy docs — guardrails are non-deterministic, policies are not
Minimize tools that can write; require human confirmation for critical writes
Optionally pipe tool results through ApplyGuardrail manually, though its catch rate in that position is unverified

Limitations: rules need structured arguments; free-text fields like email bodies can't be allow-listed, so fall back to fewer write tools plus human approval, at the cost of autonomy. The goal is shrinking blast radius, not a solved problem.

Original post →

Bedrock guardrails don't inspect tool results or arguments, leaving agents open to injection

More from coding & agent