What Is LLMjacking, and How Do We Stop AI API Key Theft?

LLMjacking is the theft and resale of access to large language models: an attacker takes your AI provider API key, or finds your exposed model endpoint, and runs their own workloads on your bill. You stop it by knowing every key you have, keeping keys out of code and clients, replacing long-lived keys with scoped short-lived credentials, and watching usage per key.

The term covers two closely related moves. One is stealing a credential that unlocks a hosted model, such as an API key for a commercial provider or a cloud role that can call a managed model service. The other is finding a model endpoint that needs no credential at all, such as a self-hosted inference server, an AI gateway or a Model Context Protocol (MCP) server left open on the internet. Either way, the attacker gets free compute, a clean identity that is not theirs, and someone else to take the blame when the provider sees abuse.

Key takeaways

• LLMjacking is a cost attack and an identity attack at once. The attacker spends your money and borrows your account's reputation, so their abuse lands on you, not them.
• AI keys leak from the same places as every other secret, plus a few new ones: frontend bundles, .env files, MCP client configs, CI logs, gateway request logs and hosting platform environment variables.
• Attackers automate discovery. On 21 October 2026, Infosecurity Magazine reported on a Symantec finding of an autonomous attack agent that hunts exposed LLM endpoints, AI gateways and MCP servers.
• Spend caps and rate limits are a real control, but a partial one. They cap the blast radius of a stolen key. They do not stop the theft, the data exposure, or abuse that stays under the cap.
• Inventory first. You cannot rotate, scope or monitor keys you do not know exist. Provider admin APIs now let you list keys, their owners and their expiry.
• Move to identity-backed, short-lived credentials wherever the provider supports them: workload identity federation, short-term cloud keys, service accounts and enforced expiry.
• Have a playbook ready. Disable the key, deploy a replacement, pull per-key usage, find the leak source, and only then delete.

What is LLMjacking, and why are AI keys worth more to attackers than many cloud keys?

LLMjacking means using someone else's AI compute without permission. The term entered security research in 2024, describing attackers who used stolen cloud credentials to call hosted models, and has since broadened to cover any stolen AI credential or exposed model endpoint.

The October 2026 reporting gives a clear picture of the motive. Infosecurity Magazine, summarising Symantec's Threat Hunter Team, describes LLMjacking as using someone else's compute or a stolen key to run AI workloads for free. The report adds two points that explain why attackers bother. Routing work through a stranger's endpoint or key shifts the cost of the model onto the victim, and it also gives the attacker anonymity and a way around the account bans that providers issue for abuse.

That second point is why AI keys can be worth more than a typical cloud access key with narrow permissions.

1. They convert straight into money. A valid key can be resold as access, used to run a paid service, or used to generate content at volume. There is no need to pivot, escalate or exfiltrate anything first.
2. They carry a clean reputation. Providers apply abuse policies and safety systems to accounts. An attacker who is banned on their own account can keep working on yours until you notice.
3. They are spread widely. A single company may have keys for several providers, in several projects, held by developers, CI jobs, gateways, agents and MCP servers. Every copy is a chance to leak.
4. They often sit next to sensitive data. An attacker who reaches a gateway or agent, not just a bare key, may also see prompts, tool outputs and logs.

TechTarget, reporting on Microsoft's legal action against a group it tracks as Storm-2139, says the group used stolen Azure OpenAI API keys, which Microsoft discovered in late July 2024. The keys were paired with a custom application that sent requests mimicking legitimate API calls and let users change request parameters the service normally blocks. According to TechTarget, the group offered the resulting tools to end users at different service tiers and price points. Microsoft amended its complaint on 27 February 2025 to name four individuals.

So LLMjacking is not just a big bill. It is a market in stolen model access, often used to produce content the provider would refuse on the attacker's own account.

How it fits the wider attack pattern this month

Three things that surfaced around 21 October 2026 show how AI keys now sit at the centre of broader attacks.

