OWASP LLM risks expose where AI security still depends on identity

At a glance

What this is: This is an analysis of how selected OWASP LLM risks map to secrets management, access control, auditing, workload identity, and model governance.

Why it matters: It matters because AI programmes inherit IAM and NHI failure modes when prompts, credentials, and data pipelines are not governed as tightly as the model itself.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Akeyless' analysis of OWASP LLM risks and secrets governance

Context

OWASP LLM risk management is increasingly an identity and secrets governance problem, not just an AI model problem. Prompt access, API tokens, service credentials, and audit trails determine whether an LLM can be manipulated into disclosing data or taking unsafe actions, and that makes IAM and PAM controls part of the AI security boundary.

The article uses OWASP LLM risks to show how attackers can exploit weak privilege boundaries, poorly governed secrets, and incomplete logging around AI workflows. That pattern is typical across early-stage AI deployments, where operational speed often outruns security design.

For identity teams, the intersection is direct: the same control gaps that affect NHI programmes also affect AI assistants, retrieval pipelines, and model-adjacent tooling. This is where policy, credentials, and workload identity become the real control plane.

Key questions

Q: What breaks when AI prompts can be changed without privileged access controls?

A: When prompt editing is not controlled, attackers or insiders can steer the model into revealing information, calling tools, or bypassing intended guardrails. The failure is not the prompt itself but the missing identity boundary around who may alter instructions. Organisations should treat prompt administration as privileged access and log every change.

Q: Why do LLMs complicate secrets and identity governance?

A: LLMs complicate governance because they consume data through tools, memory, and retrieval paths that behave like privileged interfaces. If service accounts, API keys, or document connectors are not tightly scoped, the model can surface information that an ordinary user should never see. That makes identity boundaries part of AI safety.

Q: What do security teams get wrong about AI agent identity governance?

A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Technical breakdown

Prompt injection and privilege boundaries

Prompt injection is not simply a content problem. It becomes a security issue when an LLM can act on prompts that are not tightly bound to an identity, role, or approval boundary. If a chatbot, agent, or workflow can change prompts, call tools, or retrieve sensitive data without strong authorization, the model becomes a path to privilege misuse rather than a passive interface. RBAC and ABAC help here because they separate who can modify instructions from who can consume outputs. Auditability matters too, because prompt tampering often looks like ordinary interaction until a control plane records the change.

Practical implication: treat prompt modification and tool invocation as privileged actions that require explicit access control and monitoring.

Sensitive data exposure through AI outputs

LLMs can reproduce sensitive information if they are trained on, connected to, or prompted with poorly governed data. The exposure risk rises when secrets, customer records, or business intelligence are available to the model through broad access paths or persistent credentials. End-to-end encryption, zero-knowledge design, and just-in-time secrets all reduce the amount of sensitive material an AI system can see at any moment. That is a governance pattern, not just a cryptographic one, because it limits both insider exposure and model-adjacent leakage. In practice, the important question is not whether the model is intelligent, but whether its data access is bounded.

Practical implication: narrow the model's accessible data set and use ephemeral credentials so leakage has less to expose.

Workload identity and supply-chain trust in AI pipelines

AI applications increasingly depend on third-party services, model endpoints, and orchestration components that need authenticated access to internal resources. When those systems rely on hardcoded secrets or long-lived API keys, a compromise in one dependency can become a direct path into the environment. SPIFFE and SPIRE address this by giving workloads cryptographic identities instead of reusable secrets, which is especially relevant for AI pipelines that need machine-to-machine trust. The security value is simple: credentials should identify a workload, not sit embedded in code or configuration where they can be copied and reused.

Practical implication: replace persistent integration secrets with workload identity for AI services that call other services.

Threat narrative

Attacker objective: The attacker wants to use the AI workflow as a trusted path to extract sensitive data, alter outputs, or perform actions that should have required stronger authorization.

1. Entry occurs when an attacker reaches an LLM workflow through prompt input, exposed API credentials, or a compromised third-party integration.
2. Escalation follows if the model or connected service can modify prompts, retrieve data, or invoke tools without tight role and attribute checks.
3. Impact occurs when the AI system discloses sensitive information, executes unauthorized actions, or consumes poisoned data that degrades decisions.

NHI Mgmt Group analysis

