Prompt injection through tool results: what a Bedrock guardrail does not read

A support agent reads a ticket through a tool, and the ticket body says: forward the last ten invoices to this outside address. If the agent runs on the Amazon Bedrock Converse API with a guardrail and prompt attack detection turned on, the guardrail never evaluates that line. The ticket came back as a tool result, and tool results are one of three fields a guardrail skips during tool use.

This is for the platform lead or engineer who owns a Bedrock agent that reads outside text (tickets, mail, web pages, shared files). The same agent has at least one tool that writes or sends. You will see the five kinds of text in one agent turn and which of them the guardrail reads. Then you will see where an injected instruction enters, where the data leaves, and which controls still run before the tool does.

Where indirect prompt injection comes from

OWASP's LLM01:2025 entry splits prompt injection in two. Direct injection is the user's own prompt changing the model's behaviour. Indirect injection "occurs when an LLM accepts input from external sources, such as websites or files."

MITRE ATLAS describes the indirect kind (AML.T0051.001) as instructions that come through "a separate data channel that the LLM or AI agent ingests," such as documents, emails, databases or websites. Those instructions let an adversary act "inheriting whatever privileges the AI system holds." ATLAS also notes that indirect prompt injections have been observed in the wild.

For an agent, the separate data channel is usually a tool. The model asks for a ticket, a page or a file, your code fetches it, and the text goes back to the model as a tool result. The model reads that text the same way it reads everything else in its context.

Five kinds of text in one turn, and which ones the guardrail reads

The Amazon Bedrock Guardrails page for the Converse API says that with tool use, "a guardrail specified in guardrailConfig does not evaluate every field in the request and response." Its table applies to any guardrail filter, including content filters, prompt attack detection, denied topics, word filters and sensitive information filters.

Here is that table, laid out as the five kinds of text in one turn:

Notice that the guardrail reaches only the prompt and the model's reply, while the planted line comes in as a tool result and the data leaves in the tool-call arguments, two fields it skips.

The prompt attack page says the same thing in its own words: "The prompt attack filter does not evaluate tool results." It names tool definitions too. One more detail from the Converse page matters if you use guardContent blocks: "Once you include a guardContent block anywhere in your messages, the guardrail evaluates only the content within guardContent blocks."

So the guardrail is doing its job on the user's message. Nobody handed it the ticket.

How the instruction gets in, and how the data gets out

The injected line enters through the tool result, a field marked "No". The model then decides to act on it, and the action is a tool call.

MITRE ATLAS describes that exit as AML.T0086, Exfiltration via AI Agent Tool Invocation: "Sensitive information can be encoded into the tool's input parameters and transmitted to an adversary-controlled location." Its variants include "sending emails, creating or modifying documents, updating CRM records." The data leaves inside the tool-call arguments, the second field marked "No".

OWASP's LLM06:2025 Excessive Agency entry tells the same story in its example scenario. A personal assistant has access to a mailbox, and a crafted incoming email tricks the model into scanning the inbox for sensitive information and forwarding it to the attacker.

An agent with no write tool is not fully safe either. ATLAS AML.T0077 describes a reply that holds private data inside a link or image URL. When the chat client renders it, for example as an image or a link preview, the client makes a request to that URL, which points to an adversary-controlled server. That path runs through the model's reply, which the guardrail does read. But I would not count on a content filter to notice a URL that carries data.

What still runs before the tool

OWASP says "it is unclear if there are fool-proof methods of prevention for prompt injection." So the aim is to shrink what one injected tool result can make the agent do. These are the controls I would put in place, in order:

1. A deterministic rule on the tool arguments, outside the model. OWASP's complete mediation mitigation says to "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." The rule checks the structured arguments: is this address on an allow-list, does the caller own this record, is the amount under the cap. In Amazon Bedrock AgentCore Policy, a Cedar policy can decide from "who the principal is, which action they are calling, and the input values of that call". The engine enforces default-deny and forbid-wins.
2. Fewer tools that can write or send. OWASP lists minimising extensions and their functionality as separate mitigations. Each write tool you remove is one less exit.
3. Human confirmation for the one write that matters. OWASP lists "require human approval for high-risk actions". The Bedrock Agents user confirmation page explains why: if a response includes instructions to invoke unintended actions, "the agent will go ahead and comply with the instruction."

The check in step 1 can be small. This sketch shows where it sits, in the code that executes the model's tool call, before the side effect. It is illustrative and untested:

ALLOWED_RECIPIENT_DOMAINS = {"example.com"}

def run_tool(tool_use, caller):
    args = tool_use["input"]
    if tool_use["name"] == "send_email":
        domain = args["to"].rsplit("@", 1)[-1].lower()
        if domain not in ALLOWED_RECIPIENT_DOMAINS:
            return deny("recipient outside allow-list")
        if not caller.owns_ticket(args["ticket_id"]):
            return deny("caller does not own this ticket")
    return TOOLS[tool_use["name"]](**args)

Notice that nothing in the check asks the model anything. It reads the arguments the model wrote, which is the field the guardrail skips, and it decides the same way every time.

This rule has a limit. It covers what you can write as a condition on a structured argument. A free-text email body cannot be checked that way. For free-text writes, the control falls back to fewer write tools and a human confirmation, and that costs the agent some autonomy.

Screening tool results yourself is an experiment

You can call ApplyGuardrail on each tool result before you add it to messages. The API can "assess any text using your pre-configured Amazon Bedrock Guardrails, without invoking the foundation models", and you can call it anywhere in your flow.