None of these needs a new kind of exploit. They are ordinary credential theft, aimed at a credential that has become more valuable.

Where do AI keys usually leak?

AI keys leak from the same places as database passwords and cloud keys, plus a handful of places that are specific to how AI features get built. Here are the common ones, roughly in the order teams find them during a review.

Frontend bundles and mobile apps

The fastest way to ship a chat feature is to call the provider directly from the browser or the app. That puts the key in JavaScript that anyone can read, or in a mobile binary that anyone can unpack. Google's Gemini API documentation is direct about it: do not embed keys in client side web or mobile apps in production, and run a backend proxy that makes the calls instead. Build tools make this mistake easy, because some frameworks inline any environment variable with a public prefix into the client bundle at build time.

If a client must call a model directly, use a provider mechanism built for that. Anthropic's docs describe App Attest for iOS and macOS apps, which gives attested installs a workspace scoped token that expires after one hour and authorizes only Messages API calls.

.env files and source control

The .env file is convenient and dangerous. It gets copied into Docker build contexts, attached to support tickets, committed by mistake when .gitignore is wrong, and pasted into chat. Google's guidance is blunt: "Never check API keys into source control systems like Git." A key that reaches a public repository should be treated as compromised within minutes, because automated scrapers watch public commits. Removing the commit later does not help; the key has to be revoked.

MCP client and agent configuration

MCP servers and coding agents need credentials to do their jobs, and many setups store those credentials in plain JSON config files in the user's home directory or the project folder. Those files get synced to dotfile repositories, shared in onboarding docs, and read by any process running as that user. The MCP specification's security guidance also warns that local MCP servers run with the same privileges as the client, and recommends sandboxing them and restricting their file system and network access.

Security researchers now report infostealer families that collect AI agent artifacts, including agent tokens and MCP configs holding credentials. Treat any long-lived key in an agent or MCP config as something malware will look for.

CI logs and build output

CI systems print a lot. A debug flag, a failing test that dumps its environment, or a script that echoes a request can put a key into a build log that is retained for months and readable by everyone with repository access. Forked pull request builds are another route if secrets are exposed to them. The OWASP Secrets Management Cheat Sheet recommends treating CI/CD as a production environment, avoiding long-lived high-value secrets in CI tooling, and preventing secrets from leaking through pipeline output or forks.

Gateway and application logs

This is the leak that teams underestimate. AI gateways, proxies and observability tools often log full requests and responses so you can debug prompts and measure cost. If authorization headers, tool outputs or agent transcripts contain tokens, those logs now hold credentials. The LiteLLM maintainers' account, as discussed on Hacker News, is the clearest recent example: a token appeared in tool call responses, request and response logging captured it, and an attacker with access to the logs harvested tokens, including one belonging to an organisation admin.

Hosting platform environment variables

Platform as a service products store your environment variables and inject them at build and run time. That is better than hard coding, but the platform then holds a copy of every key. Cyber Security News reports that in Railway's October 2026 incident, an unauthorised third party may have accessed customer environment variables, including some decrypted values, and that Railway advised customers to rotate every secret stored that way without waiting to confirm they were affected.

Notebooks, demos and evaluation sandboxes

Notebooks with the key in a cell, hackathon repos and evaluation sandboxes all leak keys regularly. Attackers have been reported stealing AI API keys from evaluation sandboxes. These environments are short-lived; the keys in them often are not.

How do attackers find exposed LLM endpoints and gateways?

There are two hunting grounds: leaked credentials and exposed services. Attackers work both at internet scale.

Leaked credentials. Automated tools watch public code hosts, package registries, container images, paste sites and public build logs for strings that look like provider keys. Most providers use recognisable key prefixes, which makes this easy. Anthropic's docs, for instance, show standard keys beginning sk-ant-api and Admin API keys beginning sk-ant-admin. Once found, a key is tested against the provider's API within moments, and working keys are sorted by what models and limits they unlock.

