Notifications
Clear all
Topic starter
10/06/2026 12:52 am
TL;DR: LLM risks now span prompts, outputs, data, plugins, and access governance, with Gartner predicting at least 30% of generative AI projects will be abandoned by the end of 2025 because risk controls and data quality are not keeping pace. Traditional AppSec cannot cover probabilistic model behaviour, so identity, policy, and monitoring have to move into the control plane.
NHIMG editorial — based on content published by Lasso Security: LLM Risks: Enterprise Threats and How to Secure Them
By the numbers:
- Gartner predicts that at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, with inadequate risk controls cited as a key factor alongside poor data quality, escalating costs, and unclear business value.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: How should security teams govern LLMs that can use plugins and APIs?
A: Treat every plugin and API connection as privileged access, not as a feature toggle.
Q: Why do LLMs create risk for IAM and NHI programmes?
A: Because they blur the line between user intent, system behaviour, and delegated access.
Q: What breaks when organisations trust LLM outputs too much?
A: Downstream systems can treat hallucinated or manipulated output as if it were verified business logic.
Practitioner guidance
- Classify every LLM integration by identity and access pattern Document whether the system is only generating text, reading governed data, or calling tools with delegated credentials.
- Constrain tool-calling models with context-bound policies Limit what the model can read, write, and invoke based on task context, data sensitivity, and session purpose.
- Monitor prompts, outputs, and downstream actions as one audit trail Centralise logs for inputs, model responses, retrieval events, and tool invocations so investigators can reconstruct how data moved and where trust was broken.
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 control mapping for prompt filtering, output moderation, and plugin restriction in enterprise LLM deployments
- Operational examples of logging inputs, outputs, and model versions for forensic investigation and compliance
- Implementation guidance for aligning LLM controls with GDPR, CCPA, NIST AI RMF, and ISO 42001
- Incident response sequencing for prompt injection, data poisoning, and model misuse scenarios
👉 Read Lasso Security's analysis of LLM risks, identity exposure, and enterprise controls →
LLM risks and IAM controls: what security teams are missing?
Explore further
11/06/2026 2:26 am
LLM risk management is becoming an identity governance problem before it is an appsec problem. The article shows that the most consequential failures sit in prompts, outputs, plugins, and data handling rather than in code alone. That shifts control ownership toward IAM, NHI, and policy enforcement teams because the model is now acting across governed resources, not just producing text. Practitioners should treat LLM security as an access and accountability discipline, not a narrow content-safety issue.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for LLM security and governance?
A: Accountability should sit with the team that owns the model’s operational behaviour, not only with the team that built it. Security, compliance, data, and business owners all need defined roles for prompts, data access, output review, and incident response. Shared responsibility only works when each control has a named owner.
👉 Read our full editorial: LLM risks are becoming an IAM problem, not just an appsec issue
12/06/2026 4:00 am
LLM risk management is becoming an identity governance problem before it is an appsec problem. The article shows that the most consequential failures sit in prompts, outputs, plugins, and data handling rather than in code alone. That shifts control ownership toward IAM, NHI, and policy enforcement teams because the model is now acting across governed resources, not just producing text. Practitioners should treat LLM security as an access and accountability discipline, not a narrow content-safety issue.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for LLM security and governance?
A: Accountability should sit with the team that owns the model’s operational behaviour, not only with the team that built it. Security, compliance, data, and business owners all need defined roles for prompts, data access, output review, and incident response. Shared responsibility only works when each control has a named owner.
👉 Read our full editorial: LLM risks are becoming an IAM problem, not just an appsec issue
