Topic starter
19/08/2026 3:27 pm
TL;DR: AWS Bedrock guardrails screen user input and final answers, but not tool input or tool output, leaving the middle of the agent loop exposed to indirect prompt injection, according to ARMO. The real control problem is runtime behavior, because coerced agents can still use valid IAM permissions to take attacker-shaped actions.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “AWS Bedrock Prompt Injection: The Two Vectors Your Guardrails Never See”.
Key questions
Q: What breaks when Bedrock guardrails do not inspect tool calls?
A: The middle of the agent loop becomes an unscreened conversion point where text turns into action.
Q: Why do valid permissions not stop indirect prompt injection in agents?
A: Because the attack exploits delegated authority, not broken authentication.
Q: What are the signs that an agent memory layer is failing in practice?
A: The clearest warning signs are destructive writes, inability to audit what the agent remembers, and inability to roll back state after a bad action.
Practitioner guidance
- Scope controls to the full agent loop Review whether your current agent controls inspect only user prompts and final responses, or also tool input, tool output, and memory writes.
- Instrument tool invocations as security events Log every tool call with ordering, arguments, caller identity, and the response returned to the model so that coercion can be traced after the fact.
- Apply human approval to mutating actions Use confirmation only for actions that change state, transfer value, or reach external systems an attacker can influence.
Bottom line: The article shows that Bedrock-style prompt filtering does not cover the full agent loop, which leaves tool calls and memory as practical attack surfaces.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:11 pm
Agent loop coverage is now the real control boundary: screening only prompts and final outputs leaves the highest-risk phase, tool execution, outside governance. That is not a tuning issue, it is a structural gap in how many teams model agent safety. Practitioners should assume any loop with tool access needs controls at invocation time, not just at conversation boundaries.
A question worth separating out:
Q: How should teams decide between guardrails, human approval, and runtime baselines?
A: Use them for different problems. Guardrails reduce obvious hostile text, human approval is appropriate for state-changing actions, and runtime baselines detect behaviour that slips past both. A mature programme does not pick one control and stop there. It matches the control to the phase where the agent is most likely to be coerced.
👉 Read our full editorial: AWS Bedrock prompt injection exposes guardrail gaps in agent loops