AI agent authorization needs external policy, not conversational trust

At a glance

What this is: This is an analysis of how a support chatbot let an attacker hijack Instagram accounts by persuading the agent to perform account changes it should not have allowed.

Why it matters: It matters because AI agents now sit in access paths that IAM teams traditionally protected with deterministic rules, and those paths need policy enforcement, identity context, and hard authorization boundaries.

👉 Read Cerbos's analysis of AI agent authorization and Instagram account takeover risk

Context

AI agent authorization fails when a conversational assistant is allowed to make access decisions that should be enforced by policy. In this incident, the issue was not a classic exploit chain but a trust failure in the control plane around account recovery and support workflows.

For IAM and security teams, the question is no longer whether the chatbot can answer correctly. It is whether an agent can be persuaded into granting access, and whether the decision lives outside the agent in a system that cannot be argued out of its own rules.

Key questions

Q: How should security teams govern AI agents that can reset accounts or change credentials?

A: They should treat the agent as a request origin, not an authorization authority. Sensitive actions need external policy enforcement, live identity context, and explicit principal binding before completion. If the assistant can be talked into granting access, the design is still relying on conversational trust rather than controllable authorization.

Q: Why do AI support agents create confused deputy risk?

A: Because they often sit between a user and a privileged backend, yet lack enough context to know whether the caller is entitled to the action. That makes them easy to trick into using their authority for the wrong principal. The risk grows when the agent can complete recovery steps without separate policy evaluation.

Q: What breaks when an AI agent can make its own access control decisions?

A: Access control stops being deterministic and becomes negotiable. A model can be prompted, misdirected, or socially engineered into approving actions that should have been denied, especially in support and recovery workflows. The result is not just a bad decision, but a control plane that can be manipulated through conversation.

Q: What should teams do when an AI agent sits in the account recovery path?

A: They should force every privileged action through a separate authorization service, require verified identity and relationship context, and remove standing permissions from the agent itself. Account recovery should fail closed unless the policy engine confirms the request is legitimate and the actor is entitled to proceed.

Technical breakdown

Externalized authorization for AI agents

Externalized authorization moves the allow or deny decision out of the agent and into a dedicated policy layer. The agent becomes a requester, not the authority, which matters because language models can be prompted, misled, or socially engineered into approving actions that policy would reject. In this model, the agent can initiate a request, but it cannot invent the rule, change the rule, or bypass the rule mid-conversation. That separation is what prevents helpfulness from becoming privilege misuse.

Practical implication: place sensitive account actions behind a policy engine the agent cannot modify or negotiate with.

Confused deputy and unscoped privilege inheritance

A confused deputy happens when a privileged system is tricked into using its authority on behalf of the wrong principal. In agentic systems, this often becomes unscoped privilege inheritance, where the agent carries enough delegated power to act, but not enough context to prove the request is legitimate for the user it claims to represent. The support bot in this case behaved like a deputy that could be induced to help the attacker rather than the real account owner.

Practical implication: separate who asked from who benefits, and require policy to evaluate the real principal before any privileged action proceeds.

Least agency and identity context at decision time

Least agency is the idea that an agent should only hold the minimum authority needed for a task, with no standing permission to act broadly on caller requests. But least agency fails if the system does not also fetch real identity and relationship context at decision time. An agent may know it is acting as a support assistant, yet still not know whether the caller is entitled to reset a password, add an email, or read account data. Without that context, the agent over-trusts the conversation itself.

Practical implication: bind every sensitive action to live identity and relationship data before the agent can complete it.

Threat narrative

Attacker objective: The attacker wanted the support workflow to transfer account control without authentic ownership, turning the assistant into the mechanism for takeover.

1. Entry: The attacker opened a support chat with the AI assistant and presented a request that sounded like a legitimate account recovery workflow.
2. Credential_harvested: The attacker added an email address they controlled, received the verification code there, and used that code to satisfy the bot's ownership check.
3. Escalation: The chatbot accepted the exchange as proof of account control and proceeded to password reset, giving the attacker administrative reach over the target account.
4. Impact: Accounts were hijacked, including the Obama-era White House handle and an account belonging to a US Space Force chief master sergeant.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Conversational access control is a broken assumption, not just a weak control. The support bot treated the conversation itself as evidence of legitimacy, which is exactly the kind of assumption that fails when an agent can be persuaded in real time. Identity verification is necessary, but it does not solve the deeper issue that the authority path was embedded in dialogue. Practitioners should treat conversational approval as an unsafe control boundary.

