LLM-Jacking Explained: How Stolen AI Access Is Abused and How to Respond

Direct answer: what is LLM-jacking?

LLM-jacking is unauthorized use of another person's or organization's large-language-model access or compute. An attacker may obtain a cloud credential or model-provider API key, reach an exposed self-hosted inference endpoint or take over a service account, then use that access to run inference or give access to others. The consequence may be unexpected usage, exhausted quotas, operational disruption and, depending on the credential's scope, wider account or data exposure. It is not automatically a hack of the AI provider and it is not always a data breach. Sysdig's original 2024 research named the pattern after observing stolen cloud credentials used to enumerate and invoke paid LLM services.

The term groups several mechanisms, so name the one a case actually shows. A leaked API key is not the same as a hijacked cloud IAM identity; a publicly exposed inference endpoint is not the same as a stolen human account; and prompt injection is not the same as theft of a credential, even if an attacker uses one to obtain the other. The response depends on which boundary failed and which authority the attacker reached.

A simple model of the attack path

First, an attacker gains a usable access path. It might be a key in a repository, a server environment exposed through another vulnerability, a log or browser/session artifact, an overly permissive agent dashboard, or a model endpoint without proper authentication. Second, the attacker tests whether the access works, what models and accounts are available, and whether rate or spending limits apply. Third, the access is used to generate output, automate tasks or resell compute. Finally, the owner may notice a quota alarm, unusual geography, elevated token consumption or unexpected cloud audit events. These are possible stages, not a claim that every case follows an identical script.

Sysdig's initial investigation described a path involving access to a vulnerable application and stolen cloud credentials used to discover LLM services. Its cited $46,080 per day figure is a hypothetical upper-bound cost from quotas and prices, not a measured loss for one victim. Avoid turning a scenario model into an actual invoice. A real financial assessment must use the provider's own itemized usage, billing and contract records for the affected account.

A 2026 example: what METR actually disclosed

In an August 2026 first-party disclosure, METR described a March intrusion into an agent dashboard that an external actor reached through an access-control problem. Its investigation said the actor prompted an agent to expose a public-model API key, added an SSH key and misused model access for roughly three weeks. This is a case study in tool access and credential control, not proof that an AI provider's own platform was breached. METR reported about $600,000 worth of credits consumed, while explicitly stating those credits were granted free; describing the incident as a $600,000 paid bill would be false. Its account says sensitive category-3/4 data were not accessed to its knowledge. These limits should appear beside any impact number.

The METR example also shows that a credential can be only one part of an incident. Account access, dashboard permissions, agent tool outputs and persistence via an SSH key should be examined separately. Rotating the model API key alone may leave a newly added login key or other authorization behind. On the other hand, claiming broad data exfiltration without supporting logs would overstate the case. Use a distinct timeline for initial access, key exposure, credential misuse, containment and later publication.

What should a defender look for?

Start with first-party usage evidence. Compare token consumption and model mix against normal workloads, allowing for legitimate product launches and experiments. Look for requests from new service principals, regions, source networks or projects; spikes outside expected working hours; repeated authorization failures followed by a successful new key; unusual model enumeration; and inference charges from dormant environments. A usage spike by itself does not identify an intruder. Correlate provider usage exports with cloud audit logs, key-creation and rotation events, dashboard sign-ins, repository commits and the service's own request IDs.

A practical triage record should answer: Which credential? Who owned it? What did its scope allow? When was it issued, first used and revoked? Which models or projects were invoked? Did the credential also grant access to prompts, files, vector stores, database records or billing administration? Not all AI keys grant those powers. Preserve raw request and billing records securely; redact secrets from analyst tickets and public reports. Do not treat an auto-generated summary as a replacement for original logs.

Respond without broadening the incident

This sequence is defensive guidance rather than a substitute for an organization's incident-response runbook. Whether law enforcement, a regulator, a provider or customers must be notified depends on the affected entity, data, contracts and applicable law.