Exposed services. Self-hosted inference servers, OpenAI compatible endpoints, AI gateways with admin interfaces, and remote MCP servers all answer on predictable paths and ports. Internet scanners fingerprint them the same way they fingerprint web frameworks. A gateway with no authentication, or with a default master key, is an open door to every provider key it holds.

The October 2026 Symantec finding shows where this is heading. According to Infosecurity Magazine, the captured agent instructions listed about 74 tools for internet-wide reconnaissance, exploiting web frameworks, stealing databases, harvesting credentials and managing botnets, and the agent was built to carry out up to 100,000 actions without human approval. The researchers said none of the individual techniques were new; combining them in one self-directed agent lowers the skill needed. Symantec found it through a honeypot built to look like an unprotected AI service, which recorded over 127,000 external requests from tens of thousands of unique addresses.

The practical lesson: if an AI endpoint you run is reachable from the internet without strong authentication, assume it will be found, and assume the finder may be an automated agent that tries every known exploit against it.

What are the warning signs in usage and billing data?

Most LLMjacking is discovered on the bill. You can find it much earlier by looking at usage per key, per model and per hour.

• Spend or token volume jumps on one key or project with no matching deploy, campaign or traffic change.
• New models appear. The attacker calls the largest or newest model your key can reach, often one your product never uses, or a different modality such as image generation.
• Usage at odd hours or in a flat, constant pattern. Real product traffic follows your users' day. Resold access often runs around the clock.
• Requests from unfamiliar sources. On cloud model services you can see the calling identity and network; on direct provider keys you may only see the key.
• Rate limit errors you did not cause, as your own traffic competes with the attacker's.
• A key that was "unused" starts working. Old keys from departed staff, ended projects or demos are the classic target.
• Provider notices. Some providers email when they detect a leaked key or abuse. Make sure those emails go to a monitored shared inbox, not one person.

The provider APIs make this measurable. Anthropic's Usage and Cost API returns usage in 1 minute, 1 hour or 1 day buckets, can be filtered and grouped by API key, workspace and model, and, per the docs, data typically appears within about five minutes of a request. On AWS, Amazon Bedrock model invocation logging records each call's model, token counts and the calling IAM identity, but it is disabled by default and has to be switched on. OpenAI's production best practices guide points to the usage dashboard, notification thresholds and spend alerts.

Are spend caps and rate limits a security control or only a cost control?

Both, with limits. A spend cap is a blast radius control. It does not prevent theft or detect it, but it bounds how much damage a stolen key can do before someone notices. That is a real security property, in the same way a daily withdrawal limit on a bank card is.

OWASP's Top 10 for LLM Applications lists this risk as LLM10:2025 Unbounded Consumption, which includes "Denial of Wallet," and recommends rate limiting, per-user quotas, timeouts, monitoring and anomaly detection, and a central model inventory as mitigations.

Where caps fall short:

• They do not stop data exposure. If the attacker reaches a gateway or an agent, the cap does nothing about prompts, logs or tool access.
• Abuse can stay under the cap. A careful attacker or a reseller spreads use across many stolen keys to stay below thresholds.
• A hard cap is also an outage. OpenAI's guide notes that a hard spend limit stops API traffic once tracked spend reaches the limit. If the attacker hits it first, your product goes down. That is often the right trade, but decide it in advance.

The answer is to use caps as one layer: set them per project or workspace rather than only at the organisation level, set alerts well below the cap, and pair them with per-key monitoring and short credential lifetimes. We cover the trade-offs in more depth in is an AI spend cap a security control for leaked API keys.

How do we inventory every AI provider key we have?

Start with the providers, then the places keys live, then the owners. The goal is a list with one row per key: provider, project or workspace, owner, where it is deployed, what it can do, when it expires, and when it was last used.

Step 1: list keys from each provider's admin API

Most major providers now let an organisation admin list keys programmatically.

