Topic starter
06/06/2026 2:32 am
TL;DR: LLMs create runtime security gaps that traditional tools were never built to handle, with 29% of cybersecurity leaders reporting an attack on enterprise GenAI infrastructure, according to WitnessAI. The practical issue is not model quality alone but control-plane failure: access, output, and action governance must move outside the model and into runtime enforcement.
Editorial analysis by NHI Mgmt Group, based on content published by WitnessAI: “What Are the OWASP Top 10 Risks for LLMs?”.
By the numbers:
- 29% of cybersecurity leaders said their organizations had experienced an attack on enterprise GenAI infrastructure.
Key questions
Q: What breaks when LLMs are connected to business systems without runtime governance?
A: The security boundary moves from code review to live interaction, and that is where traditional controls lose precision.
Q: Why do LLM-driven systems increase risk when they have tool access or write permissions?
A: Because the model can turn manipulated output into real-world action using legitimate access.
Q: What are the signs that LLM output controls are failing in production?
A: Common warning signs include repeated policy bypasses, user prompts that trigger disallowed content, unexpected data exposure in responses, and high rates of blocked or rewritten outputs.
Practitioner guidance
- Map AI interaction paths into your access model Identify where prompts, retrieved content, model outputs, and downstream actions cross trust boundaries, then assign ownership for each point of control.
- Separate tool permissions from model permissions Restrict write access, database access, and communication rights so the model cannot inherit broad privileges just because it can call a tool.
- Enforce runtime inspection on prompts and outputs Inspect both inbound and outbound AI traffic for injection patterns, sensitive data, and unsafe commands before any downstream action is allowed.
Bottom line: LLM deployments expose a control gap because prompts, outputs, and tool use create a runtime attack surface that traditional IAM and application security were not built to govern.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 4:16 am
Traditional IAM assumptions break when a model becomes the decision surface: access is no longer only about who logged in, but about what the system is allowed to infer, retrieve, generate, and trigger in real time. That shifts governance from static entitlements to runtime policy enforcement across prompts, outputs, and actions. The practical implication is that IAM teams must treat AI interaction paths as part of the access model, not an adjacent risk.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
Q: Why do LLM applications create governance problems for IAM and security teams?
A: LLM applications create governance problems because they can turn untrusted input into live system behaviour. Once a model can call tools, reach internal data, or shape business logic, access control, output handling, and runtime policy become one control surface. That requires identity and application governance to be designed together.
👉 Read our full editorial: LLM security risks expose the limits of traditional IAM controls