Amazon Bedrock Guardrails and the runtime safety gap for AI agents

At a glance

What this is: This is an analysis of how Amazon Bedrock Guardrails applies runtime safety controls to GenAI applications and agents, with the key finding that model-level filtering is not enough without broader agent governance.

Why it matters: It matters because IAM, NHI, and security teams must govern agent behaviour, tool access, and data exposure together instead of treating prompt filtering as a complete control set.

👉 Read Akto's guide to Amazon Bedrock Guardrails for GenAI and AI agents

Context

Amazon Bedrock Guardrails is a runtime safety layer for GenAI applications and agents that filters inputs, moderates outputs, and applies policy checks around content, grounding, and sensitive data. The governance problem is that traditional IAM and application controls were built for static requests and known execution paths, not for prompts that can redirect behaviour mid-session.

For identity practitioners, the question is not whether guardrails exist, but whether they meaningfully constrain the non-human identities behind the application. Once an agent can call tools, query data, and continue a multi-step exchange, the boundary between content moderation and access control starts to blur. That is the real control gap this article exposes.

The article’s starting point is typical for organisations experimenting with GenAI in production: they need safer runtime controls, but they also need to understand the limits of those controls when agents, APIs, and external content are involved.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do prompt-injection defences fail in multi-step AI workflows?

A: They fail because many defences evaluate each turn in isolation, while the attack often unfolds across several steps. An injected instruction can sit in retrieved content, survive summarisation, and only become dangerous when the agent later calls a tool. Multi-step workflows need context-aware verification, not only input screening.

Q: What do teams get wrong about Bedrock-style guardrails?

A: The common mistake is assuming that content moderation equals safe access. Guardrails can reduce harmful text, redact sensitive data, and block obvious jailbreaks, but they do not automatically constrain tool reach, delegation depth, or privilege scope. Those remain separate governance problems that IAM and NHI teams must own.

Q: How can organisations tell whether AI runtime monitoring is working?

A: A working programme can explain which AI-driven actions were observed, which service identities enabled them, and whether those actions stayed inside approved operational scope. If the team only sees dashboards and not the behaviour chain from input to tool use to effect, the control is too shallow to rely on.

Technical breakdown

Pre- and post-generation guardrails in GenAI

Bedrock Guardrails sits around the model rather than inside it. Input filtering blocks or sanitises prompts before generation, while output moderation checks the response before it is returned. That architecture is useful for prompt injection, PII leakage, denied topics, and harmful output, but it is still fundamentally reactive. It can catch unsafe content at the boundary, not reason over the entire identity and execution chain that produced it. In practice, this means the control can reduce obvious abuse while leaving deeper workflow assumptions untouched.

Practical implication: treat guardrails as a boundary control, not as a substitute for tool-level authorisation or workload identity governance.

Prompt injection, jailbreaks, and indirect instruction leakage

Prompt injection works because the model cannot reliably distinguish trusted instructions from malicious text once both appear in the same context window. Indirect prompt injection is more dangerous because the hostile instruction arrives through an external source such as an email, document, or web page that an agent later summarises or processes. The article also notes a limitation in long conversations, where turn-by-turn checks can miss a slowly unfolding violation. This is a classic context-contamination problem, not just a content-filtering problem.

Practical implication: classify external content as untrusted input and apply the same scrutiny to retrieved text, tool output, and user prompts.

Runtime controls for agents, tools, and orchestration stacks

The article shows how Bedrock Guardrails can be invoked in agentic workflows, including Bedrock Agents, Lambda-based action groups, and orchestration layers such as CrewAI or AgentCore. That matters because the agent does not just produce text. It can also trigger tool calls, pass data to plugins, and continue reasoning across multiple steps. Once that happens, safety policy has to cover tool selection, data flow, and execution timing, not just what the model says. The technical challenge is consistency across all those touchpoints.

Practical implication: enforce the same policy at the prompt, tool, and output layers so a bypass at one stage cannot complete the chain.

Threat narrative

Attacker objective: The attacker wants to hijack model or agent behaviour so the system leaks data, violates policy, or performs an unsafe tool action.

1. Entry occurs when a malicious prompt, injected instruction, or untrusted external document reaches the GenAI application and is treated as ordinary context. Escalation follows when the model or agent accepts the hidden instruction, continues the conversation, or sends the content into a tool call without recognising the manipulation. Impact occurs when the agent reveals sensitive data, bypasses policy, or executes an unsafe action that the original request never authorised.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime guardrails solve prompt risk, not identity risk. The article correctly shows that input and output filters can reduce unsafe generation, but the deeper governance problem is who or what is authorised to act in the first place. A guardrail can block harmful text while still leaving tool access, data reach, and execution authority broadly defined. Practitioners should read this as evidence that content safety and identity governance are separate control planes.

