LLM Provider API Key Security and LLMjacking 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 usually 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, typed into IDE plugins and stored by agent frameworks. This guide explains how LLM credentials are stolen and abused, how to replace keys with identity where providers allow it, how to manage the keys that remain, and how to detect and respond to theft. It is written for platform, cloud security, AI engineering and secrets management teams.

Key takeaways

• AI keys are high-value secrets. They carry direct financial exposure and access to data: Sysdig estimated a worst-case cost of over $46,000 per day for one stolen cloud credential in 2024, and over $100,000 per day with newer models.
• The leak routes are familiar. Code and notebooks, client-side applications, IDE plugins, compromised AI packages, agent platforms and stolen cloud credentials account for the incidents we track.
• Identity beats keys. Route model access through a central AI gateway or cloud IAM so teams and applications authenticate as themselves and never hold provider keys; disable key-based access where the platform allows.
• The gateway becomes the crown jewel. An AI gateway holds every provider key behind it, so it must fail closed, have no default admin key and stay off the open internet.
• Spend and usage monitoring are security controls. Unusual cost, new models in use and disabled invocation logging are often the first signs of theft.

What LLMjacking looks like

Sysdig's Threat Research Team named LLMjacking in May 2024 after watching attackers use cloud credentials stolen from a system running a vulnerable version of Laravel (CVE-2021-3129) to reach models hosted on AWS Bedrock. The attackers' script checked credentials against ten AI services, including Anthropic, AWS Bedrock, Azure, GCP Vertex AI, Mistral, OpenAI and OpenRouter, and Sysdig found references to an open source "OAI Reverse Proxy" that lets an operator sell access to a pool of stolen accounts without exposing the keys. Our LLMjacking 2024 to 2026 analysis and the Microsoft Azure OpenAI Abuse 2025 case follow the pattern since, and the LLMjacking campaign breach analysis tracks how stolen cloud credentials are resold. Typical steps are:

1. Obtain a credential: a cloud access key or provider API key, usually leaked in code or harvested by malware.
2. Check what it can do: Sysdig saw attackers send deliberately invalid requests (max_tokens_to_sample set to -1) so that a ValidationException, rather than AccessDenied, confirmed model access without running a real prompt.
3. Check or disable logging: attackers called GetModelInvocationLoggingConfiguration, and in later attacks DeleteModelInvocationLoggingConfiguration, to hide prompts and responses.
4. Enable more models: in 2024 Sysdig saw ListFoundationModels, GetFoundationModelAvailability and PutFoundationModelEntitlement used to switch on models. AWS now documents that access to many Bedrock models "is enabled by default with the correct AWS Marketplace permissions", which removes that step for a credential with those permissions.
5. Consume and resell: run large volumes of requests, often through a reverse proxy, for resale or for content the attacker cannot generate on their own accounts. Sysdig counted more than 85,000 Bedrock API requests over several months, 61,000 of them in a three-hour window on 11 July 2024.

Microsoft's Digital Crimes Unit describes the same business model in its Storm-2139 case: members "exploited exposed customer credentials scraped from public sources" to access generative AI services, "altered the capabilities of these services and resold access". MITRE ATLAS names the techniques: Valid Accounts (AML.T0012), Unsecured Credentials (AML.T0055), Cost Harvesting (AML.T0034) and AI Service Proxies (AML.T0008.005). The victim usually discovers it through a large bill, quota exhaustion or a provider abuse notice. See the MITRE ATLAS Guide.

Which credentials are at stake

Google's documentation makes the risk of unrestricted keys explicit: keys without API restrictions "can be used with all APIs that accept keys", and keys without application restrictions "can be used from anywhere". The Google API Keys Exposure 2026 showed what that means when a new AI API is switched on: existing unrestricted keys embedded in websites and apps gained Gemini access.

How AI credentials leak

• Code, notebooks and configuration files: keys committed in notebook cells and .env files. In the xAI API Key Leak 2025, a developer's key committed to a public repository stayed valid for about two months and could reach unreleased models.
• Front-end and mobile apps: apps calling model APIs directly with an embedded key, which is public by definition.
• Public data and archives: Truffle Security found 11,908 live secrets in one Common Crawl archive used for LLM training. See 12,000 Live Secrets in LLM Training Data 2025.
• Developer tools and plugins: the JetBrains Marketplace AI Plugin Campaign 2026 used 15 working AI assistant plugins to forward the provider keys developers typed into them.
• Compromised AI packages: the LiteLLM PyPI Package Breach 2026 harvested variables such as OPENAI_API_KEY and ANTHROPIC_API_KEY, and the Mastra npm Supply Chain Attack 2026 put a remote access trojan on developer machines and CI runners where such keys live.
• Agent platforms and hosts: the Moltbook Database Exposure 2026 exposed 1.5 million agent API tokens, and the Carbonato Botnet 2026 made AI API keys its top theft priority and used them to run its own LLM gateway. Hosted platforms that store customer keys are targets too, as the OpenCode Console breach and the Railway breach showed in 2026.
• Stolen cloud credentials: the original LLMjacking case started with a server vulnerability, not an AI key leak; any cloud credential with model permissions is an AI credential.

OWASP's NHI Top 10 covers the underlying weaknesses: NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI and NHI7 Long-Lived Secrets. See the Top 10 Secrets Management Mistakes.

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. OWASP's LLM10 Unbounded Consumption recommends "rate limiting and user quotas" and monitoring resource use.
• Harden the gateway itself. In the LiteLLM MCP Auth Bypass 2026, a failed token check fell back to an authenticated session, attackers harvested provider keys, and Wiz found internet-facing gateways still accepting the default master key.

