It was the best of clicks. It was the worst of clicks. Same dropdown. Same user. Same AI app.
One click selects the corporate account and keeps the workflow inside the company's trust boundary. The other selects a personal account and quietly builds a bridge the company cannot see, govern, or revoke.
That is the hidden risk inside every OAuth account chooser. It does not look like a security decision. It looks like a convenience feature. A list of avatars. A few email addresses. The account used yesterday. The account already signed in. The account at the top.
Most users choose in less than a second. The consequences last much longer.
The account chooser is a trust boundary
Modern AI applications run on connected resources. Users do not just sign in. They connect drives, repositories, warehouses, calendars, design tools, and agent infrastructure. Every connection starts at the account chooser.
When a user connects Google Drive, Microsoft 365, GitHub, Canva, Snowflake, or an MCP server, the question is not simply, "Which account do you want to use?"
The real question is: which trust boundary should this AI application be allowed to cross?
A corporate account and a personal account can sit next to each other in the same dropdown. They belong to different worlds. One is managed, monitored, and revocable by the enterprise. The other is not.
What is an Identity Crossover?
An Identity Crossover occurs when an AI application or agent operating in one trust domain becomes connected to resources from another.
It happens in both directions. A corporate AI application connects to a personal Google Drive. Corporate content flows out to unmanaged storage. Personal content flows into corporate workflows. Or a personal AI account connects to a corporate repository, and corporate data becomes reachable through an identity the company does not govern.
Different direction. Same problem. The important point is not which way the bridge was built. The important point is that the bridge exists.
Picture the quiet version. A developer wires a coding agent to GitHub. Two accounts are signed in: the managed work account and the personal one used for weekend projects. GitHub prompts the developer to choose, and the personal account is the one already active. One click later, a corporate coding agent is operating through a personal identity, pulling, branching, and committing across repositories the company believed were inside its perimeter. No alert fires. Nothing looks wrong. The agent simply has reach into the wrong world, through a door security cannot see and cannot close.
Once corporate and personal identities are joined inside the same AI workflow, data moves both ways. Exfiltration and contamination are not separate risks. They are two consequences of the same trust boundary being crossed.
Both cost money. They cost it differently. Exfiltration is a bill you can size — you can see what left and bound the exposure. Contamination is a bill you cannot size — once foreign data enters a corporate workflow, it does not stay where it landed, and you cannot price what you cannot find.
A breach you can bound
Corporate content flows to an account the enterprise does not control. That is a data breach, and it carries a bill: disclosure duties, regulatory penalties, damages to customers whose data moved, trade secrets that lose the protection secrecy gave them. The mercy is that it has edges. It leaves a trail. You can ask what left, when, and through which token, pull the grant, and put a number on the exposure.
A liability you cannot close
Foreign data enters a corporate workflow and does not stay put. Another team's code, someone else's copyrighted text, a second customer's records — copied into a document, embedded into a vector store, summarized into a report, shipped inside a product. The provenance is lost, and the enterprise can no longer prove that what it owns is clean. That is where the money is: infringement and indemnity claims, licenses that force disclosure or fees, a chain of title no diligence will bless, a valuation marked down or a deal called off. Remove the source and the descendants remain.
You cannot revoke a fact that has already been read, or unlearn one that has already shaped an output. Removing the source does not remove its descendants.
Exfiltration is a breach you can close. Contamination is a liability that stays open.
Why the existing controls miss it
The existing controls are not blind. Identity Threat Detection and Response (ITDR) flags suspicious logins. Cloud Access Security Brokers (CASB) and SaaS Security Posture Management (SSPM) can tell a personal account from a corporate one. Data Loss Prevention (DLP) may catch a file moving between services.
Each control sees its own slice in isolation. The identity provider sees a valid login. The OAuth provider sees a valid grant. The secure web gateway sees an approved domain. Every signal is legitimate on its own.
What no single control sees is the pairing: which identity is operating the AI application, and which identity authorized the connected resource. That pairing is the decision that mattered most, and it lives in the half-second inside the chooser, between two controls, owned by neither.
Agents make it quieter still. When a connector binds through an OAuth flow, it attaches to whichever identity is active or selected, and it does so without a human watching the dropdown at all. A personal GitHub account becomes attached to a corporate coding agent. A corporate repository becomes attached to a personal AI workspace. There is no malicious intent. No clever attack. No bypass. Just the wrong click, or no click at all.
The standard is closing the chooser
Some will say the click is already solved. In June, the Model Context Protocol made Enterprise-Managed Authorization stable. It removes the chooser. The identity provider decides in advance, and the personal account never appears in the list. The account-selection mistake cannot happen if there is no selection to make.
That is real progress. It is also narrow. It governs the connectors that have adopted it, reached through the identity providers that support it, inside the organizations that have configured it. Today that is seven connectors and one identity provider, in beta. Every other AI app still presents the dropdown. Every unmanaged tool still trusts the human.
And where the chooser is gone, one thing does not change. The protocol governs which bridge is built. It does not govern what crosses once the bridge is standing. It authorizes the connection. It does not watch the traffic. Removing the wrong click is not the same as supervising the right one.
Supervision begins at the click. It does not end there.
Supervision starts at the click
The pairing is the signal. The pairing is what gets missed.
The account chooser was never designed to understand enterprise trust boundaries. It presents identities and trusts the human to choose correctly. That is no longer enough. AI applications now act across documents, code, customer data, internal systems, and connected tools. A single account-selection mistake hands an assistant reach into the wrong world.
Classie supervises that moment. Across its three stages, Discover, Analyze, and Supervise, it observes which identity is operating the application, which resource is being connected, and whether the pairing crosses trust domains.
At Discover and Analyze, security teams can finally see where Identity Crossovers are happening: who connected what, when, and how often. At Supervise, visibility becomes enforcement.
The difference is not the app. It is not the model. It is not even the prompt. It is the identity selected in the dropdown.