Stolen AI Keys Are the New Shadow AI Bill

Most teams think of a leaked AI key as a security problem. It is also a billing problem. When someone steals an AI API key and uses it to run model requests, the account owner can end up paying for activity they never authorized.

Security professionals call this LLMjacking: the unauthorized use of stolen large language model credentials to access AI services at the owner's expense. Attackers can use the access themselves or resell it to others. Either way, the organization whose key was stolen may be left with unexpected usage charges.

October 2026 brought this risk into sharper focus. A series of incidents involving AI developer platforms showed how credentials stored outside an organization's direct control can become a route to both security exposure and financial loss.

What Happened in October 2026?

Some security professionals have started calling October 2026 "Black October." The name describes a series of incidents, not one confirmed coordinated campaign.

In its October 30 report, Wiz identified at least nine AI developer platforms that disclosed security incidents during the month: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode, and Northflank.

Wiz found that several incidents involved attackers targeting stored environment variables, particularly credentials that provided access to AI services. However, the incidents did not share one identified vulnerability or dependency, and the investigations were still developing.

One notable incident involved OpenCode. On October 17, the company disclosed unauthorized access to a legacy system in its Console service that may have exposed third-party AI provider keys stored by some users. OpenCode advised affected users to revoke their credentials.

The broader lesson is that AI credentials can be exposed through the platforms and development environments businesses rely on to build and operate AI applications.

When a Stolen Key Becomes a Large Bill

Wiz's investigation provides a clear example of how quickly credential theft can become expensive.

In one investigated case, attackers made approximately 800,000 Amazon Bedrock calls over 30 hours. Around 90% were successful. In another case, a stolen key was used for approximately 1.7 million calls over 13 hours, with more than one million successful requests.

Wiz estimated that the usage in these two cases likely exceeded $100,000 at list price. This is an estimate of usage value, not a confirmed customer invoice.

The attacks also showed how stolen credentials can move beyond the original breach. Wiz identified infrastructure associated with AI model resale services that had access to and tested the compromised keys. However, it could not definitively establish the relationship between those services and the original platform compromises.

The important point is that a stolen key can remain useful after the initial breach. Unless the credential is revoked, attackers may continue using it, testing it, or passing it to other operators.

Why This Is a SaaS Management Problem

AI keys often live in places that traditional SaaS inventories do not cover. A credential might be stored in an IDE plugin, CI pipeline, shared script, AI development platform, or integration connected to multiple services.

The employee who created the key may have left the company. The application may not be approved by IT. The team paying the bill may not even know which project is generating the usage.

Finance sees an unexpected charge. IT sees a credential without a clear owner. Both problems point to the same visibility gap: the organization does not have a reliable inventory of its AI tools, their users, and the people responsible for them.

Managing AI applications as part of the wider SaaS environment helps close that gap. It gives IT and finance a starting point for identifying unsanctioned tools, understanding ownership, and reviewing access when employees or projects change.

Eight Steps to Protect AI Keys and Control Costs

1. Inventory AI tools and credentials. List the AI provider accounts and applications used across the business. Review code repositories, CI pipelines, IDE plugins, shared scripts, and development platforms. Include tools purchased or connected through personal accounts for company work.

2. Assign an owner to every key. Record the accountable employee, team, project, and business purpose for each credential. Unowned keys should be investigated, rotated where necessary, and retired if they are no longer required.

3. Separate and scope credentials. Use different keys for different projects and environments. Apply the minimum permissions required and restrict access to the models and services each workload needs. Where supported, prefer workload identities over long-lived personal credentials.

4. Set provider-level spending controls. Configure budgets, usage limits, and alerts directly with AI providers. Set alerts below the maximum budget so teams have time to investigate unusual consumption. Make sure notifications reach someone responsible for responding.

5. Review unfamiliar usage. Check provider usage reports regularly. Investigate unexpected increases, unfamiliar models, unusual request volumes, or activity that does not match the project's workload. Usage anomalies should trigger investigation, not automatic assumptions of compromise.

6. Scan repositories and build environments. Use secret-scanning tools to identify exposed credentials in source code, configuration files, and build logs. If a key is exposed publicly or in an unauthorized location, revoke it and investigate where it may have been used.

7. Revoke credentials during offboarding. When an employee leaves or a project ends, review the AI keys and integrations they created. Revoke credentials that are no longer needed, transfer ownership of necessary workloads, and verify that dependent services continue working.

8. Respond to vendor incidents. If a platform storing your credentials reports a breach, identify every affected key and rotate it directly with the AI provider. Removing a credential from the affected platform does not necessarily revoke the original provider key.

Where Optystack Fits

Protecting AI credentials requires provider-level controls, secret scanning, and disciplined credential management. SaaS visibility is another important part of the process.

Optystack helps organizations discover SaaS and AI applications through spend, SSO, and browser activity signals. Its application inventory and Shadow AI risk ranking help IT teams identify unsanctioned tools and prioritize which applications need review.

This matters because an organization cannot properly review the ownership, access, and business purpose of an AI application it does not know exists. Optystack also supports renewal tracking and license reclamation, helping teams review subscriptions and remove unnecessary paid access as employees or projects change.

Optystack does not monitor individual API keys, detect credential misuse, or replace AI provider spending limits. Those controls should remain with the relevant providers and security tools. Its role is to improve visibility across the SaaS environment in which AI applications are being adopted.

You can start a free trial to explore AI application visibility or learn more about Optystack's Shadow IT discovery.

Conclusion

The October 2026 incidents demonstrate that AI API keys are valuable credentials, not just configuration details. When they are stored across development platforms, integrations, and employee-owned tools, they can become difficult to track and even harder to revoke quickly.

Organizations should combine credential security with broader SaaS visibility. Inventory AI applications, assign ownership, configure provider-level spending controls, and include credentials in offboarding and incident-response procedures.

A key that nobody knows exists is difficult to protect. Better visibility is the first step toward controlling both the security risk and the bill.