For Anthropic, the Admin API lists keys with their status, owner and expiry. It needs an Admin API key, which only organisation members with the admin role can create. The docs note that each listed key includes expires_at (null if it never expires), a principal showing whether it acts as a user, a service account, or nobody (a legacy workspace key), and a scope showing whether it is bound to one workspace.

# List active API keys (Anthropic Admin API)
curl "https://api.anthropic.com/v1/organizations/api_keys?limit=100&status=active" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01"

Flag keys where expires_at is null, where principal is null (legacy workspace keys with no owner), and where scope is the whole organisation.

For OpenAI, the organisation Admin API exposes project API keys per project. The production best practices guide adds that admins can cap key lifetimes at organisation or project level, and use API Key Governance to restrict key creation to service account keys or user owned project keys, or to disable new keys entirely.

For AWS, long-term Amazon Bedrock API keys are IAM service specific credentials attached to an IAM user, so you can list them per user:

# List Bedrock long-term API keys for one IAM user
aws iam list-service-specific-credentials \
  --user-name bedrock-api-user \
  --service-name bedrock.amazonaws.com

For Google, list the API keys in each project and check which ones are restricted to the Gemini API:

gcloud services api-keys list --project=YOUR_PROJECT_ID

Step 2: find where keys are used in your own estate

Next, find every place your code and infrastructure reads an AI credential. Searching for the standard environment variable names is a good start, because SDKs pick them up automatically: ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY and AWS_BEARER_TOKEN_BEDROCK.

# Where does code, config or CI reference AI provider credentials?
git grep -nE 'ANTHROPIC_API_KEY|OPENAI_API_KEY|GEMINI_API_KEY|GOOGLE_API_KEY|AWS_BEARER_TOKEN_BEDROCK'

# Did a key get inlined into a built frontend bundle?
grep -rEl 'sk-ant-api|ANTHROPIC_API_KEY|OPENAI_API_KEY' dist/ build/ .next/ 2>/dev/null

# Which MCP and agent configs on this machine hold literal tokens?
grep -rlE '"(api[_-]?key|token|authorization)"' ~/.config .mcp.json 2>/dev/null

Repeat the search across your secrets manager, your CI variables, your hosting platform's environment settings and your gateway's configuration. Secret detection tools in pre-commit hooks and CI are a standard way to catch new keys before they land; the OWASP cheat sheet recommends them alongside a rule never to log secrets in plain text.

Step 3: attach an owner and a purpose to every key

A key without an owner will never be rotated. Anthropic's docs make the case for identity-backed keys: personal and service account keys stop working when that identity is removed from the organisation, so keys do not outlive the people or workloads that own them. Workspace keys, which belong to no one, are described as legacy.

Step 4: delete what nobody claims

After a short notice period, disable unclaimed keys first (disable is reversible on most providers), wait for anything to break, then delete. Our post on inventorying AI provider keys with admin APIs covers this step in more detail.

How do we move from long-lived keys to scoped, short-lived credentials?

A long-lived static key is the worst case: it works from anywhere, for as long as nobody notices. The move is in four stages, and each provider now supports at least some of them.

Stage 1: scope what you have

• One key per workload, per environment. Never share a key between staging and production or between two services. OpenAI's guide recommends separate staging and production projects with their own rate and spend limits.
• Bind keys to the smallest container. On Anthropic, create keys scoped to a single workspace. On Google, restrict a key to the Gemini API only and add application restrictions such as an IP allowlist. Google's docs warn that a key shared with other Google APIs will break Gemini requests if you restrict it to another API, so create a separate restricted key for Gemini.
• Restrict network origin where offered. IP allowlists turn a stolen key into a useless one if the attacker is calling from elsewhere.

# Restrict a Google API key to the Gemini API and to your server egress IPs
gcloud services api-keys update KEY_ID \
  --api-target=service=generativelanguage.googleapis.com \
  --allowed-ips=203.0.113.10,203.0.113.11

Stage 2: enforce expiry

