Why Giving AI Agents Write Access to Identity Systems Is a Critical Security Risk

The Scale of the Threat: Why This Matters

As enterprises rush AI-powered support assistants and autonomous agents into production, they are increasingly embedding a new class of risk directly into their Identity and Access Management (IAM) stacks. LLM systems are being trusted with operational authority over sensitive account functions without the explicit authorization controls that such authority demands.

The June 2026 Meta AI Support Assistant incident offered a clear example of how this architectural weakness can be exploited in practice. The underlying decision to grant an AI agent direct write access to authentication state-including email addresses, phone numbers and recovery flows-to reduce user friction reflects a broader industry challenge rather than an isolated incident.

As organizations integrate AI into customer support, workforce identity management and internal access governance, this vulnerability is quietly expanding across enterprise environments. Our researchers at 5Tattva consider this an architectural time bomb that demands immediate attention from security leaders.

Where the Architecture Breaks

The breach mechanics stem from a conceptual conflation that is increasingly being introduced into AI-enabled identity workflows and often overlooked during threat modelling. This is the conflation of authentication and authorization.

Authentication establishes identity by confirming whether a user is who they claim to be. Authorization establishes explicit permission by confirming whether that authenticated identity is permitted to perform a specific state-changing action at that moment.

AI agents typically operate after authentication has already taken place. This context is sufficient for read-only functions such as document retrieval, answering account queries or surfacing information.

The problem begins when this authenticated session is mistakenly treated as implicit authorization to modify critical identity attributes. An active session does not prove that the principal should be allowed to change authentication factors such as a recovery email address or registered phone number.

Furthermore, the verification logic itself is structurally broken.

When an LLM updates the contact vector, the verification OTP is dispatched to the newly provided address. This verifies only that the requester controls the new destination. It does not verify that the legitimate account owner actually intended the change. The architecture therefore verifies forward while completely failing to verify backward, creating an authorization gap that attackers can exploit.

How the Attack Works

One of the most concerning aspects of this vulnerability is that it does not rely on malware, exploit code or traditional privilege escalation techniques. The attack can be executed entirely through natural language interactions with an AI-powered support assistant.

At 5 Tattva, we classify this as an LLM-mediated Confused Deputy attack, or Broken Object Level Authorization (BOLA) executed through an AI proxy. The execution chain is deceptively simple yet highly effective.

An attacker initiates a support session and prompts the AI agent, claiming that they have lost access to their registered email address and need to update their recovery details. The agent, designed primarily to assist users rather than evaluate security intent, accepts the attacker-controlled email address and executes a write request to the IAM endpoint.

The backend then sends the confirmation OTP to the newly registered, attacker-controlled email address. The attacker submits the OTP, successfully validating the new recovery address. From that point, a password reset can be initiated, allowing the attacker to take control of the account within minutes.

The real danger lies not in any single action but in the way these actions combine. Each individual step may appear legitimate when viewed in isolation. However, the complete workflow lacks even a single independent, out-of-band verification step through which the legitimate account owner can intervene before critical authentication factors are changed. This creates an ideal environment for account takeover through conversational manipulation rather than technical exploitation.

The Real Security Problem

The root of this issue is a modern evolution of a vulnerability pattern first described in 1988 as the Confused Deputy problem. A program holding elevated privileges is manipulated by a less-privileged caller into misusing those privileges on the caller’s behalf.

For decades, this pattern remained largely confined to traditional web applications, where endpoints accepted well-defined, structured inputs that security teams could inspect and validate.

Generative AI fundamentally changes this security model.

Unlike conventional applications, an LLM accepts open-ended natural language instructions. Its decision-making process cannot be fully audited through predictable function signatures or predefined input schemas.

By granting an LLM direct write access to IAM systems, organizations are effectively exposing their authentication infrastructure through a natural language interface. The attack surface is no longer limited to hidden API endpoints or administrative consoles. It is now the conversation itself.

This dramatically lowers the barrier for attackers. Rather than exploiting software vulnerabilities, they simply persuade an AI agent to perform privileged operations on their behalf.The result is an authorization failure hidden behind an otherwise legitimate conversation.

Building Stronger Defences

Prompt engineering alone cannot secure identity systems. Security must be enforced through backend architectural controls that remain independent of AI behaviour.

At 5Tattva, we recommend implementing out-of-band cryptographic verification before any authentication factor is modified. Any request to change a recovery email address, registered phone number or other authentication credential should remain pending until the legitimate account owner approves the request through a trusted, previously registered channel.

This approval should rely on cryptographic proof rather than conversational context. Whether through a signed confirmation link or a Time-based One-Time Password (TOTP) challenge tied to the original authenticator, the existing account owner-not the AI agent-must authorize the change.

Organizations should also enforce hardware-backed multi-factor authentication (MFA) wherever possible. FIDO2 and WebAuthnshould be treated as foundational security controls rather than optional enhancements. Because authentication depends on hardware-bound cryptographic keys associated with a specific origin, an AI agent cannot independently generate a valid authentication assertion. Requests originating from an unauthorized source will fail cryptographic validation, providing a robust defence against this class of attacks.

Finally, organizations should apply the principle of least privilege to AI deployments. AI agents should never hold unrestricted write access to IAM endpoints. Their role should be limited to assisting users, collecting information and preparing requests.Authorization must remain the responsibility of verified users and trusted backend systems, which alone should execute identity-changing operations.

Authored by Kunal Mahar, Head – Security Operations at 5Tattva