Meta Gave Its AI Support Bot the Wrong Permissions

On May 31, 2026, instructions for taking over an Instagram account began circulating on Telegram. They didn’t describe a zero-day in Instagram’s authentication stack or a credential-stuffing approach or anything requiring unusual technical skill. They described how to chat with Meta’s AI support bot, ask it to add a new recovery email address to an account, and receive the verification code that let you complete a password reset. By the weekend, two high-profile accounts had been defaced — the Obama White House Instagram and the page belonging to the Chief Master Sergeant of the U.S. Space Force — both posted over with pro-Iranian imagery. A second wave of attackers targeted Instagram handles so short they reportedly carry resale values exceeding $500,000. The exploit required knowing a target’s username and owning an email address. That was the full entry requirement.

What the Bot Could Do

Meta built its AI support assistant to handle the difficult end of account recovery: users who have lost access to their registered email, can’t receive SMS codes, or need to reverify ownership after a device change. According to KrebsOnSecurity’s reporting, the bot’s capabilities included relinking a lost email address, triggering password resets, and verifying account ownership. Those are legitimate support functions. They are also, if placed inside an automated system that takes requests from anyone who opens a chat window, a complete account-takeover toolkit.

The specific vulnerability, documented in detail by security researcher 0xsid on June 1, was this: when a user asked the bot to add a recovery email, the bot sent a one-time verification code to that email address and treated receiving it back as proof that the requester owned the account. As 0xsid wrote, there was “no additional check as to whether the email being given is actually something the user has used before.” Owning a code sent to an email address is not the same thing as owning the account that email is being added to. The bot conflated the two. This made it possible for any attacker with a fresh email address and a VPN set to an IP near the target’s location to socially engineer a complete account takeover through what 0xsid called “the first proper zero auth password reset” they had encountered in a major production system.

The bot occasionally requested additional verification, including video selfies. The workaround was equally low-effort: attackers reportedly used AI-generated photos drawn from the target account’s own public feed, which the bot accepted. Accounts permanently reverted to attacker control. Legitimate owners found no human escalation path available. Meta’s support system had, in practice, made account recovery for attackers easier than account recovery for the actual owners.

OWASP Named This Vulnerability Class in 2023

The OWASP Top 10 for Large Language Model Applications, first published in 2023, includes a category called LLM08: Excessive Agency. The definition is: “when an AI system has too much capability, permissions, or autonomy to act on LLM outputs.” OWASP identifies three root causes — excessive functionality (giving the model tools it doesn’t need for its core job), excessive permissions (access rights broader than the task requires), and excessive autonomy (no human review gate on consequential actions). Meta’s support bot had all three. It had account-mutation capabilities that a general support bot shouldn’t need for the majority of interactions. It had permissions to modify account recovery settings without authorization from the account owner through a trusted channel. And it operated autonomously on requests that, under any reasonable security model, should have required out-of-band confirmation.

OWASP’s prevention guidance is explicit: “Limit the plugins/tools that LLM agents are allowed to call to only the minimum functions necessary”; “Utilize human-in-the-loop control to require a human to approve all actions before they are taken”; “Enforce authorization checks in downstream systems rather than relying on the LLM itself.” The same principle appears in Anthropic’s own published guidance for builders deploying agents with real-world capabilities. From Anthropic’s computer use documentation: “Asking a human to confirm decisions that might result in meaningful real-world consequences and any tasks requiring affirmative consent, such as accepting cookies, completing financial transactions, or agreeing to terms of service.” Adding a recovery email to an Instagram account is a decision with meaningful real-world consequences. It is also irreversible: once an attacker has a recovery path into an account, the original owner is locked out until Meta intervenes manually.

The publication dates matter here. OWASP published LLM08 in 2023. The guidance has been public, freely available, and widely discussed in the security community for three years. Meta built and deployed a support bot with account-management capabilities during that period. The exploit that circulated on Telegram on May 31 is not a surprise discovery. It is a textbook case of a documented vulnerability class being instantiated in a production system by a company that had access to the relevant literature and didn’t apply it.