Anthropic lets you choose an expiration when you create a key (3 hours, 1 day, 7 days, 30 days, a custom duration, or Never), and an organisation can set a maximum expiration policy that removes the Never option. Expiry cannot be changed after creation. OpenAI lets admins cap key lifetimes at organisation or project level. On AWS, you can stop anyone creating long-term Bedrock keys that last more than 90 days with an IAM condition:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:CreateServiceSpecificCredential",
      "Resource": "*",
      "Condition": {
        "NumericLessThanEquals": { "iam:ServiceSpecificCredentialAgeDays": "90" },
        "StringEquals": { "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com" }
      }
    }
  ]
}

Stage 3: replace keys with identity

This is the real fix. Instead of a secret string, the workload proves who it is with a token from an identity provider you already trust, and receives a credential that lasts minutes or hours.

• Anthropic Workload Identity Federation lets a workload exchange a JWT from AWS IAM, Google Cloud, or a standards compliant OIDC issuer such as GitHub Actions, Kubernetes service accounts, Microsoft Entra ID or Okta, for a short-lived Claude API access token that the SDK refreshes automatically. The docs say there is no sk-ant-api string to mint, distribute or rotate, and warn that the trust chain is only as strong as the identity provider's configuration.
• Amazon Bedrock short-term API keys last up to 12 hours or the session length, whichever is shorter, and inherit the permissions of the IAM principal that created them. AWS recommends them for production and says long-term keys are for exploration only. Better still, call Bedrock with an IAM role and no bearer token at all.
• Google auth keys are bound to a service account so requests run under that identity. Google's docs say that from 28 May 2026 all new API keys created in Google AI Studio are auth keys, restricted to the Generative Language API by default.
• GitHub Actions OIDC lets a workflow get short-lived cloud credentials scoped to a single job, with trust conditions on repository, branch and environment claims, so no cloud key is stored as a repository secret.

Here is a typical CI pattern that calls a model on Bedrock without any stored AI key:

# .github/workflows/eval.yml
permissions:
  id-token: write
  contents: read

jobs:
  eval:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-bedrock-invoke
          aws-region: us-east-1
      - run: python run_eval.py   # boto3 picks up the short-lived role credentials

Scope the IAM role to bedrock:InvokeModel on the specific models you use, and add a trust condition on the repository and environment.

You can also stop bearer token use entirely on identities that should only use IAM signing. AWS documents a deny policy for bedrock:CallWithBearerToken:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["bedrock:CallWithBearerToken", "bedrock-mantle:CallWithBearerToken"],
      "Resource": "*"
    }
  ]
}

Stage 4: keep real keys away from agents and clients

For agents, coding assistants and MCP servers, the strongest pattern is that the real credential never enters the agent's environment. A credential injecting proxy holds the key and adds it to outbound requests, while the agent sees only a local endpoint. The LiteLLM discussion on Hacker News made the same recommendation: run agents in sandboxes with network restrictions and use proxies so real keys never reach the agent.

For MCP specifically, prefer remote servers that use OAuth with narrow scopes over local servers configured with static tokens. The MCP security best practices say servers must not accept tokens that were not issued for them (no "token passthrough"), and recommend a minimal initial scope set with step-up authorization for privileged tools. A stolen narrow token is a much smaller problem than a stolen all-access key.

What about the gateway itself?

An AI gateway holds every provider key and sees every prompt, so it is your highest value AI asset. Keep it on a private network with no public admin interface, give each team its own virtual key and budget, redact authorization headers and tool outputs before logging, and pin its version. The October 2026 LiteLLM compromise was a malicious release, not a misconfiguration, so review gateway upgrades like any critical dependency.

What is the response playbook when a key is abused?

When usage spikes on a key you did not expect, move in this order. The order matters, because deleting first can break production and destroy evidence, and investigating first lets the bill grow.

