Remember when the scariest thing about AI and email security was grammar? Back when the whole conversation was “well, now the scam messages won’t have typos”? That was the ceiling of the worry. Better spelling, slightly more convincing subject lines, maybe a bot that could fake a British accent in text.
That ceiling is gone. On 22 September 2026, Microsoft announced that its Digital Crimes Unit, working with industry partners and law enforcement, had disrupted EvilTokens, a subscription-based cybercrime service that used AI to automate phishing. The tally: more than 12,000 compromised inboxes across over 10,000 organizations. The Metropolitan Police Service arrested two men, aged 32 and 38, on 11 September 2026 in connection with the operation.
I build bots for a living. And reading through what EvilTokens actually was, I did not feel like I was reading about exotic criminal technology. I felt like I was reading a product teardown of something I could have architected on a Tuesday.
Same architecture, different intent
Strip the crime out of it and look at the shape of the system. Microsoft described EvilTokens as a subscription service. It had an AI chatbot that helped attackers decide which victims to pursue and how to exploit them. It automated phishing at scale.
Translate that into the vocabulary any of us use on a Monday standup:
- A recurring-revenue billing layer with tiers
- An onboarding flow, because paying customers who cannot figure out your tool churn
- An LLM-backed decision agent doing target triage and next-best-action recommendations
- A job runner executing the attack sequence without a human babysitting each step
- Presumably some kind of dashboard, because what is a subscription product without a dashboard
That is a standard agent stack. Retrieval, reasoning, tool calls, orchestration, a UI. The uncomfortable part is not that criminals discovered AI. It is that the architecture patterns we publish in tutorials, mine included, are intent-neutral. An agent that scores leads and picks an outreach strategy is a sales tool. The same agent pointed at stolen data with different instructions is EvilTokens.
Why the “device code” detail matters to builders
EvilTokens has been described as a device-code phishing service, and that detail is the part I want every bot developer to sit with for a minute.
Device code flow exists for a legitimate and genuinely useful reason. It is how you authenticate on something with no good keyboard or browser: a TV app, a CLI tool, an IoT device, a chat-based assistant. The device shows a short code, the user goes to a login page on their phone, enters the code, approves the request, and the device receives tokens. Clean solution to a real problem.
The weakness is structural, not a bug. The person entering the code is not the person who initiated the request, and the flow gives them almost nothing to verify who is on the other end. If someone starts the flow and convinces you the code came from your IT department, you will approve an access grant for an attacker and it will look exactly like a normal sign-in to you.
Which means the attack does not need to defeat your password. It does not need to defeat multi-factor authentication in the way people usually imagine. It needs to defeat your attention for eight seconds. That is a social problem wearing an OAuth costume, and it is one of the reasons 12,000 inboxes is a plausible number rather than a shocking one.
What I am changing in my own projects
None of this is a reason to stop building agents. It is a reason to build them with the assumption that your patterns are reusable by people you would not invite to your house.
Concrete things I have moved up my list:
- Treat device code flow as a last resort. If my bot can open a browser or accept a redirect, it does that instead. Convenience is not worth the grant.
- Make auth prompts legible. If my bot asks a user to approve something, the message says what is being granted, to what, and for how long. Vague approval requests train people to approve vague requests.
- Log and surface token grants. Anything that gets a token should leave an audit trail a human can actually read, not a line buried in a log aggregator nobody opens.
- Scope tightly, expire aggressively. Long-lived broad tokens are the whole prize in an attack like this.
The EvilTokens takedown is a genuinely good outcome. A platform is offline, two suspected administrators are in custody, and a coalition of defenders proved the model can be broken. But the blueprint was never secret, and subscription software has a habit of being rebuilt by someone else.
The people shipping agent frameworks and the people abusing them are reading the same documentation. We should probably read it more carefully than they do.
🕒 Published: