Microsoft Copilot.png)
Almost nobody decided to run four AI tools. They ended up running four.
A department trials something during a quiet quarter. A team buys a handful of seats to get a project finished. A pilot quietly becomes permanent because it worked and nobody saw a reason to stop it. Within a year there are three or four assistants in the building, bought at different times by different people for different reasons, and no single list of them exists anywhere.
Then the question arrives that IT cannot sidestep. Who is using what, and what can they reach?
This is where a reasonable assumption takes hold, and it stops more governance projects than any budget ever has. People assume they can only see the AI that is already wired into their Microsoft estate. The Copilot licences are visible because Microsoft issued them. Everything else, bought on a different contract or signed up for without single sign-on, feels like a blind spot with no way in. So the project narrows to what is easy to see, which is the part that was never the risk.
The assumption is wrong, and we watched it surface in real time on 1 October.
That was the webinar where our CEO, Matt Einig, set out why AI has outgrown the silo, and where I announced Claude Enterprise governance in preview, our first service outside the Microsoft stack. When we opened the floor, nobody wanted to debate the category. Every question was mechanical. Where does the data come from. Does it matter that we run Claude Enterprise on AWS. Are you reading our chats. The room had accepted the problem before we finished describing it and had moved on to whether the thing actually works.
One question carried more than the rest, and it got about ninety seconds on the day:
For admins to see which users are using which AI tools, do they have to have them connected to 365, or is data pulled through name, email etc?
Attendee question, live Q and A, 1 October 2026
No, they do not. But answering in one word wastes the question, because buried inside it is the assumption itself. It treats seeing the AI and identifying the person as one job. They are two, they work differently, and only one of them involves Microsoft at all.
Here is the full version of the answer that ninety seconds did not have room for.
Reading the AI
The first connection is to the AI service itself. We connect directly to the provider’s own administrative API. For Claude Enterprise that is the Anthropic Compliance API, and it is a read-only credential your administrator issues and can revoke.
From it we build an inventory. Users, groups and roles. Projects, with their owners, visibility and collaborators. Chats as metadata, which means when a chat started, which model it used and what it cost, never what was said in it. Claude Code and Cowork sessions. Artifacts, skills, connectors and plugins. Seats, adoption and token spend, against the organisation’s spend limits.
Microsoft plays no part in any of that. If you connected Claude Enterprise to Rencore and governed nothing else at all, every piece of that would still arrive.
Worth drawing one boundary here before it causes a misunderstanding later. This covers the services your organisation has deployed, the ones with an administrator who can authorise a connection. It does not find the account somebody opened on their own email address and paid for themselves. That is shadow AI discovery, it is a genuinely different problem, and we would rather say so now than halfway through an evaluation.
Identifying the person
The second connection is the one that answers who. Microsoft Entra ID is the anchor, and there are two routes to it.
Where the AI service is connected to Entra ID through single sign-on, the relationship already exists and we use it. In practice that covers most deployments. Few organisations roll out Claude Enterprise without single sign-on, and most would not want to.
Where it is not, we fall back to pattern matching. We start with the email address, which is the obvious candidate and usually the right one, then work through whatever else the two systems agree on.
So to answer the question directly: the data is pulled through the provider, and the person is resolved through the directory, by single sign-on where it exists and by email where it does not.
What happens when the match fails
This is the part worth being plain about, because it is where a lot of governance tools get vague.
If there is no mapping, you still get everything from the first connection. The users, the licences, the adoption data, the costs, the projects, the policies, the automations, the reports. All of it, because none of it depended on Microsoft in the first place.
What you lose is not the Claude picture. It is the sentence that reads across both estates.
You cannot ask what one named person can reach across their Microsoft 365 content and their AI at the same time, because nothing joins the two records together. That is a real limitation and it is the only one. It is also usually fixable, since an unmatched account normally means an address nobody knew about, which is itself worth finding.
Why we did not build this on single sign-on
There is an easier version of this product. Treat single sign-on as the source of truth, read the directory relationship the provider already holds, and skip the matching entirely.
We deliberately did not, and the reason is a governance one rather than an engineering one.
Think about an account that was issued to an email address rather than provisioned through single sign-on. Somebody leaves the company. Their Entra ID account is deactivated, because that is the step every organisation remembers. Their Claude Enterprise account is not, because it was never bound to the directory in the first place.
You are now paying for a seat that belongs to someone who no longer works there, and that person can still sign in. If our model relied on the single sign-on setting, that account would be invisible to us for precisely the reason it is dangerous. Because the model does not rely on it, the account surfaces as a policy violation: active in Claude, deactivated in Entra ID. It ships as a standard policy rather than something you have to think to build.
What it looks like for one employee
The reason any of this matters is easier to see through a person than through an architecture.
Take someone in finance. She has a Microsoft 365 Copilot licence on her work email address. She has a Claude Enterprise seat, issued on a slightly different address. She has a ChatGPT Enterprise seat, on another address again. And she uses Gemini, with no single sign-on at all.
Nobody planned that. It accumulated over a year of pilots, departmental choices and software that arrived faster than anyone’s process for it. Four services now hold a quarter of her each, under four identifiers, in four audit trails.
Ask any one of them what she can reach and you get a quarter of an answer. The question only resolves once those accounts are joined back to a person, and the directory is the only thing in the picture capable of doing that. Providers get adopted and dropped. She stays.
Once she is one person rather than four records, a set of questions that used to need a per-vendor hunt collapse into one query. What AI costs by department rather than by email address. Which employees are holding seats on two providers at once, because somebody assigned both and nobody reconciled them. Which projects have an external collaborator attached. Which artifacts have been shared outside the organisation. Which connectors are reaching into SharePoint, and on whose behalf. None of those are questions about a tool. They are questions about a person, which is why no single provider’s console can answer them.
The clock you cannot wind back
Retention is the detail people discover too late, so it is worth saying out loud.
Claude Enterprise keeps activity for around 30 days. We pull continuously and build a longer history on top of it, which means the record is there when somebody asks a question about something that happened three months ago. ChatGPT Enterprise holds around 12 months, so the window is more forgiving, but the principle does not change. Turn governance on in a year and you can see your estate as it stands that day. You cannot recover how it got that way.
That is the argument for connecting early even if you are not ready to enforce anything. Visibility is retrospective. Policies are not.
Where this goes next
Microsoft 365 Copilot remains our deepest coverage and that is not changing. Claude Enterprise is in preview now. ChatGPT Enterprise follows, with preview during October, and its APIs are richer today, so there is more we can read and more we can act on directly from the console.
Further services come after that, based on what customers tell us they need rather than what we would prefer to build. The model underneath stays the same as the list grows, which was the whole point of building it on the person rather than the provider.
Which brings this back to where it started. The assumption that you can only govern the AI that Microsoft can see is the thing keeping most organisations at one assistant out of four. It is not a technical constraint. It is a belief about how these tools have to be connected, and it is costing people visibility they could already have.
The preview exists so we can test that against real estates rather than our own. If the question at the top of this piece was one you have asked internally, bring us yours.
The Multi-AI Era: the vision and the roadmap
Webinar, recorded 1 October 2026. Matt Einig covers where Rencore is going and why. I cover what has been built, what comes next, and every question from the day, including the one above.
Claude Enterprise governance is in preview now, alongside the Microsoft 365 coverage you already run. Existing customers with the AI & Agents module can ask their customer success manager to switch it on, or request preview access.
Sources
- Rencore webinar, “Your company uses multiple AIs. Why do you only govern one?” 1 October 2026. Matt Einig and Tiina Rytkönen, including the live question and answer session. Used here for: the attendee question, the identity mapping behaviour with and without single sign-on, inventory scope and retention periods.
Coverage and status by product: Microsoft 365 Copilot, available today. Claude Enterprise, preview. ChatGPT Enterprise, coming soon. Rencore reads configuration and metadata only, and governs what the first-party provider exposes through its APIs.
Last updated 5 October 2026
