Listen to this article
On November 2, Mandiant reported enterprise LLMjacking investigations in which fraudulent AI usage exceeded $100,000 in a single day. At some organizations, cumulative charges reached $1 million before access was revoked. These were observed charges across separate incidents, not a forecast for every exposed key. The report describes stolen or exposed cloud identities as the dominant entry route and illicit gateways that resell compromised model access.
The governance question is immediate: when a valid credential starts funding an unauthorized workload, which control can refuse it? Approving an AI provider is only the beginning. An enterprise also needs an approved relationship between the identity, the workload, the model, and the account paying for it.
A working key does not establish a legitimate purpose
Mandiant describes attackers testing exposed model keys with minimal single-token requests, keeping discovery below volume-based alerts. It also reports new identities and additional credentials used to preserve access. Our reading: an alert that waits for an expensive spike can miss the earlier decision point, when a credential gains or exercises authority outside its approved purpose.
Independent evidence comes from Wiz's October 30 investigation of developer-platform breaches. In two downstream cases, unauthorized checks started within 30 minutes of reported credential access. Low-volume traffic preceded larger bursts. Wiz recorded approximately 800,000 model calls over 30 hours in one case and 1.7 million over 13 hours in another. These totals include failed requests; the cases are not equal-duration experiments.
Source: Wiz, October 30, 2026. These are request counts, not charges, successful-call counts, or a controlled rate comparison.
A credential proves that a request can authenticate. Governance must establish why that request is allowed to spend.
Billing belongs inside the AI authority boundary
Wiz's separate October 20 investigation provides useful background outside this week's news window. Attackers linked their own external cloud projects to victims' billing accounts. The victims paid while prompts and model outputs remained outside their visibility. Wiz also observed weakened organization policies and legitimate billing administrators reduced to read-only access. This is a concrete example of why an AI inventory limited to internally hosted workloads can miss financial exposure.
Our recommendation is to treat a billing-link change like a production permission change. Record the project owner, business purpose, permitted provider, cost owner, and expiry. Require separate approval when a request adds an external project or expands spending authority. A successful login or a familiar provider name should not substitute for that evidence.
| Decision | Evidence to require |
|---|---|
| Issue a credential | Named owner, narrow permissions, workload binding, and expiration. |
| Attach a billing account | Verified project ownership and independent financial authorization. |
| Increase model access | Approved models, regions, usage limits, and a tested enforcement path. |
| Resume after exposure | Old access denied, replacement access tested, and persistence reviewed. |
Test the denial and the recovery before relying on either
Start with one real workload and a controlled test identity. Ask whether it can invoke an unapproved model, use a different region, create another credential, or attach a foreign project to the bill. Preserve the actual denial results. If a test unexpectedly succeeds, block the proposed permission change until the policy and its enforcement agree. A policy document alone cannot demonstrate the effective boundary.
Separate notification from enforcement. A budget email informs someone; a tested usage restriction constrains activity. Identify which limits your provider actually enforces, their scope, and any reporting delay. Exercise a safe threshold crossing and record what stops, what continues, and who receives the escalation. Set thresholds around the workload's expected behavior and business tolerance, with an accountable exception process.
Recovery needs the same discipline. Revoking the first exposed key should trigger a review of identities, sessions, derived credentials, billing links, and permission changes created during the exposure window. Test that retired access fails. Then test that replacement credentials support the legitimate workload without recreating the old reach. Give the recovery owner evidence to sign, rather than a checklist of commands that happened to complete.
Make those checks repeatable after changes to vendors, deployment pipelines, secrets storage, or model routing. Keep a known-good record of the authorized relationships and investigate drift against it. Operations and finance should share the same incident owner and stop criteria, so a suspicious usage pattern does not wait in the gap between a security ticket and a billing dispute.
Our take
AuthorityGate Keystone addresses the validation gap between approving a change and allowing it into production. Its configurable gates combine dependency checks, production-mirroring tests, recovery readiness, and named human approval. Applying that model to AI access means making permissions and spending relationships reviewable changes with measurable acceptance criteria. This is our governance interpretation, not evidence that Keystone prevented the reported attacks or a claim that it replaces cloud identity controls. The practical outcome is clear: authorize a bounded workload, prove its limits, and require fresh evidence when those limits change.
Sources
Go deeper
Every agent action, validated before it takes effect
AuthorityGate's newsletter breaks down real AI incidents and the governance failures behind them. Our configurable 8-gate validation model is how organizations keep a named human accountable for what their AI actually does.