Microsoft 365 Copilot answers prompts by retrieving the most relevant content each user can already access across SharePoint, OneDrive, Teams, and Exchange. It grants no new permissions, and retrieval is bounded by relevance rather than exhaustive enumeration, but it makes whatever a user could already reach discoverable through plain language. Pre-existing oversharing and stale permissions become AI-surfaced data leakage in seconds, and poisoned documents can carry prompt-injection instructions into the model.
DSE inventories what Copilot can reach, remediates the permissions and labels behind the exposure, red-teams it for prompt injection and data leakage, and assembles the audit evidence an examiner expects. Senior-led, fixed-fee, governed as a vendor product under third-party risk, not as a model.
Copilot did not create new risk so much as it made existing risk searchable. Four exposures show up on almost every bank deployment that went live before risk and compliance had a seat at the table.
Permission inheritance and oversharing. Copilot reasons over your tenant through the Microsoft Graph and a semantic index, and it honors the access each user already holds. That is the point of the product and also the problem. A site shared with "Everyone except external users," a document left open through an org-wide link, a folder a contractor still belongs to: anything a user can technically open is now one prompt away from being summarized or quoted. Permissions that were buried because nobody browsed to them become trivially discoverable. The exposure was always there; Copilot is the query layer that exercises it.
Stale permissions and leavers. Access that was never revoked is the second failure mode: group membership that outlived a project, a shared mailbox a former analyst still belongs to, a site whose owner left and whose permissions nobody has reviewed in years. Traditional controls tolerate this drift because no human navigates to forgotten content. Copilot does not navigate, it retrieves, so stale access becomes a live data-leakage path.
Prompt injection through poisoned documents. Copilot summarizes and drafts from content it retrieves, and that content is attacker-reachable. A document, calendar invite, or inbound email can carry instructions an attacker planted, and when Copilot ingests that text it can follow the planted instructions rather than the user's intent. This is indirect prompt injection, and in a bank it is not academic: an injected instruction can try to surface restricted content, alter a summary a banker relies on, or steer an output toward an action nobody asked for.
Audit and logging gaps. The last exposure is the one examiners ask about first. Copilot interactions are recorded through the Microsoft Purview audit log and interaction-history records, but only when logging is enabled, retention is set to a defensible window, and someone reviews it. Many rollouts turn the product on without confirming the evidence trail exists, so when a risk committee asks who prompted what and what the model returned, the answer is a shrug.
The first governance mistake is filing Copilot under the wrong regime. Get the regime right and the obligations become clear.
Microsoft 365 Copilot is a generative-AI system, so it sits outside the model-risk scope of SR 26-2. The April 2026 revised guidance on model risk management replaced SR 11-7 and SR 21-8 and explicitly excludes generative and agentic AI from its scope. That carve-out is not a no-obligations void. You govern Copilot under third-party and vendor risk, because Microsoft builds and operates it and you consume it; under UDAP, because how the tool is used can still harm a consumer; under fair lending if Copilot output ever touches a consumer credit decision; and under your own institution's risk-management practices. The supervisory map is real; it just is not the model-risk map.
The corollary matters for procurement. Microsoft holding an ISO/IEC 42001 certificate is an upstream attestation about Microsoft's own management system, not coverage of your deployment. It says nothing about how your tenant labels sensitive data, which sites are overshared, whether stale access has been cleaned up, or whether your audit logging is on. The duty to govern your configuration stays with you. For the full institution-type view, see our AI governance for banks and fintechs hub and the AI governance for financial services pillar.
Not a policy binder. A configured, tested, and evidenced Copilot deployment built on the controls you already run in Microsoft 365.
We start with an inventory of what Copilot can reach, because you cannot govern a surface you have not mapped: the SharePoint sites, document libraries, OneDrive shares, Teams, and mailboxes in scope, and the sharing links and group memberships that decide who sees what.
On that map we run permission and oversharing remediation: sensitivity labels applied and enforced, Microsoft Purview Data Loss Prevention policies that limit what Copilot can process, and oversharing discovery through SharePoint Advanced Management restricted-content discovery and Restricted SharePoint Search, so the worst-exposed content is closed before it is prompted. We tighten access and Conditional Access controls so identity, device, and risk conditions gate who can use Copilot and from where.
Then we prove the boundary holds. We run prompt-injection and data-leakage red-teaming against the deployment, mapped to the OWASP LLM Top 10 and MITRE ATLAS, with reproducible payloads rather than a checklist. Finally we close the logging and audit evidence gap: confirm what Purview captures, set defensible retention, stand up a review cadence, and assemble the records that answer an auditor or examiner. This pairs with our shadow AI risk assessment where staff also paste bank data into public tools, and the guide to building a real AI inventory.
This is the spine of a defensible Copilot program. Each row pairs a concrete exposure with the Microsoft 365 control that addresses it and the artifact you hand a reviewer. Use it as a working checklist before an audit conversation.
| Copilot risk | Control | Audit evidence |
|---|---|---|
| Permission inheritance and oversharing | Sensitivity labels, SharePoint site access review, Restricted SharePoint Search and SharePoint Advanced Management restricted-content discovery | Oversharing report, label-coverage summary, and a site-permission inventory with owners |
| Stale access and leavers | Access reviews, group-membership cleanup, deprovisioning tied to the joiner-mover-leaver process | Access-review attestations and a before-and-after record of removed access |
| Data leakage through prompts | Microsoft Purview DLP for Copilot (Purview or E5 add-on licensing), sensitivity-label enforcement, Information Barriers, and Restricted SharePoint Search to scope retrievable sources | DLP policy export, incident reports, and label-enforcement evidence |
| Indirect prompt injection via poisoned documents | Microsoft's built-in prompt-injection safety filters, plus independent DSE red-team testing mapped to the OWASP LLM Top 10 and MITRE ATLAS and content-provenance review | Red-team findings with reproduction transcripts and remediation status |
| Audit and logging gaps | Purview Audit (Premium, E5 or add-on) for Copilot interaction logging, interaction-history retention set, and a documented review cadence | Audit-log queries, retention configuration, and dated review records |
Every engagement is fixed-fee and fixed-scope, sized in writing on the first call. Here is what ships.
Most banks arrive with one of two problems: a Copilot deployment that has never been security-tested, or governance pressure from an examiner or the board. Start where you are.
If the urgent question is whether the deployment can be broken, start with an AI Security X-Ray: a fixed-fee diagnostic that red-teams Copilot for prompt injection, data leakage, and oversharing, with evidence-backed findings and a remediation roadmap.
If the pressure is governance, start with AI Governance Readiness: an AI inventory, risk classification, and an audit-readiness gap assessment aligned to third-party risk, fair lending, UDAP, and NIST AI RMF, with ISO 42001 where procurement calls for it.
Want a senior owner to keep the program current as the tenant, the model, and the supervisory expectations change? A vCISO for AI carries the Copilot risk surface over time. Not ready for a paid engagement? Start with the free AI governance tools and the audit-readiness checklist.
No, not directly. SR 26-2, the April 2026 revised guidance on model risk management, replaced SR 11-7 and SR 21-8 and explicitly excludes generative and agentic AI from its model-risk scope. Microsoft 365 Copilot is a generative-AI system, so you govern it under third-party and vendor risk, UDAP, fair lending where it touches a consumer decision, and your own institution's risk-management practices, not as an SR 26-2 model. The exclusion is not a no-obligations void: those other regimes still apply in full.
Copilot answers using each user's existing access across SharePoint, OneDrive, Teams, and Exchange through the Microsoft Graph and a semantic index. It does not grant new access, but it makes whatever a user could already reach instantly discoverable through a natural-language prompt. Pre-existing oversharing, broad site permissions, and stale group membership that were practically buried become AI-surfaced in seconds. The risk is your permission hygiene, exercised at the speed of a search.
Yes, indirectly. A document, calendar invite, or email that Copilot retrieves can carry instructions an attacker planted, and the model may follow them when it summarizes or drafts. This is indirect prompt injection. We red-team for it and for data-leakage paths with reproducible payloads and captured transcripts, and we map findings to the OWASP LLM Top 10 and MITRE ATLAS so your security and compliance teams can connect each result to a risk they already track.
Copilot interactions are recorded in the Microsoft Purview audit log and interaction-history records, but only if logging and retention are configured and someone reviews them. We confirm what is being captured, set a defensible retention window, stand up a review cadence, and assemble the records an internal auditor or an examiner will ask for. DSE prepares the program for audit and does not certify it, and no engagement guarantees passing a specific examination.
No. A vendor certificate is an upstream attestation about Microsoft's own management system. It does not cover how your institution configures permissions, labels sensitive data, controls access, or governs Copilot in your tenant. The duty to govern your deployment, and the evidence that you do, stays with you. We help you build and document that posture; the vendor certificate does not substitute for it.
DSE provides AI governance and compliance readiness consulting and point-in-time AI security testing. We prepare your Copilot program for audit and do not certify it. We are not an accredited certification body and do not issue ISO/IEC 42001 certificates or certify NIST AI RMF or EU AI Act compliance. Only accredited certification bodies or notified bodies do that.
Security testing is point-in-time and sampling-based; it cannot guarantee the absence of vulnerabilities. We cannot guarantee passing an audit or avoiding enforcement, and we do not provide legal advice. We work alongside your counsel, who owns the legal interpretation of your supervisory and contractual obligations. Microsoft 365 Copilot is a Microsoft product, and we describe only well-established Copilot and Microsoft Purview behavior.
All engagements are governed by a signed SOW / MSA that includes a limitation of liability and requires written client authorization before any testing begins.