Governing AI across Microsoft 365

Governing AI across Microsoft 365 means making sure AI, including Copilot, only ever sees and uses what each person is entitled to, that its outputs are grounded and auditable, and that sensitive data stays inside the estate. Microsoft 365 already holds your identity, your permissions and your files. AI governance is the discipline of making AI respect those boundaries, prove where its answers came from, and leave a record.

The Microsoft 365 AI governance problem

Most organisations running Microsoft 365 have accumulated permissions the way most organisations do: unevenly. A SharePoint site was opened to “everyone” for a project years ago and never closed. A finance folder inherited access from a parent site nobody audits. A departed contractor’s group membership was never revoked. For a long time this stayed quiet, because finding an overshared document required someone to go looking, folder by folder.

Copilot changes the economics of looking. It answers questions over the content the signed-in user can already access, and it does so instantly, across the whole estate, in natural language. Ask it a broad question and it will draw on anything within that person’s reach. If a salary spreadsheet or a board paper was technically reachable but practically buried, it stops being buried. The permission was always too broad; Copilot simply makes the consequence visible at speed.

This is the point worth being precise about, because it is often misreported. Copilot does not bypass Microsoft 365 permissions and it does not grant anyone access they did not have. It inherits the existing permission model exactly. The governance problem is not that AI breaks security. It is that AI exposes the security posture you already had, and pre-existing oversharing becomes a live issue rather than a dormant one.

How permission inheritance should work

The right mental model is that AI should inherit permissions, never reinvent them. Microsoft 365 is the source of truth for who can see what. Every AI capability placed on top of it should resolve access against that same source, at the moment of the request, for the person making it. If a user cannot open a file in SharePoint, no assistant should be able to read it, quote it, or fold it into an answer on their behalf.

Getting this right is mostly ordinary information-governance work, and it pays off whether or not you adopt AI:

• Correct the permissions themselves. Review broad grants, remove stale access, tighten sites and libraries that were opened for convenience. This is the largest and most valuable part of the job.
• Apply sensitivity labels. Microsoft Purview sensitivity labels let you classify and, where appropriate, encrypt content so the most sensitive material carries its protection with it.
• Use data loss prevention. DLP policies help stop sensitive information leaving the estate or reaching audiences it should not.
• Know entitlement, not just membership. Understand what each role is genuinely entitled to, so access reflects the job rather than the accidents of history.

Do this first and AI becomes far safer to adopt, because the boundary it inherits is one you actually stand behind. Skip it and any assistant, Copilot or otherwise, will faithfully reflect a boundary you never really set.

Copilot on its own vs a governed layer on top

Microsoft Copilot is a strong assistant. It drafts, summarises and answers over your Microsoft 365 content, honours the signed-in user’s permissions, and keeps that interaction inside your Microsoft tenant. For a great deal of everyday work that is exactly what a person needs, and it is a reasonable foundation to build on.

What an assistant does not do, on its own, is make its output governed at the level of the organisation. A helpful answer is not automatically an evidence-grounded one. A drafted paragraph is not automatically approval-gated, nor is it automatically tied to the specific sources it rests on in a way a client or a regulator could later inspect. That is a different property from being a good assistant, and it is the property a governed layer is built to add.

A governed layer on top of Microsoft 365 contributes what an assistant alone leaves open:

• Permission-aware retrieval. Evidence is resolved against each person’s entitlement at query time, so an output can only ever draw on what that person is allowed to use.
• Evidence-grounded outputs. Anything presented as a business fact is derived from retrievable evidence and stays connected to it, so a claim can be traced back to its source.
• Approval and an append-only record. Work passes through a deliberate human decision, and what happened is preserved on a record that later activity adds to rather than rewrites.
• A policy gate in front of the models. Every AI request goes through approved providers, metered and logged, so the organisation always knows what was asked, of which model, on whose behalf.

Keeping evidence and audit on top of Microsoft 365

The two properties that most distinguish governed AI from an ordinary assistant are evidence and audit, and both sit naturally on top of Microsoft 365 rather than inside it.

Evidence means an output stays linked to the material it was built from. When a document says something specific, the sentence carries its sources with it: the SharePoint file, the dated record, the report it rests on. This is not a summary of where an answer “probably” came from. It is a retrievable link, checked against who is entitled to see it, so the difference between a plausible statement and a defensible one is always available.

