When the support bot hands over the keys: inside the Meta AI account-takeover attack

01 What actually happened

The attack was almost insultingly simple. Researchers who reproduced it described a five-step chain [ TechCrunch 2026 ] . Match the geography first: connect through a VPN with an IP near the target's home region, so the request looks plausible to Meta's risk signals. Start a normal password reset for the target's username. Open the AI support assistant instead of the standard recovery form. Ask the bot to add a new email address to the account, supplying a mailbox you control. Then collect the code. The assistant emailed a one-time verification code straight to the attacker, and with that code the password change went through.

TechCrunch independently verified that the attacker-controlled mailbox received the reset code. Anyone who knew a target's username could start the process. No malware. No zero-day in the traditional sense. No credential stuffing. The weakness was the agent's willingness to perform a privileged action for whoever happened to be talking to it.

INCIDENT 23:47

02 A confused deputy, not a Hollywood hack

Strip away the AI buzzwords and you are left with one of the oldest problems in computer security: the confused deputy. A deputy is any system that holds more privilege than the person asking it for something. When the deputy acts without verifying that the requester is actually allowed to make the request, the requester borrows the deputy's authority.

Meta's support bot was a deputy with the power to modify account-recovery settings. The attacker had no such power. By framing a malicious request as a routine support question, the attacker got the bot to spend its privilege on their behalf. The model was never hacked. It did exactly what it was built to do, for someone it should never have done it for.

That distinction is everything. A language model is a probabilistic text engine you can steer with words. Account recovery is a deterministic security boundary that must hold against an attacker who has read your entire support script and tried it ten thousand times. Put the model in charge of the boundary and the boundary is now only as strong as the model's ability to resist a persuasive stranger. That is not a boundary. It is a suggestion.

03 Why MFA held the line

One detail in the reporting deserves a banner of its own. Accounts protected by any form of multi-factor authentication, even basic SMS codes, did not fall [ KrebsOnSecurity 2026 ] . The bot could attach an attacker's email and trigger a reset, but the second factor still stood between the attacker and the account. One channel of separation, and it was enough to stop a takeover that otherwise needed nothing but a username and a chat.

This tells you exactly where the design went wrong, and it generalises far beyond Instagram. When you deploy an AI agent that can take a consequential action, the question is never whether the model is smart enough to refuse bad requests. The question is what verifies the action when the model gets talked into it anyway. If the honest answer is nothing, you have built Meta's bug.

It is tempting to file this under big-platform problem. It is not. Over the past year we have tested AI agents that companies connected, with genuine good intentions, to actions that carry real weight. The table below is the pattern we keep finding, next to the pattern that survives an attacker.

Every action in that left column is a privileged one: resetting passwords, changing a customer's email or phone number, issuing refunds and credits, granting access to shared tools, reciting another customer's order details, writing to the CRM or the billing platform. The moment a model can trigger any of them on the strength of a conversation, you have handed an attacker a deputy. This is already deployed across retail, banking, SaaS and healthcare support desks.

04 Stop your agent becoming the deputy

Move authorisation out of the model first. The model is allowed to understand intent. It is never allowed to be the thing that grants the action. Privileged operations must pass through a deterministic authorisation layer that checks who the requester is, what they are entitled to, and whether this specific action is permitted, independent of how persuasively it was phrased. If your agent can act purely because it decided to, the model is your access control. Fix that before anything else.

Then verify identity in code, before the action, every time. A conversation is not authentication. Before any account-recovery, data-disclosure or money-moving step, the workflow itself must complete an identity check the model cannot satisfy on the user's behalf. Meta's MFA-protected accounts survived precisely because a code-enforced second factor sat beyond the agent's reach. Tier the rest: reading a public FAQ is low risk, changing a recovery email is not, and high-risk actions should require step-up verification or a human approval the model can request but never grant.

Treat every agent input as hostile. Assume an attacker has read your support scripts, knows your agent's tools, and will craft inputs designed to misuse them [ OWASP LLM 2025 ] . Constrain what each tool can do, scope permissions to the minimum, and log every privileged call for review. Then red team the agent the way an attacker will. Functional testing confirms the agent helps honest users; it tells you nothing about whether a determined adversary can make it act against them. In our assessments, agents wired to privileged tools fail this far more often than their builders expect. The Meta bot would have failed it in an afternoon.

You walk away from an assessment with the exact list of actions your agent can be talked into, the control missing behind each one, and a fix you can ship. Once the findings are closed, RTP Robin lets your team re-run the same social-engineering and prompt-injection attacks as the agent changes, so the picture stays current between formal tests rather than ageing the day the report is signed. Enterprise-grade assurance, within reach.