Before an assistant helps people find more information, check whether that information should be available to them. Review sharing, content protection and ownership, then set the rules for the agents you intend to use.
Start with oversharing
Review organization-wide access, anonymous links and external guests separately. Each can expose content to a different audience, so one membership list is not a complete sharing review.
Ask the content owner which audiences still need the material. Preserve a useful collaboration route while removing access that no longer fits the work.
Name the team that needs the library and the work it supports. That gives the owner a clear basis for confirming membership and permissions.
That purpose gives the access review a concrete audience to preserve while other routes are reconsidered.
Remove an external sharing route when the guest no longer has a reason to reach the content. Check the actual permissions and links so the intended restriction takes effect.
Legitimate external collaboration may still be needed. Give it a reviewed scope that matches the material and purpose, rather than treating every guest the same way.
Bring broad sharing back to an intended audience with an accountable owner. The aim is to keep the right material available for the work.
Revisiting those routes when projects and participants change helps the content owner keep the sharing decision current.
Review organization-wide access, anonymous links and external guests separately. Each can expose content to a different audience, so one membership list is not a complete sharing review.
Ask the content owner which audiences still need the material. Preserve a useful collaboration route while removing access that no longer fits the work.
Name the team that needs the library and the work it supports. That gives the owner a clear basis for confirming membership and permissions.
That purpose gives the access review a concrete audience to preserve while other routes are reconsidered.
Remove an external sharing route when the guest no longer has a reason to reach the content. Check the actual permissions and links so the intended restriction takes effect.
Legitimate external collaboration may still be needed. Give it a reviewed scope that matches the material and purpose, rather than treating every guest the same way.
Bring broad sharing back to an intended audience with an accountable owner. The aim is to keep the right material available for the work.
Revisiting those routes when projects and participants change helps the content owner keep the sharing decision current.
Microsoft 365 Copilot can surface organizational content the user already has permission to view, so broad sharing shows once people ask questions. Start with old sharing links, broad groups and sites without an active owner, in a defined part of the estate, with its content owners.
Use Microsoft Purview to classify content according to its sensitivity. The classification gives people a shared basis for deciding how the material should be handled.
That gives the organization a basis for discussing how the material should be handled.
A sensitivity label can identify content and apply configured protection, including encryption. Check the settings behind the label and the policies that use it before relying on a restriction.
The owner therefore needs to understand both the label’s meaning and the controls configured around it.
Review Entra identities and group assignments alongside the content controls. Classification does not settle who has been granted access to the underlying service.
A review of content handling should still account for the assignments that allow people and applications to reach it.
Classification, sensitivity labels and configured policy have distinct roles. Identity and group access remain part of the overall model.
This makes the control decision explainable: what the content means, who can reach it and which handling rules apply.
Use Microsoft Purview to classify content according to its sensitivity. The classification gives people a shared basis for deciding how the material should be handled.
That gives the organization a basis for discussing how the material should be handled.
A sensitivity label can identify content and apply configured protection, including encryption. Check the settings behind the label and the policies that use it before relying on a restriction.
The owner therefore needs to understand both the label’s meaning and the controls configured around it.
Review Entra identities and group assignments alongside the content controls. Classification does not settle who has been granted access to the underlying service.
A review of content handling should still account for the assignments that allow people and applications to reach it.
Classification, sensitivity labels and configured policy have distinct roles. Identity and group access remain part of the overall model.
This makes the control decision explainable: what the content means, who can reach it and which handling rules apply.
A label identifies how sensitive content is and can apply configured protection; the result depends on the label, the policy and the application using the content. Start with a manageable set, and confirm the licences and who will maintain the configuration.
Review employees and guests against the Entra identities and group assignments they use. An assignment that made sense at the start of a project may no longer fit the person’s work.
The review needs to connect each assignment to the person’s current role in the work.
Follow each group assignment through to the sites and libraries it permits. The owner needs to assess the actual content available, not just the name of the group.
The destination matters: an owner needs to know which business content the assignment makes available.
Review application identities and their assigned permissions alongside people. For delegated access, also consider the signed-in user; application-only access needs its own grant assessment.
Applications can remain relevant to the access picture even when the human membership list looks correct.
The intended content scope is reached through both human and application access. Each route has its own assignment to review.
Keeping those routes visible gives the content owner a fuller basis for confirming who and what should reach the material.
Review employees and guests against the Entra identities and group assignments they use. An assignment that made sense at the start of a project may no longer fit the person’s work.
The review needs to connect each assignment to the person’s current role in the work.
Follow each group assignment through to the sites and libraries it permits. The owner needs to assess the actual content available, not just the name of the group.
The destination matters: an owner needs to know which business content the assignment makes available.
Review application identities and their assigned permissions alongside people. For delegated access, also consider the signed-in user; application-only access needs its own grant assessment.
Applications can remain relevant to the access picture even when the human membership list looks correct.
The intended content scope is reached through both human and application access. Each route has its own assignment to review.
Keeping those routes visible gives the content owner a fuller basis for confirming who and what should reach the material.
Ask content owners to confirm who still needs access, reviewing people and groups alongside the separate permissions granted to applications and agents. Give each finding an owner who decides whether access stays, changes or ends; available reports depend on the workload and configuration.
Decide who may build agents and keep an inventory of the ones the organization operates. Give each agent an owner who can explain its purpose.
That inventory gives the organization a place to account for the agents it is choosing to operate.
Record the identity each agent uses and the data it is allowed to reach. Review that access against the job the agent is intended to perform.
Check each assignment in its actual environment. Similar-looking agents can have different permissions, owners and consequences if they use the wrong information.
Review a new agent’s purpose, owner and access before bringing it into use. Keep the inventory current when an existing agent takes on different work.
This keeps growth connected to a decision about purpose and data reach instead of allowing the inventory to fall behind use.
Permission to build an agent does not settle what data it should reach. Maintain the builder rules, inventory and access decisions together as the service grows.
The organization needs to maintain those decisions as agents are added or their work changes.
Decide who may build agents and keep an inventory of the ones the organization operates. Give each agent an owner who can explain its purpose.
That inventory gives the organization a place to account for the agents it is choosing to operate.
Record the identity each agent uses and the data it is allowed to reach. Review that access against the job the agent is intended to perform.
Check each assignment in its actual environment. Similar-looking agents can have different permissions, owners and consequences if they use the wrong information.
Review a new agent’s purpose, owner and access before bringing it into use. Keep the inventory current when an existing agent takes on different work.
This keeps growth connected to a decision about purpose and data reach instead of allowing the inventory to fall behind use.
Permission to build an agent does not settle what data it should reach. Maintain the builder rules, inventory and access decisions together as the service grows.
The organization needs to maintain those decisions as agents are added or their work changes.
An agent may use a person's delegated access or a separate application identity. Before approving it, establish which one does the work and what it can reach, and record its owner, purpose and approved connections. Adding an agent does not fix an overshared source.
Decide which credentials and environments coding agents may use, which actions need review and how changes are tested. Claude Code, Codex and GitHub Copilot differ in administration and reporting. Matt builds this website with Claude Code and Codex under maintained instructions, tests and human review.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Bring sites used by Finance, Operations and project teams into a common inventory. Different work may need different controls, even when it uses the same platform.
A shared inventory gives the organization a way to compare those contexts without assuming they need identical treatment.
Assign an owner who can explain why each site exists and who needs it. Later decisions about sharing and cleanup need someone able to act on the findings.
Confirm that ownership with the responsible team. An empty field or an outdated name leaves the review without a decision-maker.
Review what is sensitive and how it is shared at each site. A broad audience may be appropriate for one collection and wrong for another.
Considering them together helps the owner assess whether the audience fits the content’s purpose and sensitivity.
Use the inventory to assign review work, with ownership and sharing questions attached to the relevant sites. The example records illustrate what to collect, not findings from a client tenant.
The useful outcome is an inventory that leads to decisions, with responsibility for keeping those records current.
Bring sites used by Finance, Operations and project teams into a common inventory. Different work may need different controls, even when it uses the same platform.
A shared inventory gives the organization a way to compare those contexts without assuming they need identical treatment.
Assign an owner who can explain why each site exists and who needs it. Later decisions about sharing and cleanup need someone able to act on the findings.
Confirm that ownership with the responsible team. An empty field or an outdated name leaves the review without a decision-maker.
Review what is sensitive and how it is shared at each site. A broad audience may be appropriate for one collection and wrong for another.
Considering them together helps the owner assess whether the audience fits the content’s purpose and sensitivity.
Use the inventory to assign review work, with ownership and sharing questions attached to the relevant sites. The example records illustrate what to collect, not findings from a client tenant.
The useful outcome is an inventory that leads to decisions, with responsibility for keeping those records current.
Bring the sites different teams use into one inventory, with an owner who can explain why each exists and who needs it. Review sensitivity and sharing together, then turn the inventory into assigned review work.
The person must already have permission to the content. That is one condition in the restricted-access model.
The permission review still needs to establish why the person should reach the material.
The person must also belong to the restricted-access group.
This adds another condition to the access decision. Membership in that group alone does not grant content permission.
For restricted site access, check both existing content permission and membership in the designated control group. Review the site’s configuration before treating either assignment as sufficient.
The intended result depends on the permission and group checks working together for the protected content.
Restricted access combines an existing content permission with restricted-access group membership.
An owner needs to review both assignments as responsibilities change so the protected site remains available to the intended people.
The person must already have permission to the content. That is one condition in the restricted-access model.
The permission review still needs to establish why the person should reach the material.
The person must also belong to the restricted-access group.
This adds another condition to the access decision. Membership in that group alone does not grant content permission.
For restricted site access, check both existing content permission and membership in the designated control group. Review the site’s configuration before treating either assignment as sufficient.
The intended result depends on the permission and group checks working together for the protected content.
Restricted access combines an existing content permission with restricted-access group membership.
An owner needs to review both assignments as responsibilities change so the protected site remains available to the intended people.
Restricted site access adds a second condition: a person needs existing permission to the content and membership in the site's control group. Owners review both assignments as responsibilities change.
Choose which sensitivity-labeled content a Purview DLP policy should exclude from supported Copilot response processing. Set the policy scope around the information and experience you need to control.
The policy decision needs to be explicit about which labels it addresses and what processing it excludes.
A configured DLP rule can prevent selected labeled files or emails from being used in a Copilot response. An excluded item may still be cited, so this is not the same as removing the user’s access.
Test the policy in the supported experience with representative content. The label, rule and scope need to produce the intended result together.
Keep the content needed for legitimate questions available within the user’s permissions. The policy should distinguish the selected exclusion from the work it is meant to support.
The intended control distinguishes the selected exclusion from the content that can support the response.
Check that selected content is excluded and permitted content remains usable in the intended experience. Review the result when the policy, labels or content change.
An owner needs to confirm that this distinction matches the organization’s intended use and maintain it when content or configuration changes.
Choose which sensitivity-labeled content a Purview DLP policy should exclude from supported Copilot response processing. Set the policy scope around the information and experience you need to control.
The policy decision needs to be explicit about which labels it addresses and what processing it excludes.
A configured DLP rule can prevent selected labeled files or emails from being used in a Copilot response. An excluded item may still be cited, so this is not the same as removing the user’s access.
Test the policy in the supported experience with representative content. The label, rule and scope need to produce the intended result together.
Keep the content needed for legitimate questions available within the user’s permissions. The policy should distinguish the selected exclusion from the work it is meant to support.
The intended control distinguishes the selected exclusion from the content that can support the response.
Check that selected content is excluded and permitted content remains usable in the intended experience. Review the result when the policy, labels or content change.
An owner needs to confirm that this distinction matches the organization’s intended use and maintain it when content or configuration changes.
For supported content, a Purview DLP policy can keep selected labelled files and emails out of Copilot responses. The person's access is unchanged. Test the policy in the experiences your team uses, and check that permitted content stays usable.
Current content needs maintenance so it remains useful to the people and tools that rely on it.
The named owner needs a way to notice when the material no longer reflects the work.
Duplicate content receives a review before removal.
That decision needs to account for which copy is authoritative and how the material is still being used.
Inactive content is reviewed for archiving. Retained content follows its retention policy.
Those are different lifecycle decisions: a lack of recent use does not by itself settle what must be kept.
Current, duplicate, inactive and retained material each call for an explicit handling decision.
The named owner connects those decisions to business use and policy, keeping cleanup deliberate and accountable.
Current content needs maintenance so it remains useful to the people and tools that rely on it.
The named owner needs a way to notice when the material no longer reflects the work.
Duplicate content receives a review before removal.
That decision needs to account for which copy is authoritative and how the material is still being used.
Inactive content is reviewed for archiving. Retained content follows its retention policy.
Those are different lifecycle decisions: a lack of recent use does not by itself settle what must be kept.
Current, duplicate, inactive and retained material each call for an explicit handling decision.
The named owner connects those decisions to business use and policy, keeping cleanup deliberate and accountable.
Retention decides how long information is kept and when it can be removed. It does not replace access control or a policy that excludes content from AI. Review duplicates before removing them, and treat inactive content differently from retained content.
Restricting discovery and removing access are different decisions. SharePoint Restricted Content Discovery keeps a site out of organization-wide search and Copilot while you review it, but a person with access can still open the content. Allow time for the setting to take effect, then verify it.
A person with existing permission can still open content directly when its discovery is restricted. If that access is no longer appropriate, review the permission itself.
That route remains part of the access picture even when the organization changes how broadly the content is discovered.
Restricted Content Discovery limits a site’s content in organization-wide search and Copilot discovery, including recently interacted files. Use it while reviewing permissions and governance.
Restricting discovery does not revoke existing permissions. Keep the permission review active when the goal is to change who may reach the content.
Discovery settings affect how people find material; permissions determine their direct access. Review both against the business purpose before calling the content appropriately restricted.
An owner seeking to change who can access content must review the permissions as well as the discovery configuration.
A person with existing permission can still open content directly when its discovery is restricted. If that access is no longer appropriate, review the permission itself.
That route remains part of the access picture even when the organization changes how broadly the content is discovered.
Restricted Content Discovery limits a site’s content in organization-wide search and Copilot discovery, including recently interacted files. Use it while reviewing permissions and governance.
Restricting discovery does not revoke existing permissions. Keep the permission review active when the goal is to change who may reach the content.
Discovery settings affect how people find material; permissions determine their direct access. Review both against the business purpose before calling the content appropriately restricted.
An owner seeking to change who can access content must review the permissions as well as the discovery configuration.
Start with the content and audiences to review first. We help you decide what to fix before wider AI use, and who keeps it fixed.
Review sharing, labels and ownership across a defined part of your content, then prioritize the changes before wider Copilot use.
Decide who can build agents, which identities and connections they use, and how coding agents are reviewed and tested.
Information you can let AI reach, with owners who keep it that way.
Matt's Microsoft 365 work includes access refactoring, guest access, sensitivity labels and data loss prevention, an Entra ID model for 6,000 internal and external users, and Copilot architecture since 2023.
Bring the Copilot rollout you are planning, or the one that stalled.