Notifications
Clear all
Topic starter
10/06/2026 12:38 am
TL;DR: Amazon Bedrock Guardrails adds content filtering, denied topics, PII handling, and prompt-attack protections across foundation models and agents, according to Lasso Security. The real issue is that policy filters can constrain outputs, but they do not by themselves solve identity, delegation, or data-access governance in AI workflows.
NHIMG editorial — based on content published by Lasso Security: Guardrails for Amazon Bedrock: AI Safety and Compliance Guide
By the numbers:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern AI model access and output controls together?
A: Security teams should govern them as separate layers.
Q: Why do AI guardrails fail if identity access is too broad?
A: Because guardrails only shape what the system says or returns.
Q: What should organisations check before putting AI agents into production?
A: They should check the full delegation chain, including the agent identity, the service account, the model endpoint, the knowledge base, and any downstream tool permissions.
Practitioner guidance
- Map every Bedrock-connected identity Inventory the service accounts, API keys, roles, and agent identities that can call models, access knowledge bases, or trigger tools.
- Separate content policy from access policy Keep prompt filtering, denied topics, and PII redaction in one control plane, but enforce caller authentication, authorisation, and data permissions elsewhere.
- Review secrets exposure around AI workflows Check code repositories, config files, CI/CD jobs, and agent integrations for long-lived credentials that let models or adjacent services reach regulated data.
What's in the full article
Lasso Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for content filters, denied topics, word filters, and PII handling in Amazon Bedrock.
- Practical guidance on associating guardrails with models, agents, and knowledge bases in a live environment.
- Examples of block-message configuration and customer-managed key usage for compliance-oriented deployments.
- Implementation details for prompt-injection and jailbreak detection in the Secure Gateway for LLMs.
👉 Read Lasso Security's guide to Guardrails for Amazon Bedrock and AI compliance →
Amazon Bedrock guardrails: are your AI controls keeping up?
Explore further
11/06/2026 2:22 am
Guardrails are content controls, not identity controls. Amazon Bedrock Guardrails can reduce unsafe output, but it does not answer the more important governance question: who or what is authorised to reach the model, the data, and the downstream action path. That distinction matters because many AI incidents begin with over-broad access, not with unsafe text. Practitioners should treat guardrails as one layer in a larger identity model, not as a substitute for NHI governance.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Seventy-one percent of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time. That persistence problem matters in AI workflows because long-lived credentials are exactly what model-connected services inherit.
A question worth separating out:
Q: What is the difference between content filtering and least privilege in AI systems?
A: Content filtering decides what the model may say. Least privilege decides what the underlying identity may access or trigger. The two are complementary, but they solve different problems. A system can be perfectly filtered and still dangerously over-connected if the agent or service account has broad read, write, or execution rights.
👉 Read our full editorial: Guardrails for Amazon Bedrock: AI safety and compliance limits
12/06/2026 3:56 am
Guardrails are content controls, not identity controls. Amazon Bedrock Guardrails can reduce unsafe output, but it does not answer the more important governance question: who or what is authorised to reach the model, the data, and the downstream action path. That distinction matters because many AI incidents begin with over-broad access, not with unsafe text. Practitioners should treat guardrails as one layer in a larger identity model, not as a substitute for NHI governance.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Seventy-one percent of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time. That persistence problem matters in AI workflows because long-lived credentials are exactly what model-connected services inherit.
A question worth separating out:
Q: What is the difference between content filtering and least privilege in AI systems?
A: Content filtering decides what the model may say. Least privilege decides what the underlying identity may access or trigger. The two are complementary, but they solve different problems. A system can be perfectly filtered and still dangerously over-connected if the agent or service account has broad read, write, or execution rights.
👉 Read our full editorial: Guardrails for Amazon Bedrock: AI safety and compliance limits
