AWS Bedrock prompt injection exposes guardrail gaps in agent loops

At a glance

What this is: This analysis shows that AWS Bedrock guardrails do not inspect tool calls, which leaves the agent’s middle loop unscreened even when the input and output layers are covered.

Why it matters: It matters because IAM, PAM, and NHI governance teams need controls that govern agent behaviour at runtime, not just the text that enters and exits the model.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read ARMO's analysis of AWS Bedrock prompt injection and guardrail gaps

Context

AWS Bedrock prompt injection is not only a model-safety problem. It is a governance problem for AI agents because the agent’s tool loop can turn an unscreened instruction into a real system action while the guardrail still only sees the start and the end of the exchange. In identity terms, the issue is that valid permissions do not make execution trustworthy when the agent itself becomes the path of abuse.

The key distinction is between text control and action control. A guardrail can classify language, but it does not by itself govern what an agent is authorised to invoke, what it is allowed to persist, or how its runtime behaviour should be monitored. That is why AI agent security increasingly overlaps with NHI governance, workload identity, and privileged execution controls.

ARMO’s analysis is typical of the current market discussion around agent safety, but the underlying control gap is broader than one platform. Any environment that lets an agent call tools, read external content, and retain memory needs to treat the runtime path as the primary attack surface.

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. A hostile instruction can enter through retrieved content or tool output, then become a valid tool argument or memory write while the model still appears compliant. That is why runtime inspection belongs at the action boundary, not only at the chat boundary.

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. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

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. A healthy memory layer should have a stable baseline for what gets stored and when. If memory entries are not logged and reviewed, the organisation cannot tell whether it is preserving context or preserving coercion.

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.

Technical breakdown

Why Bedrock guardrails miss tool input and tool output

AWS describes Bedrock agent guardrails as applying to user input and the final answer, not to tool input or tool output. That means the model’s central action path, where prompts become arguments and responses become context, runs outside native screening unless the customer adds extra checks. In practical terms, this is a boundary problem: the control exists at the conversational edges, while the risky transformation happens in the middle. If the tool can read attacker-reachable content, the agent can import hostile instruction disguised as data.

Practical implication: inspect tool inputs and outputs at the action-group boundary, not just the chat boundary.

How indirect prompt injection becomes an agent action

Indirect prompt injection works when attacker-controlled text is retrieved, summarised, or reused as if it were trustworthy context. On Bedrock, that is dangerous because the agent already has credentials and tool access through IAM, so coercion does not need to break authentication. It only needs to redirect authorised behaviour. The agent still appears legitimate to control-plane logs because the calls are valid, which is why simple allow-listing of tools is insufficient on its own.

Practical implication: pair authorisation with runtime behavioural inspection so valid calls can still be challenged when the sequence is abnormal.

Why agent memory creates a longer-lived attack path

When an agent stores session summaries or other memory artifacts, untrusted content can survive beyond the original interaction. That shifts prompt injection from a single-session event into a persistence problem, because a planted instruction can return later as apparently trusted context. The technical risk is not only recall, but provenance collapse. Once memory and system instructions share the same context space, the model cannot reliably distinguish what it observed from what it absorbed under attacker influence.

Practical implication: instrument memory writes as security events and baseline them separately from ordinary retrieval traffic.

Threat narrative

Attacker objective: The attacker wants the agent to perform authorised actions on their behalf, including data exposure, memory poisoning, or destructive tool use, without tripping traditional guardrails.

1. Entry occurs when attacker-controlled text reaches the agent through user input, retrieved content, or tool output.
2. Escalation occurs when the agent converts that text into tool arguments, memory writes, or other authorised runtime actions.
3. Impact occurs when the agent executes unintended operations while every individual permission check still appears valid.

NHI Mgmt Group analysis

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.

Agent memory creates governance debt when provenance is lost. Once untrusted content can be summarised into memory and later replayed as trusted context, the organisation has created a persistence layer for instructions, not just data. That is a specific failure mode, and it is easier to miss than a simple exposed secret. The durable control question is whether memory entries are treated as tainted inputs with lifecycle controls, or as ordinary application state. Practitioners should classify memory as a governed asset, not a convenience feature.