The Tradeoff That Got Made

The reason Meta’s support bot had these capabilities is not difficult to reconstruct. Human account recovery is expensive. A support agent who has to verify identity, review account history, and manually approve email changes costs more per ticket than an automated system that handles the same workflow in seconds. Meta’s platforms collectively handle support requests at a scale where even a small reduction in the fraction of cases requiring human review represents a large dollar figure. Even a one-percentage-point reduction in human-reviewed support tickets across Instagram alone translates to tens of millions of decisions per month that skip the queue. The bot wasn’t built to be exploitable. It was built to be fast and cheap, and someone underestimated what fast-and-cheap cost in a different currency.

This is the tradeoff embedded inside most AI-powered support systems being deployed right now. The business case for automation is real: lower cost per ticket, higher volume capacity, 24-hour availability. The security cost of automation is also real but tends to be felt later, by different people, in different budget lines. When Meta’s support team shipped the bot, the cost of the efficiency gain appeared on their P&L immediately. The cost of the security gap showed up in June 2026 as a Telegram channel full of takeover instructions, which is not a line item that attribution ever traces cleanly back to the original decision.

Meta deployed an emergency patch by June 1. Andy Stone, Meta’s communications director, stated the issue “had been resolved” and that the company was “securing impacted accounts.” No backend database was breached — this was entirely a social engineering attack against an AI agent, requiring no technical exploitation of Meta’s infrastructure. Accounts with any form of multi-factor authentication were not vulnerable: the bot’s recovery flow was apparently not configured to override existing MFA sessions, only to establish recovery methods where none were verified.

That last detail is precise and worth holding. The only users who lost accounts were those who hadn’t enabled MFA. Which is to say: the exploit specifically targeted users who were already the most vulnerable members of the platform. Meta’s AI support bot was configured, in effect, to offer the weakest users the least protection. The people who knew to enable MFA were safe. The people who didn’t were the ones whose accounts ended up in a Telegram trading channel.

What Changes After the Patch

Meta patched the specific mechanism that 0xsid documented. That’s a fix to one exploit path through one bot’s one configuration. It is not a fix to the design philosophy that produced the vulnerability in the first place. The question worth asking about the broader ecosystem is how many other AI-powered support systems — customer service bots, account management tools, identity verification agents — are currently deployed with account-mutation capabilities and no human-in-the-loop gate for irreversible actions.

The answer is not zero. Support automation is one of the most active deployment areas for large language models. The pitch to enterprise buyers emphasizes cost reduction and scale. The security requirement that every consequential action must be confirmed through a channel the requester doesn’t control adds friction, which is exactly what support automation is supposed to remove. When the business case runs against the security principle, the friction tends to lose. The result is a class of systems that are working as designed until they aren’t, and the failure mode looks exactly like what happened to the Obama White House’s Instagram account over the weekend of May 31.

The fix for LLM08 is not complicated in principle. Scope the bot’s capabilities to information and initiation: it answers questions, starts a recovery flow, and tells users what to do next. Any action that changes account-level settings — adding an email address, modifying MFA configuration, transferring account ownership — requires confirmation through a channel the requester cannot impersonate or, when that’s impractical, a human review queue. That adds resolution time and costs more. It is also the only design that doesn’t expose account-modifying capabilities to anyone willing to open a chat window and ask nicely.

OWASP calls the vulnerability Excessive Agency. The name is correct but undersells what it describes. It isn’t that these systems have too much agency in the abstract. It’s that they have been granted the specific capability to take irreversible actions on behalf of users, with no verification that the person requesting those actions is the user. That’s not an edge case. That’s the base case for any sufficiently motivated attacker who finds the bot before the security team does.

AI-generated editorial illustration · TemperatureZero · June 3, 2026