Every enterprise AI control you bought attaches to an account. Two thirds of the AI users on corporate laptops are signed in on accounts your tenant has never heard of, so the agreement your counsel negotiated governs a minority of the work.
Verizon's 2026 Data Breach Investigations Report (opens in new tab) put a number on something most security teams had only sensed. Forty-five percent of employees are now regular users of AI on their corporate devices, up from fifteen percent the year before, where the report defines a regular user as someone reaching an AI platform at least once every fifteen days. That tripling is the stat everyone dropped into a board deck. The sentence sitting next to it is the one that should have changed a budget: sixty-seven percent of those users are signing in with non-corporate accounts on those same corporate devices.
Sit with the shape of that. The laptop is managed. The network is yours. The provider is very possibly the exact provider you signed paper with. The account is not. And the account is the only thing your AI controls are attached to.
I run security and DevOps for a fintech that serves more than 1,500 financial institutions, so I sit in a lot of AI vendor reviews. They are thorough. We read the business terms, negotiate the retention window, stand up SSO, wire SCIM, confirm the audit log export, make somebody demonstrate the deletion path. Then we sign, and the control goes on the list as implemented. It is implemented. It is also scoped to a tenant, and a tenant is nothing but a set of accounts.
Every control on your AI inventory binds to an account, not to a person and not to a device
Take your own AI control inventory and, line by line, ask what each control is bound to. This is what I find every time.
- Negotiated business terms. The no-training commitment, the confidentiality language, the DPA, the sub-processor list. All of it applies to traffic from the tenant. A session on a personal login is governed by consumer terms of service that nobody at your company has read.
- Retention configuration. Your thirty-day or zero-retention setting is a tenant property. The personal account runs the provider's consumer default, whatever that happens to be this quarter.
- Admin and audit logs. Workspace logs record workspace activity. There is no line in them for a conversation that never entered the workspace.
- SSO, SCIM, and conditional access. These govern who gets into the tenant. They are silent on someone who never tried.
- Offboarding. Deprovisioning revokes tenant access. It does not touch an account the employee registered on a personal address, and it cannot reach the year of pasted internal material sitting in that account's history.
- Legal hold and eDiscovery. A hold on your tenant preserves your tenant. The other conversations are held by a provider you have no contract with, on behalf of a person, at their discretion.
Not one of those binds to a human or to a machine. Every one binds to a directory object. That is not a flaw in how the vendors built it. That is what tenancy means. The mistake is ours. We bought account-scoped controls and reported coverage as though we had bought device-scoped or person-scoped ones.
One honest caveat, because the title of this piece overstates by a hair. Verizon is counting users, not sessions and not tokens. A third of the users is not literally a third of the traffic, and I cannot tell you whether the ungoverned share of volume is better or worse. That is the problem. The governed side is instrumented and the ungoverned side is not, so the only number you can put in front of a regulator is the one that describes the part you can already see.
The verified domain is the keyspace, and a personal address was never in it
If that sounds abstract, the vendors document the mechanism plainly. OpenAI requires you to verify ownership of one or more email domains before you can configure identity and provisioning at all, which makes the domain the primary key of the entire enterprise identity story. Then comes the line that belongs on the cover of every AI governance program. In OpenAI's own admin documentation (opens in new tab), if an invited user has an existing account on an email address that does not match a verified domain, they are not prompted to migrate it, and they "can keep both their personal account and their access to the Enterprise workspace."
Read that as a control statement rather than a support article. Your enterprise onboarding flow can reach and absorb the shadow accounts that were registered on your domain. It is structurally incapable of seeing the ones registered on a personal address, because domain matching is the mechanism it uses to find accounts at all. The blind spot is not a configuration gap, not a rollout oversight, and not something a sharper administrator closes next quarter. It is the definition of the boundary.
So the employee with a personal login open beside their enterprise login is not evading a control. They are outside its addressable space, and often both windows sit on the same screen with the same document moving between them.
Consumer defaults are the inverse of enterprise defaults, and that is deliberate
The second half of the exposure is what those consumer terms actually say, because the defaults do not merely differ from your negotiated ones. They invert. Anthropic's August 2025 update to its consumer terms is the clearest published example. Claude users on the Free, Pro, and Max plans choose whether their chats and coding sessions help improve the models, and choosing to allow it extends retention from the existing thirty-day window to five years. Anthropic is explicit that the change does not apply to "Claude for Work, Claude for Government, Claude for Education, or API use, including via third parties such as Amazon Bedrock and Google Cloud's Vertex AI."
That is a well-run vendor being transparent about a real product distinction, and I have no complaint with the disclosure. I have a serious complaint with how it lands inside an enterprise. The retention posture your legal team negotiated and the retention posture governing most of your AI users are set by two different documents, and only one of them was ever reviewed. I have argued before that "we don't train on your data" answers the wrong question, because it says nothing about where the data travels and where it rests. The account problem sits a rung below that. On a personal login, even the wrong answer is not yours. You are not a party to the agreement.
A preservation order already showed you which side of the line you are on
There is a cleaner demonstration than any diagram I could draw. During the New York Times litigation, OpenAI was ordered to preserve output log data it would otherwise have deleted. In its own explanation of the order's scope (opens in new tab), OpenAI said the order reached "ChatGPT Free, Plus, Pro, and Team" subscriptions and API use without a zero-retention agreement, and that it "does not impact ChatGPT Enterprise or ChatGPT Edu customers."
The carve-out ran precisely along the tenancy boundary. Not along a data classification, not along a geography, not along how sensitive the content was: along the account. An enterprise workspace was one kind of object under that order and a personal subscription was another, and which one an employee's conversation belonged to was settled the moment they chose an email address.
Now run the same logic in the direction that should worry you. Your enterprise workspace is a system you administer, with an audit trail you can export and a vendor obliged to answer you. A personal account holding your internal material is a third party's system holding a third party's records about your employee, and the route to it runs through a request to a person plus a subpoena to a provider you never contracted with. Every hour you spent designing legal hold for the tenant designed it for the smaller half of the problem.
Discovery tooling finds agents. It does not find a person on the wrong account.
I have published a discovery playbook for this whole category, and I want to be direct that it does not solve this. That playbook hunts fingerprints: non-human identities in your IdP, OAuth consent grants, long-lived access keys, egress to inference endpoints, connector toggles inside sanctioned SaaS. Every one of those signals assumes the shadow thing is an artifact holding a credential. The line I drew between a personal tool and a production system has the same dependency. It classifies things that somebody built.
Nobody built anything here. A person opened a browser tab. At the network layer, a session with a sanctioned provider looks the same whether the account is yours or theirs, because the hostname is identical and the account identity lives inside the TLS session. Your CASB sees an approved destination. Your egress logs see approved traffic. Your DLP might see the payload if you inspect it, and Verizon's data suggests that is where the truth has been hiding: shadow AI became the third most common non-malicious insider action in their DLP dataset in 2025, a fourfold increase over the prior year, drawn from a figure of more than four million untrusted DLP events. The most commonly submitted data type was source code, by a wide margin.
Report the federated share, then ask your provider for the control that does not exist yet
The remedy is not another awareness module and it is not a ban. I have made the make-the-sanctioned-road-easier argument several times on this site and I am not making it a fourth time, because this failure is not primarily a friction problem. Plenty of people with an enterprise seat, an SSO tile, and a two-click login still end up on the personal account, usually because they had it first and their entire working history lives there.
Start with measurement, which is embarrassingly cheap. Publish the federated share of your AI use as a coverage metric and put it beside the SSO coverage percentage you already report, a number your board understands and a control the industry spent years fighting to make table stakes. Here is the arithmetic, and you can run it Monday. Pull distinct internal users with sessions to your sanctioned provider's hostnames from thirty days of proxy or DNS logs. Pull distinct active users from that provider's own enterprise admin export for the same window. The second number over the first is your federated share, and the gap between them is a roster of real people you can go talk to. If you cannot compute it at all, that is itself the finding, and a more useful one than a green tile.
Then push on enforcement at the identity edge rather than inside the application, and here I have to be precise about what exists. The control pattern is proven. Microsoft's tenant restrictions (opens in new tab) let an organization decide which external tenants and which consumer Microsoft accounts may be used from the networks and devices it manages, signaled at a corporate proxy or on the device and enforced during authentication. That is the right shape: the organization, not the employee, decides which account may be used from its infrastructure. The catch is that it governs Microsoft's own identity plane. I am not aware of a published equivalent from any major AI provider, no header you can inject that says allow this tenant and refuse consumer logins, and that absence is the finding rather than a footnote to it. Put the request in your next renewal in writing, and record the answer.
In a regulated shop this is not optional hygiene, it is an obligation you already carry. The FTC Safeguards Rule, at 16 CFR 314.4, requires you to identify and manage the data, personnel, devices, systems, and facilities that enable you to achieve business purposes, and to take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards for the customer information at issue. Read both duties with the account problem in mind. A provider your employee selected, on terms you never read, holding data you cannot enumerate, is not a service provider you retained. It is a service provider you acquired.
Divide your coverage claim by three before an examiner does it for you
When an examiner or a customer asks how AI is governed here, the answer most of us are prepared to give describes the tenant. The terms. The retention setting. The audit log. The SSO enforcement. The deletion path. Every word of it true, and every word of it scoped to a fraction of the real use, and until recently none of us had a defensible number for that fraction.
Now there is one. Forty-five percent of employees are using AI on corporate devices and roughly two thirds of them are doing it on accounts your agreement cannot reach. Take whatever your AI governance program claims to cover, divide it by three, and see whether the sentence still holds up in the room.
I would genuinely like to hear from anyone who has actually measured their federated share of AI use, and especially from anyone enforcing tenant identity at the egress layer for a major AI provider rather than detecting the violation after the fact. If you have that number, tell me how you computed it and what your denominator was, because I have not yet met a security team that could produce it on request. That includes mine.