1. Contain: disable the key. On Anthropic, Disable is reversible and the key reports status inactive; Delete is permanent. On AWS, deactivate a long-term Bedrock key with UpdateServiceSpecificCredential, and for short-term keys invalidate the session or attach the deny policy above. Google's docs say to create and deploy a replacement first, then disable the old key, and not to delete it until the new one is fully active.

   # Anthropic: deactivate a key (reversible)
   curl "https://api.anthropic.com/v1/organizations/api_keys/apikey_XXXX" \
     -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
     -H "anthropic-version: 2023-06-01" \
     -H "content-type: application/json" \
     -d '{"status": "inactive"}'
   
   # AWS: deactivate a long-term Bedrock API key
   aws iam update-service-specific-credential \
     --user-name bedrock-api-user \
     --service-specific-credential-id ACCA_EXAMPLE_ID \
     --status Inactive
   

2. Restore service with a new, better credential. Issue a replacement with expiry, scope and network restriction, or switch that workload to federation now. Deploy it.

3. Bound the spend. Lower the project or workspace cap temporarily and contact the provider's support about the fraudulent usage. Collect the evidence they will ask for.

4. Pull per-key usage for the window. On Anthropic, group usage by API key and model at hourly granularity:

   curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
   starting_at=2026-10-20T00:00:00Z&ending_at=2026-10-22T00:00:00Z&\
   api_key_ids[]=apikey_XXXX&group_by[]=model&bucket_width=1h" \
     -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
     -H "anthropic-version: 2023-06-01"
   

   On Bedrock, if invocation logging was on, this CloudWatch Logs Insights query from the AWS docs ranks callers by tokens:

   fields identity.arn as principal,
          input.inputTokenCount as inTokens,
          output.outputTokenCount as outTokens
   | stats sum(inTokens) as totalInput, sum(outTokens) as totalOutput, count() as calls by principal
   | sort totalInput desc
   

5. Find the leak source. Check where that key was deployed according to your inventory. Search Git history, CI logs, frontend bundles, gateway logs and MCP configs for it. If it came from a laptop, treat that machine as compromised and rotate everything on it, not just the AI key.

6. Check what else the attacker could reach. If the key lived in a gateway or agent, review prompts and tool outputs in that window for data exposure, and rotate every other credential that sat next to it.

7. Delete the old key once the replacement is confirmed and evidence is saved.

8. Fix the route and write it down. Close the leak path (move to a proxy, add log redaction, switch CI to OIDC), and add the key's new owner and expiry to the inventory.

A one-week hardening plan

If you have a week and a small team, this order gives the most protection per hour.

Common mistakes

• Rotating without revoking. Creating a new key does nothing if the old one still works. Disable it.
• Deleting before the replacement is live. You cause your own outage and lose the record of what the key did.
• Relying on the monthly invoice as a detector. By then the money is spent. Watch hourly usage per key.
• One key for everything. A shared key across environments and services makes it impossible to tell good traffic from bad, and impossible to revoke without breaking everything.
• Logging full requests in the gateway. Authorization headers and tool outputs in logs turn your observability stack into a key store.
• Trusting a hard cap as the whole defence. It limits loss; it does not stop theft or data exposure, and it can take your product down.
• Leaving legacy and orphan keys alive. Keys from former staff, old demos and finished experiments are what attackers find and test first.
• Static tokens in MCP configs on laptops. These are exactly what infostealers collect. Prefer OAuth based servers and short-lived tokens.

Fix it without waiting for upstream

LLMjacking often starts with a component you run rather than a key you leaked: an AI gateway, an MCP server or an inference server with a known vulnerability or a bad release. Those components are open source dependencies and container images like any other, and the same remediation habits apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What does LLMjacking mean?

It means using someone else's large language model access without permission, either with a stolen API key or cloud credential, or through an exposed model endpoint, gateway or MCP server. The victim pays for the compute and the attacker hides behind the victim's account.

How do hackers get OpenAI, Anthropic or Gemini API keys?