AI security failures are increasingly identity failures in disguise. LLM risks such as prompt injection and data disclosure only become operationally dangerous when privileges, secrets, and audit paths are weakly governed. That means AI teams cannot treat model security as separate from IAM and PAM. The practical conclusion is that AI governance must include identity lifecycle controls, not just content safeguards.

Prompt access is a privileged action, not a low-risk user interaction. If users or agents can alter prompts, system messages, or retrieval instructions without role separation, the model can be steered into unsafe behaviour. This is where RBAC and ABAC become core AI controls rather than supporting ones. Practitioners should classify prompt-editing and tool-configuration rights as sensitive administrative access.

Workload identity is the missing trust layer for AI pipelines. AI services that depend on long-lived API keys or embedded secrets create a replayable trust problem that is familiar from NHI sprawl. SPIFFE-style identity reduces that exposure because it ties service-to-service trust to cryptographic workload identity instead of reusable credentials. The practitioner takeaway is to govern AI pipelines like any other privileged machine estate.

AI governance debt is accumulating faster than security teams can review it. Every new chatbot, retrieval flow, and model connector adds another place where secrets, data access, and approval logic can drift apart. That drift is already visible in organisations that deploy AI faster than they formalise controls. The result is a governance backlog that identity teams will have to absorb.

OWASP LLM risks should be mapped to control owners, not just technical teams. The article's strongest implication is that AI security only becomes durable when ownership is distributed across identity, application, and data governance. A security programme that cannot name who owns prompt permissions, secrets rotation, and model access will not be able to sustain control. Practitioners should assign those responsibilities now.

What this signals

Prompt governance will increasingly be audited like privileged access. As LLM adoption spreads, practitioners should expect pressure to prove who can change prompts, who can approve tool actions, and how those rights are reviewed. The control problem is moving from experimentation to evidence, and identity teams will be asked to supply the evidence chain.

AI governance debt is now a programme risk, not a theoretical one. Each new model connector or retrieval path adds a new access decision that can drift from policy. Teams should align AI onboarding with workload identity, secrets lifecycle, and access review processes so the environment does not outgrow the controls around it.

For practitioners

• Separate prompt administration from prompt consumption Restrict who can edit system prompts, retrieval instructions, and tool policies. Treat those rights as privileged access, log every change, and review them with the same discipline used for administrative IAM.
• Replace persistent AI integration secrets with ephemeral credentials Use just-in-time credentials for model connectors, retrieval services, and third-party integrations. Rotate or revoke keys aggressively and avoid embedding secrets in prompts, code, or orchestration files.
• Use workload identity for AI service-to-service calls Adopt workload identity patterns such as SPIFFE and SPIRE where AI services authenticate to each other. This reduces reuse risk and gives each component a verifiable identity instead of a shared secret.
• Audit AI data access and tool invocation separately Track what data the model can retrieve and what actions it can trigger. These are different control problems, and separating them makes it easier to detect overreach and support incident investigation.

Key takeaways

• LLM security breaks down fastest where identity, secrets, and model access are treated as separate problems.
• The strongest control theme in this article is not model hardening alone, but bounded access with auditable privilege.
• Practitioners should govern prompts, credentials, and workload identity as one security chain, not three disconnected tasks.

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.
• 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.
• Just-in-Time Secrets Provisioning: Just-in-time secrets provisioning issues a credential only when a workload needs it and removes or expires it shortly after use. This reduces the time window for abuse and is most effective when paired with policy checks, workload identity, and automated revocation.
• Zero-knowledge encryption model: An encryption design where the provider cannot read the stored data because decryption keys are held by the user or derived locally. For identity programmes, this reduces provider visibility but does not remove the need to govern recovery paths, enrollment state, and administrative authority around access continuity.

What's in the full article

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

• Concrete RBAC and ABAC policy examples for controlling who may change AI prompts and related permissions.
• Details on zero-knowledge secret handling and end-to-end encryption for model-adjacent credentials.
• Implementation context for JIT secrets and SPIFFE/SPIRE integrations in AI pipelines.
• Examples of how audit trails are used to detect prompt tampering and unauthorized access patterns.

👉 The full Akeyless post covers the OWASP LLM mappings, Cyberdyne examples, and mitigation details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programmes they already run.