One Domain, Two Tenants, Only One Governed

An organization licenses ChatGPT Enterprise. An employee opens a second browser profile, signs into the personal account already logged in there, and pastes a customer extract into it. Same laptop, same managed browser, same corporate egress, same person, same web address.

‍

Every control in the path reads that session as ordinary and correct, because by every attribute any of them can see, it is. The account the session belongs to decides whether the conversation is governed, and the account is the one attribute a standard stack does not capture.

‍

Why Can't the Proxy Tell the Difference?

‍

Because there is no field to tell it with. The corporate workspace and a personal account share the host, the certificate, the URL category and the network range.

‍

A gateway log for the personal session is identical to a gateway log for the enterprise one, and both sit among thousands of records for the same domain in a given week. Sorting them requires reading something inside the authenticated session rather than something about the connection, and the connection is all a proxy has unless it decrypts and parses the application traffic.

‍

Does Blocking the Domain Help?

‍

No, and it makes the position worse. Blocking a licensed tool removes the sanctioned path while the personal one moves to a phone or a home laptop, so the organization keeps the exposure and loses the telemetry, which how regulated data reaches these tools covers from the content side.

‍

Why Does the Identity Provider Show Nothing?

‍

Not because of a coverage shortfall, but because no event exists. A personal account is not a registered application in the corporate tenant, so there is nothing for the directory to record.

‍

The distinction matters when somebody asks why the sign-in logs did not catch it. A shortfall implies a source that should have seen something and missed it. Here the directory is complete and correct, and the session simply never touched it. Asking the identity provider to cover this is asking it to log an authentication that happened somewhere else entirely.

‍

What Does the Directory Still Contribute?

‍

Everything about the person, which is what makes the finding reportable rather than merely interesting. Whether the identity sits in a regulated scope, holds a license for the sanctioned workspace, and was working normally that day. The directory establishes that corporate access was available, so the personal session was a choice rather than a workaround, and discovering unsanctioned use starts from that kind of attribution.

‍

Which Attribute Decides Governance?

‍

The tenant. Everything downstream follows from it and nothing else in the session changes.

‍

In the corporate workspace, the conversation sits under retention control, is reachable when legal issues a hold, is producible on request, and can be deleted with proof. In a personal account the same conversation sits outside every one of those, with no administrator path to preserve, export or remove it. Vendor terms differ too, since consumer tiers commonly train on input by default with no enterprise data-processing agreement behind them.

‍

Which Makes One Paste Two Different Events

‍

Identical content into the same tool on the same laptop produces a policy question in one case and an unrecoverable disclosure in the other. The difference is not a matter of degree, and it is decided by an attribute nothing in the path reports.

‍

Where Is the Tenant Visible?

‍

Occasionally on the wire, which is worth knowing because it tells you where the problem is easy and where it is not.

‍

Some vendors put the account tier in the hostname, so a personal-tier session and a business-tier session resolve to different addresses and a single sensor separates them without help. Where that is true, this whole problem is a filter rule.

‍

Most vendors do not. The tier lives inside the authenticated session, available from the application's own compliance interface, from a proxy that decrypts and parses the traffic, or from an agent inside the browser. None of those is a default configuration, and each sees a different subset of the estate. The browser is the only one of the three that sits where the session is rendered.

‍

So the Fact Has to Be Reconstructed

‍

Reconstruction is what an AI Interaction Data Fabric does. One source establishes that a named identity in a regulated scope reached a particular application. Another reads the session and returns which account it belongs to. A third supplies what the vendor's terms permit at that tier. Each reads as unremarkable alone, and the exposure exists only where they overlap.

‍

Is There a Control That Prevents It?

‍

For some vendors, and it is worth checking before building anything. Several AI providers issue each enterprise workspace an identifier and accept a header restricting sessions to approved workspaces.

‍

A gateway configured to inject that header blocks a personal-account session at the network edge, with no incident to investigate afterward. The requirement is a gateway tier that decrypts the traffic, someone to curate the workspace identifier, and an owner for the policy. If your gateway already does data loss prevention on that traffic, the capability is probably present and unconfigured.

‍

Why Doesn't That Close the Category?

‍

Because it is per-vendor. The header approach works where a provider implements it and does nothing for the rest of the AI applications a large enterprise touches, which is a long list growing faster than anyone configures gateway rules. Fixing the two or three largest destinations is worth doing and leaves the general problem standing, which is why the reconstruction approach and the enforcement approach are complements rather than alternatives. An AI data fabric covers the destinations no header reaches.

‍

How Does This Show Up in an Audit?

‍

As an answer nobody can give. An examiner asks which AI tools process regulated data and receives the register. The follow-up question is whether all use of those tools is governed, and that is where the position becomes difficult.

‍

The honest answer is that sanctioned use is governed and the organization cannot demonstrate that all use was sanctioned, because the sessions are indistinguishable. The position is defensible when stated deliberately with the reason attached. It is a poor one when discovered by the examiner in a log review, and worse when the register implies coverage the telemetry does not support.

‍

Which Regimes Make This Concrete?

‍

Anything requiring records to be preservable or producible. A conversation in a personal tenant cannot be preserved on legal hold, collected for discovery or deleted on request, so the same paste that is a manageable policy matter in the corporate workspace becomes a records-preservation problem outside it. Data protection obligations behave similarly, since a subject access request cannot reach a conversation the organization has no path to.

‍

What Does That Mean for the Register Entry?

‍

It needs a field the usual template lacks. Alongside vendor, terms and data classification, whether tenant enforcement is in place for that tool, and whether tenant visibility exists if it is not. Two tools with identical vendor assessments can sit in entirely different positions on that question, and an inventory built from telemetry is where the answer comes from rather than from a questionnaire.

‍

What Should You Check This Week?

‍

Four questions, and the first two need no tooling.

‍

• Which AI vendors expose the tenant: Check whether your top few destinations put the account tier in the hostname or offer a workspace-restriction header.
• Whether your gateway can inject it: If it performs decryption and data loss prevention on that traffic, the capability is likely there already.
• Whether anyone owns the workspace identifier: The control fails quietly if nobody maintains the approved list.

‍

The fourth is the harder one. For any destination with no enforcement path, establish which source in your environment could report the account behind a session, and whether it covers managed browsers only or the whole estate. Where the answer is nothing, the honest position is that governed and ungoverned use of that tool are indistinguishable to you, which is a finding worth recording rather than a shortfall worth hiding, and recording the unit of governance is where it belongs.

‍

What This Changes About Sanctioning a Tool

‍

Approving an AI application is normally treated as a decision about the vendor. Terms reviewed, data processing agreement signed, risk assessment completed, tool added to the register.

‍

None of that governs the session. The vendor is approved and the tenant is what determines whether a given conversation falls inside the agreement, so an approval with no tenant enforcement and no tenant visibility has approved the application while leaving the exposure open. Recording alongside each sanctioned AI tool whether the tenant is enforceable, observable, or neither turns that from an assumption into a documented position.

‍

The Attribute Nothing Reports

‍

A personal-account session inside a sanctioned tool is invisible by construction rather than by oversight. The host, certificate and category are identical, the identity provider has no event to log because a personal account is not a registered application, and the account is the attribute deciding whether the conversation is preservable, deletable and covered by contract. Where a vendor exposes the tenant, a filter or a header settles it. Where it does not, the fact has to be assembled from sources that each see part of the session. Kovrr's AI Security and Governance Platform reads the account behind an AI session and joins it to identity and vendor terms, which is what makes the distinction reportable.

‍

To see which AI sessions in your environment run under corporate accounts and which do not, book a demo mapped to your own estate.