Topic starter
10/06/2026 12:52 am
TL;DR: LLM risks now extend across prompts, outputs, data, plugins and access governance, according to Lasso Security, and conventional application security cannot control probabilistic model behaviour or identity-driven misuse. Identity, policy and monitoring have to move into the control plane before LLMs become a governance blind spot.
Editorial analysis by NHI Mgmt Group, 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 because risk controls and data quality are not keeping pace.
Key questions
Q: How should security teams think about protecting LLM applications beyond simply restricting access?
A: Security teams should treat LLM protection as a control problem, not just an access problem.
Q: Why do LLMs create risk even when the underlying code is secure?
A: Because the failure point is often the interaction layer, not the codebase.
Q: What are the signs that an enterprise LLM programme is losing control?
A: Common signs include unmanaged shadow AI, inconsistent output moderation, unclear ownership, excessive plugin reach, and limited logging of prompts and tool calls.
Practitioner guidance
- Define context-based policy boundaries Separate allowed queries from allowed actions, data exposure, and tool invocation so that the model cannot treat every valid prompt as permission to act.
- Inventory AI access paths and delegated tools Map every model, plugin, API, and connected application the AI can reach, then classify each path by data sensitivity and privilege level.
- Instrument prompts, outputs, and model decisions Centralise logs for inputs, outputs, configuration changes, and tool calls so that misuse and drift can be investigated after an incident.
Bottom line: LLM risk is not confined to prompts and outputs, because delegated access, plugins, and data paths turn model behaviour into an identity problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 hours ago by NHI Mgmt Group
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 now identity governance by another name: once a model can see data, call tools, or trigger actions, the control question becomes who is authorised to influence that behaviour. The article’s core insight is that LLM risk is not confined to code quality or content moderation. Practitioners should treat model-linked access as a governed entitlement surface, not an isolated AI feature.
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.
A question worth separating out:
Q: What should organisations do first when LLMs can reach sensitive systems?
A: Start by separating read-only use cases from action-capable workflows. Then restrict model access to the minimum data, tools, and sessions required for each use case. That sequencing reduces the chance that a harmless conversational interface becomes a privileged execution path.
👉 Read our full editorial: LLM risks are becoming an IAM problem, not just an appsec issue
This post was modified 3 hours ago by NHI Mgmt Group