Unexpected AI Bills? Understand LLMJacking and Stolen Access

An unexpected AI bill needs investigation at the credential and usage level, rather than only a count of employees trying a new model. One risk is LLMJacking: outsiders abusing an organization's access to model or cloud services.

A November 2, 2026 report from Google Threat Intelligence and Mandiant describes incidents across several sectors and substantial fraudulent charges at affected organizations. Those are investigation findings, not a prediction of every company's losses.

How this differs from an ordinary AI subscription

Application subscriptions and API consumption are separate cost categories. API charges may depend on requests, tokens, models, or other provider-specific resources. Stolen credentials can generate usage within the same project as legitimate team work.

Imagine a test project's key becoming publicly accessible. Reducing subscription seats may do nothing to stop requests using that key. Access and usage need their own investigation.

Signals worth checking

These signals do not prove theft. A legitimate automation loop can also generate unexpected costs. Review logs, job ownership, and permissions before calling it a breach.

Budget alerts are different from enforced limits

A budget notification tells you that usage passed a threshold. Do not assume it automatically stops the service. Ask whether your provider offers an enforced limit, its scope, and any reporting delay.

Separate development and production access for new projects. Grant only the required permissions and models, record an integration owner, and set an expiry for trial access. Verify dashboard controls against the documentation for the actual provider you use.

Responding to suspected stolen access

Have the account operator restrict or revoke suspicious credentials. Preserve logs and billing details, identify affected integrations, and rotate relevant access. Coordinate incident and billing review with the provider without assuming refunds are automatic.

Removing a key from code does not invalidate copies already in circulation. Disable the old key and store its replacement appropriately. Check for additional access created during the incident.

Keep a useful inventory

For each integration, record the project, purpose, owner, permissions, cost measurement, and stopping procedure. Business owners do not need to inspect every request, but they should know who can explain unusual spending.

This complements auditing the team's AI subscriptions. Unused seats and abused access need different responses even when both appear as waste.

If AI integrations are accumulating without clear access ownership, we can start with an inventory and usage monitoring.

Incident information checked November 10, 2026. Billing controls vary by provider and must be verified for the account in use.

Cover photo: Jakub Żerdzicki on Unsplash, used under the Unsplash License. This is an illustrative stock photo, not documentation of the incident, featured product, or a test result.