IT Consulting · Capability area
Governing what AI can reach in a Microsoft 365 estate
Copilot and the agents built alongside it have no view of their own. They have the view the tenant already gives to whoever is asking. Governing them is a question about the estate: its permissions, its labeling, and what anybody is allowed to build.
What follows is governance work on a client's Microsoft 365 tenant. Establish what these systems can reach. Decide what they should be able to reach. Make the second true.
What Copilot and agents can reach
An AI tool that authenticates against a Microsoft 365 tenant inherits that tenant's permission model. That is a property of the estate rather than of the tool. It holds for Copilot, for an agent somebody builds in Copilot Studio, and for a third-party assistant a department connects on its own.
The work is establishing what that model resolves to in practice — the effective permissions, not the org-chart version. And it does not finish. Permissions change every time someone moves team, a project ends, or a site is created to solve something quickly.
Deciding whether to switch Copilot on is a bounded engagement with its own page. This capability is the wider version: the same question asked about an estate that keeps changing, and about tools nobody has approved yet.
AI data governance
Deciding what an AI system should be able to use is a different question from deciding who can open a file, and it is answered with different instruments.
In a Microsoft estate that means sensitivity labels, retention, and the container-level controls that keep content out of an index entirely. Labeling is the durable one. A permission is a decision about a person, and it drifts as people move. A label is a decision about the content, and it travels with it.
Most estates arrive with almost nothing labeled. That is the honest starting position rather than a failure. The useful work is deciding what would have to be labeled for an exclusion to mean anything, rather than labeling everything.
The controls themselves sit with data security and identity. This is about what you decide to point them at.
Agent governance in the tenant
An agent is something people in the organization can now create, and it runs with access to whatever its creator or its configured identity can reach.
The governance questions are the ones a tenant has always asked about applications: who may publish one, what identity it runs as, which data sources it is connected to, who can use it, and how anyone finds out it exists. An agent a department built and shared is an application nobody registered.
The work is establishing what exists, what each one can reach, and what the tenant's position is on who may create them at all. That position is a setting, and in most estates it is still on the default.
The subject is AI; the discipline is identity and access, which is why this sits where it does.
Where this leads
Most of this becomes urgent when somebody wants to switch something on. The useful order is to know what the estate permits today, then decide what it should permit.