• Contain the exact access path. Disable or rotate the affected key and relevant refresh tokens; block a suspicious public endpoint or compromised service identity; preserve an owner-approved emergency route for legitimate users. Scope matters—do not disrupt unrelated tenants to make a security report look decisive.
• Preserve evidence. Export usage, cloud audit, IAM change history, service logs and recent deployment/secret-manager events before a rebuild removes them. Record UTC timestamps, local display timezone, source-system clock drift and the identity that collected each record.
• Find other authority. Inspect added SSH keys, browser sessions, role changes, newly created tokens, scheduled tasks and connected storage permissions if the first-access path could reach them. The METR incident illustrates why a model key is not the only possible artifact.
• Bound impact. Reconcile actual inference volume and credits with provider records; distinguish granted credits from cash spend, compute use from data access, and a suspected account compromise from confirmed exfiltration. Notify affected account owners or contractual partners based on verified scope, not speculation.
• Restore and verify. Issue new least-privilege credentials through an approved secret store, confirm the old credentials no longer authenticate, monitor usage and test that the legitimate service still works. Record a rollback path and follow-up deadline.

Reduce the chance of another stolen key

Keep long-lived provider secrets off client-side bundles, public repositories, screenshots and shared documents. Use workload identities or short-lived tokens where the provider supports them. Apply per-project scopes, restricted model families and separate read/usage/billing administration; do not issue one powerful production key to all AI agents and experiments. Set reasonable usage caps and alerts, but treat spending controls as damage reduction rather than identity security. A charge limit does not keep a stolen key from reading any data it was already authorized to see.

For self-hosted inference, put endpoints behind authentication and network access control; disable unauthenticated exposure and keep management interfaces separate from inference. For agent applications, prevent external prompt or retrieved-page text from deciding to reveal secrets through a tool. Protect the credential broker and require resource-level authorization downstream. Regularly scan for accidentally exposed secrets, rotate with an expiry plan and test that revocation actually cuts off queued agent work. These controls address distinct failure modes; no one setting guarantees protection.

What LLM-jacking is not

An unauthorized model call does not, by itself, prove that the model vendor was hacked, that all prompts in an account were stolen or that a compromised browser session exists. Conversely, a stolen key can have dangerous ancillary permissions even when the first anomaly is just compute usage. Distinguish cost/availability, account control, data access and downstream tool authority in the same incident record. The CYBERoinfo AI application exposure guide discusses separate SSRF/autologin paths; the infostealer guide addresses credential and session theft. These related routes must not be used as evidence that either mechanism occurred in the METR case.

India-focused organizational note

India-based teams should map a confirmed AI service compromise to their own incident types, contractual notification duties and applicable CERT-In directions, preserve logs and record when the organization first became aware. No universal conclusion about reporting can be drawn from a generic LLM-jacking label alone: an unexpected bill, an unauthorized login and a personal-data leak are different facts. Escalate to security and legal owners for entity-specific decisions. Avoid putting secrets or identifiers into a public report; keep first-party internal case identifiers in a restricted incident record.

Decision checklist

• Identify the precise credential, service principal or exposed endpoint and the owner responsible for it.
• Preserve time-bounded model usage, billing records, cloud audit events and request IDs before remediation destroys evidence.
• Check whether a stolen key also authorized files, prompts, role changes, billing management or separate SSH access.
• Disable or rotate the affected key and sessions, then verify revoked credentials cannot still make a request.
• Distinguish measured spending from free credits consumed and from hypothetical quota-based cost exposure.
• Bound the earliest and latest unauthorized request, actual project scope and any independently verified data access.
• Restore least-privilege access and usage alerts, then test legitimate service operation and record follow-up ownership.

Limitations

• Sysdig's $46,080/day is a hypothetical quota-and-price maximum for an example, not a measured victim charge.
• METR's approximately $600,000 equivalent was free model credits consumed, not a paid bill.
• METR reported no category-3/4 data accessed to its knowledge; the statement is not proof about all possible systems or cases.
• Credential theft, account takeover, exposed inference and prompt injection are different mechanisms; an AI provider breach is not implied.

Evidence sources

1. Sysdig Threat Research Team — LLMjacking: Stolen Cloud Credentials Used in New AI Attack
2. METR — Update on Security at METR