Cybersecurity briefing
/
When Stolen AI Access Becomes a Finance Problem
Stolen cloud credentials can run up huge AI bills. Learn how to tie model usage to owners and authorized work, and which control actually stops the spend.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
A stolen cloud credential can buy an attacker an expensive supply of AI, charged to somebody else's account. In research published November 2, Mandiant reported unauthorized model consumption exceeding $100,000 in a day in individual incidents, with accumulated charges reaching $1 million at some organizations before access was revoked. Those are observed charges, not a statement about final losses or the experience of a typical company.
The development puts AI spending inside the security perimeter. Companies need to establish who can consume models, what that consumption is meant to accomplish and how quickly they can interrupt it when the answer becomes unclear.
The permission to spend hides inside access
The technique, known as LLMJacking, turns access to large language models into a resale business. Mandiant describes operators pooling stolen access through illicit proxy services. In some investigated environments, attackers enabled model services that had not been enabled before the compromise.
That last detail changes the exposure assessment. A department that has never approved an AI project may still hold cloud permissions capable of creating an AI bill. An inventory of approved applications will miss that possibility if nobody examines the authority behind the accounts.
Security reviews should therefore distinguish permission to invoke a model from permission to enable a service, create another credential or raise a quota. These are different powers. Combining them in a broadly privileged workload identity gives a single compromise more room to grow.
Assign model access to a specific workload and business owner. Separate development from production, narrow the models and environments each identity can reach, and remove privileges that the workload does not need. A convenient shared credential makes attribution harder precisely when several teams are trying to explain an unexpected charge.
The same discipline helps ordinary operations. When a project ends, its credentials and consumption authority should end with it. Otherwise, the organization retains a spending channel whose original justification may have disappeared.
Give the consumption a business explanation
A rising token count cannot establish whether the company is growing, wasting money or funding an intruder. The useful evidence connects a request with the identity that made it, the agent or application involved, and the work it was authorized to perform.
Consider a hypothetical legal-document review service. A large batch of new contracts could explain an expensive afternoon. Repeatedly processing the same document after a failed completion check could produce a similar bill with very little useful output. Requests made with a copied credential from outside that service would require a security investigation. The total alone cannot distinguish them.
Geordie.ai develops security and governance software for organizations running AI agents across employee computers, cloud platforms and business applications. It discovers those agents, identifies their owners and maps the models, tools and data sources they can use. By observing their activity after deployment, it helps security and AI operations teams understand whether agents are operating as intended.
That operational record also provides financial context. Its Cost Intelligence capability links observed agent activity to token consumption, model choice and estimated spend. Teams can examine an expensive workflow in terms of the agent that ran it, the work it performed and the person responsible for it.
For cloud deployments, Geordie.ai connects through APIs and telemetry across AWS, Azure and GCP, including agent environments such as Amazon Bedrock. That can help establish what instrumented agents normally do and what their activity costs. It does not establish visibility into every stolen-key request made outside those agents. Provider access records and billing remain necessary, and exact collection coverage must be checked against the deployed architecture.
A practical reconciliation compares provider-reported consumption with the activity the organization can attribute. Differences may reflect reporting delays, pricing assumptions or uninstrumented legitimate applications. They deserve an explanation before anyone labels them fraud. Conversely, a complete-looking agent dashboard should not persuade finance to disregard charges that the dashboard cannot account for.
Keep enough identifiers to investigate that difference without collecting unnecessary document contents. Request times, workload identities, model identifiers and an accountable owner can be more useful for this purpose than another copy of the sensitive material being processed.
Decide what actually stops the meter
Alerts, usage quotas and enforced spending caps have different effects. An email warning somebody about a threshold does not, by itself, withdraw the permission generating the expense.
AWS documents a delay between resource consumption and budget notifications, during which additional charges can accrue. Google Cloud likewise distinguishes alerts-only budgets from enforced spend caps. Its caps cover specified eligible services within a single project, and enforcement is not instantaneous. Teams should inspect the control they actually configured rather than relying on the word “budget.”
Stopping consumption also has operational consequences. A limit shared by a test workload and a customer-facing application could interrupt both. Put financially sensitive workloads into scopes that permit a selective response, and agree with application owners which interruptions are acceptable.
For suspected credential theft, the response must address the identity and any additional access created through it. Reducing a quota may contain expense while leaving unauthorized access available. Cloud security teams need to investigate that access separately from finance's reconciliation of the charges.
The next AI budget review should include security and the people running the workloads. Ask them to trace a representative charge to authorized work, identify consumption they cannot attribute and demonstrate the permitted stop action in a controlled environment. Record how long the signal takes to arrive and whether the action affects unrelated services. Those results give executives a concrete basis for accepting the remaining financial exposure. A growing AI bill becomes manageable when somebody can explain the work behind it and exercise authority over what happens next.