Prefer identity over keys

• For cloud-hosted models, use cloud IAM roles and managed identities rather than provider API keys where supported. On Azure, local authentication can be disabled with the policy "Azure AI Services resources should have key access disabled" or the disableLocalAuth property; Microsoft notes the gateway can accept old keys for "up to several hours", so test with an old key before declaring it done.
• On AWS, prefer short-term Bedrock API keys, which last "up to 12 hours" and inherit the permissions of the IAM principal that generated them, over long-term keys, which create an IAM user.
• Restrict which identities can enable models, subscribe through AWS Marketplace, change quotas or create provider keys. AWS describes blocking model access with service control policies or IAM policies until it is approved. See the Cloud Workload Identity Guide and the AI Infrastructure Workload Identity Guide.

Manage remaining keys properly

• Create keys under organisation accounts, not personal ones; one key per application and environment (NHI9 NHI Reuse).
• Scope keys to specific projects, APIs and models where the provider allows; on Google Cloud, add API and application restrictions to every key; set usage limits and expiry.
• Store keys in a secrets manager; never in notebooks, front-end code, container images or plugin settings. See the API Key Management Guide and the Secrets Management Guide.
• Add AI provider key formats to secret scanning across code, notebooks, CI/CD and collaboration tools, and route alerts to someone who can revoke, not only the developer who leaked the key.

Keep keys out of client applications and untrusted tools

• Call model APIs from a backend that authenticates the user, never directly from browsers or mobile apps with a shared key.
• Approve IDE plugins and AI coding tools before developers enter keys into them, and keep a record of where each key has been entered. See the AI Coding Agents Security Guide.
• Pin and verify AI framework dependencies; OWASP's LLM03 Supply Chain covers compromised packages and plugins. See the Malicious Package and Dependency Confusion Guide.

Detection and monitoring

AWS logs Bedrock runtime operations such as InvokeModel, Converse and ConverseStream to CloudTrail as management events, but prompts and responses are only captured if model invocation logging is configured. Agent runtime calls such as InvokeAgent are data events that need advanced event selectors.

See the Cloud Logging and Audit Trail Guide.

Responding to a stolen AI credential

1. Revoke first: disable the key or cloud credential immediately; for Bedrock long-term keys, deactivate or delete the service-specific credential; on Azure, move the workload to Entra authentication and disable local authentication.
2. Scope the abuse: review usage and invocation logs for volume, models used and any data accessed (files, fine-tuned models, stored prompts).
3. Hunt for persistence: new keys, new IAM users, enabled models, Marketplace subscriptions, raised quotas, disabled logging.
4. Contact the provider about fraudulent charges and abuse reports.
5. Fix the source: remove the key from code, history, images and tools; find how it leaked; move the workload to gateway or identity-based access.

See the Leaked Credential Response Playbook and the Cloud Credential Compromise Playbook.

Common failure patterns

• Personal keys in production: a developer's key becomes the application's key, then leaks with the developer's repository, as in the xAI case.
• Alerts that reach only the leaker: a scanner emails the developer but nobody with authority revokes the key.
• Unrestricted keys meeting new APIs: a key intended as a public identifier silently gains AI access when a project enables a new service.
• Cloud credentials not treated as AI credentials: teams lock down provider keys while a broad IAM user key can invoke every hosted model.
• An exposed, default-configured gateway: the control meant to centralise keys becomes a single place to steal all of them.
• No spend ceiling: budgets alert but do not stop usage, so the first real control is the invoice.
• Logging that attackers can switch off: invocation logging is configurable by the same principals that use the models.

Framework mapping

This is an indicative alignment prepared by NHI Mgmt Group, not an official mapping. IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls (control level) and a published ISO/IEC 27001:2022 Annex A list.

See the OWASP Top 10 for LLM Applications Guide.

Metrics that show progress

Implementation roadmap

See the Shadow AI Discovery Guide to find unmanaged AI accounts.

Practitioner checklist

• Inventory AI provider accounts, keys and cloud AI services across the organisation.
• Stand up or harden a central AI gateway and move teams off personal and shared provider keys.
• Use cloud IAM for hosted models; disable key-based access where the platform allows.
• Restrict who can enable models, subscribe to them, change quotas or create keys.
• Scope, vault and expire remaining keys; restrict Google API keys by API and application.
• Scan code, notebooks, CI/CD and chat for AI keys, with alerts routed to someone who can revoke.
• Set hard spend limits and usage anomaly alerts.
• Enable and protect model invocation logging; alert when it is changed.
• Keep keys out of client-side code and unapproved plugins.
• Maintain and rehearse a stolen-AI-credential response procedure.

Standards and references

• OWASP GenAI Security Project: LLM10:2025 Unbounded Consumption
• OWASP GenAI Security Project: LLM03:2025 Supply Chain
• OWASP: Top 10 Non-Human Identities Risks 2025
• MITRE ATLAS: ATLAS data repository
• AWS: Amazon Bedrock API keys
• AWS: Access Amazon Bedrock foundation models
• AWS: Monitor Amazon Bedrock API calls using CloudTrail
• Microsoft Learn: Disable local authentication in Foundry Tools
• Google Cloud: Manage API keys
• Sysdig: LLMjacking: Stolen Cloud Credentials Used in New AI Attack
• Sysdig: The Growing Dangers of LLMjacking: Evolving Tactics and Evading Sanctions
• Microsoft: Disrupting a Global Cybercrime Network Abusing Generative AI

Related NHI Mgmt Group resources: API Key Management Guide · AI Infrastructure Workload Identity Guide · Shadow AI Discovery Guide · Secrets Management Guide · LLM Security Guide