OWASP LLM risks expose where AI security still depends on identity

At a glance

What this is: Akeyless maps OWASP LLM risks to the governance gaps that let prompts, secrets, third-party access and poisoned inputs become practical attack paths.

Why it matters: IAM, PAM and secrets teams need to treat LLM risk as an identity problem as much as a model problem, because access scope and auditability shape exposure.

👉 Read Akeyless' analysis of OWASP LLM risks and identity controls

Context

LLM security is not just about model behaviour. The operational failure mode is usually weaker control over who can change prompts, which credentials an AI workflow can use, and how much access a third-party integration inherits. In that sense, the article is really about governance around machine access, not about the model alone.

Akeyless frames five OWASP LLM risks through prompt control, sensitive information disclosure, supply-chain access, data and model poisoning, and resource abuse. That makes the identity bridge explicit: if secrets, RBAC, ABAC, rotation and audit trails are loose, AI systems inherit the same control gaps that already trouble NHI and workload identity programmes.

Key questions

Q: What breaks when LLM prompt control is not tied to access governance?

A: Prompt control becomes a bypass path when teams let unreviewed users or integrations modify system instructions, retrieval sources or tool calls. The model can then act on attacker-supplied content as if it were trusted input, which turns a language feature into an authorisation failure. The fix is to treat prompt changes as privileged actions with explicit approval, logging and scope limits.

Q: Why do long-lived secrets create more risk for workloads and agentic AI systems?

A: Long-lived secrets increase blast radius because any exposed key can be reused until it is rotated or revoked. In workload and AI environments, those credentials are often embedded in automation, shared across services, or retrieved repeatedly, which weakens accountability. Short-lived, identity-based access reduces persistence, limits reuse, and makes compromise easier to contain.

Q: What are the signs that an LLM environment is overexposed?

A: Common warning signs include broad prompt-edit permissions, shared API keys across tools, no clear audit trail for model-driven actions, and third-party integrations that can reach internal systems without separate identity controls. These conditions do not prove compromise, but they show the environment can turn a model issue into an access incident very quickly.

Q: How do teams reduce supply-chain risk in agentic AI deployments?

A: Teams should verify every artefact that can influence runtime behaviour, including tokenizer files, prompt templates, and packaging metadata. They also need a revocation path for mirrored or derived models so tampering does not persist across environments. The goal is to govern the full model package, not just the weights.

Technical breakdown

Why prompt injection is an access-control problem

Prompt injection succeeds when the system treats prompt text as safe input despite allowing it to steer privileged behaviour. The security issue is not the language model alone. It is the absence of a strong boundary between user-supplied content, system instructions, and actions that can modify data, expose records, or trigger downstream tools. When prompt writers, support staff, or integrated services can alter behaviour without tightly scoped approval and logging, the model becomes a policy bypass path. In practice, prompt governance has to sit alongside authentication and authorisation, not after the fact.

Practical implication: treat prompt modification as a privileged action and bind it to least privilege, change control and audit.

How secrets exposure turns LLM workflows into identity exposure

LLM applications often touch APIs, vector stores, plugins and external services, which means they inherit secrets and tokens that can outlive the session that used them. If those credentials are long-lived or broadly scoped, a leak in one path becomes reusable access elsewhere. The article’s emphasis on JIT credentials, encryption and access controls reflects a core identity lesson: the shortest possible credential lifetime is what limits blast radius. For AI workflows, secrets management is not just storage hygiene. It is the control plane that decides whether the model can act only inside its intended boundary.

Practical implication: issue ephemeral credentials to AI workflows and rotate any persistent tokens that reach model-adjacent services.

Why third-party AI supply chains need workload identity

Supply-chain risk in LLM environments often appears when external models, datasets or services are given standing access into internal systems. The control failure is credential inheritance without lifecycle governance. If a third-party integration can authenticate with a hardcoded key or a reused service secret, compromise of the supplier becomes compromise of the downstream environment. A workload identity pattern such as SPIFFE and SPIRE reduces that exposure by replacing static shared secrets with verifiable service identities. That matters because LLM ecosystems are increasingly composable, and composability without identity discipline is just delegated risk.

Practical implication: replace shared API keys with workload identities for every third-party AI integration that can reach internal resources.

Threat narrative

Attacker objective: The attacker wants to turn an LLM interaction into unauthorized access to sensitive data, privileged actions or downstream systems.