Audit means the history is kept. Who asked, what evidence was used, who approved the result, and what was ultimately produced are all on the record after the fact, permanently, and cannot be quietly rewritten. Microsoft 365 keeps its own activity and audit logs; a governed layer adds an append-only record of the AI work itself, so the organisation can always answer the two questions that matter later: what was this based on, and who stood behind it.

Neither of these changes Microsoft 365. They ride on top of it. Identity, permissions and files remain exactly where they are, governed by Microsoft as they always were, and the governance layer inherits that ground rather than replacing any part of it.

A short example

A general manager asks for a supplier performance summary ahead of a contract renewal. In an ungoverned version, an assistant produces a fluent paragraph, some of it drawn from a procurement site that was opened broadly two years ago and never closed, and the summary goes into a board pack with no way to say what any figure rests on.

In a governed version, three things are different. First, the permissions were corrected beforehand, so the procurement site is scoped to the people entitled to it and the assistant never had reach it should not have had. Second, each figure in the summary stays linked to its source: a dated delivery record and a signed variation, both retrievable, both access-checked. Third, the summary passes through an approval that is logged. When someone asks, six months on, where the on-time delivery figure came from, the answer takes minutes. Nothing about that is exotic. It is the difference between an assistant that sounds right and work the organisation can defend.

Shared work and the intersection of access

Governance gets harder the moment work is shared, and this is where a lot of well-meaning AI setups quietly leak. If two people collaborate on a document and one of them can see a source the other cannot, an ungoverned assistant will happily let the broader-access person pull that source into shared output, and the narrower-access colleague ends up reading, in the finished work, content they were never entitled to see. The permission was respected at the moment of retrieval and then defeated at the moment of sharing.

The governed answer is to tighten shared work to the intersection of its members’ access. When a workspace is shared, its evidence is re-evaluated against everyone in it, and only material accessible to all members remains in scope for retrieval and generation. There is no per-person redaction and no “share anyway” override; if access differs, the shared evidence set is reduced, not fudged. Everyone in the shared workspace sees the same evidence and the same output, and the system never becomes a way for one person’s access to leak to another. Where that leaves someone needing broader access, the safe path is the ordinary one: request it through Microsoft 365, not around it.

A practical setup

If you are putting AI governance in place across Microsoft 365, a workable order of operations looks like this:

1. Assess your permission posture. Find broad or stale grants, especially SharePoint sites opened to wide audiences. This is where most real exposure lives.
2. Correct oversharing before you scale AI. Tighten access to reflect genuine entitlement, so the boundary AI inherits is one you stand behind.
3. Classify with sensitivity labels. Use Microsoft Purview to label, and where appropriate encrypt, the material that most needs protection.
4. Apply data loss prevention. Put DLP policies in place so sensitive information cannot casually leave the estate.
5. Decide where an assistant is enough, and where governed output is required. Everyday drafting and questions may sit fine with an assistant; anything a client, board or regulator might inspect needs evidence and approval.
6. Add a governed layer for defensible work. Permission-aware retrieval, evidence-bound outputs, approval and an append-only record, with a policy gate in front of the models.
7. Keep the estate as the source of truth. Let identity, permissions and files stay in Microsoft 365, and inherit them rather than building a parallel, uncontrolled layer.

The sequence matters. Reaching for AI controls before fixing permissions is treating the symptom; the permission work is the cure, and it makes everything after it safer.

How Square One fits

Square One is a governed layer that builds on the Microsoft 365 ground an organisation already owns. It inherits identity, permissions and files rather than bypassing them, and it does not replace or reconfigure Microsoft security. Retrieval is permission-aware, resolved against each person’s entitlement at query time. Outputs are evidence-grounded and stay linked to their sources. When a workspace is shared, evidence is tightened to the intersection of members’ access, so shared work never becomes a permission-bypass layer. Every AI request runs behind a policy gate, through approved providers, metered and logged, and Square One is model-agnostic: it uses the right model for each task and keeps the governance constant as models change.

You can see the same discipline applied to different work: documents that defend themselves, where every sentence traces to its source, and operations that stay on the record, where activity sits on an append-only history nothing rewrites. On the model question, our note on not marrying a model sets out why the governance, not the model, is the thing you keep.

Frequently asked questions

Related reading

• What is governed work?
• Enterprise AI governance: a practical guide
• Shadow AI: the definitive guide
• Documents that defend themselves
• Groundwork: Don’t marry a model