Prompt injection is an NHI control problem because the attacker is steering non-human execution, not just content. Once an agent can read, summarise, and call tools, the security question becomes whether the non-human identity can be induced to misuse its own access. That is why least privilege, scoped tool permissions, and line-of-business data segmentation remain central even when guardrails are deployed. The practitioner conclusion is simple: a safer model is not the same thing as a safer identity.

Multi-step agent workflows expose a runtime governance gap. The article’s limitation around long conversations and multi-step reasoning shows that one-turn policy checks are often too short for the behaviour they are meant to govern. This is where the named concept runtime governance gap matters: policy exists, but it does not observe the full chain of action from prompt to tool to response. Teams should treat that gap as an architectural constraint, not a tuning issue.

Guardrails become more valuable when they are paired with verification, not when they are treated as the primary control. The article’s discussion of plan-verify-execute patterns points to a broader principle in NHI governance: policy enforcement works best when upstream intent is checked before downstream execution. That does not make the model trustworthy by default. It means the organisation has to govern the handoff between intent, identity, and action with the same seriousness it applies to privileged automation.

Agent-specific policy variation is a sign that identity risk is already contextual. The article notes that customer-facing bots and internal parsers may need different thresholds, which is exactly what many IAM and NHI programmes struggle to operationalise. Uniform policy looks tidy on paper, but runtime risk depends on task, data, and tool reach. Practitioners should conclude that one-size-fits-all guardrails are usually too blunt for real production estates.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The governance gap is widening as more organisations deploy agents into production, which makes lifecycle controls, auditability, and tool-scoped access the next control layer to examine, as explored in OWASP Agentic Applications Top 10.

What this signals

Runtime governance gap: organisations are adding model-side safety controls faster than they are adding identity-side constraints, which means the residual risk now sits in tool reach, delegation depth, and data exposure. That is why agent governance has to be measured as an identity programme, not only as an AI safety initiative.

With 80% of organisations already reporting AI agents acting beyond intended scope in the New Attack Surface research, the practical question is no longer whether to deploy guardrails but whether the organisation can observe and constrain agent behaviour end to end. The weakest estates will be the ones that can moderate text but cannot explain access decisions.

Security leaders should expect runtime policy to become a standard requirement for agentic systems, especially where tools, external content, and sensitive data intersect. The programme shift is toward continuous verification, strong audit trails, and explicit scoping of non-human identities before the next wave of agent deployment expands the blast radius.

For practitioners

• Map guardrail coverage to actual identity and tool boundaries Inventory where prompts, model responses, tool calls, and plugin requests are intercepted, then identify any execution path that bypasses the same policy set. Prioritise flows where agents can reach third-party software or sensitive internal systems.
• Classify external content as untrusted input Treat email text, web pages, retrieved documents, and tool output as hostile context until they pass the same prompt-attack checks used for direct user input. This reduces indirect injection risk in multi-step workflows.
• Scope agent permissions to the minimum task boundary Limit which tools, APIs, and data domains each agent can touch, then review whether the guardrail can stop an unsafe request after the identity already has access. If it cannot, the access scope is too broad.
• Test long-horizon conversations and chained tool calls Run adversarial scenarios that span multiple turns, nested tool actions, and delayed instruction changes, because single-turn tests miss the gradual deconstruction pattern the article describes. Keep a record of where policy fails across the chain.

Key takeaways

• Bedrock Guardrails addresses unsafe generation, but it does not by itself solve the identity and access problems created by AI agents.
• The strongest signal in the article is the gap between content safety and runtime governance, especially when agents can call tools across multiple steps.
• Practitioners should evaluate guardrails as one control layer inside a broader NHI and agent governance model, not as the model for that model.

Key terms

• Agentic Runtime Governance Gap: The distance between approving an AI agent as a project artefact and controlling its actual production behaviour. This gap appears when static approvals, access reviews, or policy documents do not keep pace with the agent’s live tool use and changing operational context.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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-scoped Access: A permission model that limits which external tools, APIs, and resources an agent can use for a specific task. For autonomous or semi-autonomous systems, tool scope is a core identity control because access to action often matters more than access to text.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step configuration guidance for prompt, output, and content-filter policies across Bedrock guardrails.
• Implementation detail for applying guardrails inside agent workflows, Lambda action groups, and orchestration stacks.
• Examples of testing and tuning patterns for false positives, false negatives, and multi-step jailbreak attempts.
• Operational notes on combining runtime filtering with tool scoping, logging, and incident workflows.

👉 Akto's full post covers configuration detail, guardrail limitations, and agent workflow examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, IGA, or NHI programme, it is worth exploring.