Why enterprises need a real AI security standard for LLMs

At a glance

What this is: This is an analysis of why fragmented AI security frameworks leave LLM and agent deployments without a consistent control model.

Why it matters: It matters because IAM, PAM, and governance teams now have to secure AI systems as identities, not just as applications, across both human and non-human access paths.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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%).
• 17 minutes.

👉 Read Lasso Security's analysis of a real AI security standard for LLMs and agents

Context

LLM and agent security fails when organisations treat AI as a feature rather than an identity-bearing runtime that needs continuous governance. The first gap is not model quality, but the absence of a clear control plane for who or what can access the system, what it can reach, and how those permissions are reviewed over time.

The primary issue is lifecycle drift. AI systems move through training, fine-tuning, deployment, updates, and retirement, yet many security programmes still think in static asset terms. That mismatch leaves gaps in access control, monitoring, and incident response once models and agents are live in production. For readers building a governance programme, the question is no longer whether AI needs security, but which identity controls can actually be enforced end to end.

Key questions

Q: How should security teams govern LLM and agent access in production?

A: Treat every model, agent, connector, and service account as part of one identity surface. Define owners, scope permissions to task and environment, and require logging that shows who or what accessed the system, what data was touched, and what downstream actions occurred.

Q: Why do existing AI security frameworks fall short for IAM teams?

A: Because most frameworks describe desired outcomes rather than enforceable control design. IAM teams still need to translate them into identity verification, least privilege, lifecycle review, monitoring, and incident response that work across training, deployment, and retirement.

Q: What breaks when AI systems are governed like static applications?

A: Lifecycle drift breaks the model. AI systems change through training, fine-tuning, updates, and retirement, so static controls miss where risk enters and where access should end. That creates blind spots for data exposure, connector reuse, and post-deployment misuse.

Q: Who is accountable when AI access leads to data leakage or misuse?

A: Accountability should sit with the named business owner and the technical owner of the AI runtime, not with an abstract platform team. If the access path includes service accounts or connectors, those identities must also be in scope for review and revocation decisions.

Technical breakdown

Why fragmented AI security frameworks do not become control models

Frameworks such as NIST AI RMF, ISO/IEC 42001, cloud guidance, and the EU AI Act each address part of the problem, but they do not automatically become enforceable security architecture. A framework describes intent, not operational control. Teams still need concrete mappings for identity, authorisation, logging, monitoring, and incident handling across model lifecycle stages. Without those mappings, “secure AI” stays interpretive rather than measurable. The real gap is translation from principle to control plane, especially when the same system is touched by users, applications, and automated workloads.

Practical implication: Map every AI use case to explicit identity controls, logging requirements, and operational ownership before production rollout.

How access control changes when LLMs and agents become shared resources

LLMs and agents are accessed by employees, applications, and other automated systems, often across multiple environments. That creates a non-human identity problem as much as an AI problem. Least privilege, strong identity verification, and anomaly detection become the practical controls that prevent uncontrolled sharing, shadow AI, and data leakage. The challenge is that the access boundary is not just the model endpoint. It includes the accounts, tokens, connectors, and service identities that can reach the model and reuse its outputs elsewhere.

Practical implication: Inventory every principal that can call or relay AI output, then scope access by task, environment, and data sensitivity.

Why lifecycle-wide security is the real missing layer for AI systems

AI systems are not static assets, so security controls that only exist at deployment time do not hold up. Risks can enter through training data, development pipelines, testing, production monitoring, or retirement. That makes lifecycle security the decisive issue. If the programme cannot answer how data, prompts, models, connectors, and permissions change between stages, it cannot reliably prove control. This is where identity governance and AI governance converge: both must track what exists, who can use it, and when that access should disappear.

Practical implication: Build lifecycle checkpoints for training, deployment, monitoring, and retirement so AI access and data exposure can be reviewed continuously.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Fragmented AI guidance is not a security standard. The article is right to separate broad frameworks from operational control, because most current guidance stops at intent. Security teams still need a control model that binds identity, access, logging, and incident response into one lifecycle view. The implication is straightforward: if the programme cannot be enforced, it is not yet a standard.

AI systems are becoming non-human identity estates. Once employees, applications, and other automated systems all access the same models, the problem shifts from model-only security to identity governance for the surrounding runtime. That means access scope, connector trust, and token sprawl matter as much as the model itself. Practitioners should treat AI access as a governable identity surface, not an isolated application.

Lifecycle security is the named concept enterprises keep missing. AI systems move through training, fine-tuning, deployment, updates, and retirement, but many security programmes still secure only the deployment moment. That assumption fails because risk can enter before and after production, including through compromised training data and unmonitored updates. The implication is that static control reviews no longer describe actual exposure.

