Notifications
Clear all
Topic starter
10/06/2026 12:38 am
TL;DR: GenAI guardrails are being used to constrain input, output, data access, and policy enforcement across enterprise AI apps, with Lasso Security citing that over 13% of employees share sensitive information with GenAI tools. The real issue is that traditional IAM and content controls do not fully address model behaviour, prompt injection, or policy drift in AI systems.
NHIMG editorial — based on content published by Lasso Security: GenAI Guardrails, Implementation & Best Practices
By the numbers:
- Over 13% of employees share sensitive information with GenAI applications and chatbots, according to Lasso Security.
Questions worth separating out
Q: How should security teams govern GenAI applications without breaking usability?
A: Start by mapping the request path and applying controls where risk appears, not only at login.
Q: Why do GenAI tools create gaps that standard IAM does not close?
A: Because IAM can authorize access, but it does not control how a model interprets prompts, retrieves data, or generates output once access is granted.
Q: What breaks when GenAI guardrails are only implemented as static rules?
A: Static rules go stale as prompts, plugins, data sources, and policy obligations change.
Practitioner guidance
- Map GenAI request paths to identity and data controls Inventory which user identities, service accounts, APIs, and datasets a GenAI workflow can touch, then document each decision point where access, filtering, or redaction should occur.
- Enforce policy-as-code for prompt and output control Version control your guardrail rules, tie them to role and context signals, and require change tracking so security teams can review policy updates before they reach production.
- Instrument every model interaction for auditability Log prompts, outputs, policy decisions, and remediation events in a format that supports incident review, compliance reporting, and false-positive tuning.
What's in the full article
Lasso Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the guardrails integrate with IdPs, APIs, service meshes, and proxy layers.
- Implementation guidance for policy-as-code with OPA, YAML, or JSON DSLs across GenAI workflows.
- Operational monitoring details, including logging formats, false-positive tuning, and feedback loops.
- Examples of automated responses such as prompt blocking, output rewriting, and token revocation.
👉 Read Lasso Security's guide to implementing GenAI guardrails and best practices →
GenAI guardrails and IAM: are your controls keeping up?
Explore further
11/06/2026 2:22 am
GenAI guardrails are an identity governance problem, not just a model-safety problem. Once an LLM can read data, call APIs, and return content in an enterprise workflow, the security question becomes who can trigger those actions, under what context, and with what oversight. That places guardrails inside the same governance family as access control, auditability, and policy enforcement. Practitioners should treat GenAI as a governed identity surface, not a standalone feature set.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security and ESG.
A question worth separating out:
Q: Who is accountable when a GenAI system exposes sensitive data or generates harmful content?
A: Accountability sits with the organisation that designed, approved, and operated the workflow, including the teams responsible for identity, data, model governance, and compliance. In regulated environments, the control owner must be able to show logs, policy decisions, and remediation evidence.
👉 Read our full editorial: GenAI guardrails expose the IAM gap in AI application control
12/06/2026 3:56 am
GenAI guardrails are an identity governance problem, not just a model-safety problem. Once an LLM can read data, call APIs, and return content in an enterprise workflow, the security question becomes who can trigger those actions, under what context, and with what oversight. That places guardrails inside the same governance family as access control, auditability, and policy enforcement. Practitioners should treat GenAI as a governed identity surface, not a standalone feature set.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security and ESG.
A question worth separating out:
Q: Who is accountable when a GenAI system exposes sensitive data or generates harmful content?
A: Accountability sits with the organisation that designed, approved, and operated the workflow, including the teams responsible for identity, data, model governance, and compliance. In regulated environments, the control owner must be able to show logs, policy decisions, and remediation evidence.
👉 Read our full editorial: GenAI guardrails expose the IAM gap in AI application control
