Beyond the Meter : AI Consumption Fraud

Catching AI compute fraud before it blows through your forecast, without blocking the users you want to keep.

Your AI compute budget started as a forecast, a clean line you could plan and price against. Lately that line keeps breaking: costs spike above plan with no launch or traffic win to explain them, and every unit of it looks like ordinary usage. The opportunity now is knowing who (or what) is really driving those spikes, so you can catch abuse early, protect your margin, and keep scaling, instead of shutting the tap or writing the overage off after the fact.

The meter shows how much, not who

AI compute is billed like a utility: you pay for what flows through the line, metered by the token, the call, or the GPU-hour. That meter is precise about one thing and blind to another. It records exactly how much was consumed, and nothing about who consumed it or whether anyone authorized the spend. Usage is trusted by default, because charging for consumption is the whole business model. So the abuse arrives looking like demand, clears the meter, and lands in the same totals as your best customers. The question the meter cannot answer is the one that now matters most: who, or what, is really behind the usage.

The door holds. The bill climbs.

Here is what that looks like in practice. A company launches a free generative-AI tool to break into a new market. Signups climb overnight, which is the point. Then the fraud team notices the shape of the usage: accounts arriving in bursts, from generated email addresses, dozens at a time, each one draining its free credits within minutes to mass-produce images. The traffic is not a person trying the product. It is bots harvesting it, using the launch to build a training library for a model of their own. No system was breached. No invoice went unpaid. Every account signed in cleanly and used exactly what it was offered.

That was one company, and it is not the exception, at any size. The headline version makes the news: in 2026, Canva moved to shut down a ‘seat cycling’ scheme that spun up trial accounts to harvest and resell its AI image credits. The everyday version is quieter, and just as costly: a developer pushes an API key to a public repository, or a poisoned open-source package lifts the keys out of a team’s pipeline, and the first anyone hears of it is a five-figure inference bill.

Access controls are not what failed here. The front door was locked: keys, OAuth, rate limits, all in place. The problem is that valid access is exactly what gets taken, and it gets taken in more than one way. Attackers spin up fake accounts by the dozen to farm free trials and promotional credits, cycling through a fresh allotment with every new signup.

They take over legitimate, paying accounts and burn through the credits your customers already bought, so the loss lands on your best users before it lands on you. And they buy valid access outright, from credentials that leaked into public code, got phished, or were sold on marketplaces built for it. Once a valid key or a believable account is loose, the meter bills whoever holds it, human or machine.

Stolen keys running models on someone else’s bill are now common enough to have a name, LLMjacking; in a March 2026 research note, the Cloud Security Alliance documents a single compromise running to roughly $46,000 a day in stolen inference.

The methods and the motives keep changing, from reselling stolen access to powering other attacks, but they share one trait: each looks legitimate on the way in, so the bill climbs until someone catches it.

Where the loss lands

The direct overage is only the visible part. Underneath it, compute fraud spreads into the work and the numbers your team already owns. It burns quota you provisioned for paying customers, so real users hit limits and service degrades. When the credits being drained belong to a paying customer, that customer feels the fraud first, and the refund, the dispute, and the lost trust land on you next. It pulls a lean trust and fraud team into credential-rotation fire drills and incident response instead of the roadmap. It sets the false-positive trap: tighten the rules too far and you block the good users and the conversion you are measured on. And it quietly corrupts the metrics you forecast from, so the next plan inherits the noise.

Weak or missing credentials were the top way into cloud environments, tied to 47 percent of intrusions in a recent period, according to Google Cloud Threat Horizons research, and that same open door is what turns your compute into someone else’s free resource.

What actually stops it

By the time the cost is climbing, the login is not the problem. The credential is valid, the account cleared every check at the door, and on its own it looks like a customer. What gives the fraud away is the pattern across accounts: the same devices, the same infrastructure, the same behaviors and relationships surfacing again and again. So the way to stop it is to stop judging accounts one at a time and start triangulating the actual entity behind the activity, connecting the signals a single account hides and recognizing the shape of an operation already running inside your system. This is a different discipline from authentication. Login and MFA verify a credential at the door; catching compute fraud means identifying the entity doing the damage once it is already inside, with enough confidence to act on the call and defend it to a customer, an auditor, or your leadership. It takes pattern recognition and judgment at scale, applied continuously as the tactics change, which is usually what a lean team lacks.

By the time the cost is climbing, the login is not the problem. The credential is valid, the account cleared every check at the door, and on its own it looks like a customer. What gives the fraud away is the pattern across accounts: the same devices, the same infrastructure, the same behaviors and relationships surfacing again and again. So the way to stop it is to stop judging accounts one at a time and start triangulating the actual entity behind the activity, connecting the signals a single account hides and recognizing the shape of an operation already running inside your system.

This is a different discipline from authentication. Login and MFA verify a credential at the door; catching compute fraud means identifying the entity doing the damage once it is already inside, with enough confidence to act on the call and defend it to a customer, an auditor, or your leadership. It takes pattern recognition and judgment at scale, applied continuously as the tactics change, which is usually what a lean team lacks.

Where to start

That is where FiveBy comes in. We pair Entity Intelligence and pattern recognition with experienced fraud practitioners who triangulate the actual entity behind the damage and handle the fraud already inside your system, alongside your team. The outcome is fewer bad accounts, protected margin, and a compute line you can forecast again, without new headcount or a heavy lift. Start with one capability, prove it against your own traffic, and expand as it earns its place. If your forecast keeps breaking and the usage all looks legitimate, let us scope a pilot: one capability, with the proof and the numbers you can take to finance.

Limit your risk, not your business.

Sources