Meta's AI support agent bound recovery emails for anyone who asked. Your SOC never saw an alert.

Meta's AI support agent bound recovery emails to accounts for whoever asked, and SOCs never saw an alert. An authorized agent writes a log of legitimate transactions, so nothing in the detection stack fired. Attackers asked the bot to make the change, took the one-time code it sent, and ran the password reset, 404 Media reported.

No malware, no stolen credentials, and no prompt injection in the sense most security teams drill for. The agent did exactly what Meta built it to do. That is what should keep a security operations leader up at night: The takeover did not break a control; it rode one that was already trusted.

What a SOC needs is a way to walk each recovery path through an audit grid with its AI build team before the next renewal closes. The AI Authority Audit Grid at the end of this article maps every authentication write a support agent can make on the recovery path, what Meta's incident proved about each one, why it stays dark to the SOC, and the control that closes it.

The agent is an authorized actor, so the SOC reads the takeover as routine traffic

From inside the detection stack, the attack produced no signal the stack could read. The agent binds a new email, then resets the password, and identity and access management logs both writes as an authorized actor, so each lands in the authentication state as a legitimate transaction. No anomalous login, no failed-auth spike, nothing for EDR or DLP, no SIEM rule to match, because nothing in the sequence looks like an attack. The takeover lived inside the trust boundary the stack assumes is safe. There is no foothold to find, because the agent was the foothold, and it was supposed to be there.

The chain was almost insulting in its simplicity. Brian Krebs documented the version pro-Iran hackers posted to Telegram on May 31. The attacker switched on a VPN to appear in the victim's region, sidestepping Instagram's location alarms, then asked the support assistant to add a new email and send a verification code, as the BBC confirmed from the same recordings. The bot complied, sending the one-time code straight to the attacker, Gizmodo reported. The reset finished and the owner was locked out, in minutes. The exploit failed against any account with MFA enabled, according to Krebs.

The hijacked accounts were not soft targets. They 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, according to 404 Media. Meta disputes the Obama account, according to TechCrunch, and called claims that leaders' accounts were breached "completely false," according to the BBC. The rest stand.

MFA held. The recovery path beside it did not.

The detail that decided who survived was narrow. Krebs reported the attack failed against any account with multifactor authentication, even SMS. The recovery path beside it was the gap. When that path asked for a selfie video, attackers ran the target's public photos through an AI video generator and submitted the clip, which Meta accepted as valid identity verification, gHacks reported. Either way the failure was the recovery door, not the login door MFA guards.

That makes this an architecture problem, not a Meta problem. MFA gates the login path for owner and attacker alike, but the recovery path runs beside it, built to relax the usual checks because it exists for the moment a user has lost the normal way in. Meta put an agent on that path with write access to authentication state and no deterministic check between a convincing request and a committed change. Authorization cannot live inside the model, because a conversational system can be talked into skipping a check. It has to live outside the model, in a gate the agent cannot reason its way past. Security researchers have a name for this pattern, the confused deputy, a trusted system tricked into spending its privileges on an attacker's behalf.

This is not the last support agent that will hand over an account. 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. "AI chatbots create interesting new attack surface, and we're likely going to see a lot more of these kinds of attacks," Goldin said. Every enterprise wiring an agent into a recovery, provisioning, or password flow is shipping the same write access Meta did.

Simon Willison, who coined the term prompt injection, put it plainly on his blog. "Meta really did wire their support system into an AI chatbot that had the ability to fast-forward through the entire account recovery process," he wrote. "This one hardly even qualifies as a prompt infection. Don't wire your support bot up to allow one-shot account takeovers." The attacker never tricked the agent. The attacker asked, and the agent had untrusted input, write access, and a way to execute, all at once.

OWASP named this class before Meta shipped it, as Excessive Agency at LLM06 and Identity and Privilege Abuse at ASI03 in the Agentic AI Top 10. The warning label was on the box: Meta pushed the assistant to every Facebook and Instagram account in March, according to 404 Media, with the power to reset passwords and handle recovery, the product page promising "solutions, not just suggestions" under the line "account security and recovery." Meta gave the agent the power and never built the gate to govern it.

The AI Authority Audit Grid

Security operations leaders need to run this against their own support agent before the next renewal closes. Each row is an authentication write the agent makes on the recovery path, with what Meta proved, why your stack misses it, and the control that closes it.

| Authentication write | What Meta's incident proved | Why your stack misses it | The control that closes it | | :--- | :--- | :--- | :--- | | Login authentication (MFA, factor prompts) | Held on login. Accounts with any MFA enabled, even SMS, survived (Krebs). The gap was the recovery path beside it. | MFA gates the login path for owner and attacker alike. It does not gate the recovery path beside it. | Enforce MFA as the baseline and extend step-up verification to the recovery path, the same standard login gets (OWASP). A selfie video is not proof of identity. Any agent that operates on a path MFA does not cover fails the audit. | | Email rebind | Full takeover. The agent bound attacker-controlled emails on request, taking Sephora and a U.S. Space Force account (404 Media). | IAM logs the agent as an authorized actor, so the rebind reads as a legitimate transaction and no alert reaches the SOC or the account owner. | Confirm out-of-band to the existing verified contact before any rebind commits, gated outside the model, and notify the old address the moment it changes (IBM). An agent that rebinds without confirming the old address fails. | | Password reset | Full takeover in minutes. Researcher Jane Manchun Wong was among the affected accounts (404 Media). | The reset runs on the recovery path, outside the login MFA check, so no factor prompt fires and no detection rule triggers. | Require a second non-email factor before any reset completes. NIST dropped email as a valid out-of-band channel (NIST 800-63B). An agent reset must clear the same gate a human reset does. | | Recovery-method change | Persistent lockout. Victims could not self-recover. The support loop offered only AI with no human escalation (BleepingComputer). | A silent swap of the recovery email or phone removes the owner's re-entry path with no SOC visibility. | Require step-up review on any change, notify the prior method, and grant time-delayed, reduced-scope access after recovery so a swap never hands over instant control (Authsignal). Keep a human escalation path the agent cannot close. |