LLMjacking
Your stolen AWS credentials, spent on someone else's AI. The bill is yours.
Sysdig's threat research team named the pattern in 2024: attackers take leaked cloud credentials and use them to invoke — and resell access to — the victim's hosted models, Amazon Bedrock included. The attack creates no new infrastructure. What it does leave are configuration and metric facts a read-only audit can check: the credential hygiene that lets it start, the spend and invocation baselines that scale shows up in, and the logging gap that erases the trail.
Published 2026-07-13 · ~7 minute read
How a jack unfolds
Four stages, in order. Each one leaves something observable — a configuration fact or a metric — readable through a read-only role, before and without touching a single prompt.
- the leak
A long-lived access key leaks
A public repo, a laptop backup, a CI log that printed the environment — the classic exits. The key keeps working for months because nothing forces rotation. The leak itself makes no sound in your account.
observable · read-onlyold_access_keysiam_policy_wildcard - enumeration
The attacker enumerates what the key can reach
The first calls are quiet capability checks. bedrock:InvokeModel is the jackpot; Sysdig's researchers also documented GetFoundationModelAvailability probing — testing model access without invoking anything. Wildcard IAM turns this step into a formality.
observable · read-onlypossible-LLMjacking spend flag - invocation at scale
Invocation at scale, often resold
Access gets fronted through OAI-reverse-proxy-style endpoints and sold on, so strangers' prompts flow through your account and you pay per token. Sysdig's researchers estimated potential victim costs in the tens of thousands of dollars per day. Invocation counts and token metrics pull away from your baseline in CloudWatch.
observable · read-onlyrunaway_agent_anomalyAWS/Bedrock Invocations · token counts - no trail
The bill arrives. The trail does not.
Bedrock model-invocation logging is off by default, and attackers prefer accounts that keep it that way. Without it there is no record of what was asked or generated — only line items. The invoice becomes your incident report.
observable · read-onlybedrock_invocation_logging_off
Stages and resale pattern as documented by Sysdig's threat research team (2024). Signal chips name CloudArq checks and the CloudWatch metrics they read.
Why AI credentials became the target
The classic use for a stolen AWS key was crypto-mining: spin up compute, mine until caught. That leaves new infrastructure to spot. Model access is different — bedrock:InvokeModel spends through an API the account already has, creating no instance, no container, nothing new to inventory. The artifacts are metrics and a bill.
Model access is also directly resellable. Sysdig's researchers documented stolen credentials being fronted through reverse-proxy endpoints and sold on: the buyer gets frontier-model tokens, the victim gets the meter. A leaked key with a wildcard Bedrock grant is not a foothold that needs developing — it is the product.
At AWS's published on-demand list price (as of 2026-07), 1M input tokens plus 100k output tokens on a frontier model runs a few dollars. Pocket change for one request — and that is the point: an attacker reselling access multiplies it by thousands of requests a day, on your bill, at a price the buyer never sees.
Illustrative arithmetic from public list pricing, not a customer figure.
The signals CloudArq watches
Every signal below is a configuration or metric fact the read-only audit can prove — the conditions that let a jack start, and the numbers it moves once running. None of them is a claim to catch attackers.
AI spend-spike detection
Cost Intelligence baselines your AWS-billed AI spend month over month. A spike — or AI spend appearing on an account that never had any — combined with credential-hygiene risk found in the same scan raises a possible-LLMjacking flag. A billing-data read: it proves the anomaly, not the attacker.
Runaway-agent anomaly
Compares Bedrock invocation and error counts against the account's own trailing baseline and reads Lambda's RecursiveInvocationsDropped metric for runaway loops. CloudWatch metrics only — token counts as numbers, never what was asked.
Bedrock used with no audit trail
Flags a region where Bedrock is actively used while model-invocation logging is disabled — the exact no-trail condition step four relies on. CloudArq proves logging is off; the unlogged calls are precisely what nobody can see.
Leaked-key hygiene
The ingress. Flags access keys past rotation age and IAM policies granting wildcard actions or resources — the standing conditions that turn one leak into full model access. Configuration reads, not a claim that a key has leaked.
Exposed self-hosted model server
Self-hosted models get jacked directly, no AWS key needed. Correlates a GPU/accelerator instance that is internet-reachable on a known model-server port (Ollama 11434, Ray 8265, vLLM 8000). CloudArq reads security-group configuration and never probes the port.
Provisioned Throughput burn
A Bedrock Provisioned Throughput running with no commitment term is an always-on cost surface — billed hourly at the full on-demand rate whether the model is invoked or not. A configuration read; no dollar figure is invented.
These signals ride the same read-only audit as the broader AI Workload lens, which covers Bedrock agents, RAG, and guardrails beyond the stolen-key story.
Ten minutes of prevention
Frequently asked
- 01What is LLMjacking?
- LLMjacking is the abuse of stolen cloud credentials to invoke — and often resell access to — the victim's hosted AI models, Amazon Bedrock included. Sysdig's threat research team named and documented the pattern in 2024. The victim pays per token for someone else's traffic.
- 02How do I know if it is happening to me?
- Look for what the attack cannot hide: AWS-billed AI spend away from your baseline, Bedrock invocation and token metrics you cannot attribute, and CloudTrail bedrock:InvokeModel calls from unfamiliar principals or regions. CloudArq's read-only audit covers the spend, metric, and credential-hygiene side; the CloudTrail principal review is yours to run.
- 03Does CloudArq read our prompts?
- No. CloudArq never reads prompts, completions, S3 objects, or database contents. It connects through a read-only IAM role secured with an ExternalId and reads configuration, billing data, and CloudWatch metrics — token counts as numbers, never content.
- 04We use IAM roles, not access keys. Are we safe?
- Safer at the ingress: short-lived role credentials expire, which closes the classic leaked-key entry. The rest still applies — a stolen session or an over-broad role can still reach bedrock:InvokeModel, and invocation logging still defaults to off. Scope what roles can invoke, and keep the audit trail on.
- 05Does invocation logging stop LLMjacking?
- No — it records, it does not block. Logging gives you the audit trail step four otherwise erases: what was invoked, when, and by which identity. Prevention lives in credential hygiene and scoped IAM; logging decides whether you can reconstruct what happened.