Topic starter
22/06/2026 9:58 am
TL;DR: Traditional security controls do not map cleanly to LLMs because their inputs, outputs, data sources, and runtime behavior are probabilistic rather than deterministic, according to Orca Security and IBM Institute for Business Value. The governance gap is no longer theoretical: access scope, data exposure, and runtime monitoring all need AI-specific treatment, not legacy application assumptions.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “The Complete Guide to LLM Security: Risks, Best Practices, and Solutions”.
By the numbers:
- According to IBM Institute for Business Value’s 2024 research cited by Orca Security, 82% of executives say secure and trustworthy AI is essential to their business, but only 24% of current generative AI projects have a security component built in.
Key questions
Q: What fails when traditional IAM is used for generative AI security?
A: Traditional IAM fails because it assumes stable identities, predictable actions, and deterministic outcomes.
Q: Why do ordinary service accounts become a shadow AI risk?
A: Because AI agents often operate through identities that already have read, call, or act permissions.
Q: What are the signs that GenAI guardrails are not working as intended?
A: Common warning signs include unsafe outputs reaching users, policy violations slipping through, slow or inconsistent enforcement, and operational friction that pushes teams to bypass controls.
Practitioner guidance
- Audit AI workloads and their service identities Inventory training jobs, inference endpoints, vector databases, API keys, and service accounts together so you can see which credentials can reach which model-adjacent data stores.
- Restrict model-to-service communication Apply least privilege and explicit policy authorization so training environments, retrieval services, and inference endpoints cannot move laterally without approval.
- Classify and sanitize training inputs before ingestion Scan data lakes, vector stores, and fine-tuning datasets for sensitive material before training begins, then mask or quarantine what should not shape model behaviour.
Bottom line: Generative AI breaks the assumption that identity and access can be governed through static permissions alone, because model behaviour is probabilistic and context-sensitive.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 10:39 am
Generative AI is an authorisation problem before it is a model problem. Traditional IAM assumes the system being governed has fixed actions and predictable outputs. That assumption fails when an LLM can reinterpret prompts, pull in shifting context, and influence downstream services at runtime. Practitioners should stop treating model access as a simple login event and start treating it as a governed decision surface.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams balance IAM, DSPM, and runtime monitoring for AI workloads?
A: IAM should constrain who and what can reach AI services, DSPM should restrict what data is allowed into training and retrieval pipelines, and runtime monitoring should detect when model behaviour drifts or starts calling services in unexpected ways. The controls are complementary, not interchangeable.
👉 Read our full editorial: Why traditional IAM fails for generative AI security