Authorization without behavioural verification is no longer enough for autonomous tooling. IAM can still say yes even when the agent has been redirected. That is why the new concept here is coercion-resistant agent governance: a control model that assumes credentials are valid but treats runtime behaviour as suspicious until it matches an established baseline. The implication is clear for identity teams: policy must extend from who can call the agent to what the agent does after it is called. Practitioners should align AI agent controls with NHI and PAM-style runtime oversight.

Control coverage gaps now matter more than single-layer hardening. Screening, user confirmation, orchestration checks, and logging each solve a different part of the problem, but none of them alone closes the loop. That is why Bedrock-style attacks are revealing a market shift toward layered runtime governance rather than point defenses. The practical conclusion for security architects is to map each layer to a failure mode and accept that no single guardrail owns the whole chain.

Tool output is the most underestimated bridge from data to action. Retrieved content, ticket bodies, database rows, and MCP responses can all become instructions once the agent reuses them in context. This is where AI agent security intersects with NHI governance most directly: the system is importing external text into an authorised decision path. Practitioners should apply taint thinking to every source the agent can read, especially where humans or third parties can write first.

What this signals

Coercion-resistant agent governance: organisations need a control model that assumes the agent’s permissions are valid but its runtime intent may not be. That means detection has to move from prompt screening toward execution baselining, with memory writes, tool sequence, and network destinations treated as identity-relevant events.

The operational signal for teams is that AI agent security now depends on the same discipline used for NHI and privileged workload control: short-lived scope, runtime monitoring, and explicit ownership. Where agents can touch external content, the boundary between model output and system action is too thin to trust conversational filters alone.

For practitioners, the priority shift is clear. Bedrock-style coverage gaps show that the next phase of agent governance will be about controlling what an agent can do after it has already been authorised, not just what it is allowed to say.

For practitioners

• Inspect tool calls at the action boundary Add inspection where the agent invokes tools, not only where users submit prompts. Apply controls to the arguments going into Lambda functions and the payloads returning from them, especially when the tool reads attacker-reachable content such as tickets, webpages, or customer input.
• Treat agent memory as a governed security asset Log memory writes separately from ordinary retrieval and review them for unexpected instruction-shaped content. Build a baseline for what each agent normally persists, because memory poisoning becomes durable only after a write looks normal enough to survive summarisation.
• Baseline each agent’s runtime behaviour Track tool sequence, network destinations, API calls, and container-level execution so you can detect coercion by deviation. Use per-agent profiling rather than namespace-level telemetry, because the security question is what this specific agent normally does.
• Align AI agent controls with IAM and PAM oversight Map every agent permission to a runtime use case and review whether the same permission would be acceptable if a human held it interactively. Where the answer is no, add approval, sandboxing, or step-up checks for the agent before it reaches the tool.

Key takeaways

• AWS Bedrock guardrails do not cover the entire agent loop, so the control gap sits where instructions become actions.
• The useful signal is runtime behaviour, because valid permissions can still be used for coerced execution.
• Teams should govern agent memory, tool calls, and IAM permissions as one runtime security problem.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Tool Output Trust Boundary: The point at which information returned by an external tool re-enters the agent’s reasoning context. If that boundary is not validated, the agent can confuse attacker-controlled content with trustworthy system input, making data retrieval a path to manipulation rather than just information gathering.
• Agent Memory: Agent memory is the stored context an AI agent uses across sessions or tasks. In governance terms, it is controlled state, because the memories an agent retains can influence future actions, permissions use, and the safety of subsequent decisions.
• Coercion-Resistant Agent Governance: A control approach that assumes the agent’s permissions are legitimate but its runtime intent may be manipulated by untrusted content. It combines identity, behavioural telemetry, and execution policy so the organisation can detect when authorised actions are being redirected toward an attacker’s objective.

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.

👉 ARMO's full post covers the Bedrock attack chain, memory poisoning path, and control trade-offs in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is built for practitioners who need to connect identity controls to runtime risk across modern AI and cloud programmes.