Every request was authorized. That was the problem.

The pipeline that built a mining farm

It’s 7:40 on a Monday, and you’ve barely touched your coffee when Finance pings you:

“Hey, quick one: why do we have a fleet of GPU machines running in a region we don’t use?”

Your first thought is that the report is wrong. It isn’t. On Friday night someone spun up a batch of the most expensive GPU machines your cloud provider sells, in a region none of your teams has ever touched, and they’ve been running flat out all weekend.

You go through the usual checklist. No one hacked through the firewall. No rogue login; every call came from a valid identity, and nobody went beyond their permissions.

Then you find it. The identity belongs to your CI/CD pipeline, which someone gave Contributor rights across the whole subscription a year ago because releases kept failing on permissions. Its secret ended up in a build log that far too many people could read. Whoever picked it up did exactly what the pipeline was allowed to do. They created resources, just not yours, and built a crypto-mining farm on your bill.

What bothers me most is this: for a whole year, the pipeline deployed the same three services to the same two regions every other week. Then, one weekend, it set up a fleet of GPU machines in a new region at midnight, and nothing in the system stopped to consider whether that made sense. The role was stated as “create resources”, so the platform agreed.

The AI platform that started working for someone else

That first story is one the industry knows well. The newer version is worse.

Different company, different Monday. This time the spike is on the enterprise AI platform, which usually runs at a steady, almost boring rate. On Saturday afternoon, its cost line went nearly vertical and stayed there. The checks came back the same: no break-in, valid authentication, nothing outside the granted role.

This time the identity was a service principal with owner-level access, again set up that way “to keep things simple.” The attacker didn’t need to build anything. They deployed new models, listed the access keys, and ran inference at a volume the real application had never come close to. The first attacker took raw processing power. This one took the company’s AI capacity and used it to generate, reason, and act for someone else, while the company paid for every token.

Side by side, the story is the same. Nobody broke in; someone logged in. Every operation was allowed by the role, the workload was obviously wrong, and the security stack said yes at every step.

Both stories are composites drawn from real enterprise incidents, anonymized here.

When compute stopped belonging to an application

Compute used to be tied to an application. If you knew the app, you had a decent idea what the machine would do and who should be touching it. Compute-as-a-Service (CaaS) broke that link, for good reasons: compute is now elastic, programmable, and consumable on demand. But once compute can be consumed on its own, it can be stolen on its own too. Authorization by itself can’t tell your workload apart from someone else’s workload running under your name.

So the threat has shifted from stolen data to stolen compute (the first story) to stolen intelligence (the second).

The industry data points the same way. The Cloud Security Alliance’s Top Threats to Cloud Computing 2026 report ranked inadequate identity and access management as the number one cloud threat, displacing misconfiguration, and two AI-related threats made the list for the first time. SpyCloud’s 2026 Identity Threat Report found that compromised non-human identities, service accounts, API keys, and tokens were the primary entry point for 31% of incidents, nearly twice the rate of phishing (17%).

None of this is brand new. Resource hijacking, denial-of-wallet, and LLMjacking are well documented, and MITRE ATT&CK lists Cloud Service Hijacking (T1496.004) with LLMjacking as an example. It also notes that conventional controls can’t easily prevent these attacks because they abuse features that work exactly as designed.

Compute is the new currency

In a March 2024 interview, Sam Altman has called compute “the currency of the future.” He meant it as a statement about value. I think it’s also a warning. If compute is currency, someone is already trying to steal yours.

Neither attacker was after files. They were after something they could spend. Compute can be drawn on instantly through an API and converted into cryptocurrency, content, code, or automated actions, and stolen AI access is even resold. Every GPU-minute and token has a price. And the platform spends it for whoever holds the keys, checking that the credential is valid, not who benefits. Seen that way, an over-privileged service principal is a signed blank check on the company bank account.

What your bank already knows about you

Most of us have had a text like this:

“Did you just try to spend $2,400 at an electronics store in another country? Reply YES or NO.”

Your card number was right, your PIN was right, and you had plenty of credit. By the logic most cloud platforms use, that purchase should have gone straight through.

It didn’t, because your bank knows how you spend. It knows where you shop, roughly how much you spend, and that it’s usually weekday lunchtimes, not twenty purchases at 3 a.m. after a $1 “test” charge. When something falls outside that pattern, it doesn’t send you a report next month. It holds the transaction and asks you to confirm. Your identity was never the question. The bank is protecting you from someone else using it.

Your compute has no fraud desk

Both identities in the stories had clear patterns sitting in the telemetry. When the attackers completely broke those patterns, nothing stopped the spending, and nobody was asked to confirm anything. The organizations found out after the money was gone.

With AI workloads, that gets expensive fast. As early as 2024, security researchers at Sysdig estimated that LLMjacking can cost a victim more than $46,000 a day, rising to over $100,000 a day on the most capable models. That’s thousands of dollars every hour, far faster than a budget alert can be read, escalated, and acted on.

None of us would accept a bank that let a stolen card run until the end of the month, yet that’s roughly how most organizations protect their compute today.

