LLMjacking: How Attackers Steal AI API Keys and Run Up Your Bill

Your OpenAI API key is sitting in a .env file. Your AWS credentials are stored in ~/.aws/credentials. Your Anthropic key is set as an environment variable in your CI pipeline. Any one of these, if exposed, can cost you tens of thousands of dollars in a matter of hours — not because an attacker is stealing your data, but because they're using your AI quota to run their own workloads.

This is LLMjacking, and it's the fastest-growing credential abuse vector in cloud security right now.

What LLMjacking Actually Is

The term was coined by Sysdig's Threat Research Team in 2024, and the attack pattern has since accelerated significantly. LLMjacking is straightforward in concept: an attacker obtains credentials that grant access to a hosted AI service — OpenAI, Anthropic, AWS Bedrock, Google Vertex AI, Azure OpenAI — and then uses those credentials to run inference workloads for their own purposes.

The attacker doesn't care about your data. They care about compute access.

The stolen credentials get resold on underground forums, integrated into reverse proxy infrastructure, or used to power unauthorized services. The victim discovers it on their next billing cycle — or sooner, if they have alerts configured.

Sysdig's 2026 threat research documented a 376% increase in credential theft specifically targeting AI services between Q4 2025 and Q1 2026. The unit economics explain the growth: a stolen OpenAI API key sells for as little as $30 on the dark web, while the daily compute cost it can rack up for the victim can exceed $46,000.

How the Attack Unfolds

LLMjacking follows a predictable lifecycle. Understanding it is the first step to interrupting it.

1. Credential Discovery

Attackers don't typically break into systems to find AI credentials. They scan for them passively.

Common discovery vectors:

