Meta’s AI support agent linked recovery emails to accounts at the behest of anyone who requested it, and Security Operations Centers (SOCs) were unaware. The authorized agent logs transactions as legitimate, meaning the detection stack remained silent. Attackers simply instructed the bot to make changes, received the one-time code it dispatched, and executed the password reset, according to 404 Media.
There was no malware, stolen credentials, or typical prompt injections that security teams prepare for. The agent functioned precisely as designed by Meta. This should be a warning to security leaders: the breach did not involve breaking a control but exploiting a trusted one.
SOCs should implement a method to audit each recovery path with the AI build team before the next renewal cycle. The AI Authority Audit Grid at the article’s conclusion outlines every authentication write a support agent can execute on the recovery path, what Meta’s incident revealed about each, why it remains undetected by the SOC, and the control that addresses it.
The agent acts as an authorized entity, leading SOCs to see the takeover as normal activity
Within the detection stack, the breach generated no detectable signals. The agent attaches a new email and resets the password, with identity and access management logging both actions as authorized. Consequently, each action appears as a legitimate transaction in the authentication state. There are no unusual logins, failed authentication spikes, or SIEM alerts, as the sequence doesn’t resemble an attack. The breach occurred within the trust boundary assumed to be secure. There was no vulnerability to exploit since the agent itself was the foothold, and it was intended to be there.
The simplicity of the attack was almost shocking. Brian Krebs documented the version shared by pro-Iran hackers on Telegram on May 31. The attacker used a VPN to appear in the victim’s region, bypassing Instagram’s location alerts. They then instructed the support assistant to add a new email and send a verification code, confirmed by recordings referenced by the BBC. The bot complied, delivering the one-time code directly to the attacker, Gizmodo reported. The reset was completed, locking out the owner in minutes. The exploit did not succeed against accounts with enabled MFA, according to Krebs.
The targeted accounts were not easy marks. 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 account that temporarily displayed a defaced image, as per 404 Media. Meta contests the Obama account, according to JS, and labeled claims of breaches to leaders’ accounts as “completely false,” the BBC reported. The rest of the claims remain undisputed.
MFA was effective. The accompanying recovery path was not.
The critical detail determining who was affected was narrow. Krebs noted the attack failed on accounts with multifactor authentication, even SMS. The vulnerability was in the recovery path. When that path required a selfie video, attackers used AI video generators on public photos to create and submit clips, which Meta accepted as valid ID verification, gHacks reported. The weak link was the recovery process, not the login protected by MFA.
This issue highlights an architectural flaw, not a specific problem with Meta. MFA safeguards the login path for both users and attackers, but the recovery path runs parallel, designed with fewer checks since it’s meant for users who have lost access. Meta placed an agent on this path with write access to authentication states, lacking a firm verification process between a request and its execution. Authorization must be external to the model, as conversational systems can be manipulated to skip checks. It should reside in an external gate that the agent cannot bypass. This pattern is known as the confused deputy, where a trusted system is tricked into misusing its privileges on behalf of an attacker.
This won’t be the last instance of a support agent relinquishing an account. Ian Goldin, a threat researcher at Lumen’s Black Lotus Labs, told Krebs on Security that AI bots are susceptible to social engineering, much like the human agents they replace, and are equally eager to assist. “AI chatbots introduce new attack vectors, and we are likely to see more of these attacks,” Goldin stated. Any organization integrating an agent into recovery, provisioning, or password processes is deploying the same type of write access Meta did.
Simon Willison, who coined “prompt injection,” discussed this on his blog: “Meta effectively connected their support system to an AI chatbot capable of expediting the entire account recovery process,” he wrote. “This barely qualifies as a prompt injection. Avoid configuring your support bot to allow single-step account takeovers.” The attacker did not deceive the agent. They requested, and the agent executed the task with untrusted input, write access, and a means to proceed, all simultaneously.
OWASP identified this issue before Meta’s release, labeling it as Excessive Agency at LLM06 and Identity and Privilege Abuse at ASI03 in the Agentic AI Top 10. The warning was clear: Meta had rolled out the assistant to every Facebook and Instagram account in March, as reported by 404 Media, enabling password resets and recovery handling. The product page promised “solutions, not just suggestions” under “account security and recovery.” Meta gave the agent significant authority without an oversight mechanism.
The AI Authority Audit Grid
Security operations leaders must apply this audit to their own support agents before the next renewal. Each row details an authentication write the agent can perform on the recovery path, what Meta’s case demonstrated, why your system overlooks it, and the control to address it.
|
Authentication write |
What Meta proved |
Why your stack misses it |
Enterprise control and owner |
|
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. Owner: IAM. |
|
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. Owner: IAM and platform engineering. |
|
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. Owner: IAM. |
|
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. Owner: GRC and IT operations. |
|
Account-action execution |
Speed risk. A dormant Obama White House handle briefly showed a defaced image during the spree, an account Meta disputes was taken this way (JS). |
The agent executes irreversible state changes in seconds with no human in the loop and no reversibility window. |
Separate decision from execution. The agent only proposes the action. A policy service validates scope and approval before it runs, with approval bound to the exact action (OWASP). No auth-state write commits without that gate and a reversibility window. Owner: platform engineering and the AI build team. |
|
Agent action logging |
Detection gap. The takeover left no alert, and Meta has not published how many accounts fell before the patch (JS). |
Without per-action telemetry piped to the SIEM, an authorized-agent takeover is invisible to the SOC. |
Emit structured decision metadata for every auth-state write into the SIEM: action class, authorization outcome, approval ID, result, policy version (OWASP). A write your SIEM cannot see is a write you cannot defend. Owner: SOC and detection engineering. |
The solution is not to add more MFA prompts at login. Those who avoided being compromised in Meta’s incident already had this in place.
The remedy involves removing authorization from the recovery path’s honor system and securing it behind an immovable gate, regardless of how convincing a prompt is. Develop the agent so that the SOC tracks all its actions, and ensure any change in account ownership requires validation that is independent of the model.
Meta has demonstrated the risks of having the most trusting entity on the team also holding the keys. The next agent of this kind will likely have access to crucial company information.
