Notifications
Clear all
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.
NHIMG editorial — based on content published by WitnessAI: the OWASP Top 10 risks for LLMs and how to defend against them
By the numbers:
- 29% of cybersecurity leaders said their organizations had experienced an attack on enterprise GenAI infrastructure.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams govern LLMs that can call tools and APIs?
A: Treat LLMs with tool access as privileged runtime identities.
Q: Why do LLMs create more risk than ordinary application workloads?
A: LLMs do not just process input, they interpret natural language, retrieve context, and may trigger actions based on that interpretation.
Q: What breaks when prompt injection meets excessive agency?
A: The model can turn attacker-controlled text into privileged action.
Practitioner guidance
- Map every AI-connected identity and token Inventory service accounts, API keys, and delegated tokens used by LLM apps and agents, then classify which systems can read data, write data, or trigger workflows.
- Enforce bidirectional inspection at runtime Inspect both prompts and responses before the model or downstream system can act on them.
- Separate model output from authorisation Require independent approval checks in any system that receives LLM-generated commands, especially where the model can write records, send messages, or invoke APIs.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- A risk-by-risk walkthrough of the full OWASP Top 10 for LLMs, including direct and indirect prompt injection patterns.
- Detailed runtime defense patterns for inspection, policy enforcement, and output validation across AI interactions.
- Examples of how excessive agency turns model output into downstream action in enterprise workflows.
- Operational guidance for visibility and discovery across employees, models, apps, and agents.
👉 Read WitnessAI's breakdown of the OWASP Top 10 risks for LLMs →
LLM security risks and the governance gap IAM teams are missing?
Explore further
06/06/2026 4:16 am
Runtime AI security is now an identity problem, not just an application problem. Once an LLM can read files, call tools, query databases, or trigger workflows, its security posture depends on the same governance questions IAM teams already ask of service accounts and privileged workloads. The difference is that the model can combine those permissions dynamically at runtime, which means static controls alone are not enough. Practitioners should treat AI runtime as part of the identity plane, not as a separate security island.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
A question worth separating out:
Q: How do teams decide whether an AI agent needs human approval?
A: Use the sensitivity of the action, not the cleverness of the model, as the decision point. If the agent can change records, move funds, send external messages, or access regulated data, human approval or an independent policy engine should remain in the path. The more irreversible the action, the less autonomy the agent should have.
👉 Read our full editorial: LLM security risks expose the limits of traditional IAM controls