Shadow LLMs are a governance failure, not just an inventory problem. When organisations cannot see who is using AI systems or where those systems are embedded, they lose the ability to enforce policy, investigate misuse, or answer for data exposure. Visibility gaps turn into accountability gaps quickly, especially when access is spread across business teams and automation. Practitioners need to see shadow AI as a lifecycle and access issue, not merely discovery debt.

Zero trust for AI must start with the identity behind the call, not the model response. The article’s real subtext is that AI systems are only as governable as the principals and connectors that reach them. That aligns with identity-first thinking in Zero Trust, where continuous verification and least privilege are applied to every access path. Teams should re-evaluate how they authenticate, authorise, and monitor AI interactions across human and machine actors.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, which shows how wide the policy-to-practice gap remains.
• Ultimate Guide to NHIs , 2025 Outlook and Predictions helps teams translate that gap into lifecycle controls for workloads, agents, and other non-human identities.

What this signals

Lifecycle security is becoming the organising concept for AI governance. Teams that still separate model risk, access governance, and operations will struggle to prove control once AI moves across training, deployment, and retirement. The practical shift is toward one control plane that links identity, data access, and monitoring across the whole system, not just the live endpoint. For related governance patterns, see Top 10 NHI Issues.

With 80% of organisations already reporting AI agents acting beyond intended scope, the programme question is no longer whether the risk exists, but how quickly access can be bounded and reviewed before it spreads. That pushes practitioners toward continuous verification, tighter connector governance, and better separation between human, application, and agent access paths. For control alignment, the OWASP Agentic AI Top 10 is a useful external reference point.

Shadow LLMs are the early warning signal for broader identity drift. Once AI adoption happens faster than governance, access moves outside the visible control plane and accountability fragments across teams. The result is not just a model security issue but an IAM and audit issue that will keep expanding as more systems embed AI capabilities. Readers should expect governance teams to treat AI discovery, connector review, and lifecycle retirement as routine control work.

For practitioners

• Map AI systems to named identity owners Assign business and technical ownership for every model, agent, connector, and service account that can reach production AI. No AI system should enter production without a named owner for access decisions, monitoring, and retirement.
• Enforce least privilege across AI access paths Scope human and machine access separately for prompts, outputs, connectors, and downstream APIs. Remove broad shared tokens and make each integration use the smallest workable permission set.
• Add lifecycle checkpoints before and after deployment Review training data, fine-tuning inputs, production permissions, and retirement steps as separate control moments. If a model changes environment or purpose, re-authorise its access rather than assuming prior approval still applies.
• Operationalise anomaly detection for AI usage Watch for unusual request patterns, unexpected data access, and shadow LLM behaviour across environments. Tie alerts to a response path that can suspend access before sensitive data is reused or exfiltrated.
• Build incident response for AI-specific failure modes Document how to contain prompt abuse, connector misuse, data leakage, and model or agent decommissioning failures. Incident response for AI should include access revocation, log preservation, and a review of where the identity boundary broke down.

Key takeaways

• Enterprises do not yet have a consistent AI security standard, and that leaves LLMs and agents governed by fragmented guidance rather than enforceable controls.
• The scale of the gap is already visible in access and auditability, where AI systems are being used in production faster than teams can prove who accessed what.
• Practitioners should manage AI as an identity and lifecycle problem, with ownership, least privilege, monitoring, and retirement controls built in from the start.

Key terms

• Lifecycle Security: Lifecycle security is the practice of governing a system across its full life, from creation and deployment to update and retirement. For AI, it means security cannot stop at launch because risk can enter through training data, configuration, access, monitoring, and decommissioning.
• Shadow LLM: A shadow LLM is an AI model or LLM usage that exists outside approved governance and visibility. It may be embedded in tools, workflows, or automations without clear ownership, making access, data handling, and incident response hard to control or audit.
• Identity Surface: An identity surface is the full set of human and non-human principals that can authenticate to, invoke, or relay actions through a system. In AI environments, that includes users, applications, service accounts, tokens, connectors, and agents that can touch the model or its outputs.
• Connector Governance: Connector governance is the control of integrations that let an AI system reach data, tools, and downstream services. It matters because the security boundary is often the connector, not the model itself, and weak connector control expands both access and blast radius.

Deepen your knowledge

AI lifecycle governance and access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for LLMs and agents, it is worth exploring.

This post draws on content published by Lasso Security: Why enterprises need a real AI security standard for LLMs and agents. Read the original.