For years, stolen cloud credentials have been the crown jewels of cybercrime. A single leaked AWS access key could hand attackers the keys to an entire company’s infrastructure, letting them spin up cryptomining rigs, exfiltrate databases, or hold systems hostage. Now, a new class of secrets has joined the target list: AI credentials. API keys for services like OpenAI, Anthropic, Google Gemini, and Azure OpenAI are being harvested, traded, and abused at an alarming rate. The reasons are strikingly similar to why cloud keys became so valuable, but the AI angle adds fresh incentives that make these credentials even more attractive to certain attackers. Understanding why hackers want your AI keys, and how to protect them, is quickly becoming an essential part of any security program.
Why AI Credentials Are the New Cloud Keys for Hackers
The most obvious motivation is money. Access to large language models isn’t free, and premium models can cost significant amounts per million tokens. When attackers steal a valid API key, they’re effectively stealing prepaid compute that someone else has to pay for. This has given rise to a thriving underground market for what researchers call “LLMjacking,” where stolen AI credentials are resold through proxy services that let anonymous buyers run unlimited queries on the victim’s dime. Victims often discover the theft only when a shocking invoice arrives, sometimes tens of thousands of dollars in unauthorized usage racked up in a matter of days.
Beyond raw cost theft, AI credentials offer attackers something cloud keys traditionally didn’t: anonymous access to powerful generative capabilities. Threat actors use hijacked accounts to generate phishing content, write malware, produce disinformation, or create material that violates the provider’s terms of service, all while the abuse traces back to the legitimate account holder. This laundering of identity is valuable in itself. Just as compromised cloud accounts were prized for hosting malicious infrastructure under someone else’s name, compromised AI accounts let attackers operate at scale while shifting both the financial burden and the reputational risk onto the victim.
The attack surface is also depressingly familiar. AI keys leak through the same channels cloud keys always have: hardcoded secrets committed to public GitHub repositories, credentials baked into mobile apps and client-side JavaScript, exposed environment files on misconfigured servers, and secrets scooped up by infostealer malware. Automated scanners crawl code repositories around the clock, and a leaked key can be discovered and abused within minutes of exposure. Because AI adoption has exploded faster than governance practices have matured, many organizations are sprinkling API keys across notebooks, prototypes, and side projects with far less discipline than they apply to their cloud credentials.
How to Lock Down Your AI Keys Before Attackers Strike
The first line of defense is keeping keys out of places they don’t belong. Never hardcode API keys in source code, and never ship them in client-side applications where anyone can extract them from the bundle. Store secrets in a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or your platform’s equivalent, and inject them at runtime through environment variables or secure configuration. Complement this with automated secret scanning in your CI/CD pipeline using tools like Gitleaks or TruffleHog, and enable push protection on your repositories so a key never lands in git history in the first place. Once a secret has been committed, treat it as compromised and rotate it immediately, since removing it from the latest commit does not remove it from history.
Next, apply the principle of least privilege and limit the blast radius of any single key. Most AI providers now support scoped keys, per-project keys, and granular permissions, so avoid using one master key across your entire organization. Create separate credentials for each application, team, and environment, and restrict each one to only the models and endpoints it genuinely needs. Set hard spending limits and usage quotas at the provider level so that even a stolen key can’t generate a catastrophic bill. Rotating keys on a regular schedule, and immediately when staff leave or a device is lost, further narrows the window of opportunity for an attacker holding an old credential.
Finally, assume that prevention will occasionally fail and invest in detection. Monitor API usage for anomalies: sudden spikes in token consumption, requests from unfamiliar geographic regions, calls to models your applications never use, or activity at odd hours. Configure billing alerts with thresholds low enough to catch abuse early rather than at month’s end. For enterprise deployments, route AI traffic through a gateway or proxy that provides centralized logging, rate limiting, and the ability to revoke access instantly. Having a documented incident response plan for credential compromise, including who rotates the key, who reviews the logs, and who contacts the provider, turns a potential disaster into a manageable event.
AI credentials have inherited the target status that cloud keys have held for a decade, and for good reason: they represent real money, powerful capabilities, and a convenient way for attackers to hide behind someone else’s identity. The good news is that the defenses are well understood, because they’re largely the same disciplines that mature organizations already apply to cloud secrets. Keep keys out of code, scope them tightly, cap their spending power, watch their usage, and be ready to rotate them at the first sign of trouble. Companies that treat AI keys with the same seriousness as their most sensitive cloud credentials will avoid the painful invoices and reputational damage that early victims of LLMjacking have already experienced. The attackers have adapted quickly; your security practices need to keep pace.