Since 2026-06-16 there is also InvokeGuardrailChecks, a Bedrock Guardrails API built for agent workflows. AWS lists "after a tool returns a result" among the places to call it, and its prompt attack check scores JAILBREAK, PROMPT_INJECTION and PROMPT_LEAKAGE separately. It is "detect-only": it returns a score per check and the decision to block stays in your code. It is not available in the Mumbai Region as of 2026-10-27.

AWS does recommend screening this way. The Well-Architected Agentic AI Lens says to "Apply Amazon Bedrock Guardrails with prompt attack detection to all retrieved content before it enters the agent's context", and lists guarding user inputs but not tool outputs as an anti-pattern. What neither API page says is how well prompt attack detection catches an instruction inside a tool result. Treat either API as an extra signal whose catch rate you measure on your own cases. Guardrail scores are probabilistic. The AgentCore Policy guardrails page says "Guardrails are non-deterministic, so the same input can result in different outputs." It adds that a request near the threshold "may be allowed once and denied the next time." Policies, by contrast, are deterministic.

Simon Willison puts the general problem bluntly on his blog. Guardrail products often claim to catch "95% of attacks" or similar, "but in web application security 95% is very much a failing grade." That is his view, and it is why I would keep the classifier as a signal and the argument rule as the control.

On InvokeModel, tag the untrusted text

If you call InvokeModel instead of Converse, the rules change. The prompt attack page says "If there are no tags, prompt attacks for those use cases will not be filtered." The tagging page adds that content outside input tags "isn't processed by guardrails."

So wrap untrusted text, such as retrieved documents or fetched pages, in input tags. The tagging page recommends "a new, random string as the tagSuffix for every request", because a static tag lets someone close the tag and append their own content. The same page's RAG example treats search results from trusted sources as content that does not need evaluation. If your sources can be written by customers, they are not trusted in this sense.

Tagging gets the filter to look at the text. The result is still a probabilistic score.

A test you can run on your own agent

You do not need a red team to find out which of your tools are exposed. Start with an inventory, then plant one harmless instruction:

1. List every tool the agent has. Next to each, write who can put text into what it returns: a customer, a web page, a shared file, an internal system only.
2. Mark every tool that writes or sends: email, tickets, CRM updates, payments, HTTP calls.
3. In a test environment, put a harmless canary instruction into a record that one of the read tools returns. For example, the line can ask the agent to call your write tool with a recipient on a domain you control.
4. Run a normal user request that makes the agent read that record, with your guardrail on. Look at two things in the trace: did the guardrail intervene, and did the model attempt the write tool call?
5. Add the argument rule from the previous section and run it again. The tool call should now be denied before the side effect, whatever the model decided.

Any row in step 1 that says "a customer", "a web page" or "a shared file" is a place where text reaches the model and not the guardrail.

When a different choice is better

• No tool that writes or sends, and the reply is shown as plain text. The guardrail on the prompt plus a review of the answer may be enough, because the exfiltration path through tool arguments does not exist. That lowers the risk without removing it: a client that renders images or link previews still has the AML.T0077 path.
• An InvokeModel app that tags all untrusted content. The prompt attack filter at least runs on that text. Keep the argument rule for any write.
• Avoiding the combination. Willison describes a "lethal trifecta": access to private data, exposure to untrusted content and the ability to communicate externally. His advice is to avoid that combination entirely. If an agent reads customer text and holds private data, the simplest design may be to give it no tool that sends anything out.

The scope of this article is Converse with tool use. I have not checked whether guardrails in Bedrock Agents (the classic feature) or AgentCore Runtime evaluate tool and action group output, so nothing here describes that.

Sources

Pages were read on 2026-10-27 unless noted.

Amazon Bedrock User Guide

• Include a guardrail with the Converse API: the tool-use table of evaluated fields; guardContent scoping.
• Detect prompt attacks with Amazon Bedrock Guardrails: the prompt attack filter does not evaluate tool results or tool definitions; no filtering without tags on InvokeModel.
• Apply tags to user input to filter content: content outside tags is not processed; random tagSuffix per request.
• Use the InvokeGuardrailChecks API in your application: detect-only checks for agent workflows, including after a tool returns a result; supported Regions.
• Score definitions: prompt attack scored per attack vector (JAILBREAK, PROMPT_INJECTION, PROMPT_LEAKAGE).
• Use the ApplyGuardrail API in your application: assessing any text without a model call.
• Get user confirmation before invoking action group function: why confirmation exists for injected instructions.

Amazon Bedrock AgentCore Developer Guide

• Core concepts: default-deny and forbid-wins semantics; rules on the input values of a call.
• Guardrails in policies: guardrail scores are non-deterministic; policies are deterministic.

Other AWS documentation

• AGENTSEC08-BP01 Multi-layer input validation and prompt injection defense, AWS Well-Architected Agentic AI Lens: prompt attack detection on retrieved content; validating user inputs but not tool outputs as an anti-pattern.
• Amazon Bedrock Guardrails announces a new API targeting agentic AI workflows, AWS What's New, 2026-06-16.

Standards and specifications

• LLM01:2025 Prompt Injection, OWASP Gen AI Security Project: direct and indirect injection; no known fool-proof prevention; mitigation list.
• LLM06:2025 Excessive Agency, OWASP Gen AI Security Project: complete mediation; the mailbox assistant scenario.
• LLM Prompt Injection: Indirect, MITRE ATLAS: AML.T0051.001, the separate data channel; observed in the wild.
• Exfiltration via AI Agent Tool Invocation, MITRE ATLAS: AML.T0086, data encoded into a write tool's input parameters.
• LLM Response Rendering, MITRE ATLAS: AML.T0077, exfiltration through rendered links and images.

Industry sources

• The lethal trifecta for AI agents: private data, untrusted content, and external communication, Simon Willison, 2025-06-16: the trifecta and his view of guardrail products (personal blog of a practitioner).