TL;DR

Hackers reportedly abused Meta’s AI powered support assistant to take over high profile Instagram accounts by convincing the bot to associate attacker-controlled email addresses with target accounts. Once the AI driven support flow accepted the new email, attackers could receive verification codes and reset passwords, effectively turning a customer support automation feature into an account takeover path.

This was not a traditional exploit against a backend database or application vulnerability. The failure occurred at the decision layer: an AI support agent was allowed to perform sensitive identity and account recovery actions without strong enough verification, risk gating, or human escalation.

The core lesson is simple: AI agents must not be trusted as final authority for identity, ownership, or account recovery decisions. Any AI system that can modify credentials, reset access, or change recovery channels must be constrained by deterministic controls outside the model.

The Core Attack Pattern

Meta had rolled out an AI support assistant for Facebook and Instagram to provide always-on support for account issues. The assistant was designed to do more than answer questions. It could take action on user requests, including password resets and profile or account setting changes.

According to 404 Media, hackers shared videos and screenshots showing that Meta’s AI support bot could be manipulated into linking a target Instagram account to a new attacker controlled email address. The reported compromises included high profile accounts such as the Barack Obama White House account, Sephora, and the Chief Master Sergeant of the U.S. Space Force.

The attack reportedly spread through Telegram and other channels, where hackers demonstrated the workflow and claimed it worked against accounts that did not have MFA enabled. Meta later said the issue had been resolved and that impacted accounts were being secured.

The important point is not just that individual Instagram accounts were compromised. The broader concern is that a generative AI support layer was wired into a sensitive account recovery workflow and appeared able to complete a high risk identity action based on conversational persuasion rather than hardened verification.

The attacker did not need to break into Meta’s backend systems. They targeted the AI support workflow.

At a high level, the attacker:

1. Selected a target Instagram account.
2. Initiated an account recovery or support interaction.
3. Used Meta’s AI support assistant to request that a new email address be linked to the target account.
4. Caused the support flow to send a verification code to the attacker controlled email.
5. Used the verification flow to reset the account password.
6. Took control of the account and, in some cases, defaced or resold access to valuable accounts.

Some reporting also indicates that attackers used VPNs to spoof the victim’s normal location, suggesting that they attempted to satisfy or bypass location based risk signals.

The Attack Progression Across the AI Kill Chain

The attack followed the AI Kill Chain across 10 stages:

1. Reconnaissance - Active. Attackers identified valuable Instagram accounts likely worth hijacking. The reported targets were high-profile accounts, including the Barack Obama White House account, Sephora, and the Chief Master Sergeant of the U.S. Space Force, and the workflow was demonstrated and shared across Telegram and other channels.
2. Trust Manipulation - Active. The attacker framed the request as a legitimate account recovery action. Because Meta's assistant was built to act on user requests — including password resets and profile or account setting changes — a request presented as routine recovery was handled as a credible support interaction rather than challenged.
3. Input & Instruction Weaponization - Active. The attacker asked the AI assistant to link a new email to the target account. The malicious input was the request itself: a conversational instruction directing the support flow to associate an attacker-controlled email address with an account the attacker did not own.
4. Reasoning-Time Execution - Active. The AI driven workflow was manipulated into treating the requester as authorized to modify recovery details. The assistant's interpretation of the request stood in for real authorization, proceeding as though the requester owned the account without requiring the deterministic ownership proof the action should have demanded.
5. Tool Invocation - Active. The support assistant triggered account recovery actions. Acting on the manipulated request, it initiated the recovery-channel change and caused a verification code to be sent to the attacker-controlled email address.
6. Privilege Escalation - Active. The attacker converted support access into password reset capability. With the verification code delivered to an address they controlled, the recovery flow could be completed to reset the account password, escalating a support interaction into direct credential control.
7. Lateral Movement - Bypassed entirely**.** Not observed in the reporting, and not required — the target account was reachable directly through the support and recovery workflow, so the attacker achieved the objective without pivoting to any other system or account.
8. Persistence - Active. Attacker reset the password, creating a stored credential state that preserved account access. With both the password and the relinked recovery email under attacker control, that access persisted beyond the initial interaction.
9. Command & Control - Active. Attacker-controlled email became the trusted recovery and verification anchor for the account. Because the recovery channel itself had been rebound to the attacker, subsequent verification and recovery would route back to them rather than the legitimate owner.
10. Action on Objectives - Active. Compromised accounts were reportedly defaced or offered for sale, converting access to high-value accounts into the operational payoff of the chain.