Mostly from places developers put them: public Git commits, frontend JavaScript bundles, mobile apps, .env files, CI logs, gateway logs, MCP config files on laptops, and hosting platform environment variables. Infostealer malware on developer machines and compromised packages that read environment variables are the other big sources.

How do I know if my AI API key has been stolen?

Look for a sudden rise in tokens or spend on one key, calls to models you do not use, round the clock usage, rate limit errors you did not cause, and activity on keys you thought were unused. Check per-key usage hourly through the provider's usage API or console, and make sure provider abuse notices reach a monitored inbox.

What should I do first if my API key is leaked?

Disable the key, deploy a replacement, then investigate. Do not just create a new key while the old one still works. Pull usage for the leaked key, find where it leaked from, rotate anything stored alongside it, and delete the old key once the replacement is confirmed.

Is it safe to put an AI API key in a frontend app?

No. Anything shipped to a browser or mobile device can be read. Call the model from your backend, or use a provider feature built for clients that issues short-lived, narrowly scoped tokens to verified app installs.

Do spend limits stop LLMjacking?

They limit the damage but do not stop it. A cap bounds how much a stolen key can cost before the provider cuts it off. It does not prevent theft, does not protect data the attacker can reach, and can cause your own outage when hit. Use caps together with alerts, per-key monitoring and short-lived credentials.

Are environment variables safe for AI API keys?

They are better than hard coding, but every system that sets or reads them holds a copy, including your hosting platform. Prefer fetching keys from a secrets manager at runtime, or better, using workload identity federation so there is no long-lived key at all. Rotate all of them if your platform reports an incident.

Can attackers abuse a self-hosted model without any key?

Yes, if the endpoint is reachable from the internet without authentication. Self-hosted inference servers, gateways and MCP servers are actively scanned for. Keep them on private networks, require authentication, and never expose admin interfaces publicly.

See how Safeguard would help

Safeguard does not replace your provider's key controls, your secrets manager or your billing alerts, and the steps above are where most LLMjacking defence happens. Where it helps is the component side: knowing which repositories and images carry an AI gateway, MCP server or inference library at a given version, matching those versions against vulnerability databases, ranking what is reachable, holding vulnerable versions back with policies and gates, and opening fix pull requests when a safe version exists (autonomous remediation is switched off by default). It does not claim to prevent LLMjacking.

This demo is a real Safeguard CLI session. You ask it to fix a vulnerable dependency, it reads the finding and advisory, asks before each command, edits the manifest, runs install and tests with your approval, and pushes nothing. The same flow applies when an advisory lands for the gateway or MCP server package in your AI stack and you need it upgraded across repositories quickly.

Click through it at your own pace, or open it full screen.

This demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which tools Claude can use. It is a working example of the pattern recommended above for MCP: an OAuth sign in and an explicit tool allowlist instead of a static token pasted into a config file.

Click through it at your own pace, or open it full screen.

This demo sets up the local runner on your own machine, approves it with a device code, and scans from the terminal. It is useful for scanning the projects and images on a box that runs AI services, without handing a long-lived credential to anything.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• Infosecurity Magazine: Symantec finds AI agent built for LLMjacking (21 Oct 2026)
• Cyber Security News: Railway security incident (22 Oct 2026)
• Hacker News: discussion of the LiteLLM 1.107.0 compromise
• TechTarget: Microsoft targets AI deepfake cybercrime network in lawsuit
• OWASP GenAI: LLM10:2025 Unbounded Consumption
• OWASP Secrets Management Cheat Sheet
• OpenAI: Production best practices
• Anthropic: Authentication (API keys, expiration, Workload Identity Federation, App Attest)
• Anthropic: Admin API
• Anthropic: Usage and Cost API
• Google: Using Gemini API keys
• AWS: Amazon Bedrock API keys
• AWS: Amazon Bedrock model invocation logging
• GitHub Docs: OpenID Connect in GitHub Actions
• Model Context Protocol: Security best practices

Last reviewed: 22 October 2026. Provider key features change often; check the linked provider documentation for current options and defaults.