Account Recovery Is Root Access

If your support bot can change the recovery email, it is not doing customer service. It has root.

Context

The cleanest mainstream agent-permissions story this week did not come from a wallet team, an EIP thread, or another cloud vendor pretending to discover "governance." It came from Meta getting caught with an AI-assisted recovery flow that appears to have handed attackers account ownership at scale.

According to a breach notice reported by This Week in Security, Meta notified at least 20,225 people that Instagram accounts were compromised through "a vulnerability in an AI-assisted account recovery system." The reported failure was brutally simple: the system sent a password-reset link to an email address supplied by the requester even when that email was not associated with the account. Meta's own explanation is worse than the rumor mill. The company said the tool itself functioned as intended, but a separate code path failed to verify that the supplied email matched the account's email before issuing the reset link.

Read that again. The problem was not that the bot said something dumb in chat. The problem was that an AI-mediated recovery path held account-transfer authority and exercised it without a hard boundary around who was allowed to invoke it.

The independent researcher write-up at 0xsid adds the ugliest detail: because the system treated the attacker as the true owner, the flow reportedly bypassed existing 2FA and revoked the real user's sessions. That is not a help-desk bug. That is an ownership-transfer bug.

This is exactly the category error the agent industry keeps making. Companies talk about assistants, copilots, and support flows as though these are conversational wrappers around harmless automation. They are not. The moment an agent can reset a password, swap a recovery address, issue a reset link, or revoke the real user's session, the agent is sitting on the same side of the security boundary as the account owner.

Wallet teams should be paying attention, because the same mistake is about to be repeated everywhere. Recovery is not an edge case. Recovery is the part of the system that can overrule every other control when things go wrong.

Analysis

The lazy industry story is that this was a prompt injection problem, or an AI safety problem, or a chatbot problem. That framing is too flattering. It makes the failure sound novel. It was not novel. It was a privilege design failure wearing an AI nametag.

The core issue is simple: account recovery is a privileged action that changes the identity anchor of the account. That means it needs a different authority model from ordinary support activity. "Can answer a user question" and "can redirect account ownership" are not neighboring permissions. They are different planets.

What should a serious recovery authority object contain?

It should bind the target account, the currently verified recovery channels, the permissible recovery action, the evidence required to unlock that action, the risk score that changes the required evidence, the cooldown window, the notification destinations, the rollback path, and the human or system approver that released the change.

That sounds heavy because it is heavy. Recovery should be heavy. It is supposed to be the moment where the platform decides whether to transfer effective ownership of the account.

Instead, companies keep treating recovery like a support UX problem. Make it smoother. Reduce friction. Let the assistant help. Use chat because chat feels modern. Fine. Then own the consequence: if the assistant can trigger the side effect, the assistant has the authority. Stop pretending otherwise.

This is where the agent-permissions conversation in crypto has been more honest than mainstream product teams. ERC-7710, ERC-7715, smart-account caveats, session keys, and policy engines all start from the obvious truth that authority should be scoped, typed, revocable, and inspectable. Meta's recovery flow appears to have done the opposite. It built a high-privilege path whose effective rule was close to: if the system believes the story, let it rewrite the identity boundary.

That is insane. And it is not isolated to social accounts.

Robinhood now talks openly about agentic trading. Payment providers are building machine-payment flows. Productivity suites want always-on assistants in mailboxes, drives, and calendars. Messaging platforms want agents to book appointments and handle support. Every one of those products is quietly growing a recovery surface. What happens when the wrong agent asks to rotate a key, reconnect a payment instrument, transfer a support thread, or relink an identity? What exactly is the artifact that says the action was allowed?

Most teams do not have an answer. They have logs. Maybe screenshots. Maybe an internal event trail. That is not the same thing.

A recovery receipt should be able to answer at least five questions after the fact:

Who requested the change?

Under which authority path was the request accepted?

Which prior recovery channels were checked or rejected?

Which out-of-band proof released the ownership change?

Which side effects followed from the recovery event?

That is not paperwork. That is the minimum viable proof that the system did not just hand root access to whoever told the best story.

The most revealing line in Meta's explanation is that the issue lived in a "separate code path." That is always where authority systems die. One path has the policy. Another path has the side effect. The industry still behaves as if connecting those two paths is implementation detail. It is not implementation detail. It is the entire security model.

This is why agent permissions cannot stop at the surface-level task description. "Support assistant" tells you almost nothing. The authority object has to describe which exact state transitions that assistant may cause. Can it view an account? Freeze it? Escalate it? Queue a reset? Issue a reset? Replace email? Replace phone? Bypass 2FA? None of those should be inferred from the phrase "customer support."

The same principle applies to wallets and smart accounts. People keep acting as if wallet recovery is a separate topic from agent permissions. It is not separate. Recovery is simply the most dangerous permission in the system. If a future wallet agent can help a user restore access, rotate devices, recover a delegate, or reissue spending authority, then that agent is not a helper unless the recovery path is locked behind stronger proof than the rest of the product.

And yes, that means more friction. Good. Ownership transfer should feel expensive because it is expensive.

Meta's failure should kill one more bad habit: the habit of describing privileged AI actions as if they are "assistive" until proven otherwise. Wrong. The default assumption should be the opposite. If the AI path can change a security-critical state, it is a privileged actor first and a conversational experience second.

That is the right mental model for support agents, payment agents, admin agents, scheduling agents, and eventually every cross-application assistant that claims to "help" with account problems. Help is not a permission class. State transition is.

The Caveat: Recovery can never be fully frictionless and fully safe at the same time. People lose phones, lose email access, get locked out while traveling, and forget which authenticator they used. A platform that makes recovery impossible is broken too. But that tradeoff does not excuse lazy architecture. It means recovery needs its own mandate layer: separate privileges, stronger verification, risk-tiered escalation, cooldowns, out-of-band notices, and receipts that show exactly why the system believed it was allowed to transfer control. Any team shipping "agentic" anything without a separate recovery authority model is building the same breach with nicer product language.