An AI service that nobody on your team enabled starts receiving thousands of requests. By the time the cloud bill reflects them, the attacker may have created more keys, moved through the account, and routed your model access to paying customers elsewhere.

Mandiant calls this LLMJacking. In incidents it investigated during 2026, attackers used compromised cloud identities and model access to consume or resell AI resources. It reported more than $100,000 in fraudulent charges in a single day in individual cases, and cumulative charges reaching $1 million at some organizations. Those figures describe investigated cases, not a typical loss or a forecast for every exposed key.

TL;DR

  • Attackers can start with a leaked model key, a stolen cloud credential, an active session, or an exposed model endpoint. A model key is only one of several possible entry points.
  • Watch for the sequence: unusual credential use, new identities or permissions, unexpected model service enablement, and rising request or token volume. A small test request may precede the spike.
  • Join identity, cloud audit, model usage, and billing signals. A cost alert alone may arrive after substantial usage.
  • If abuse is suspected, preserve the event trail, disable the exposed access, check for persistence and other stolen secrets, and verify that usage stops.

Why This Matters

LLMJacking is a cloud identity incident with a fast billing consequence. Mandiant observed actors using stolen IAM credentials, service account keys, personal access tokens, active sessions, and LLM API keys. In some cases they enabled model services that the organization had not been using. Others created additional identities or keys so revoking the first credential would not end their access.

The attacker may also use the same foothold for repository reconnaissance, secret theft, or other cloud activity. A large model bill is therefore an incident indicator, not the full scope of the incident.

How the Access Becomes Revenue

Mandiant’s cases show several paths, not one universal exploit chain:

  1. Find an entry point. An attacker discovers an exposed model endpoint or obtains a valid key, cloud credential, or session. Mandiant observed checks of exposed keys using requests as small as max_tokens=1, which would be easy to miss in a volume-only alert.
  2. Expand access. The attacker inspects permissions and connected services, then may create service accounts, keys, or privileged roles. Some incidents involved repository and secret-store searches. These actions depend on the permissions of the compromised identity.
  3. Consume or resell capacity. The actor enables model APIs, sends high-volume inference requests, provisions compute, or routes access through an illicit proxy. Mandiant describes “LLM Mixers” that aggregate stolen access and sell it onward.

One reported case used a compromised cloud service account to enable additional AI services and rapidly accumulate charges. Another involved more than 500,000 model API calls in under eight hours. Treat these as examples of observed behavior, not thresholds to hard-code into detection rules.

Build a Detection Chain

Start with a baseline for each account, project, model, and workload identity: which model services are approved, which principals can enable them, expected regions, normal request rates, and who owns the bill. Then correlate deviations across four evidence sources.

EvidenceInvestigate when you seeWhat it helps establish
Identity and cloud audit logsA key first used from a new context; a new service account, access key, role grant, or token-creation permissionHow access began and whether the actor established persistence
Model service administrationA model API enabled or a quota raised without an approved changeWhether the attacker prepared new capacity
Model invocation telemetryAn unexpected caller, model, region, or destination; bursts of requests or tokens; tiny validation calls followed by sustained trafficWhich credentials and services were used
Cost and quota signalsSudden model charges, approaching quota, or use outside the owning team’s budgetThe financial impact and whether abuse is still active

Do not assume every provider logs inference the same way. For Amazon Bedrock’s bedrock-runtime, AWS documents common inference calls in CloudTrail management events. Its bedrock-mantle endpoint records inference as data events, which must be explicitly selected for an audit trail. AWS also offers Bedrock model invocation logging, but it is disabled by default and can capture prompt and response content. Choose the metadata needed for investigation and protect any content logs according to your data policy.

Build the alert around a sequence, such as a newly created key followed by a previously unused model and a sharp rise in calls. A billing anomaly should trigger investigation, but it should not be the first and only signal. Billing data can lag behind usage.

Contain the Credential and the Cloud Footprint

If the pattern is plausible, capture audit events, key and role changes, model usage, and billing data before making changes that remove evidence. Then:

  1. Disable or revoke the exposed credential and its derived sessions. Rotate related secrets found in the same repository, workload, or secret store.
  2. Remove unauthorized identities, keys, policy grants, proxies, and compute resources. Check whether the attacker can still mint fresh credentials through another role.
  3. Restrict model access to the identities and services that need it. Review network exposure for self-hosted model endpoints and gateways.
  4. Verify that model calls, new key creation, and unauthorized charges have stopped. Continue reviewing the period before the first alert for earlier reconnaissance or data access.

Do not treat a password reset as sufficient when the actor has a service account key or an active API token. Do not treat a falling request rate as proof of containment while unauthorized identities remain.

What You Can Do Today

  • Inventory model APIs and gateways across cloud accounts, including services that are available but not yet approved for use. Assign an owner and an expected workload identity to each.
  • Alert when a model service is enabled, a new key or service account receives model permissions, or a quota changes. Correlate those events with the next model invocations.
  • Test whether your provider’s logs show the caller, model, region, request count, and token use you need. Enable missing audit event categories deliberately; avoid collecting prompt content by default just to count calls.
  • Set model and account quotas where available. Add cost alerts as a second signal. An alert-only budget is not a spending cap; Google Cloud offers separate spend caps for eligible services and projects, with possible reporting and enforcement delay.
  • Run a controlled test with a low-privilege key: make one authorized request, rotate the key, and confirm that later calls fail while the alert and audit trail identify the activity.

Record the credential ID, first suspicious model request, and related account changes in the same incident timeline. Responders can then revoke every access path they found and check for activity beyond model usage.

Sources