Every security team knows how to think about an attacker who wants your data. Fewer are thinking about an attacker who wants your budget. Most AI services are metered with every request costing money. Here is my hypothesis on a new type of attack that we aren’t thinking enough about.
To be clear, the scenario I’m about to describe has not been publicly documented as far as I can find. This is a prediction that I believe is coming, and I think the organizations that prepare now will cut their risk significantly.
Over the next year, I believe we will start seeing more businesses being hit with an AI Bill Attack. This is when a malicious actor deliberately burns through a company’s AI token budget, in an attempt to financially disrupt or take out a business.
What’s already happening
The outside version is real. Researchers call it LLMjacking, this is when attackers obtain someone else’s AI credentials and use the service at the victim’s expense. Sysdig’s threat research team, which coined the term, estimated the cost to a victim could exceed $46,000 per day on a Claude 2.x-class model, and potentially two to three times that on newer models. I've also had conversations with other security executives who estimate average losses at $50,000 to $100,000 per day per affected company, with stolen keys resold through intermediary services.
This is closely tied to something researchers call denial of wallet, where metered AI billing itself becomes the attack surface. Most of the documented cases involve an outsider who has either stolen a valid credential or found a publicly exposed AI feature with weak rate limits, then uses it to run up charges at the victim’s expense. The illustrative math is simple: a support bot using 100,000 tokens an hour might cost about $3, while one pushed to 100 million tokens an hour would cost about $3,000 for that same hour. Scale that over a weekend and the numbers stop being rounding errors.
It’s also important to consider something we all know already…access is access. Whether it was stolen from the outside or already sitting with someone on the inside, a valid key behaves the same way. On top of that, the billing system has no idea whether the hand on the keyboard is a thief or an employee. The difference in intent is the important part nobody is talking about yet.
What I think comes next
So far, almost everything written about this problem assumes the access was stolen. I think the next version is access that was never stolen at all. However, both are likely to be huge problems.
Think about who already holds legitimate credentials to a company’s AI tools right now: employees, contractors, vendors, and the service accounts. Then consider the motives that already drive insider incidents in every other part of security: a layoff, a dispute, a grudge, or a departure where access was never fully cut off. In most organizations, AI tooling was rolled out quickly, under pressure, with shared keys, generous limits, and very little thought about who could spend what.
Two things make this type of “attack” hard to catch:
Nothing breaks. There’s no outage, no malware, no alert from your normal security stack. The first sign may be an invoice weeks later.
It looks legitimate. A valid credential making valid requests is indistinguishable from a busy week of real work, unless someone is watching the shape of usage and not just whether it’s authorized.
For a large enterprise, a spike like this is a painful line item. For a startup or a midsize company running close to the edge, this could be the kind of event a business doesn’t recover from. This is especially true if a provider won’t reverse the charges.
It isn’t only about money
Spending is the loud version of this problem. There are others worth sitting with.
Someone else’s AI instead of their own. Why pay for compute when you can use your victim’s? Stolen AI credentials have reportedly sold for as little as $30 per account and then been resold at a steep discount to legitimate pricing.
Borrowed authority. An AI agent with access to email, files, or internal tools is more than a cost center. Whoever controls its credentials or its inputs effectively inherits whatever that agent is allowed to do.
Suspension risk. Providers can restrict or shut down accounts for activity the account owner never intended or even knew about. Your AI dependency can go dark because of someone else’s behavior on your key.
Actions taken in your name. This one is probably the most serious, as it can impact the business and employees on a personal level.
Who’s responsible when it’s your AI doing the damage?
There’s a harder question underneath all of this, and it has nothing to do with the invoice.
If someone gains access to your AI account and uses it to generate malicious code, draft a convincing phishing campaign, or produce content designed to harm someone else, the trail leads back to you. Not to the person who actually did it, at least not at first.
This is a different kind of exposure than a surprise bill. A provider, a victim, or a regulator investigating the resulting harm starts the trail at the credential that made the call. Untangling “it wasn’t us, someone else was using our access” after the fact is a forensic and legal problem, which may take time you don’t have if law enforcement or an affected third party is already asking questions.
Ask yourself: if your AI account were used right now to generate something harmful, would you be able to prove it wasn’t you? Could you show, quickly and convincingly, which key made the call, which person or system was behind it, and when access was granted or revoked? For a lot of organizations, the honest answer is no.
Who’s job is this?
Most orgs would love it to be easy to say this lands on the CISO’s desk, however, I don’t think it’s that simple.
This should be a collaborative solution. Whether you’re the CISO, a security lead, an IT manager, or whatever your organization calls the person responsible for AI tooling, you’re probably going to end up holding this one. Finance will ask why the bill spiked, and legal will ask what the exposure is, but the board will be asking who was supposed to be watching it. In most organizations, that question lands on security, whether or not security was the one who stood up the AI tools in the first place.
That’s exactly why this deserves attention now, before an incident forces the conversation. It strengthens the case for hardening your environment and genuinely knowing what’s running inside it. Shadow AI, the tools, plugins, and agents that showed up without a formal review, is the root of this problem. You cannot govern spend, attribute usage, or catch misuse on something you don’t know exists. Rate limits, hard spending caps, per-user credentials, and fast offboarding all matter, but none of them work if there’s an AI tool operating in your environment that nobody on the security team knows about.
