The Cost Of The Attack Just Collapsed

If your security posture leans on the assumption that finding a particular flaw would take real skill and real time, stop leaning on it. I watched that assumption fail recently, almost by accident, over a chat that started as a joke. Someone pointed a general-purpose AI assistant, running on one of its cheaper, faster settings, at an ordinary business application. No specialist tooling, no read of the source code, no deliberate reconnaissance. Just a plain instruction to act like someone trying to get in. Under six minutes later, it had worked out how to chain a sequence of ordinary API calls together, obtained a token meant for a different privilege tier than the one it started with, and used that token to pull data it was never supposed to reach.

The exploit itself wasn't exotic. Anyone who has spent time around API security will recognise the shape immediately: a token issued with broader scope than the endpoint that requested it needed, and a downstream service that trusted the token's presence more than it checked the token's purpose. This is a well-documented category of mistake. What made the moment worth paying attention to wasn't the vulnerability. It was everything that used to stand between an ordinary person and that vulnerability, and how completely it had disappeared. No need to understand the framework underneath the application. No need to read a line of its code. No meaningful time cost. And notably, no dependency on what the backend was actually written in — the reasoning that found the gap worked the same way regardless of language or stack, because it was reasoning about the shape of an API, not about any particular implementation of one.

That last point is the one worth sitting with, because it quietly demolishes a risk calculation a lot of teams have been making for years without ever writing it down. The unspoken logic went something like this: yes, in theory, a sufficiently determined and skilled attacker could probably find a way to misuse this token, or chain these two endpoints, or guess at that internal state — but doing so would take real expertise, real time, and our application is not an interesting enough target to justify either. That was never a security control. It was a bet on cost. It relied on the attacker's skill being scarce and their time being expensive. AI has just made both of those things cheap, for anyone, against any application, roughly simultaneously. A bet on cost stops paying off the moment the cost goes to zero.

The part that stuck with me more than the technical detail was the tone in the room while it happened. Nobody treated this as a serious red-team exercise. It was closer to a party trick, tried on a whim between two people who half expected it not to work, followed by a slightly stunned silence when it did. That gap between how casually the exploit was produced and how seriously its consequences would land on a real customer is the actual signal here. If something is trivial enough to demonstrate for fun on a Wednesday afternoon between colleagues who weren't even trying that hard, it is well within reach of someone who is trying, and who has a reason to.

None of this means the sensible response is trying to detect or ban the use of AI assistants against your own systems. That fights the wrong layer, and it's a fight you can't win anyway, because the attacker doesn't need your permission to use one. The actual response is to go back and take seriously the fundamentals that were always supposed to be non-negotiable, and that many teams have quietly under-invested in because the old cost of discovery made the risk feel abstract. Every protected endpoint needs to independently verify what it's being asked to do and by whom, regardless of how the caller obtained whatever credential they're presenting. Tokens need to carry the narrowest scope that the calling context actually requires, not the broadest scope that was convenient to issue at the time. Sessions need to expire quickly enough that a token found today is worthless tomorrow. And monitoring needs to start watching for the shape of automated exploration — many small, quickly varying requests probing the edges of what's allowed — rather than assuming an attacker moves at the pace and volume of a human clicking through a browser.

There's a broader point underneath the technical one, and it's the one I keep coming back to when I think about the businesses I work with that hold data people have trusted them with — healthcare records, payment details, anything that would hurt someone if it ended up in the wrong hands. The obligation was never really "defend against attackers who might eventually get around to finding this." It was always "assume this can already be found, because someone determined enough would eventually find it regardless of how long it took." AI hasn't changed that obligation. It has just stopped letting anyone pretend the timeline mattered. The honest version of secure design was always meant to assume the attacker is already capable, already motivated, and already inside your API's edge cases. We just used to get away with not quite meaning it.

The uncomfortable part is that this almost certainly isn't a one-off. If a token-scoping mistake that had presumably sat unnoticed for a long time surfaced in minutes on a whim, it's a reasonable bet that a meaningful share of production systems right now have something structurally similar waiting to be found the same way. The vulnerability was never the interesting part of this story. It was there the whole time, sitting quietly behind an assumption that nobody would bother. That assumption is the thing that actually broke.