LLMjacking shows how compromised NHIs can hijack AI systems

At a glance

What this is: LEVO links LLMjacking to compromised non-human identities that can be used to take over AI systems through exposed credentials and AI-linked secrets.

Why it matters: IAM, PAM, and NHI teams need to treat AI service access as a governed runtime exposure problem, not just a secrets hygiene issue, because stolen machine credentials can drive direct abuse of AI workloads.

Context

LLMjacking is a credential abuse pattern in which stolen or exposed machine credentials are used to access AI services and consume them as if the attacker were a legitimate workload. The risk sits at the intersection of API access, NHI governance, and AI security because the same service account, token, or key that enables automation can also become the attacker’s entry point.

Traditional secrets storage controls do not fully address this problem because the abuse happens after authentication, inside the runtime trust boundary. That means teams must think about issuance, scope, telemetry, and revocation together. In mixed AI and identity environments, the machine identity becomes part of the attack surface, not just a supporting control.

The source article frames this as a practical and growing exposure for environments where AI-linked credentials are embedded in application and cloud workflows. That is typical of modern integration-heavy estates, where the boundary between an application credential and an AI workload credential is increasingly thin.

Key questions

Q: What breaks when non-human identities are managed separately from AI security?

A: What breaks is the ability to see the full trust chain. AI tools often rely on service accounts, API keys, and delegated permissions to operate, so separating AI security from NHI governance leaves gaps in ownership, entitlement review, and incident containment. The result is duplicated controls that still miss the real access path.

Q: Why do stolen service accounts create such a fast path to AI abuse?

A: Service accounts often authenticate directly to APIs and orchestration layers without interactive friction. If those identities are broad, long-lived, or reused across environments, an attacker can move from credential theft to model invocation quickly. The risk rises when detection is tuned to human logins rather than machine-to-machine access patterns.

Q: How do you know if AI access controls are actually working?

A: They are working only if you can answer three questions consistently: which identity accessed the system, which data it touched, and whether that access matched the intended business use. If audit logs cannot produce that chain, the control is partial and the exposure is still active.

Q: Should IAM teams treat AI credentials like standard API keys?

A: No. AI credentials often carry broader scope than standard API keys because they can touch model access, training data, inference endpoints, and consumption costs. That wider blast radius means they need more precise inventory, tighter revocation, and more explicit ownership than a generic secret category would suggest.

Technical breakdown

How compromised NHI credentials reach AI services

AI systems are commonly reached through API keys, service accounts, or cloud credentials that sit outside a human login flow. When those non-human identities are exposed, an attacker can authenticate directly to the AI provider or to the application layer that brokers model access. The important detail is that the credential itself often carries enough authority to invoke model calls, read prompts, or trigger downstream workflows. In practice, the machine identity is not just an access artifact but a live control plane for the AI workload.

Practical implication: Map every AI integration to the exact NHI credential that authorises it and treat that credential as a production access path.

Why runtime abuse matters more than secret storage alone

Secret leakage and runtime abuse are related but not identical. A leaked secret becomes dangerous only when it remains valid, broadly scoped, and reachable from a workflow that an attacker can use before detection or rotation closes the window. LLMjacking exploits that gap. The issue is not simply whether the secret was stored securely, but whether the runtime environment can detect anomalous use, constrain the blast radius, and revoke access fast enough to stop model consumption or service abuse.

Practical implication: Prioritise short-lived credentials, scoped permissions, and runtime anomaly detection over static secret vaulting alone.

Why AI-linked secrets create a distinct governance problem

AI-linked secrets often sit across application code, CI/CD, orchestration layers, and cloud service roles, which makes ownership ambiguous. That creates a governance gap: teams may protect the model endpoint but fail to govern the identity that can call it. In NHI terms, this is a privilege and lifecycle issue, not just a key-management issue. If the credential can be reused, inherited, or embedded in multiple workflows, one compromise can extend into repeated AI abuse and harder-to-trace operational loss.

Practical implication: Assign a named owner to each AI-facing machine identity and require offboarding, rotation, and scope review on the same lifecycle as the workload it serves.

Threat narrative

Attacker objective: The attacker wants to turn stolen machine access into direct control of AI services and the workloads that depend on them.

1. Entry occurs when attackers obtain exposed AWS credentials or similar machine secrets tied to AI workflows.
2. Credential abuse follows when those non-human identities are used to authenticate to AI services or the applications that broker them.
3. Impact appears as hijacked AI usage, with the attacker consuming model capacity or abusing the connected workload under legitimate-looking access.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

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

