Four consoles, one person

Tiina Rytkönen 25 September 2026 9 min read

Most companies now run AI in several places at once. The hard part is not connecting to each one. It is working out that the same person is behind all four accounts, and that gets more expensive the longer you leave it.

Governing one AI is a solved problem. Governing several at once is not, and the reason has very little to do with any of them individually.

One number sets the shape of that work, and it is the one that decides what we build and in what order.

Menlo Ventures asked 495 enterprise AI decision makers in November 2025 which providers they use. No single provider has more than 40%.¹

That chart is the whole engineering problem in one picture. There is no provider you can connect to and call the job done, because the largest one still leaves 60% of enterprise use somewhere else. Whichever AI you govern today, you are governing a minority of your own estate.

So the work is never one integration. It is the same job, done again, for every provider, forever.

That sounds like a scale problem. It is not. It is a shape problem, and it took building the second one to see it.

What this looks like from the engineering side

When we started building for a second provider, the connector was not the hard part. Connectors are work, not difficulty.

The hard part is that every provider is its own governance system. Its own admin console. Its own audit log. Its own way of naming things, its own list of events, and its own idea of who or what counts as doing something. When we counted on one provider, it came to 46 settings at the organisation level, 464 different types of event, and six kinds of actor, meaning the different things that can perform an action: people, service accounts, agents and so on. Very little of that lines up with the next provider. All of it moves when the provider changes its API.

A team can build that once. The cost is the second year, and the year after that, for every provider, forever.

Underneath it sits the thing that actually breaks governance. The same employee is a separate account in every system.

Here is what that looks like in practice. Someone joins the finance team and gets a Microsoft 365 account. Over the next year they turn up as a user in a second AI tool through a departmental pilot, as the owner of two projects in a third, and as a member of a workspace someone else set up in a fourth. Four systems now hold part of that person. Each one names them differently. Each records what they do in its own format, under its own ID, with its own view of what is worth recording. None of this is unusual, and none of it is joined up.

Four accounts, four IDs, four audit trails, and nothing connecting them. Ask what one person can reach across all the AI your company runs and no system can answer, because no system holds the whole person.

That is the gap we set out to close. Not seeing into AI. Seeing the estate the AI sits in.

The part that gets more expensive every month

The fair response at this point is that this is a next-year problem. Three reasons it is not, and all three are practical rather than commercial.

The mess grows, and nobody clears it up for you. We have watched this happen once already. Between 2015 and 2020, Microsoft 365 collaboration grew faster than anyone’s governance could keep up with. The companies that started governing after the sprawl spent years cleaning up what the companies who started before never had to. AI has the same shape. It just moves faster. Every month without governance means more accounts, more projects, more shared files and more permissions to sort out by hand later.

Audit logs are not archives. This one is specific to AI and it is the one most people miss. Retention is finite, and how long you get varies by provider and often by plan, so it is worth checking what yours actually keep. Whatever the window turns out to be, the principle holds. Turn governance on in eighteen months and you can see your estate as it stands that day. You cannot see how it got that way.

Every question a security team asks after an incident is about the past. The past you did not record is gone.

Agents change what governance is for. Until recently, AI answered questions. Now it acts. An agent has its own identity, holds its own permissions, and runs without anyone watching. Gartner expects 40% of business applications to have task-specific agents built in by the end of 2026, up from under 5% in 2025.² Once AI acts instead of answering, controlling what it can reach stops being housekeeping. It becomes the thing that decides what an unsupervised system is allowed to do.

Why this cannot be fixed inside the tools

Every provider governs itself, and most do it well. Each one gives you an admin console, an audit log, a permissions model and a sensible set of controls for the thing it covers.

None of them governs across. That is not a criticism, and it is not a gap any of them will close. No provider can see inside another provider. None of them has a reason to build the view that would let you compare its own risk against a competitor’s. The information does not sit in one place, and nothing in the market is going to put it there.

So the question of what one person can reach across all your AI has no owner. The answer is not hard to find. No system is responsible for holding it.

That leaves one place for the answer to live. A layer above the tools, reading from all of them and owned by none of them.

The next question is what that layer is built around, and it decides whether it still works in three years.

Coverage is the obvious answer. Connect to as many providers as you can and show a list for each one. It demos well. It solves very little, because four lists still leave someone joining them up by hand, and the fifth provider adds a fifth list.

We are building around the person instead. Every AI account gets matched back to the same person in Entra ID, the directory the organisation already runs. AI users, projects, sessions, settings and spend then sit in the same inventory our customers already govern Microsoft 365 from. Same policies, same automation, same access reviews.

Identity is the right thing to build on for a simple reason. It is the only part that does not change. Providers come and go. Pilots end, departments switch tools, software gets replaced. The person stays, their job stays, and what they are allowed to reach is what the security team asks about. Governance built around the provider has to be rebuilt every time the provider list changes. Governance built around the person does not.