Confused deputy risk is now an agentic governance problem, not only an application design flaw. Traditional confused deputy patterns assumed a fixed code path, which could be reviewed and constrained. Here, the deputy was a language model that could be negotiated with, which makes least agency and externalized authorization central to the control model. IAM teams need to recognise that the issue is not simply who asked, but which system was allowed to decide.

Least agency becomes the right named concept for AI support workflows. The agent should not hold standing authority to reset credentials, link emails, or expose records on the basis of a conversational request. That privilege must remain externally scoped, condition checked, and context aware at decision time. The implication is clear: support agents are request channels, not authorization endpoints.

Identity context must be resolved outside the agent before any privileged action completes. The assistant knew it was acting in a support role, but that is not enough to prove who the real principal was or whether the request matched entitlement. This is where agentic systems diverge from conventional IAM flows, because the conversational surface can obscure the actual subject of access. Practitioners should redesign around verified principal context, not inferred intent.

Anthropic's Zero Trust guidance is directionally correct here because friction is not a barrier at machine speed. The location check that was bypassed with a VPN demonstrates that soft friction fails when an attacker can iterate quickly and adapt. The important lesson is not to harden the prompt, but to remove authorization authority from the conversational layer entirely. Security teams should assume agent-facing friction will be probed and eventually bypassed.

From our research:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why identity and secret handling remain uneven in real programmes.
• For a broader view of how AI systems intersect with identity and secrets exposure, see AI LLM hijack breach.

What this signals

Conversational authority is becoming a new governance surface. As AI front doors spread across support, IT, and customer operations, the control question shifts from whether the model sounds right to whether a separate system can enforce the decision. Teams should expect more pressure to prove that policy, not dialogue, is the source of truth, and they should align that thinking with the OWASP Agentic AI Top 10.

Least agency needs to be operationalised as a design constraint. When agents can trigger recovery, retrieval, or reset flows, even small permission errors become account-takeover paths. The practical move is to review every agent-facing workflow for standing authority, implicit delegation, and missing principal context before those patterns become normalised.

Account recovery is now a zero-trust problem, not only an IAM support problem. If a support assistant can be persuaded to act, the programme needs stronger separation between request intake and decision authority, plus explicit verification of the real principal. Teams that map this to NIST AI Risk Management Framework governance will be better positioned to classify and constrain the risk.

For practitioners

• Externalize sensitive authorization decisions Move password resets, email changes, record reads, and similar privileged actions behind a policy engine that the agent cannot edit or reason around mid-session.
• Bind requests to verified principal context At decision time, resolve the real human, account, and relationship context from authoritative identity systems before the assistant can complete the action.
• Reduce standing authority in support agents Strip support assistants of default permission to complete account recovery tasks unless policy and context explicitly authorize the specific request.
• Test conversational abuse paths Red-team account recovery, support escalation, and delegation flows by trying to persuade the agent into actions that should fail under policy.

Key takeaways

• This incident shows that AI support workflows can fail because the conversational layer is allowed to decide access, not just request it.
• The evidence is a classic account takeover path disguised as a support interaction, proving that identity checks and friction alone do not stop agent misuse.
• The control that changes the outcome is externalized authorization with verified principal context and least agency for the agent itself.

Key terms

• Externalized Authorization: Externalized authorization keeps the allow or deny decision outside the application or agent and in a dedicated policy layer. The request can be made by the system, but the authority to approve it sits elsewhere. For AI agents, this is what prevents conversational persuasion from becoming privilege escalation.
• Confused Deputy: A confused deputy is a privileged system that is tricked into using its authority on behalf of the wrong party. In agentic environments, the deputy may be a chatbot, support assistant, or workflow agent that cannot reliably distinguish the true principal from the requester.
• Least Agency: Least agency is the principle that an AI agent should only hold the minimum authority needed for its task. It is the agentic analogue of least privilege, but it must be enforced with contextual policy and separate approval paths because the agent can otherwise overreach through natural language interaction.
• Principal Context: Principal context is the verified identity and relationship data used to decide whether a request is legitimate. It tells the authorization system who is actually involved, what account or resource is in scope, and whether the action matches entitlement at the moment of decision.

Deepen your knowledge

AI agent authorization and externalized policy are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing support workflows, recovery paths, or delegated access for agents, it is worth exploring.

This post draws on content published by Cerbos: AI agent authorization and why external policy beats chat-based trust. Read the original.