NHI Mgmt Group analysis

LLMjacking is an NHI governance problem before it is an AI problem. The attack succeeds because a machine credential is granted enough trust to reach valuable AI services and the surrounding workload chain. That makes identity scope, ownership, and revocation the primary control questions, not model quality. Practitioners should treat AI-facing non-human identities as production access paths with explicit governance.

AI-linked secrets create a new form of shadow access. Many organisations can inventory models and APIs more easily than the credentials that invoke them. When service accounts, tokens, or cloud keys are embedded in integration layers, the real exposure is often hidden in runtime dependencies rather than in the AI platform itself. Practitioners should force visibility from credential to workload to model call.

Blast radius, not just leakage, defines the risk. Once a compromised NHI can call an AI service, the control problem becomes how far that identity can move, what it can consume, and whether the call path is observable. AI access blast radius: the amount of model, data, or workflow exposure a single machine identity can reach before revocation. Practitioners should design for contained misuse, not perfect prevention.

Shadow AI and shadow NHIs are converging. AI services are increasingly accessed through credentials that teams did not originally classify as AI assets, which means unmanaged machine identities can become a hidden route into model consumption and downstream automation. This expands the governance perimeter from the model endpoint to every credentialed workflow that can invoke it. Practitioners should align AI governance with NHI inventory and lifecycle control.

OWASP-NHI and AI governance now overlap materially. The article’s topic maps directly to secret leakage, overprivileged NHI, and insecure authentication patterns, because the attacker is not breaking the model so much as borrowing a legitimate machine identity. That intersection means identity controls are now part of AI security architecture, not a separate concern. Practitioners should review AI access through NHI governance, not just AI policy.

What this signals

AI access blast radius: organisations now need to measure how far a single machine identity can move from an integration layer into model access, because that is where LLMjacking becomes operationally expensive.

The practical response is to collapse the distance between credential ownership, workload ownership, and model usage telemetry. If those three views do not line up, a stolen key can look legitimate long enough to cause material abuse.

For practitioners

• Inventory every AI-facing machine identity Identify service accounts, API keys, tokens, and cloud roles that can invoke AI services or AI-brokered workflows, then assign owners and business purpose.
• Reduce the authority of AI invocation paths Scope each credential to one workload, one environment, and one AI service, and remove broad or reusable permissions that allow credential reuse across pipelines.
• Add runtime detection for abnormal AI use Monitor for unusual model call volume, off-hours usage, unfamiliar source systems, and rapid sequences of API authentication that suggest stolen NHI abuse.
• Shorten the lifetime of AI-linked secrets Move high-value credentials toward ephemeral issuance and enforce rotation on the same schedule as workload changes, not on ad hoc manual cycles.
• Revoke credentials before misuse becomes persistent Build kill-switch procedures for AI service credentials so exposed keys can be invalidated quickly across all linked integrations and deployment paths.

Key takeaways

• LLMjacking shows that AI security failures often begin with a compromised machine credential rather than with model exploitation.
• The main risk is not secret leakage in the abstract, but the ability of an attacker to reuse valid NHI access against AI services before revocation or detection.
• Teams should tighten scope, shorten lifetime, and improve runtime visibility for AI-facing NHIs so misuse is contained at the credential layer.

Key terms

• LLMjacking: Abuse of cloud AI services through stolen machine credentials rather than human user accounts. The attacker uses valid non-human identities such as API keys or tokens to enumerate model access, invoke endpoints, and create cost, data, or policy exposure under the victim's tenancy.
• AI-Facing Non-Human Identity: An AI-facing non-human identity is a service account, token, key, or workload credential that can invoke AI systems or the workflows around them. These identities matter because they often carry direct production authority and can be reused across integrations if governance is weak.
• Credentialed Workflow: A credentialed workflow is an automated process that depends on a machine identity to reach services, move data, or trigger actions. When that identity is compromised, the workflow itself becomes the attacker’s vehicle, which is why ownership and scope matter as much as storage.
• AI Blast Radius: AI blast radius is the amount of damage an AI system can cause if it behaves incorrectly, is compromised, or is given unsafe access. It describes the scope of affected data, systems, users, and decisions. In security terms, it is shaped by permissions, tool access, autonomy, and the trust placed in the model.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that maps directly to AI-facing access risk. It helps practitioners connect identity controls to the runtime systems their programmes depend on.