LLMjacking and LLM API Key Security Guide

API keys for large language model (LLM) providers and cloud AI services have become some of the most sought-after credentials on the internet. With one, an attacker can run expensive models at your cost, resell access, bypass the provider's safety controls on their own account, or read the prompts, files and fine-tuned models attached to your account. This abuse is often called LLMjacking. AI keys are also unusually easy to leak: they are created by individual developers and data scientists, pasted into notebooks and front-end code, and embedded in tools and plugins. This guide explains how LLM credentials are stolen and abused, and how to manage them properly.

Key takeaways

Treat model provider keys and cloud AI credentials as high-value secrets: they carry direct financial exposure and access to data.
The main leak routes are code and notebooks, client-side applications, developer tools and plugins, and compromised cloud credentials.
Route model access through a central AI gateway so teams and applications authenticate with their own identities and never hold provider keys.
Spend limits and usage monitoring are security controls: unusual cost is often the first sign of theft.

What LLMjacking looks like

Security researchers have described attackers using stolen cloud credentials to enable and invoke hosted models, then selling access through reverse proxies. The AI LLM hijack breach and the Azure OpenAI hacking-as-a-service case are examples covered on our breaches page. Typical steps are:

Obtain a cloud access key or provider API key, usually leaked in code or harvested by malware.
Check which AI services and models the credential can use.
Enable model access or raise quotas where permissions allow.
Run large volumes of requests, often for resale or for content the attacker cannot generate on their own accounts.

The victim discovers it through a large bill, quota exhaustion or a provider abuse notice.

How AI credentials leak

Notebooks and scripts shared or committed with keys in cells.
Front-end and mobile apps calling model APIs directly with an embedded key. The Google API keys and Gemini exposure showed keys in client code gaining new, sensitive capabilities.
Developer tools and plugins: the JetBrains Marketplace campaign used malicious AI plugins to steal AI API keys.
Compromised AI packages: the LiteLLM PyPI breach and Mastra npm backdoor targeted credentials in AI development environments.
Agent platforms: the Moltbook breach exposed AI agent keys at scale.
Training and public data sets: researchers found nearly 12,000 live secrets in a public data set used for LLM training.

Controls

Centralise model access

Use an internal AI gateway or proxy that holds provider credentials and exposes model access to internal consumers.
Consumers authenticate to the gateway with their own identity (SSO for people, workload identity for applications), so access can be attributed, limited and revoked individually.
Apply per-team and per-application rate limits, budgets and model allowlists at the gateway.

Prefer identity over keys

For cloud-hosted models, use cloud IAM roles and managed identities rather than provider API keys where supported. See the Cloud Workload Identity Guide.
Restrict which identities can enable models, change quotas or create provider keys.

Manage remaining keys properly

Create keys under organisation accounts, not personal ones; one key per application and environment.
Scope keys to specific projects and models where the provider allows; set usage limits and expiry.
Store in a secrets manager; never in notebooks, front-end code or images. See the API Key Management Guide.
Add AI provider key formats to secret scanning across code, notebooks, CI/CD and collaboration tools.

Monitor usage and spend

Set budget alerts and hard limits per project.
Alert on requests from unknown networks, new models being enabled, sudden volume increases and use outside business patterns.
Review cloud audit logs for AI service enablement and quota changes.

Keep keys out of client applications

Call model APIs from a backend that authenticates the user, never directly from browsers or mobile apps with a shared key.

Responding to a stolen AI credential

Revoke the key or disable the cloud credential immediately.
Review usage logs to scope abuse and any data accessed (files, fine-tuned models, stored prompts).
Check for changes attackers made: new keys, enabled models, raised quotas, new users.
Contact the provider about fraudulent charges.
Fix the leak source and move to gateway or identity-based access.

Practitioner checklist

Inventory AI provider accounts, keys and cloud AI services across the organisation.
Stand up a central AI gateway and move teams off personal and shared provider keys.
Use cloud IAM for hosted models; restrict model enablement and quota changes.
Scope, vault and expire remaining keys; scan for leaks.
Set budgets, limits and usage anomaly alerts.
Keep keys out of client-side code.
Maintain a stolen-AI-credential response procedure.

Standards and references

OWASP Top 10 for LLM Applications (2025): LLM10 Unbounded Consumption, LLM03 Supply Chain
OWASP Non-Human Identities Top 10 (2025): NHI2, NHI7
MITRE ATLAS

LLM Provider API Key Security and LLMjacking Guide