Notifications
Clear all
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.
NHIMG editorial — based on content published by ARMO: AWS Bedrock Prompt Injection: The Two Vectors Your Guardrails Never See
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
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 AI agents complicate existing IAM and PAM controls?
A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed.
Q: How do security teams know whether agent memory is becoming a risk?
A: They look for writes that carry instruction-like content, unexpected persistence across sessions, and summaries that reintroduce hostile text as trusted context.
Practitioner guidance
- Inspect tool calls at the action boundary Add inspection where the agent invokes tools, not only where users submit prompts.
- Treat agent memory as a governed security asset Log memory writes separately from ordinary retrieval and review them for unexpected instruction-shaped content.
- Baseline each agent’s runtime behaviour Track tool sequence, network destinations, API calls, and container-level execution so you can detect coercion by deviation.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step Bedrock guardrail coverage analysis for user input, tool input, tool output, and final answer.
- Operational comparison of user confirmation, ApplyGuardrail, and plan-verify-execute patterns across different agent tasks.
- Memory-poisoning proof-of-concept detail showing how malicious content persists into later Bedrock sessions.
- Runtime behaviour examples that distinguish healthy agent execution from coerced execution in production workflows.
👉 Read ARMO's analysis of AWS Bedrock prompt injection and guardrail gaps →
AWS Bedrock prompt injection: are your agent controls missing the loop?
Explore further
19/08/2026 4:11 pm
Runtime behaviour, not prompt text, is the real control plane for AI agents. A Bedrock agent can pass every conversational screen and still be coerced into harmful action if the underlying tool loop remains unsupervised. That makes agent governance a runtime identity problem as much as a model-safety problem, because the agent is acting with valid credentials. Practitioners should treat the execution trace as the primary security signal.
A question worth separating out:
Q: Who is accountable when an AI agent accesses the wrong data?
A: Accountability sits with the team that defined the agent’s scope, the owner of the delegated user context, and the operators who allowed access to persist beyond the task. For customer workflows, audit logs should show both the agent and the user identity so responsibility can be traced clearly.
👉 Read our full editorial: AWS Bedrock prompt injection exposes guardrail gaps in agent loops