1. Entry occurs when an attacker manipulates prompts, poisoned inputs or a third-party integration path that an LLM trusts to perform actions.
2. Credential access follows when the AI workflow exposes tokens, API keys or other sensitive data that let the attacker move beyond the model interface.
3. Impact occurs when those credentials or altered outputs are used to exfiltrate data, modify downstream decisions or persist access through connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM security is already an identity governance problem. The article is right to focus on prompt injection, supply-chain access and sensitive data exposure, because each risk becomes materially worse when the AI workflow can act with broad or poorly audited credentials. The model may generate the behaviour, but access scope decides the damage. Practitioners should treat LLM governance as a control question about who and what can act, not just what the model can say.

Prompt governance without privilege governance is incomplete. Fine-grained RBAC and ABAC matter here because prompts are operational inputs with security consequences, not just text. If a user can alter an AI prompt, connect a plugin, or change a retrieval source without explicit authorisation, the control boundary has already failed. The practical conclusion is that LLM access paths need the same entitlement discipline applied to other high-risk production systems.

LLM supply chains are creating a new form of access sprawl. Third-party models, datasets, connectors and agent workflows can accumulate standing secrets faster than teams can review them. That is a named concept worth tracking because the exposure is not only in the model, but in the mesh of delegated access around it. Identity teams should assume AI ecosystems will multiply trust relationships unless workload identity and secret lifecycle controls are made mandatory.

Immutable auditability is becoming a baseline requirement for AI trust. The article’s emphasis on detailed audit trails and tamper-proof logs reflects a broader reality: AI incidents are hard to reconstruct when prompt changes, credential use and downstream actions are not correlated. The control gap is not just visibility, it is evidentiary integrity. Security teams should align AI logging with broader NIST-CSF monitoring and response expectations so incidents can be investigated as access events, not model anomalies.

From our research library:

• 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.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

AI credential sprawl is becoming a measurable governance problem: 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. For practitioners, the signal is that model security cannot be separated from secrets governance, because the surrounding workflow is where most exposure now accumulates.

That changes the programme priority list. Identity teams should expect AI platforms, connectors and agentic workflows to outgrow static review cycles unless credentials, entitlements and audit trails are designed for short-lived use from the start.

For practitioners

• Bind prompt changes to privileged change control Classify prompt edits, system-instruction changes and retrieval-source updates as privileged changes, then require approval, logging and review before they can affect production AI workflows.
• Replace standing secrets in AI workflows Remove hardcoded API keys and long-lived tokens from model integrations, then issue short-lived credentials that expire with the task or session.
• Scope AI access with RBAC and ABAC Use role and attribute policies to restrict who can modify prompts, call tools or access sensitive data through the AI path, and review those entitlements as part of production access certification.
• Instrument AI activity with tamper-resistant audit logs Record prompt modifications, token use, third-party calls and policy decisions in logs that support incident reconstruction and abuse detection.
• Replace shared integration keys with workload identities Where AI systems integrate with external services, prefer workload identity patterns such as SPIFFE and SPIRE over shared secrets so third-party compromise does not automatically transfer into your environment.

Key takeaways

• The article’s core warning is that LLM risk becomes an identity problem as soon as prompts, tokens and third-party integrations can influence production actions.
• The evidence points to governance gaps around access scope, secrets lifetime and auditability rather than to model output alone.
• The most effective controls are privileged change control, ephemeral credentials, workload identity and tamper-resistant logging.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Tamper-proof audit log: A tamper-proof audit log is an access record designed to resist alteration while preserving enough detail to reconstruct who accessed what, when, and from where. In identity programmes, it supports investigations, compliance evidence, and accountability when controls are challenged.

What's in the full article

Akeyless' full article covers the operational detail this post intentionally leaves for the source:

• The specific RBAC and ABAC patterns used to restrict prompt modification and AI-related permissions
• The zero-knowledge and encryption model behind its secrets handling for AI prompts, keys and credentials
• The JIT credential approach and how ephemeral access is applied across AI and third-party integrations
• The Cyberdyne examples showing how each OWASP LLM risk maps to a concrete mitigation pattern

👉 Akeyless' full post covers the Cyberdyne examples, secrets handling and mitigations for each selected OWASP LLM risk.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps identity and security practitioners turn AI access risk into enforceable control decisions.