This is best understood as authorization drift inside an AI mediated support process. The AI assistant substituted its goal from helping with support to enabling account control.

Why This Isn’t a Traditional Attack

In a traditional account recovery system, attackers usually need to exploit a software vulnerability, steal credentials, compromise email/SMS, phish the user, or socially engineer a human support representative.

This incident is different because the abuse path flowed through an AI agent that was connected to sensitive account-management capabilities.

The weakness was not just “prompt injection” in the narrow sense. The deeper issue was that the AI support assistant had access to actions that should have required deterministic ownership proof. The attacker did not need to defeat the full security architecture. They needed to convince the AI mediated workflow to initiate the wrong recovery action.

Traditional systems fail when code, credentials, or humans are exploited. AI agentic systems can fail when the model’s interpretation of intent becomes a substitute for authorization.

That makes this incident especially important. It shows that AI support agents can become privilege brokers: systems that translate natural language requests into real account changes. If those changes are not independently validated, the model becomes part of the attack surface.

How to Prevent This Class of Attack

The fix is not simply  to make the model smarter, It is to remove final authority from the model for sensitive actions.

Effective controls include:

Hard authorization gates outside the model.

The AI assistant should never decide whether a user owns an account. Ownership must be verified through deterministic controls such as authenticated sessions, trusted devices, passkeys, existing MFA, recovery history, and risk scoring.

Human-in-the-loop for high-risk account actions.

High-value accounts, public figures, government-linked accounts, brands, and verified profiles should require manual review for recovery-channel changes and password resets.

Tool permission separation.

The AI support assistant should be separated from privileged account management tools. The model can explain the process, but tool execution should be mediated by policy enforcement.

MFA and passkeys.

Reporting suggests the exploit failed against accounts with MFA enabled. Strong MFA, especially passkeys or hardware-backed authentication, reduces the chance that account recovery abuse turns into full takeover.

Auditability and replay detection.

Every AI-initiated support action should be logged with the prompt, model decision, tool call, account risk score, and outcome. Repeated attempts against different accounts should trigger abuse detection.

Kill switches for autonomous support actions.

When abuse is detected, organizations need the ability to immediately disable specific AI-triggered actions, such as email relinking or password reset initiation, without shutting down the entire support experience.

Stop It Before the Bot Hands Over the Keys

This incident shows the danger of giving AI agents authority over identity workflows before the authorization model is mature.

The attacker did not need a zero-day. They did not need database access. They did not need malware. They simply exploited a support agent that could translate a persuasive request into a privileged account action.

For enterprises, the lesson is direct: do not connect AI agents to sensitive tools unless every high-risk action is constrained by deterministic policy, step-up verification, and human escalation where appropriate.

AI can improve support speed, but it must not become the control plane for account ownership.

The real danger is not that AI answers support questions incorrectly. The real danger is that AI agents can act incorrectly — at scale, with privilege, and in workflows where one mistaken action becomes an account takeover.

Lineaje UnifAI closes that gap before it becomes an incident. UnifAI maps your AI inventory, sets policy, and defends at runtime — ensuring that a persuasive support request cannot become a privileged account action without passing through the security constraints your organization requires. UnifAI's policies authenticate every agent, hold each to least-privilege credentials, confine the tools and destinations it can reach, and gate high-risk actions behind human approval — all enforced at runtime, outside the model — so that no AI agent can change a recovery channel, reset a credential, or complete an account-recovery action without deterministic ownership proof and human escalation where appropriate. UnifAI also provides the control and flexibility to orchestrate policies that are most appropriate for your environment.