“It only shows users what they can already access” is true, and it is the most misleading true sentence in enterprise AI. The permission model held still when you switched Microsoft 365 Copilot on. What changed is the cost of discovery — and effort, rather than entitlement, was doing most of the protective work in your tenant.
Both halves of the point, in one place. Microsoft’s documentation states that Copilot “only surfaces organizational data to which individual users have at least view permissions”, and then, in the next breath, tells administrators it is important that they are using the permission models available in Microsoft 365 to ensure the right people have the right access. The first sentence gets quoted in board packs. The second one is the obligation.
Plain-English explainer · Microsoft product behaviour, blade locations and cmdlet parameters change — verify current documentation before you script or budget · Last reviewed August 2026
Microsoft 365 Copilot enforces your existing permissions and does not repair them, and that is the whole problem. A retrieval-grounded assistant collapses the effort required to discover information: finding the compensation model on a site nobody remembers used to require knowing it existed, knowing roughly where it lived, and caring enough to look. Now it requires asking a question in ordinary language. Every latent over-permission in the tenant — the site shared with the whole organisation “just for now” in 2021, the ownerless project site, the link that was meant for two people — moves from theoretically exploitable to routinely exercised, by employees who are attacking nothing and will believe they have done nothing wrong. Everything on this page is an access-control finding made visible, which is why the fix is sequenced remediation rather than a feature toggle. What follows is the retrieval mechanism in precise terms, the six Microsoft 365 surfaces where the debt accumulates and the admin paths and cmdlets that measure them, why executives are the worst population to pilot on, a remediation-priority table, what an AI management system asks that Purview leaves empty, why Copilot Studio agents are separate systems, how Microsoft Graph connector permissions resolve, where prompts and responses live for eDiscovery and legal hold, and the populations and sample sizes an examiner works from.
Key Takeaways
- The reassurance is accurate and incomplete. Copilot enforces the existing permission model and leaves it exactly as it found it. What changes at rollout is how likely it is that somebody reaches a given document. In most Microsoft 365 tenants obscurity was doing the protective work, and removing it exposes years of accumulated grants nobody revisited because nothing ever forced the question.
- The debt has named sources: organisation-wide claims on sites that were never meant to carry them, organisation-scope sharing links, Teams membership that only ever grew, ownerless and inactive sites, and meeting transcripts nobody assigned an audience to.
- Executives are the highest-risk accounts because broad standing access, delegated mailboxes and genuinely sensitive material compound — and piloting with the leadership team means testing an unverified permission model on the identities where a mistake is least recoverable.
- Restricted Content Discovery buys calendar time and changes what users see: permissions stay as they are, while the site loses its Copilot entry points and gains a visible Restricted tag. Budget comms for it and give every restriction a lift date.
- Purview, sensitivity labels and DLP answer one of the nine governance questions well and contribute to two more. Purpose, ownership, impact on people, competence, lifecycle, suppliers and the decision trail sit outside them — which is exactly the list an ISO/IEC 42001 assessment works through.
- Copilot Studio agents and Microsoft Graph connectors are separate systems with their own identities and authorisation models. The moment the retrieving identity stops being the person asking, “it only shows what the user can already see” stops being true.
What actually happens when someone asks
Trace the path, because the governance questions all hang off it. A prompt is grounded against the tenant’s search index and the semantic index built over Microsoft Graph content. The retrieval step executes as the asking user’s identity, so item-level access control lists are applied at retrieval time rather than filtered afterwards. The passages that survive that check are passed to the model together with the prompt, and the response comes back with citations pointing at the source items. That is why the permission model is load-bearing: it is evaluated inside the loop, on every question, for every user.
Scope follows from the same fact. Content is reachable only if it is in the index, which means SharePoint, OneDrive, Exchange and Teams are in by default, and a file share, a Confluence space or a Jira project is outside it until a Microsoft Graph connector puts it there. That is the reason the connector section further down is load-bearing rather than an appendix: enabling a connector is the act that extends the blast radius beyond Microsoft 365. Indexing scope, semantic index coverage and connector behaviour all change between releases, so confirm the current position in Microsoft’s documentation before you write any of it into a control description.
Access control in a real organisation has two components, and only one of them is written down. The documented half is the entitlement: who is permitted to open what. The undocumented half is friction — the practical difficulty of finding a particular document among several million, in a tenant with thousands of sites, using a search engine that rewards knowing the right noun. For twenty years the second half quietly carried a great deal of load. Nobody designed it that way. It simply held.
A grounded assistant removes three barriers at once. You need no prior knowledge that a document exists, because you can ask about the subject. You need no idea where it lives, because retrieval spans the estate. And you need no keyword instinct, because the question is the interface. What remains is the entitlement layer on its own, load-bearing for the first time, in a tenant where it was never maintained to that standard.
Put in the terms a risk committee already uses: impact held still, and likelihood changed by an order of magnitude. The set of documents a given employee is entitled to open is identical the day before and the day after. The probability that they open a specific one they were never intended to see goes from something close to zero to something close to one, for anything an ordinary question would surface. That is the entire mechanism, and it is why an accurate statement about permissions is such a poor answer to a question about risk.
Two secondary effects matter enough to name. The first is citation: a grounded answer tells the reader where the source lives, so one accidental disclosure becomes a durable pointer to everything else on that site. The second is aggregation: summarisation assembles fragments that are individually unremarkable into a paragraph that is not. Ten scattered references to a restructuring become a coherent account of a restructuring, which is a different disclosure from any of its parts.
None of this is new as a control requirement. ISO/IEC 27001:2022 already asks for access control rules established on the basis of business and information security requirements (Annex A 5.15), with A 5.18 and A 8.3 both requiring access to follow the organisation’s topic-specific policy on access control — A 5.18 across the joiner-mover-leaver lifecycle, A 8.3 as a restriction on access to information itself — and A 8.2 requiring privileged rights to be restricted and managed. Under the SOC 2 trust services criteria, CC6.3 already asks that access be authorised, modified and removed on the basis of roles and responsibilities, with least privilege and segregation of duties considered, and CC6.1 and CC6.2 sit alongside it. The deployment creates none of these obligations. It makes the gap between them and your tenant impossible to ignore. Our access control primer covers the underlying model.
Six surfaces that accumulate quietly
Over-permissioning has six distinct accumulation mechanisms, with different owners, different remedies and different reports. The third column names what to run. The fourth gives typical ranges seen in remediation work — treat them as orders of magnitude and benchmark against your own first run. Product names, report locations and behaviour change, so confirm each against current Microsoft documentation before you write it into a control description.
| Surface | How the debt accrues | What to run | What you typically find |
|---|---|---|---|
| SharePoint site permissions | Sites are created faster than they are governed. Permission inheritance gets broken for one folder and never restored, direct grants accumulate alongside group-based ones, and a site provisioned for a six-week project outlives the project by four years. Nobody revokes anything, because nothing has ever made the grant visible. | The SharePoint Advanced Management (SAM) data access governance reports in the SharePoint admin center: the site permissions baseline report for a tenant-wide snapshot of permission structure, and the site permissions for users report, which inverts the question and lists every site a named individual can reach. | In a decade-old tenant, expect a four-figure site count and a long tail with broken inheritance. Expect the per-user report on an ordinary employee to return tens of sites and on a long-tenured manager to return several hundred. |
| “Everyone except external users” grants | A built-in claim that resolves to every internal account in the tenant. It is applied to make a site work for a launch, a policy rollout or an all-hands, and it is almost never removed afterwards. It is also applied by default in some provisioning paths that administrators did not choose and have never audited. | The Everyone except external users (EEEU) sharing report under Reports · Data access governance in the SharePoint admin center, which surfaces the top sites where content was shared organisation-wide over a rolling lookback, together with the security policies applied to those sites. | A two-figure count of sites carrying an organisation-wide claim is normal in a mature tenant, with a handful of them in HR, finance or legal. That handful is the whole reason to run the report. |
| Teams membership and channel sprawl | Teams membership grows monotonically. People are added for one thread and stay for years. Every team carries a SharePoint site behind it whose permissions follow that membership. Standard channels expose everything in the team, and shared channels can reach identities in other tenants. Leavers from a project are removed from the project, and stay in the team. | A membership export per team, reconciled against current role, plus the tenant list of shared channels and their external participants. Microsoft Entra ID group membership is the authoritative source where teams are group-backed. Treat channel type as a permission decision. | Expect median team membership to exceed the number of people who posted in the last quarter by a wide margin, and expect at least a few shared channels with external participants that nobody currently owns. |
| OneDrive and sharing links | Link-based sharing is a parallel permission system that no site-level review sees. “People in your organisation” links behave like an EEEU grant with none of the visibility, get pasted into chats and tickets, and outlive their purpose. Tenants that permit “Anyone” links carry the same problem with the boundary removed. | The sharing links reports under Data access governance, which rank sites by links created over a rolling lookback and separate “Anyone”, “People in the organisation” and “Specific people” links. Then set the default link type and link expiry with Set-SPOTenant in the SharePoint Online Management Shell. | On the top-ranked sites, organisation-scope links routinely outnumber specific-people links. Expect the backlog to be four or five figures across the tenant and to keep growing until the default is changed. |
| Ownerless, inactive and orphaned sites | The owner leaves, the project closes, the site remains — indexed, permissioned as it was on its last active day, and with nobody left who can answer a question about it. These are the sites where the permission model is least likely to reflect any current intent, and most likely to be surprising. | SAM site lifecycle management policies: site ownership policies to detect and fix ownerless sites, inactive site policies to detect dormant ones, and site attestation policies that ask owners to confirm the site is still needed and its permissions are still right. | Five to fifteen per cent of the sites in a decade-old tenant commonly have no valid owner. A meaningful share of those are dead and can be archived outright once somebody is willing to sign the decision. |
| Meeting recordings and transcripts | Recordings and transcripts are files with ordinary permissions. For channel meetings they land in the team site and inherit channel membership. For other meetings they land in the recorder’s OneDrive and follow that account’s sharing behaviour. Very few organisations have decided, in writing, who should be able to read a transcript six months later. | Teams meeting policy per user group for recording and transcription, the storage location for each meeting type, and the Microsoft Purview retention policy applied to both. Verify current Teams storage behaviour before you write a control description around it. | Expect transcription to be on for far more meeting types than anyone chose deliberately, and expect the retention setting to be the tenant default rather than a decision anybody made. |
The transcript row deserves a sentence of its own, because it is the highest-fidelity exposure on the list. A transcript is unhedged speech. Search over transcripts turns an offhand remark in a leadership meeting into a retrievable, quotable, cited claim, and it does so months later, to an audience that was never in the room. Decide the audience for a transcript at the point you decide to record.
The click paths and commands
| Oversharing and permission baseline | SharePoint admin center → Reports → Data access governance | Covers the EEEU sharing report, the sharing links reports and the site permissions reports. Reports are generated on a schedule. On a large tenant the first run can take days to populate, so start it before you need it. |
| Per-site and per-group permission export | Get-SPOSite · Get-SPOSiteGroup (SharePoint Online Management Shell), or the PnP PowerShell equivalents | Use this where you need a machine-readable export with a timestamp for evidence. Capture the command, the parameters and the record count alongside the output. |
| Sharing-link default and expiry | Set-SPOTenant -DefaultSharingLinkType Internal, plus the anonymous-link expiry parameter | Changing the default stops the backlog growing. Capture the tenant sharing configuration before and after so the change has two dated states. |
| Executive per-user review | SharePoint admin center → Reports → Data access governance → site permissions for users | Run it per named account. This is the report that turns an argument about executive risk into a list the executive can read. |
| Agent identity inventory | Microsoft Entra admin center, reconciled against the published-agent list in Copilot Studio | Agent identities in Microsoft Entra ID are what makes an inventory possible at all. Reconcile the two lists monthly and explain every difference. |
| AI interaction posture and audit | Microsoft Purview → DSPM for AI, and Microsoft Purview Audit | Provision the roles first. Audit has to be running before the period you will later be asked about, and its retention has to outlast that period. |
Two practical notes on the tooling. First, the data access governance reports sit behind SharePoint Advanced Management, licensed per user as an add-on or included in some Microsoft 365 E5 paths, and Restricted Content Discovery requires both a Copilot licence and SharePoint Advanced Management — the same capability tier the reports sit behind. List pricing and packaging change, so confirm current terms with your licensing partner before you budget. Second, blade locations and cmdlet parameters move between releases, so verify against current Microsoft documentation before you script any of the above. Where you cannot measure before you deploy, the honest position is that you are deploying without a baseline, and that belongs in the risk register as a recorded decision.
Why executives are the highest-risk accounts
Three things compound at the top of an organisation, and the compounding is what makes this population different in kind rather than degree. Executives hold the broadest standing access, accumulated over years of joining every governance forum and every programme steering group and leaving none of them. The material inside that reach is the most consequential the organisation holds — remuneration, restructuring, disputes, transactions, regulatory correspondence. And the assistant operates in that context: it drafts, summarises and answers using the identity of a person for whom almost nothing is out of reach.
Delegation widens it further. Executive assistants commonly hold delegated mailbox and calendar access, sometimes to several principals at once, and that delegation is rarely reviewed with the same care as a system entitlement. A single assistant account can therefore carry effective reach across the leadership team, and a site-oriented permission review will miss all of it, because none of it is a site permission.
A useful review enumerates each of these, per executive and per assistant account:
- Full-access and Send-As mailbox delegation, and Send on Behalf.
- Calendar delegate permissions, including read-and-write delegates.
- Shared mailbox membership.
- OneDrive site collection administrator assignments.
- Teams private and shared channel membership.
- SharePoint site owner and member groups reached through nested Microsoft Entra ID groups.
- Standing membership of governance-forum sites the person stopped attending years ago.
Expect the numbers to be startling. A C-suite account commonly returns several hundred reachable sites on the site permissions for users report where the tenant median sits in the dozens — an observed range from remediation work, offered as an order of magnitude to calibrate against your own run.
The practical consequence is a sequencing rule that runs against every instinct of a rollout programme. Pilot somewhere other than the leadership team. Executives are the natural choice — they are the sponsors, they are enthusiastic, and their endorsement carries the programme. Choosing them also means testing an unverified permission model on the identities where a mistake is least recoverable and most visible. Pilot with teams whose permissions you have measured, and bring the executive cohort in afterwards, once per-user review has been done. That ordering also produces a better demonstration, because by the time they use it the answers are trustworthy.
The review itself runs per user. Run the report that lists every site a named individual can reach, enumerate the delegation surfaces above, work through both with the person concerned, and record the decisions on the entries that surprise either of you. Expect that conversation to be uncomfortable and expect it to be productive: in engagements of this kind it is the most effective way to convert executive sponsorship of an AI programme into executive sponsorship of the access review that has to go with it.
Remediation priority, in the order that pays
The order matters more than the list. Teams that start at P7 — a labelling programme — spend nine months and reduce exposure less than a fortnight spent at P2 would have. The rule behind the ranking is simple: measure, then close the widest grants, then contain what remains open, then work the long tail.
| Rank | Action | Why it sits here | Effort and owner | Evidence it produces |
|---|---|---|---|---|
| P1 | Run the SAM data access governance reports and produce a ranked site list | You cannot sequence remediation you have not measured, and the reports are the only thing that converts a general anxiety into a finite list of sites with names and owners. Everything below depends on this output. | Days, plus report-generation lag on a large tenant. SharePoint administrator. Invisible to users. | The exported reports with the run date and parameters, the ranked site list, and the named owner assigned to each site on it. |
| P2 | Remove organisation-wide claims from sites that were never meant to carry them | This is the highest yield per hour of work anywhere in the programme. A single EEEU removal on an HR or finance site closes more exposure than months of policy drafting, and it is reversible if you get it wrong. | Weeks. Site owners doing the decisions, administrators doing the changes. User-visible, so it needs comms. | Before-and-after permission state per site, the approval from the site owner, and the change record showing who made it and when. |
| P3 | Apply Restricted Content Discovery (RCD) to the sites still under review | Remediation takes longer than the rollout timeline allows. RCD keeps a site out of organisation-wide discovery and Copilot responses while permissions are being fixed. Permissions are untouched — nobody loses access to a document — but the site’s AI entry points disappear, including the Copilot button, AI actions menus such as creating agents, and Create pages with AI, and a Restricted tag becomes visible to users on the site. Budget comms for it. It buys the calendar. P2 is the fix. | Hours to configure per site. Propagation is slower on very large sites. Requires both a Copilot licence and SharePoint Advanced Management. | The list of restricted sites with the justification recorded for each, the audit events for enabling and disabling, and the date each restriction is due to be lifted. |
| P4 | Fix the sharing-link defaults with Set-SPOTenant and expire the backlog | Sharing links are the permission system that site-level review misses. Changing the default link type and enforcing expiry stops the backlog growing while you work through the sites that generate the most links. RCD has no equivalent here, because it cannot be applied to OneDrive. | Days to set the policy. The backlog is a long tail — run it as a standing task with a monthly report. | The tenant sharing configuration captured at two dates, the link activity report before and after, and the exception process for the teams that genuinely need broader links. |
| P5 | Resolve ownerless and inactive sites with lifecycle policies, then archive what is dead | A site with no owner can only be remediated by an administrator guessing. Assigning ownership makes the rest of the programme delegable, and archiving genuinely dead content removes it from the problem entirely. | Weeks, mostly waiting on people. SAM site lifecycle policies automate the chasing. | Ownership policy configuration, the attestation responses from owners, and the archive decisions with the approver named. |
| P6 | Treat the executive and assistant population as a separate remediation stream | These identities hold the broadest standing access to the most sensitive material, and they are usually first into the pilot. A tenant-wide average tells you nothing about them. Review them one account at a time, including the delegated-access surfaces that a site report never shows. | Days per person, and politically the hardest item on this list. | The site permissions for users report run for each named account, the delegation enumeration, the decisions taken on each surprising entry, and a re-run at a stated interval. |
| P7 | Label and protect the material that must never be summarised | Permission repair is always incomplete at the margin. Microsoft Purview sensitivity labels with encryption, and policies that stop labelled content grounding a response, are the backstop for the small set of documents where a permission mistake is unsurvivable. Labels also govern the output: as documented at the time of writing — verify current inheritance behaviour — a Copilot response or a document created from labelled sources inherits the most restrictive label of the material it cited. The corollary is that unlabelled sensitive sources produce unlabelled derived content that then circulates freely. | Months if you are starting a labelling programme from nothing. Scope it to the small set first and expand later. | The label taxonomy and its owner, the policy configuration, coverage statistics for the in-scope repositories, and the exception log. |
| P8 | Turn on Microsoft Purview Audit and DSPM for AI before you need them | Auditing of Copilot and agent interactions has to be running before the period you will later be asked about. Retrospective monitoring does not exist. This is the item most often deferred and most often regretted, and it is also what makes eDiscovery and legal hold work when somebody asks. | Days. Requires Microsoft Purview Audit and DSPM for AI to be provisioned and roles assigned. | Configuration captured at two dates inside the period, the retention setting applied to Copilot interaction records, and evidence that somebody actually reviewed the output on the stated cadence. |
Read the last column as the real output. Each of these actions produces an artefact that a certification body or a customer’s security team will later ask for, and the difference between a programme that evidences well and one that struggles is almost entirely whether those artefacts were captured as the work happened or reconstructed afterwards. Reconstruction is visible, and it converts a control question into a credibility question.
Purview answers one question. A management system asks nine
“We have Purview and DLP, so we are governed” is the second most common sentence on this subject, and it makes a smaller claim than it sounds like. The data-security stack answers one of the nine questions below well and contributes materially to two others, leaving six empty. ISO/IEC 42001:2023 — the AI management system standard, certifiable by an accredited certification body — works through all nine. The fourth column names the clause where each lands, by title: the numbering of individual Annex A controls is deliberately left out rather than guessed.
| The question | What the data-security stack answers | What an AI management system additionally asks | Where it lives in the standard |
|---|---|---|---|
| Is this material protected? | Answered. Sensitivity labels, encryption and usage rights, DLP policies that stop labelled content grounding a response, and Purview DSPM for AI posture reporting on where sensitive data sits. | Accepts the data answer and adds the requirement that the protection be proportionate to the assessed risk of the specific AI use case. | Clause 6, planning. Clause 8, operational planning and control. |
| Why are we doing this at all? | Empty. A DLP policy has no opinion on whether the use case should exist. | A stated purpose per use case, the benefit expected, and the boundary of acceptable use — which is what makes a later “should we have done this?” answerable. | Clause 4, context and scope of the AI management system, and the AI policy under Clause 5. |
| Who owns it? | Empty. Ownership of the tooling sits with IT or security, but ownership of the outcome is outside the data-security model. | Named accountability for the AI use case, distinct from the administrator of the platform, with authority to stop it. This is usually the gap an assessor finds first. | Clause 5, leadership: roles, responsibilities and authorities. |
| What could go wrong, and for whom? | Contributes. The data controls speak to confidentiality and, to a lesser extent, integrity of information assets — one input to a wider assessment. | Risk to the organisation and impact on people, assessed separately, because a system can be low-risk to the enterprise and materially consequential for an individual affected by its output. The AI system impact assessment is the requirement with no ISO/IEC 27001 equivalent. | Clause 6, AI risk assessment and AI system impact assessment. |
| Are the people using it competent to? | Empty. DLP has no view on who is prompting. | Role-appropriate competence, including knowing when an output must be verified before it is relied on, and a record that the competence was established. | Clause 7, competence and awareness. |
| What happens over its life? | Empty. Policies persist until changed, and configuration drift is the only lifecycle concept. | Defined stages from proposal through approval, deployment, monitored operation, change and retirement — including who decides an agent is decommissioned and what happens to its data and its identity. | Clause 8, operational planning and control, including the AI system lifecycle. |
| What about the vendor? | Empty. Contractual terms are procurement’s concern, while the data-security stack enforces settings. | Supplier obligations, notification of material change, the artefacts you rely on for assurance, and the principle that accountability for the outcome stays with you. | Clause 8, operation, with the Annex A controls on third parties and suppliers. |
| How do we know it is still working? | Contributes. Alerts, policy match reports and posture dashboards are real and necessary, and they measure data movement. | Monitoring against the objectives you set for the use case, internal audit, management review, and a corrective-action route when the answer is no. | Clause 9, monitoring, internal audit and management review. Clause 10, nonconformity and corrective action. |
| Can you show me the decision trail? | Empty. Configuration history and audit logs record what the platform did, and stop there. | Documented decisions: what was approved, by whom, on what basis, with what conditions, and when it is next reviewed. This is the artefact class certification turns on and that almost nobody has on day one. | Clause 7.5, documented information. |
None of this argues against the data controls. Labels, encryption and policies that stop labelled content grounding a response are the right backstop for the small set of material where a permission mistake is unsurvivable, and they belong at P7 in the table above precisely because they are valuable — just slower and narrower than the permission work that precedes them. Label inheritance strengthens the case: as documented at the time of writing, a response or a document derived from labelled sources carries the most restrictive label of the material it cited, so a labelling programme protects derived artefacts as well as source ones. The error is reporting the data stack upward as governance and discovering, in an assessment or a customer questionnaire, that six of the nine rows are empty.
If you already run an ISO/IEC 27001 information security management system, most of the machinery for the right-hand column exists and needs extending rather than rebuilding — the risk process, internal audit, management review, supplier management and corrective action all transfer. What genuinely stays behind is the AI system impact assessment, which is assessed separately from risk to the organisation, and the AI-specific lifecycle and transparency obligations. We set out that overlap in integrating ISO 42001 with ISO 27001 and the separation of the two assessments in risk versus impact.
Every agent is a system of its own
A Copilot Studio agent is a purpose-built application that happens to be assembled in a low-code tool. It has its own identity in Microsoft Entra ID, its own knowledge sources, its own connectors, its own publishing surface and its own audience. Treating it as a configuration of the assistant is the category error behind most agent findings, because it means the agent inherits none of the scrutiny a new system would attract and all of the assumptions that attach to the assistant.
Four questions decide the risk class of any agent, and they should be answered in writing before it is published rather than after somebody asks.
Whose permissions are evaluated at retrieval?
If the agent reaches a knowledge source as the person asking, the familiar reassurance holds. If it reaches the source under its own identity or a service identity, the reassurance lapses and the agent needs an authorisation model of its own.
Who can talk to it?
An agent published to a channel that permits unauthenticated conversation is a very different system from one that requires a Microsoft Entra ID sign-in, and Power Platform DLP policies are where that gets constrained centrally rather than left to the person who built it.
What can it do, not just read?
A connector that writes, sends, schedules or transacts moves the agent out of the retrieval class entirely. That is Excessive Agency — LLM03 in the OWASP Top 10 for LLM Applications, 2026 edition, up from LLM06 in 2025, the largest upward move in the list and one driven by production incidents in agentic systems. It is also an identity and delegated authority question, and content it retrieves from untrusted sources becomes a prompt injection question — LLM01 in the OWASP Top 10 for LLM Applications, 2026 edition, published 4 August 2026.
Who owns it when the builder leaves?
Agents are built by people who move teams. An agent with no current owner is the ownerless site problem again, with an identity and a set of standing permissions attached.
The platform side of this has matured quickly. Agents are represented as first-class identities in Microsoft Entra ID, which is what makes an agent inventory possible at all. Connector use is constrained by Power Platform DLP policy that is revalidated at run time as well as at build time, and authenticated conversation is the default posture for newly created agents. Confirm the current behaviour of each of those in Microsoft’s documentation before you rely on it — this is the fastest-moving part of the estate, and a control description written against last quarter’s defaults will struggle in front of a competent assessor.
Governance-side, the requirement is unglamorous: agents belong in the same AI system inventory as everything else, with an owner, a purpose, a risk class, an assessment proportionate to that class, and a retirement decision. Where an organisation expects dozens or hundreds of them, assess by risk class with inheritance instead of writing one assessment per agent — the approach we set out in the agent governance framework. A register that lists the agents somebody remembered will fail its first reconciliation.
Connectors inherit somebody else’s access model
A Microsoft Graph connector brings content from an external system into the tenant index so the assistant can ground answers on it. Two permission models therefore apply at once, and an assessment that examines only one of them is incomplete. The first is the connector configuration: what it indexes, under what identity, and how each item’s access is expressed as it lands. The second is the source system’s own authorisation model, which is the thing the first is trying to represent.
Indexed items carry an access list, and that list can name users, name groups, or claim that everyone in the tenant may see the item. That last option is the one to look for first. It is legitimate for genuinely public reference material and catastrophic elsewhere, and it is chosen surprisingly often — sometimes because the source system has no permission model worth mapping, sometimes because mapping it properly was harder than the deadline allowed. Either way the effect is the same: content that was protected by obscurity in a legacy system becomes universally retrievable in a system that answers questions confidently.
Propagation is the second thing to establish. Permission changes in the source reach the index on a delay, and in some configurations they are picked up only on a full crawl rather than an incremental one — which means a revocation can take considerably longer to bite than an administrator assumes. Confirm the current behaviour for your connector, then write the actual lag into the offboarding procedure. A leaver whose source-system access was removed on their last day, but whose index-level entitlement persists into the following week, is a control gap that no site-permission review will detect.
For each connector, keep a record with five fields: the source system and its owner, the identity the connector uses, how source permissions map into item-level access, the crawl behaviour for content and for permission changes, and the assessed sensitivity of what is being indexed. That record is the thing an assessor asks for, and it is also the artefact that makes a later decision to retire a connector straightforward instead of archaeological. Where the connector reaches an external service that also exposes tooling to the model, the additional questions are in MCP server security governance.
Prompts and responses are records too
Most Copilot readiness programmes treat interaction logging as a monitoring question and stop there. Legal teams treat it as a records question, and they are right. As documented at the time of writing — verify the current storage location and behaviour before you rely on it — Copilot interactions are retained in the user’s Exchange mailbox and are reachable through Microsoft Purview eDiscovery and Microsoft Purview retention policies. That single fact reframes several decisions elsewhere on this page.
The first consequence is legal hold. If prompts and responses live in the custodian’s mailbox, a hold placed on that custodian now captures their AI interactions, including the question somebody typed at 11pm and the summary the assistant produced from a site they should never have reached. Organisations that place holds routinely should establish this behaviour deliberately, test a search, and write down what the hold does and does not capture, because discovering it during litigation is an expensive way to learn.
The second consequence is retention arithmetic, and it is why P8 sits where it does in the priority table. Retention on interaction records has to exceed the longest assurance period anybody will later ask you about. A twelve-month SOC 2 observation window with a ninety-day retention setting means the examiner can test the last quarter and nothing else, and the gap is visible in the configuration itself. Set retention once, set it long, and capture the setting at two dates inside the period so the operating effectiveness of the control is demonstrable.
The third consequence is the one nobody has answered. Under the GDPR and under DPDP-style regimes, a data subject access request reaches personal data about the requester wherever it is held, and interaction content that mentions a named employee is now part of that estate. Decide, in advance and in writing, whether Copilot interactions are in scope for your DSAR process, how you would search them, and what you would redact — the overlap between assurance regimes and privacy law is covered in SOC 2 alongside GDPR, DPDP and HIPAA. The same decision governs how long you can defensibly keep the records at all, which pulls against the retention arithmetic above. Resolving that tension is a decision for legal and the AI governance owner together, and it belongs on paper before the first request arrives.
2,400 seats, 300 licences, eleven years of debt
An illustrative composite, not a client. Read the dates: the whole argument of this page is that the measure-contain-remediate sequence happens before the deployment date rather than around it.
| Starting position | January 2026 | A 2,400-person services group buys 300 Microsoft 365 Copilot licences. The tenant is eleven years old, carries roughly 9,000 SharePoint sites, and has never had a tenant-wide permission review. The security team is asked to confirm it is safe to switch on, and has no evidence either way. |
| Measure | 19–30 January | The SAM data access governance reports run for the first time. The EEEU report returns a set of sites carrying an organisation-wide claim, of which four are HR, two are finance and one is a legal matter site. The sharing-links report shows a long tail of organisation-scope links. Six hundred sites have no owner. |
| Contain | 2–13 February | Restricted Content Discovery is applied to the seven high-sensitivity sites and to the sixty largest ownerless sites, each with a recorded justification and a lift date. Permissions are untouched — nobody loses access to a document — but the AI entry points disappear from those sites and a Restricted tag becomes visible on them, so a short note goes to the affected site members first. This buys the remediation programme its calendar. |
| Remediate | 16 February – 10 April | Organisation-wide claims are removed from the seven sites and from a further ninety identified in the ranked list. Default link type is changed with Set-SPOTenant and expiry is enforced. Ownership policies chase the 600 ownerless sites: 210 are archived, the rest get owners. |
| Instrument | From 1 March | Microsoft Purview Audit is confirmed on with retention set beyond twelve months, DSPM for AI is provisioned, and a monthly review of the agent and connector inventory begins. The first review finds two agents nobody had registered. |
| Deploy | 13 April – 29 May | The pilot runs with two operational teams, chosen on the measured cleanliness of their site permissions. The executive cohort goes last, in June, after per-user access review. |
The containment step is what made the timeline possible. Without it, the programme faced a binary choice between deploying over an unmeasured estate and delaying until nine thousand sites had been reviewed. Restricting discovery on sixty-seven sites took two weeks, left every existing permission in place, and converted an open-ended problem into a scheduled one. Every restriction carried a lift date, which is what stopped it becoming permanent and undocumented. The comms cost was one paragraph to the affected site members explaining why the Copilot button had disappeared from those sites and when it would return.
Two findings were unplanned and both were worth more than the pilot. The monthly inventory review in March found two agents in production that no register knew about, built by a team that had reasonably assumed agent creation was a self-service feature rather than a system deployment. And the per-user review of the executive cohort in late May found an assistant account with delegated access to three principals and standing membership of a corporate development site closed in 2023.
The artefacts this produced are the point. By the time the group’s largest customer sent an AI-specific security questionnaire in July, the answers already existed: the pre-deployment reports with their dates, the remediation record with owners and closure evidence, the agent and connector inventories, the interaction-logging configuration with its retention setting, and the approval record for the use case. All of it was produced as the work happened, which is precisely why it held up.
What the assessor actually requests
A SOC 2 examination under AT-C 205, performed by a licensed CPA firm, opens the same way every time, and it surprises people: the first request is for a population, because a sample drawn from an incomplete list tells you nothing about the list. Internal audit works the same way. A certification-body auditor operating under ISO/IEC 17021-1 approaches it differently — they sample against your scope statement and Statement of Applicability instead of drawing from a stated population — but they will still challenge an inventory that is visibly hand-maintained, and the artefacts below settle that challenge in either regime.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of AI-enabled surfaces | A system-generated list produced before any sample is drawn: every licensed user, every published Copilot Studio agent with its owner and authentication mode, every Microsoft Graph connector with its source system, and every site carrying an organisation-wide claim. Query, filter, date range and record count visible. | A hand-maintained inventory in a spreadsheet. A list of agents somebody remembered. Any export where the examiner has no way to tell whether it is complete. |
| Show that the pre-deployment permission review happened | The data access governance reports as run before go-live, with dates, the ranked remediation list they produced, per-site decisions with the owner named, and evidence that the actions were closed rather than merely raised. | A report run last week offered as evidence about a decision taken last year. A remediation list with open items and no dates. A screenshot of a dashboard showing today’s posture. |
| Show that access review continues, not just that it happened once | The recurring review with a stated cadence and a named reviewer who did not perform the grants, working from system-generated output, with the exceptions found and what was done about them. | A one-off clean-up before launch. A review performed by the same administrator who provisions access. A review that has never found anything, which invites the question of whether it is performed at all. |
| Show the agent inventory reconciles to reality | The Microsoft Entra ID list of agent identities reconciled against the published-agent list in Copilot Studio and the business register of approved use cases, with every difference explained — including agents built, tested and abandoned. | A count that does not match. An agent in production with no entry in the register. A register entry whose owner left the organisation. |
| Show monitoring operated throughout the period | Microsoft Purview Audit and interaction-logging configuration captured at more than one point inside the period, the retention setting applied to Copilot interaction records, and the reviews actually performed with their findings. | Logging enabled during fieldwork. Retention shorter than the period being examined. Configuration with no evidence anybody read the output. |
| Show the decisions behind the deployment | The approval record for the use case, the risk and impact assessment with its date and author, the residual risk accepted and by whom, the conditions attached, and the next review date. | A business case with no risk assessment. An assessment signed after deployment. A decision recorded in a chat thread nobody can produce. |
Population, frequency and how much gets tested
Sample behaviour follows from population size, and these populations are unusually small. Where the population runs to a handful of items, the examiner tests all of them, and the cost of a missing item rises accordingly.
| Control | Typical population size | Frequency | Sample likely drawn | Note |
|---|---|---|---|---|
| Published Copilot Studio agents | 10–80 in a mid-size tenant | Continuous | Complete population | One unregistered agent is a deviation in a population you called complete, and it is treated that way. |
| Microsoft Graph connectors | 1–12 | Continuous | Complete population | Too few to sample. Each connector needs its own five-field record, including the identity it indexes under. |
| AI use case approval records | 1–6 in year one | Per use case | Complete population | A live use case with no approval on file is the finding, whatever the rest of the file looks like. |
| Recurring access review of organisation-wide sites | 4–12 occurrences in a twelve-month period | Monthly or quarterly | 2–4 occurrences | Tested for whether the review ran on cadence, who performed it, and whether it produced exceptions. |
| Sharing-link exception approvals | 30–300 | Ad hoc | 25–40 | The approval has to predate the link. Approvals dated after the fact read as reconstruction. |
| Site remediation decisions | 50–500 | One-off programme | 25–40 | Each sampled item needs the owner decision and the closure evidence, and a ticket alone rarely carries both. |
Market practice, not standard requirement. Neither AT-C 205 nor ISO/IEC 17021 prescribes a sample size. The ranges above reflect common CPA-firm and certification-body practice for the stated frequency, and the examiner exercises professional judgement over the final selection, informed by the risk of the control and by any deviations found. What is genuinely required is that the population be complete and that you can demonstrate it. The asymmetry is worth internalising: the inventory is cheap to maintain monthly and expensive to reconstruct once.
Two vocabulary points from attestation practice that make SOC 2 fieldwork easier. What the examiner is establishing about anything you export is its completeness and accuracy, which is why they want the query, the filter, the date range and the record count visible alongside the result. And an exported report is information produced by the entity — usually shortened to IPE — a category that attracts its own testing. A tidy screenshot with the filter bar cropped out is an assertion with a picture attached. A certification-body auditor uses different vocabulary and applies broadly the same scepticism to a hand-built list.
A boundary worth stating plainly, because it is the same one that applies everywhere else in assurance. Tranquility Cybersecurity advises on this work, designs the controls, prepares the evidence and coordinates the examination. It does not certify, attest, audit or sign. ISO 42001 and ISO 27001 certificates are issued by accredited certification bodies. SOC reports are issued by licensed CPA firms.
The before-rollout checklist
Fifteen items, each with an owner and the artefact that proves it happened. The third column is the one to design for: a check that leaves no artefact is a check that, for assessment purposes, did not occur. Every item needs a named owner and a date, and the pilot can start before all of them are complete.
| Check | Owner | Artefact that proves it |
|---|---|---|
| SAM data access governance reports run, and the ranked site list produced and owned | SharePoint administrator with a named business sponsor | Exported reports with run dates, ranked list, owner per site |
| Organisation-wide claims removed from sites that should never have carried them | Site owners decide, administrators execute | Before-and-after permission state, owner approval, change record |
| Restricted Content Discovery applied to sites still under review, with a lift date and user comms | SharePoint administrator with the enablement lead | Restricted-site list with justifications, enable and disable audit events, the comms sent |
| Default sharing link type tightened with Set-SPOTenant and link expiry enforced | Tenant administrator | Sharing configuration at two dates, link activity report before and after |
| Ownerless and inactive sites resolved, attested or archived | Site owners, chased by SAM lifecycle policy | Policy configuration, attestation responses, archive approvals |
| Executive and assistant accounts reviewed individually, including delegated mailbox and calendar access | Security, with the executive’s explicit agreement | Per-user access report, delegation enumeration, decisions on surprising entries, re-run date |
| Meeting recording and transcript policy decided, by meeting type and audience | Collaboration owner with legal input | Teams meeting policy, storage location per meeting type, Purview retention setting |
| Sensitivity labels applied to the small set that must never be summarised | Data protection owner | Label taxonomy, policy configuration, coverage statistics, exception log |
| Agent creation governed: who may publish, to whom, authenticating as what | Power Platform administrator with the AI governance owner | Environment and Power Platform DLP policy configuration, and the approval route in writing |
| Every Microsoft Graph connector assessed for its own configuration and its source authorisation model | Connector owner plus the source-system owner | Per-connector record: source, identity used, permission mapping, crawl behaviour |
| Microsoft Purview Audit enabled, with retention longer than any period you will be asked about | Compliance administrator | Configuration at two dates, retention setting on interaction records, first review performed |
| eDiscovery and legal hold behaviour for Copilot interactions established and written down | Legal, with the compliance administrator | The documented storage location and hold behaviour, a test search, the DSAR scoping decision |
| Use case approved, with purpose, owner, risk and impact assessment on record | AI governance owner, approved by the accountable executive | Approval record, assessment with date and author, conditions, review date |
| Rollout cohort chosen on measured permission hygiene | Programme lead | Cohort definition with the measurement and the rationale recorded |
| Users told what the assistant can reach, and what to do when it surprises them | Enablement lead | Communication sent, the reporting route, the first reports received and triaged |
The last item is the one that gets cut and should survive. Users who have been told, in plain terms, that the assistant can reach anything they can reach, and that a surprising answer is a permissions bug worth reporting rather than an embarrassment to be quietly ignored, become the most effective detection layer available in the first ninety days. Give them a route that takes thirty seconds and lets them stay anonymous if they want to, and treat what comes back as findings. The related problem of people routing around a sanctioned tool that is too restrictive is covered in shadow AI governance.
The edge cases that generate the arguments
The sequence above covers the common eighty per cent. These are the situations where a security team, a programme sponsor and an assessor will genuinely disagree, and where settling the answer in advance is worth several weeks.
The board wants a date, and remediation is open-ended
Permission debt in a decade-old tenant is unfixable before a launch date, and pretending otherwise produces either an indefinite delay or an ungoverned rollout. The workable answer separates containment from repair: restrict discovery on the ranked high-risk sites, deploy to a cohort whose permissions you have actually verified, and run remediation as a standing programme with monthly reporting. What you commit to the board is a rate of progress and a bounded pilot, with the residual risk recorded on the face of the paper.
A discovery restriction is treated as a security control
It is containment, and the vendor documentation is explicit about the boundary. Restricted Content Discovery keeps content out of organisation-wide search and Copilot responses and leaves permissions untouched, so anyone who could open the document before can still open it. Its scope has edges worth knowing: it leaves content a user is already working with alone, it leaves searches originating from within the site alone, it has no effect on experiences such as Microsoft 365 Feed and Recommendations, and it cannot be applied to OneDrive sites at all — which is why the sharing-link work at P4 has no containment equivalent. It also changes what users see: the site’s AI entry points disappear and a Restricted tag appears. The predecessor, Restricted SharePoint Search, was capped at a hundred sites, can no longer be newly enabled since July 2026, and stops functioning in January 2027, with its PowerShell cmdlets retired the following month. Microsoft does not migrate its settings to RCD automatically. Use restriction to buy time for the permission fix, and write the permission fix into the control description.
The pilot cohort is the leadership team
This is the most common sequencing error and the one with the worst downside. Executives and their assistants hold the broadest standing access in the tenant, over the most sensitive material, and delegated mailbox and calendar arrangements widen it further. Piloting there means testing an unverified permission model on the identities where a mistake is least recoverable and most visible. Pilot where you have measured the permissions, and bring the executive cohort in after per-user review — which is also a better demonstration, because by then the answers are trustworthy.
An agent authenticates as itself rather than as the user
The whole reassurance on this page — that the assistant surfaces only what the asker could already open — depends on the retrieving identity being the asker. An agent configured to reach a knowledge source under its own identity, or a connector indexing content with a broad access claim, breaks that dependency completely. The question to put to every agent and every connector is simply: whose permissions are evaluated at retrieval time? If the answer is anything other than “the person asking”, the system needs an authorisation model of its own and an assessment that says so.
The source system has no usable permission model
Plenty of legacy repositories have either no meaningful access control or one so coarse that mapping it into an index is meaningless. Indexing them under a broad claim is the path of least resistance and the worst outcome, because it launders a weak model into a system that answers questions confidently. The honest options are to fix the source model first, to index only a curated subset whose sensitivity you have assessed, or to leave it out. A Microsoft Graph connector is a poor place to solve an access-control problem you have declined to solve at the source.
Legal, works councils and monitoring
Interaction logging is necessary for governance and, in several jurisdictions, is also employee monitoring. In parts of the EU that makes it a consultation matter before it is a configuration choice, and the sequencing is not optional. Decide early what is logged, for what purpose, who can read it, how long it is retained, and what it will never be used for. The organisations that handle this well write those answers down before enabling anything. The ones that do not end up switching monitoring off at exactly the point they need it.
The EU AI Act question about a Copilot rollout
A general productivity assistant deployed for internal drafting and retrieval sits outside the Annex III high-risk categories of Regulation (EU) 2024/1689 in most deployments, so the deferral introduced by the Digital Omnibus on AI, Regulation (EU) 2026/1744 — in force 27 July 2026, moving stand-alone Annex III obligations from 2 August 2026 to 2 December 2027, with AI embedded in Annex I products moving to 2 August 2028 — is rarely the operative question. What is operative is deployer-side and specific: whether a particular thing you build on top pulls that use case into Annex III, such as an agent that screens job applicants, assesses creditworthiness or supports an employment decision. The AI literacy obligation the Act places on deployers applies whatever the risk class, which is the same competence requirement an AI management system asks for, arriving from a different direction.
Content that was overshared before you started measuring
Removing a permission does not un-read a document, and it does not remove an answer somebody already saved. Where the reports reveal that sensitive material sat under an organisation-wide claim for years, the remediation and the incident question are separate: fix the permission, then assess whether the exposure requires notification under any obligation you carry. Interaction logs help only from the date they were enabled, which is the practical argument for enabling them before rollout.
Where the answer needs a standing owner rather than a project, that is what a fractional CISO or DPO engagement is for. Where the disagreement is about which decisions need approval at all, start with use case approval versus vendor approval.
What people push back on and the answer
These seven come up in almost every rollout, in board papers, in security committees and in customer questionnaires. The difference between a good answer and a defensive one is specificity about what changed and what held still.
“Copilot only shows people what they already have access to, so this is not a new risk.”
The first half is right and the second half does not follow from it. Risk is likelihood multiplied by impact, and the assistant leaves impact where it was while moving likelihood sharply, for every document an ordinary question would surface. Before, discovering the compensation model required knowing it existed, knowing roughly where it lived, and caring enough to look. Now it requires asking. The honest framing for a security committee is that this was always an access-control finding. The deployment is what makes it certain to be exercised, by people who are attacking nothing.
“We have Purview and DLP, so we are governed.”
You are protected, in the data sense, and that is genuinely valuable. Governance is a wider claim. Labels and DLP say nothing about whether the use case was approved, who is accountable for its outcomes, what the impact assessment concluded, whether the people using it are competent to, how it is monitored against its objectives, what happens when the vendor changes something material, or how it is retired. Against the nine questions an ISO/IEC 42001 assessment works through, the data controls answer one well and contribute materially to two more. Keep them, and report them as what they are.
“Is our data training the model?”
Answer it structurally and then verify it contractually, because the specific answer moves. Enterprise and consumer tiers of the same product generally differ in contractual protection, retention default and training use, and that difference is durable enough to plan around. The commitment that actually binds your tenant lives in the Microsoft Products and Services Data Protection Addendum and the Copilot service documentation for your plan and region, and residency lives alongside it in the EU Data Boundary commitments where those apply to you. The governance action is the same in every case: capture the current terms as a dated artefact in your supplier assessment, record which commitments you are relying on, and set a re-check trigger on material-change notification. What you must avoid is quoting a marketing sentence into a board paper and treating it as durable.
“Our tenant is too large to review. This is not realistic.”
Tenant-wide review is nobody’s proposal, and it would be a poor use of the effort. The reports rank exposure, so the work is finite: the sites carrying organisation-wide claims, the sites generating the most links, the ownerless ones, and the identities with the broadest reach. That is a list with a length, and it can be worked in priority order while Restricted Content Discovery holds the worst of it out of scope. The unrealistic plan is the one that tries to clean every site before switching anything on.
“The vendor is certified. Doesn’t that cover us?”
A provider’s certification covers the provider’s management system. Your permission model, your approval decisions, your agents, your connectors and your monitoring are yours, and a supplier attestation speaks to none of them. This is the shared-responsibility conversation in a new context: the platform gives you controls, and the accountability for configuring and operating them stays with you. A supplier artefact is genuinely useful as one input to your own supplier assessment, alongside the contractual terms you have captured and dated.
“Our users would tell us if they saw something they should not.”
Some will, if you have told them how and made it safe to do so. Most will stay quiet, because a cited answer from an internal system feels like the tool working. That is why the reporting route has to be explicit, blameless and easy, and why it belongs in the rollout communication rather than in a policy nobody reads. Treat the first few reports as the most valuable output of the pilot: they tell you where the permission model is wrong faster than any report will.
“Can we just block the assistant from sensitive sites and move on?”
You can restrict discovery on those sites, and for a bounded period you should. What you cannot do is leave it there, because the underlying permission is untouched: everyone who could open the document yesterday can still open it today, and the restriction leaves alone both content a user is already working with and searches that start from inside the site. It is also a blunt instrument — over-applied, it degrades the answers enough that people stop using the sanctioned tool, which creates a different problem. Restriction buys the time. The permission fix is the control.
Three statements you can lift and adapt
If you are writing this into a SOC 2 control matrix or an ISO control set, the hard part is phrasing something that is specific enough to test and general enough to survive a product change. These are illustrative starting points and they need tailoring to your tenant, your cadence and your risk assessment.
On a quarterly basis, a named reviewer who does not administer SharePoint reviews the system-generated list of sites carrying organisation-wide access claims. Exceptions are remediated or formally accepted by the site owner within 30 days, and the review output is retained.
Maps to: SOC 2 CC6.3. ISO/IEC 27001:2022 Annex A 5.18 and A 8.3.
On a monthly basis, the list of published Copilot Studio agents is reconciled against the Microsoft Entra ID agent identity list and the AI system register. Agents present in production and absent from the register are removed or registered with an owner and risk class within 10 business days.
Maps to: The AI system inventory and lifecycle requirements of an AI management system. SOC 2 CC6.1 where the agent holds standing access.
Microsoft Purview Audit is enabled for Copilot and agent interactions, with retention configured to exceed the longest assurance period the organisation reports on. Output is reviewed monthly by the compliance administrator, and the review is evidenced.
Maps to: SOC 2 CC7.2 monitoring, ISO/IEC 27001:2022 Annex A logging controls, and Clause 9 monitoring in an AI management system.
Two drafting notes. Keep product names out of the control statement itself where you can — put them in the procedure the control references, so a rename or a blade move costs you a procedure edit instead of a control-matrix revision. And state the remediation window explicitly: a control that says exceptions are “addressed promptly” has no testable attribute, and an examiner will say so. Tranquility Cybersecurity drafts and prepares this material and coordinates the examination. The opinion and the certificate come from the licensed CPA firm and the accredited certification body respectively.
Frequently Asked Questions
Is it true that Copilot only shows users what they already have access to?
What is the single biggest source of Copilot oversharing?
Does Restricted Content Discovery fix the problem?
What do we need to be licensed for before we can run any of this?
Why are executives the highest-risk accounts?
We have Microsoft Purview and DLP. Are we governed?
How are Copilot Studio agents different from Copilot itself?
What should we check about a Microsoft Graph connector before enabling it?
Are Copilot prompts and responses discoverable?
Is our tenant data used to train the model?
Do we have to fix every permission before we deploy?
What evidence will an assessor ask for?
Does this fall under ISO 42001, ISO 27001 or SOC 2?
Related Reading
Connectors and the Permission Inheritance Problem
Data access entitlement is not authorisation for an AI purpose. Assessing connectors proportionately.
Read moreHow Much Should an AI Agent Be Allowed to Spend?
Per-transaction ceilings are the easy part. Velocity and aggregate limits are what actually bind.
Read moreWhat Counts as an AI Incident?
The classification test, the categories worth defining, and what an AI incident record must capture.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more