It also means nobody has to log into a fifth console to fix having four. AI becomes another set of things in a governance model the company already runs.

That approach costs us speed. It is slower to ship than a connector, and it only works where there is a directory to match against. It pays back on the second provider, and on every one after that, because the model does not change when the provider does.

What we are not going to do

We are not going to claim we can govern every AI. There is a sequence, it follows where enterprise usage actually sits rather than where we would prefer to start, and we will set it out in full on 1 October.

I would rather say that than something more impressive. A roadmap you can check is worth more than a claim that falls apart under the first technical question, and this audience asks it early.

What I can tell you now is the shape. Three providers account for roughly 80% of enterprise use,¹ so most of the problem is reachable without boiling the ocean. And the long tail after that does not need a rebuild each time, because governance built around people does not have to be reinvented for every vendor.

What we look at, and what we do not

One more thing, because it is the first question in every security review we go through.

Rencore governs what AI can reach. We work from ownership, permissions, sharing and labels: who owns something, who can get to it, where it has been shared outside the company, and how it is classified. We do not read the contents of conversations, files or prompts to do that.

That is a design decision, not a limitation we are working around. Access is where the risk sits. An agent is only as safe as the data it can reach, and you do not need to read the content to control the access.

The Multi-AI Era: the vision and the roadmap

Webinar, 1 October 2026, 16:00 CET. Matt Einig covers where Rencore is going and why. I cover what governs more than one AI from a single place today, what is being built next, and in what order.

Sources

Menlo Ventures, “The State of Generative AI in the Enterprise”. Published November 2025. 495 US enterprise AI decision makers, surveyed 7 to 25 November 2025. Used here for: which AI providers enterprises use. Anthropic 40%, OpenAI 27%, Google 21%, all others 12%.
Gartner press release, 26 August 2025. “Gartner Predicts 40% of Enterprise Applications Will Feature Task-Specific AI Agents by End of 2026.” Used here for: 40% of business applications having task-specific AI agents built in by the end of 2026, up from under 5% in 2025.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organisation and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Common questions on this

Why can't I just use the admin console each AI provider gives me?

You can, and for the provider it covers it is usually a good console. The limit is that each one sees only itself. It lists its own users, its own projects and its own audit events, under its own IDs, and it has no way to know that the account it calls one thing is the same employee another provider calls something else. Four consoles give you four partial answers and leave someone joining them by hand. The question a security team actually asks, what one person can reach across all the AI the company runs, sits between the consoles, so no single console can answer it.

Does Microsoft Entra ID already tell me which AI tools each employee uses?

Only for the tools federated to it. When an AI service is signed into with a work account through single sign-on, Entra ID records the sign-in and the application, which is useful and worth reviewing. What it does not hold is what happens inside the tool: the projects that person owns, the workspaces they belong to, the settings, the spend and the files they have shared there. A tool bought on a personal card or reached with a separate login does not appear at all. Entra ID is the right anchor for identity, which is why it is the directory to match against, but it is not an inventory of the AI estate.

How long do AI providers keep their audit logs?

It varies by provider and often by plan, so check what each of yours actually retains rather than assuming. The point that matters is that retention is finite. An audit log is a rolling window, not an archive, and anything older than the window is gone for good. If you start collecting those logs into a store you control today, you keep the history from today onward. If you start in eighteen months, you can see your AI estate as it stands on that day and nothing about how it got there, which is exactly what an incident review asks about.

What does it mean to govern AI around the person rather than the provider?

It means every AI account is matched back to one identity in the directory the organisation already runs, so the same employee appears once, with everything they can reach listed under them, instead of once per tool. Rencore does this against Entra ID, then puts AI users, projects, sessions, settings and spend into the same inventory customers already use to govern Microsoft 365, with the same policies, automation and access reviews. The practical gain is that adding a new provider adds data to an existing model rather than a fifth console with its own rules.

Does Rencore read our prompts, chats or files to govern AI?

No. Rencore works from ownership, permissions, sharing and sensitivity labels: who owns something, who can get to it, where it has been shared outside the company and how it is classified. It does not read the contents of conversations, files or prompts to do that. This is a design decision rather than a gap, because the risk sits in access. An agent is only as safe as the data it can reach, and controlling that reach does not require reading the content itself.

Last updated 25 September 2026

About the author

Tiina Rytkönen

Tiina is a tech executive who thrives in the space between "what is" and "what could be." For 20+ years, she led organisations through critical transformations - from scaling enterprise programs in telecommunications to building award-winning digital teams, and currently making a difference for Rencore Governance as VP of Product & Engineering. Tiina embraces taking complex technical or organisational challenges and translating them into executable strategies. Her approach: Bridge the gap between technical reality and business vision. The best solutions come from understanding both the code and the customer, both the sprint and the strategy.