• Public repositories. Developers commit .env files or hardcode keys directly in source files. Automated scanners continuously monitor GitHub, GitLab, and npm for credential patterns. The median time from a public commit to first abuse is under four minutes.
• Exposed AI training data. In early 2025, researchers found over 12,000 valid API keys and passwords embedded in public datasets that had been ingested into LLM training pipelines — credentials that were publicly accessible before being scraped.
• Server-side request forgery (SSRF). In containerized environments, SSRF vulnerabilities against cloud metadata endpoints (e.g., http://169.254.169.254 on AWS) can expose IAM role credentials with permissions to invoke Bedrock models.
• Misconfigured proxy infrastructure. LiteLLM, OpenRouter, and similar AI proxy layers are increasingly common in production. A misconfigured or outdated proxy instance can expose the backing credentials.
• Old application vulnerabilities. Sysdig documented LLMjacking campaigns that targeted outdated Laravel installations to gain shell access and enumerate environment variables for AI service keys.

2. Reconnaissance Without Triggering Alarms

Once an attacker has potential credentials, they don't immediately start running expensive queries. They probe quietly first.

For AWS Bedrock, this looks like calls to GetFoundationModelAvailability and ListFoundationModels — read-only operations that identify which AI models the account can access and in which regions. No actual inference is invoked. No meaningful cost is generated. But the attacker now knows exactly what they have.

They also check logging configurations. If CloudTrail is logging model invocations, sophisticated attackers may attempt to disable or reduce logging scope before exploitation begins.

For direct API key validation (OpenAI, Anthropic), the probe is a minimal, cheap inference call — something that generates a fraction of a cent — to verify the key is active and has quota remaining.

3. Exploitation and Monetization

With validated credentials and a clear picture of available resources, exploitation begins. The two main monetization paths:

Direct resale. Credentials are listed on Telegram channels or dark web marketplaces. Buyers purchase access at a fraction of what legitimate API access would cost them. The seller profits immediately; the victim's costs accumulate in the background.

Reverse proxy services. More sophisticated operations build reverse proxy layers that route third-party requests through the victim's credentials. This turns one stolen set of credentials into ongoing revenue. The attacker never needs to touch the credentials again once the proxy is running — it operates autonomously.

In one documented case, an attacker accessed Anthropic Claude 2.x through compromised AWS credentials, reached quota limits across multiple regions, and generated over $46,000 in costs in a single day. A personal AWS account was compromised through a different LLMjacking campaign and had its average $2/month bill spike to $730 in two to three hours.

Why AI Credentials Are Specifically High-Value

Developers have leaked database passwords, OAuth secrets, and cloud access keys for years. LLMjacking is not fundamentally new in concept — what's different is the financial leverage.

A stolen database password gives an attacker access to your data, which they then have to extract, store, and monetize. That takes effort and carries risk.

A stolen AI API key gives an attacker access to expensive compute that they can resell directly. No data extraction needed. The "product" is the compute itself, and there's an established market of buyers.

The average Anthropic Claude 3 Opus request costs between $0.015 and $0.075 depending on token count. Running a service that makes tens of thousands of such requests per day — on someone else's key — is a meaningful business for an attacker.

The financial incentive also makes AI credentials more attractive than credentials for services that only offer data access.

The Hardcoded Secret Problem in AI Applications

AI integrations have created a new wave of credential hygiene problems, partly because the developer experience for most AI SDKs defaults to insecure patterns.

The OpenAI SDK documentation shows this in the first code example:

from openai import OpenAI

client = OpenAI(api_key="sk-...")

That's the quick-start path. For a developer spinning up a prototype at 2am, that key ends up in a file that gets committed. Multiply that by the number of developers building AI-powered side projects, internal tools, and production applications — and you have a significant exposure surface.

The same pattern repeats across LangChain, LlamaIndex, AWS Bedrock SDK, and every other AI framework. Configuration via constructor arguments or environment variables is technically equivalent in terms of security, but the quick-start examples typically show the insecure path.

In CI/CD pipelines, the problem is different. Teams frequently store API keys as "secrets" in their CI configuration, but then expose them in build logs, pass them through environment variables across job boundaries without scoping, or embed them in Docker image layers during build steps.

# This bakes the API key into the image layer history
ARG OPENAI_API_KEY
ENV OPENAI_API_KEY=$OPENAI_API_KEY
RUN python setup.py  # this step runs with the key in the environment

Even if the final image doesn't expose the key at runtime, docker history on the built image can reveal it.

Detection: What to Monitor

If you're running AI services in production, these are the signals worth building alerts around:

Unexpected cost spikes. Set billing alerts at 20%, 50%, and 100% of your expected daily spend. These thresholds sound obvious, but most teams set a single monthly budget alert and miss intraday abuse. AWS Budget Alerts and OpenAI's usage monitoring both support threshold-based notifications with email or webhook delivery.

Unusual geographic distribution of API calls. Your application likely calls AI services from a predictable set of IP ranges — your cloud region, your CI runner IPs, your developer VPN endpoints. Calls originating from TOR exit nodes, residential proxies, or unrecognized cloud regions are worth investigating immediately.

High error rates from a single source. A high rate of ValidationException or AccessDenied errors from a single IP or IAM role is characteristic of credential probing. The attacker is testing which models and operations are accessible.

Calls to model enumeration APIs. ListFoundationModels and GetFoundationModelAvailability on AWS Bedrock are not called by typical production applications. A CloudTrail alert on these API calls from unexpected principals is a reliable early indicator.

IAM anomaly detection. AWS GuardDuty's machine learning-based anomaly detection can flag unusual usage patterns on IAM roles, including unexpected service invocations.

Prevention: The Actual Fixes

Detection matters, but the goal is to make credential theft non-exploitable.

Use Short-Lived Credentials Wherever Possible

Static API keys are the root of the LLMjacking problem. For AWS Bedrock, your production workloads should be using IAM roles with instance profiles or OIDC-federated credentials — not long-lived access keys. Short-lived credentials expire in hours; a stolen credential from a compromised server is useless after rotation.

For OpenAI and Anthropic, true short-lived credentials don't exist yet in the same way. The mitigation is key rotation policies and tight scoping.

Scope Permissions Precisely

An IAM role that can invoke anthropic.claude-3-opus-20240229-v1:0 in us-east-1 but cannot invoke any other model or operate in any other region limits the blast radius of a compromise.

For direct AI API keys, OpenAI supports project-scoped keys with restricted usage. Use project keys rather than organization-level keys wherever possible. Anthropic's API key management similarly supports rate limits and workspace scoping.

Minimum viable permission scope is not bureaucracy — it's a meaningful limit on what an attacker can do with a stolen credential.

Scan Before You Commit

Integrate secret scanning into your pre-commit workflow. Tools like trufflehog and gitleaks can detect API key patterns for major AI providers:

# Install gitleaks
brew install gitleaks

# Scan the current repo
gitleaks detect --source . --verbose

# Set up as a pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "Secret detected in staged files. Commit blocked."
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

gitleaks ships with detection rules for OpenAI keys (sk-...), Anthropic keys, AWS access key ID patterns (AKIA...), and dozens of other credential types.

Pre-commit scanning only helps if enforced consistently. Adopt it at the repository level, not as a personal convention.

Never Pass Secrets Through Environment Variables in Dockerfiles

The correct pattern for secrets in Docker builds is not ARG or ENV. Use Docker BuildKit's secret mounts:

# Correct: secret is never written to the image layer
RUN --mount=type=secret,id=openai_key \
    OPENAI_API_KEY=$(cat /run/secrets/openai_key) python setup.py

The secret is accessible during the build step but not stored in any layer. docker history will not reveal it.

For runtime secrets, pass them through the container runtime's secret management (Kubernetes Secrets with appropriate RBAC, Docker Swarm secrets) rather than environment variables set at image build time.

Rotate Immediately on Suspicion

If you suspect a key has been exposed — a public commit, a log that printed environment variables, a server compromise — rotate first and investigate second. The cost of an unnecessary rotation is minutes of work. The cost of waiting to be sure is potentially tens of thousands of dollars.

Most AI providers support key rotation without downtime if your application is written to read credentials from a central configuration source rather than hardcoded values.

Centralize Credential Storage

Credentials scattered across .env files on developer machines, CI runner secrets, container environment variables, and cloud KMS systems are impossible to audit uniformly. A centralized secrets store makes rotation, access control, and audit logging tractable.

The specific tool matters less than the principle: secrets should live in one place, with clear ownership, and rotation should be a single operation that propagates everywhere.

When You Find an Exposed Key in Your History

If you find that an API key has been committed to a Git repository — even if it was removed in a subsequent commit — treat it as compromised. The key exists in the commit history and is accessible to anyone who clones the repository, now or in the future. Squashing the commit doesn't help if the repository was ever pushed to a remote.

The only correct response:

1. Rotate the key immediately. Issue a new credential in your AI provider's console and update all systems using it.
2. Revoke the old key. Do not wait to confirm abuse — revoke before investigating.
3. Check your usage logs. Look for any calls you don't recognize in the window between the original commit and the rotation. File a dispute with your provider if you identify unauthorized charges.
4. Audit what else was in that commit or repository. A leaked AI key often isn't the only credential in the same file.

The Broader Pattern

LLMjacking is a specific attack, but it's a symptom of a broader pattern: as AI API costs become significant, the credentials that authorize those API calls become high-value targets. The same is true as AI inference gets embedded deeper into production workflows — more applications mean more credentials in more places.

The developers building AI integrations today are, on average, less security-conscious about their AI credentials than they are about their database passwords. That's partly because the AI SDK onboarding experience optimizes for speed, and partly because the consequence of a leaked database password feels more visceral than a billing surprise.

The financial consequences of a leaked AI API key are now directly comparable to a cloud storage data exfiltration incident. Treat them accordingly.

The credential hygiene principles here — avoid long-lived static keys, scope permissions tightly, centralize secret storage, scan before commit — apply across AI provider credentials the same way they apply to database passwords and cloud access keys. If your team is still managing AI API keys in .env files passed around in Slack, that's the first problem to fix.