Security is a financial risk. When a cloud account is compromised, the damage is not only data exposure and incident response — it is a live, accelerating bill. This week a company we work with had a Google Cloud service account compromised. In two hours, the attacker ran roughly $12,000 of Gemini API requests, and the rate was still climbing. Left unchecked overnight, it would have been more than $50,000 in a day.
The breach was not caught by a security tool. It was caught by a spend anomaly. StackSpend flagged the abnormal Gemini spend within the hour, the customer killed the credentials and the API key, and the bleed stopped. This is the point where security and FinOps collide — and why a real-time spend layer is now a security control, not just a finance one.
Quick answer: how does a compromised cloud account turn into a runaway bill?
An attacker who obtains a valid cloud credential does not need to steal data to cause immediate financial harm. Modern cloud and AI services are metered and elastic, so a stolen identity can spin up expensive resources — most commonly GPU instances, crypto miners, or paid LLM APIs — and generate real cost in minutes. This pattern of hijacking someone else's cloud account to run large-language-model inference on their bill is now common enough to have a name: LLMjacking. The financial blast radius scales with how long the access goes unnoticed, which is why time-to-detection is the number that matters most.
The incident: anatomy of an LLMjacking attack
The attack followed a textbook privilege-escalation-to-monetization chain. None of the individual steps were exotic; the damage came from how fast they compounded.
| Step | What the attacker did | Why it mattered |
|---|---|---|
| 1. Initial access | Compromised an existing service account credential | A machine identity with standing permissions — no user MFA to stop it |
| 2. Privilege escalation | Used the service account to create a new IAM role for itself | Established durable, self-granted access independent of the original creds |
| 3. Enable the service | Turned on the Gemini / Generative Language API on the project | Unlocked a metered, high-value resource that was not previously in use |
| 4. Create a key | Generated a new API key | A clean, portable credential to drive inference at volume |
| 5. Monetize | Submitted a high volume of Gemini API requests | $12k in ~2 hours, accelerating — the actual financial damage |
The tell was not in the security logs the team was actively watching. It was in the cost curve: a project that normally ran a predictable daily figure suddenly had a new, expensive API firing thousands of requests off-hours. That shape — a service that was dormant yesterday driving material spend today — is exactly what cost anomaly detection is built to catch.
Why security tooling alone missed the window
Most security stacks are tuned for data exfiltration, malware, and known-bad indicators. They are excellent at those things. But an attacker using valid credentials to call a legitimate first-party API does not look like an intrusion to many of those tools — it looks like normal cloud usage. The requests are authenticated. The API is Google's own. Nothing is being stolen in the traditional sense.
What changed was the money. And money is a signal most security programs do not monitor in real time:
- Cloud-native billing is retrospective. GCP, AWS, and Azure billing data is built for reporting, not for same-hour exception handling. By the time a spike shows in a billing export or a monthly invoice, the two-hour window that mattered is long gone.
- Budget alerts fire too late. A monthly budget threshold that trips at 90% is useless against an attack that would blow through the entire budget before lunch.
- The spend was in a "new" line item. The Gemini API had just been enabled, so there was no baseline in the native tooling and no reason for a static alert to exist yet.
A spend layer that watches daily and intraday cost against a live baseline treats "a dormant service is now the biggest line item on the project" as a first-class anomaly — regardless of whether the traffic is authenticated or the API is legitimate. That is the gap between a security tool and a cloud cost anomaly detection layer, and it is why the two are complementary.
Security is a financial risk — for companies of every size
It is tempting to file this under "enterprise problem." The opposite is true. The economics of a compromised account are worst for smaller teams, because a single stolen credential can represent a larger share of the monthly budget and there is rarely a 24/7 SOC watching. Three structural shifts have made this a universal risk:
- Everything is metered and elastic. Usage-based pricing on cloud, AI, and data infrastructure means a stolen identity converts directly into uncapped spend. There is no physical limit to hit first.
- Machine identities outnumber humans. Service accounts, CI tokens, and API keys are the fastest-growing class of credential and the least likely to have MFA, rotation, or tight scoping. They are the preferred entry point.
- AI APIs are the new payload. GPU mining used to be the monetization step. Now paid LLM inference is easier, quieter, and often more lucrative per compromised hour — hence LLMjacking. Any project with a cloud AI service one API-enable away is a target.
The financial exposure is real and it is fast. An accelerating attack that reaches $50k/day is not a hypothetical — it is the trajectory the incident above was on when it was cut off. Treating cost as a security signal is no longer a finance nicety; it is part of the control plane.
What a spend layer actually gave the customer
The value was not a prettier dashboard. It was time. Specifically:
- A same-hour warning. The anomaly fired while the attack was still ramping, not after the invoice. That converted a potential five-figure-per-day loss into a contained two-hour event.
- A precise location. The alert named the provider, the project, and the specific service (Gemini) driving the spike — so the team knew exactly which credential and API key to revoke first, instead of hunting.
- A shape, not just a number. Because the spend was compared against a live baseline, "new expensive API, off-hours, accelerating" read as an exception immediately, even though the raw dollar figure was still small in the first few minutes.
That is the difference between detecting overspend and detecting it in time to act. The same anomaly engine that catches a runaway retry loop or a bad model-routing change catches a compromised credential monetizing your cloud account — because to the cost curve, they look the same. If you want the mechanics, see how AI cost anomaly detection works and the runbook for investigating an AI spend spike.
How to close this gap on your own stack
You do not need to rebuild your security program. You need to add cost as a real-time signal alongside it.
- Baseline every project and provider. Know what normal looks like per project, per service, per day. Anomaly detection is only as good as the baseline it compares against.
- Alert on shape, not just budget. Watch for new or dormant services suddenly driving spend, off-hours acceleration, and spend velocity — not only monthly budget thresholds.
- Route alerts where the team already is. A same-hour Slack alert that names the provider, project, and service is the difference between a two-hour incident and an overnight one.
- Scope and rotate machine identities. Service accounts should have least-privilege roles, no ability to grant themselves new ones, and short-lived credentials. This is the security control; cost monitoring is the tripwire when it fails.
- Make revocation fast. When the alert fires, the response is disable the credential, delete the rogue API key, and disable the newly enabled API. Rehearse it.
This is where security and FinOps stop being separate disciplines. The same cloud + AI cost monitoring loop that keeps engineering costs honest doubles as an early-warning system for account compromise. For the broader operating pattern, see cost incident response, from anomaly to resolved issue.
Practical takeaway
A breach is not only a security event — it is a financial one, and often the financial signal moves first. When an attacker uses valid credentials and legitimate APIs, the cost curve is frequently the earliest, clearest evidence that something is wrong. A real-time spend layer that baselines usage and alerts on abnormal, accelerating spend gives you the one thing that determines the size of the loss: time to act.
If your cloud or AI providers can be turned into a bill by a single compromised credential — and they can — then cost anomaly detection belongs in your security posture, not just your finance review. See AI cost anomaly detection and cloud cost monitoring for the workflow. For a related fast-moving cost attack, see Twilio SMS pumping fraud.
FAQ
What is LLMjacking?
LLMjacking is an attack where a threat actor uses stolen cloud credentials to run large-language-model inference on the victim's account, billing expensive AI API calls to someone else. It is the AI-era successor to cloud crypto-mining and is attractive because the traffic is authenticated and uses legitimate first-party APIs, so it often evades traditional security tooling.
How much can a compromised cloud account cost?
It depends entirely on time-to-detection, because the spend is uncapped and elastic. In a recent incident, a compromised Google Cloud service account ran about $12,000 of Gemini API requests in two hours and was accelerating toward a $50,000-per-day run rate before it was stopped. The financial damage scales with how long the access goes unnoticed.
Why don't security tools catch this kind of attack?
Because the attacker uses valid credentials to call a legitimate API, the activity looks like normal, authenticated cloud usage rather than an intrusion. Nothing is being exfiltrated. The clearest early signal is financial — a sudden, abnormal, accelerating spend curve — which most security programs do not monitor in real time.
How does cost anomaly detection help with security?
Cost anomaly detection compares live spend to a recent baseline per provider, project, and service, and alerts when spend is abnormally high or accelerating. A dormant service suddenly driving material spend off-hours is flagged immediately — regardless of whether the traffic is authenticated. That makes it an early-warning tripwire for account compromise, complementing (not replacing) your security stack.
Is this only a risk for large enterprises?
No. Smaller teams are often more exposed: a single stolen credential is a larger share of their budget, they rarely have 24/7 monitoring, and machine identities like service accounts and API keys frequently lack MFA, tight scoping, or rotation. Any account with metered cloud or AI services is a target.
What should I do the moment a spend anomaly indicates a breach?
Disable the compromised credential, delete any rogue API keys the attacker created, and disable the newly enabled API or service driving the spend. Then rotate related machine identities and review IAM roles for self-granted permissions. Speed matters more than completeness in the first hour.
References
- AI cost anomaly detection
- Cloud + AI cost monitoring
- AI Cost Anomaly Detection: How to Catch Spend Spikes Before the Invoice
- How to Investigate an AI Spend Spike: A Practical Runbook
- Cost Incident Response: From Anomaly to Resolved Issue
- Twilio SMS Pumping Fraud: Catching the Cost Before It Compounds
- Google Cloud IAM best practices
- Sysdig: LLMjacking research