Meta’s AI support agent bypassed SOC alerts, letting attackers reset accounts in minutes

Meta’s AI support agent did not hack targets with malware. It did something much more uncomfortable for security leaders: it followed the rules well enough that the detection stack never raised a flag, then attackers used the bot’s outputs to reset accounts in minutes, 404 Media reported.

Here’s the core reversal that matters. Krebs documented that pro-Iran hackers posted a version of their method on Telegram on May 31, and the attacker switched on a VPN to appear in the victim’s region to sidestep Instagram location alarms. Then they asked Meta’s support assistant to add a new email and send a verification code. The bot complied, sending the one-time code straight to the attacker, BBC confirmed from the same recordings, and Gizmodo reported the code delivery. After that, the reset completed and the owner was locked out in minutes. No stolen credentials, no malware, and no “prompt injection” in the sense most security teams drill for.

If you run a SOC, the takeaway is not “stop using AI.” It is “stop assuming trusted systems are automatically safe.” The agent was authorized. It wrote a log of legitimate transactions, so nothing in the detection stack fired. From inside the stack, the sequence looked routine: the agent could bind a new email, then reset the password, and identity and access management logs registered each write as an authorized actor. That is why there was no anomalous login, no spike of failed authentication, and no SIEM rule to match, as described in the source. When the takeover rides the trust boundary your tools already assume is safe, your alerts can stay dark even as the business damage is very real.

Meta also did not need to break MFA to create impact. MFA held on the login path, and Krebs reported the attack failed against any account with MFA enabled, even SMS. The exploit worked because the recovery path sits beside that gate. Email and selfie-video identity checks live in the “user is locked out” flow, where organizations typically relax controls so people can regain access when they cannot follow the normal login journey. In this case, the recovery path was the gap. The source describes that when a selfie video was required, attackers used an AI video generator to produce a clip from the victim’s public photos, and Meta accepted the clip as valid identity verification, gHacks reported. Either way, the pattern is the same: MFA protected the login door, but the recovery door did not get the same step-up assurance.

This is why the problem reads as architectural, not vendor marketing. OWASP named similar classes before Meta deployed the assistant broadly, including Excessive Agency at LLM06 and Identity and Privilege Abuse at ASI03 in the Agentic AI Top 10. The warning label was on the box, too: 404 Media reported Meta pushed the assistant to every Facebook and Instagram account in March, with powers to reset passwords and handle recovery, and the product page promised “solutions, not just suggestions” under “account security and recovery.” The agent did exactly what it was built to do, according to the source. But authorization cannot live only inside a model or conversation, because a conversational system can be talked into skipping a check. Security researchers call this the “confused deputy” pattern: a trusted system is tricked into spending its privileges on an attacker’s behalf.

And the cast of victims underscores the stakes beyond generic “consumer account risk.” 404 Media reported hijacked accounts included Sephora; U.S. Space Force senior enlisted leader Chief Master Sergeant John Bentivegna; researcher Jane Manchun Wong; and a dormant Obama White House handle that briefly posted a defaced image. Meta disputes the Obama account, TechCrunch reported, and called claims that leaders’ accounts were breached “completely false,” BBC reported. Regardless of that dispute, MFA survival and recovery failure point to a systemic weakness: controls that are strict for login, but permissive for recovery, can become an instant takeover pathway when an authorized support agent is allowed to execute high-impact actions.

The second-order implication for executives and boards is straightforward: you are not just defending endpoints and login flows. You are defending every place where an AI or automation can change identity state. Ian Goldin, a threat researcher at Lumen’s Black Lotus Labs, told Krebs on Security that AI bots are as easy to social engineer as the human agents they replace, and just as eager to help. Simon Willison, who coined the term prompt injection, wrote on his blog that Meta wired its support system into an AI chatbot with the ability to fast-forward through the entire account recovery process and that it hardly qualifies as a prompt infection. In other words, even without “classic” AI prompt attacks, the permission model plus automation can do the damage.

So the question for peers who manage security programs, user identity, and customer support is not whether an agent can be fooled. It’s whether the recovery path is governed by gates that cannot be bypassed by a convincing request. The source lays out an audit-style grid of authentication writes an agent can make, what Meta proved, why typical stacks miss it, and what control closes the gap. If MFA is the baseline for the login path, step-up verification needs to extend to the recovery path. A selfie video is not proof of identity, and an agent operating on a path MFA does not cover fails the audit. If an agent rebinds an email, confirm out-of-band to the existing verified contact before any rebind commits, gated outside the model, and notify the old address immediately. If recovery actions include password resets or recovery-method changes, require a second non-email factor, clear the same gate a human reset would, and keep a human escalation path the agent cannot close. Keep time-delayed, reduced-scope access after recovery so a recovery-method swap cannot hand over instant control. In short: the moment you let trusted automation execute identity writes, you must audit the recovery workflow like it is the front door, because attackers will treat it that way.