Oleksandr TverdokhliebIn the spring of 2026, attackers stole tens of thousands of Instagram accounts without ever breaking the password, the encryption, or the firewall. They simply opened a chat with Meta's AI-powered account-recovery assistant and talked it into doing the takeover for them. It's one of the cleanest case studies I've seen of a problem I keep coming back to: the AI itself is now part of the attack surface.
I write about AI as leverage a lot — for analytics, for automation, for shipping faster. So it's worth being just as clear-eyed about where it goes wrong. This story isn't a "see, AI is dangerous" cautionary tale. It's something more specific and, to me, more useful: a worked example of what happens when you place an AI agent inside a workflow that exists precisely because it decides who someone is.
What actually happened
According to reporting by TechCrunch and SecurityWeek, the entry point was Meta's AI assistant for Instagram account recovery — the chatbot you'd normally reach when you're locked out and need help getting back in. Instead of helping a legitimate owner, attackers used the conversation to drive a hostile recovery against accounts they didn't own.
The sequence was almost mundane, which is what makes it unsettling. The attacker would coax the assistant into attaching an email address they controlled to the target account. The bot then dispatched a verification code to that attacker-owned address — treating it as if it belonged to the real owner. The attacker read the code off their own inbox, handed it back to the bot, and the bot, now satisfied that the request was "verified," offered up a password reset. Reset complete, the account belonged to the attacker. To slip past automated defences that watch for logins from unexpected places, the attackers leaned on VPNs to make their traffic look like it was coming from the victim's own region.
By Meta's own account, the abuse ran from roughly 17 April to 31 May 2026 and affected in the region of 20,225 Instagram accounts, some of them high-profile. Meta says it caught the pattern on 31 May and pulled the tool offline. Notice the timeline: this quietly worked for about six weeks before anyone noticed. That gap is the part security teams should sit with.
Why this is a new kind of vulnerability
There's a temptation to file this under "chatbot gone wrong" and move on. I'd push back on that. The password system worked. Two-factor mechanics worked — a code really was generated and really was entered. The location checks were in place. Every individual control behaved as designed. What failed was the decision-maker sitting in the middle, and that decision-maker was an AI agent that could be talked into things.
An account-recovery flow is, at its core, an identity adjudication: it answers "is this person allowed to take control of this account?" The moment you let a language model drive that adjudication, you've created a path to account takeover that doesn't route through any of your hardened technical defences. It routes through persuasion. The attacker doesn't need a zero-day; they need a convincing conversation.
That's the shift worth internalising. For years we modelled threats around code: injection, misconfiguration, leaked credentials, unpatched services. An AI agent with real permissions adds a new entry in the threat model — one where the input is natural language and the "vulnerability" is the model's willingness to be steered. You can't fully patch that the way you patch a buffer overflow, because flexibility is the entire reason the agent exists. So the defence has to live somewhere other than the model's good judgement.
What I take from it
I'm bullish on AI agents. I use them, I build around them, and I think the productivity case is real. But this incident sharpens a line I already try to hold: the more consequential the action, the less an agent should be allowed to take it alone. Drafting a summary, triaging a ticket, querying data — let the agent run. Changing who controls an account — that needs a wall around it.
Concretely, here are the lessons I'd carry into any system where an AI agent touches a trust-sensitive workflow.
- Treat the agent as an untrusted intermediary. Assume anyone talking to it may be hostile and that the conversation can be manipulated. Don't grant trust based on what the bot "decided" — grant it based on verification the bot can't fabricate.
- Keep account-takeover-class actions out of the agent's hands. Adding recovery contacts, resetting credentials, or changing ownership should demand strong, independent verification and, for high-stakes cases, a human in the loop. The agent can prepare the request; it shouldn't be the one to approve it.
- Apply least privilege to the agent itself. Scope exactly what it can do and deny everything else by default. An assistant that can explain the recovery process is far safer than one that can execute it.
- Log everything and rate-limit aggressively. Six weeks is a long time for a campaign to run unseen. Per-account and per-session limits, anomaly alerts, and full audit trails are what turn a slow-burn breach into a same-day catch.
- Assume attackers will aim at the AI, not the perimeter. If the agent is the softest path to a privileged action, that's where pressure goes. Red-team the conversation, not just the code.
None of this is anti-AI. It's the same principle I apply to people and automation alike: give the easy, reversible work to the fast actor, and put the irreversible, high-stakes work behind verification and review. An AI assistant that can reset a stranger's password on the strength of a chat was never a model problem — it was a design that handed an unsupervised agent the keys to an identity decision. The fix isn't to fear the agent. It's to stop letting it decide who you are.