Notifications
Clear all
Topic starter
02/08/2026 12:10 pm
TL;DR: Amazon Bedrock Guardrails adds pre- and post-generation safety checks for GenAI apps, including prompt-injection defence, PII redaction, denied-topic filtering, and grounding validation, while also extending into Bedrock Agents and orchestration stacks at runtime. For identity teams, the deeper issue is that safety controls still depend on constrained execution paths, so governance must account for tool use, prompt flow, and policy drift together.
NHIMG editorial — based on content published by Akto: Amazon Bedrock Guardrails and secure GenAI applications
Questions worth separating out
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.
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.
Q: What do teams get wrong about Bedrock-style guardrails?
A: The common mistake is assuming that content moderation equals safe access.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Akto's guide to Amazon Bedrock Guardrails for GenAI and AI agents →
Amazon Bedrock Guardrails: are runtime controls enough for AI agents?
Explore further
02/08/2026 1:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Amazon Bedrock Guardrails and the runtime safety gap for AI agents