“But we already have controls for this”

You do, and you should keep using every one of them. The trouble is that each answers only part of the question. Identity proves who is asking, but not that a valid credential has been stolen. Role-based access control (RBAC) defines what an identity may do, but not why or for which workload. Network controls shrink the attack surface but can’t spot abuse that comes through an allowed path. Budgets and cost anomaly detection alert you, but an alert isn’t a block. Threat detection flags suspicious activity, but someone still has to connect it to identity, usage, and cost.

This year, the big cloud providers have started offering hard spending caps. Google Cloud introduced Spend Caps in preview in July, and AWS began rolling out project spend limits to a limited set of customers in September. Both pause usage once a limit is hit. That’s real progress. But a spending cap is a credit limit, not a fraud desk. It stops everything in the project,  including legitimate production work; it acts on estimated spend that can lag; and it has no idea who is spending or why. Your bank doesn’t cancel your card when you reach your limit. It declines the one transaction that doesn’t look like you.

Each control does its own job well. What’s missing is something that combines them into a single decision.

The question has to change

Cloud authorization still asks: can this identity perform this operation?

In a Compute-as-a-Service world, it has to ask what your bank asks about every transaction: should this identity use this resource, for this workload, from this context, at this scale and cost, right now? Should a pipeline create GPU machines in an unused region at midnight? Should an owner deploy an unapproved, expensive model from a country you don’t operate in? Today the answer is usually yes, because the role allows it.

So the question I’d put to every CISO, cloud architect, and CFO is this: when does a valid credential become an invalid workload?

Answering it means evaluating authorization continuously, not granting it once. It has to consider context, not just identity; turn signals into decisions instead of alerts; and treat cost as a security signal. We call this direction Context-Aware Dynamic Authorization. Think of it as a fraud desk for your compute.

If that sounds like Zero Trust, it’s related. Zero Trust taught us to keep checking who gets in. It has rarely been applied to consumption: what an identity spends once it’s in, and whether that still fits the workload it was trusted for. This doesn’t replace IAM, RBAC, or Zero Trust. It adds context  get about and how resources are actually used.

Two layers of control, not one

Your bank’s fraud protection works on two levels. The bank sets rules that apply to every customer, such as blocked merchants and daily limits. But it’s you, the cardholder, who knows what normal looks like for your card, which is why the bank asks you to confirm and not someone in a call center.

Compute needs the same split. Central IT and security should set global guardrails that apply everywhere and stop the obvious before it happens: which regions can be used, which GPU machine types and AI models are approved, no long-lived secrets or shared access keys, and no standing Owner or Contributor rights for pipelines. Those rules alone would have stopped the GPU fleet in an unused region before anyone created it.

But central IT can’t know what normal looks like for every workload. Resource owners can. Every significant compute or AI resource should have a named owner who states what it’s for, which identities should use it, and roughly how much it should consume. That owner approves exceptions, and confirms or rejects usage when it drifts outside the pattern. The owner of the AI platform in the second story would have known straight away that nobody on their team deploys new models on a Saturday afternoon.

Global guardrails block what nobody should ever do. Resource-level ownership catches what this particular workload should never do. You need both.

What about AI agents?

So far I’ve talked about attackers. But the fastest-growing version of this problem may not need one.

AI agents spend compute on their own, under perfectly valid identities that nobody stole. When one gets stuck in a loop, misreads its task, or a malicious input nudges it into doing far more work than it should, the bill climbs just as fast as in an LLMjacking attack. OWASP now lists Unbounded Consumption (LLM10), including denial-of-wallet, among its top 10 risks for LLM applications. This is “valid credential, invalid workload” in its purest form.

There’s a twist, too. The same agentic AI can also help protect compute, because it watches continuously and acts faster than a human escalation chain. That raises a hard question: how much should an agent decide on its own, and how do you keep its actions explainable, auditable, and reversible? Your bank answers that its fraud system acts automatically but asks you to confirm before anything is final. Give an agent too little authority, and it can’t contain anything in time. Give it too much, and you’ve handed your environment to a system you can’t fully account for.

So where do you start?

There isn’t a one-size-fits-all answer. It depends on your cloud estate, your AI workloads, your risk appetite, and how well your security, platform, and finance teams work together. A few honest questions are a good place to start:

• Do we know which identities can spend our compute and AI capacity, and why each of them needs to?
• If inference volume jumped 100× tonight, how long would it take for something to stop it?
• Are our identity, security, and cost signals connected, or are they sitting in three separate dashboards?
• Do we have organization-wide guardrails on where and what compute can be created, and does every expensive resource have a named owner who would notice, and could say no, when its usage stops looking normal?

If any of those made you pause, you’re in good company. Most of the organizations we talk to are in the same place.

At WinWire, we work with enterprises building on cloud and AI platforms, and this problem sits right at the intersection of our cloud, security, data, and AI work.

If you’d like to work through those four questions for your own environment, reach out to the WinWire team. We’ll look at which identities can spend your compute and AI capacity, where your identity, security, and cost signals live today, and what it would take to catch the next Monday-morning story before Finance does.