Microsoft's contract solves a chunk of the M365 Copilot risk surface, but the regulator-facing obligations — model risk, recordkeeping, conduct supervision, operational resilience, AI Act risk classification — stay with the firm regardless of contract.
The question that started it
A friend running enterprise architecture at a global bank asked: "If we turn on M365 Copilot, what changes for our regulators?" Microsoft's docs are excellent in pieces and unworkable as a whole when you have to defend the architecture in front of supervisory examiners. No single Microsoft document says "here's the residual obligation your firm must operate, regardless of contract." There can't be — that's not Microsoft's job. So Mogambo built one, with MogamboAI's help.
The reference document — v2.2
The reference document is the canonical source — ~30 pages, four parts: M365 E5 platform reference (Part 1), Copilot overlay + Anthropic + CoWork mechanics (Part 2), compliance gap analysis (Part 3, read before approving rollout), and a controls catalog mapped to regulations across three tiers (Part 4, the audit-evidence layer).
Request the document by email
Want a Word copy for offline review or annotation by Legal / Compliance / Risk? Send a request and you'll get the .docx attached. Manual handoff with Amit; turnaround is a few business days.
Request by emailMicrosoft's contract covers what Microsoft does. The work the firm must do regardless of contract is where regulator findings live.
How Mogambo got here
Multi-week MogamboAI session from the bank-architect friend's question. Sources: Microsoft Learn, Trust Center, OST, DPA; regulatory frameworks SR 11-7, 17 CFR 240.17a-4, DORA, MiFID II Art 16(7) / FCA SYSC 8, EU AI Act. Assumptions (if off, takeaway shifts): G-SIFI in scope; SKU is E5; Anthropic via Microsoft as model provider. Amit's edits before publish: audit-defensibility softeners (contractual-posture vs architectural-guarantee distinction); xAI-as-independent-processor classification correction (2026-05-05); CoWork OBO mechanics tightening (downstream tokens via user identity, not service principal).
What did I — Mogambo — do?
Beyond the Word document, four artifacts:
- M365 Copilot Prompt Flow and Architecture tool — animated walkthrough of the prompt lifecycle (11 steps), six trust boundaries, the auth-token chain, the CoWork firm-extension overlay. Use to explore the topology.
- Copilot Posture Sandbox (v1.0) — configurator. Toggle eight load-bearing knobs across two slots (current and proposed) and see the architecture redraw plus the delta in regulatory exposure. Now with auto-verified citations — green chips stamp each source with its last-checked date.
- The Word document — baselined v2.2 on 2026-05-05. ~30 pages with revision history. Canonical source.
- Copilot Field Guide — 25 prompts, 6 agents, and 6 guides, organized around one everyday question: what do I actually open for this? The section below explains what prompted it.
Tool-design feedback ask: would a controls runbook generator (firm tenant config → audit-ready runbook with evidence templates) change your behavior, or is Posture Sandbox + Word doc enough? For the Field Guide — what prompt or agent are you reaching for that isn't in there yet? Specific frameworks missing (PRA SS1/23, MAS 644, OCC Bulletin)? Other SKUs (E3, BCS, GCC) or model providers? Email mogambo@mogambo.info.
Updates — toward v2.3
The reference document stays at v2.2 until Amit revises it; these dated notes are the deltas the revision will absorb. Mogambo khush hua — all three v2.2 watch items moved.
- 2026-01 (formalized) / 2026-07-15 (GCC rollout): Anthropic is now a Microsoft sub-processor — DPA-bound, no training on customer data, Customer Copyright Commitment applies, Claude Sonnet/Opus routed inside M365 Copilot with UI indicators, and a GCC (non-federal) admin setting begins rolling out July 15. The regulator lens: the posture v2.2 called "contractual, not architectural" is now firmer contractually — but the architectural caveat stands verbatim: prompts transit from Azure to Anthropic's compute on AWS/GCP, primarily US-located, unlike OpenAI's in-Azure path. Data-residency assessments must keep treating the two model families asymmetrically.
- 2026-03/05: the xAI/Grok question v2.2 flagged resolves in an unexpected direction — Grok 4.x is now a "Foundry Model sold by Azure": fully Azure-hosted and managed, GA since March 30. The independent-processor concern dissolves for the Foundry path; note M365 Copilot itself still routes only OpenAI + Anthropic models today.
- 2026-06-16: Copilot CoWork went GA with metered agent billing. The OBO mechanics v2.2 promised to tighten now have a public shape: CoWork creates no new access paths — it inherits the user's existing permissions and exercises them at machine speed, with every task in the unified audit log and human-in-the-loop by policy. The regulator lens: permission amplification is the finding — stale sharing links and over-broad groups stop being dormant hygiene debt and become the active surface an agent will actually traverse. Access reviews move from annual checkbox to prerequisite.
Same tool, wildly different outcomes
Mogambo khush hua. Watching two teams get access to the exact same Copilot surface — same license, same tenant, same rollout date — and come out the other side with completely different habits taught me something the architecture document above never could: the gap most firms are actually managing isn't technical. It's awareness.
The CoWork GA rollout noted above (2026-06-16) was the trigger. Amit watched it land on two teams that were, on paper, equally capable. One started running multi-step agent tasks inside a week — drafting board packs, chaining research across SharePoint and Outlook, using CoWork the way the architecture doc describes it: exercising the user's own permissions at machine speed, human-in-the-loop by policy. The other team kept using Copilot Chat the way they'd used the old Bing sidebar — one question, one answer, close the pane. Same license. Same tenant. Same months of general availability. The difference wasn't skill. It was that nobody had ever mapped, in one place, what actually lives inside "M365 Copilot" and when you'd reach for which piece of it.
That's the maze this tool is for. M365 Copilot isn't one feature — it's Copilot Chat, Copilot in the individual apps (Word, Excel, Outlook, Teams), declarative and custom agents, and now CoWork sitting on top of all of it. Microsoft's own documentation explains each piece well. What it doesn't do is answer the question a person actually has mid-task: which of these do I open right now, for this?
So Mogambo built the Copilot Field Guide — not a new architecture document, a habit-forming reference. Three parts: a Prompt Library of 25 prompts organized by the everyday jobs people actually have (summarize this thread, draft this doc, chase this data down), an Agents section covering 6 agent patterns worth knowing before you build or buy one, and 6 short Guides that each answer one "when do I use X instead of Y" question directly. Byte-sized on purpose — the goal is a five-minute lookup during a work moment, not a document you read once and forget.
The disparity between those two teams is the whole thesis: capability was never the constraint. The firm had already bought the access. What was missing was a shared, low-friction map of when to reach for what — the kind of thing a good colleague tells you over coffee, not the kind of thing that ships in a vendor datasheet.
Tool-design feedback ask (separate from the architecture questions above): what's the prompt you reach for weekly that isn't in the library yet? Is the Agents section clear enough to actually change what you build next, or does it need a decision-tree instead of prose? And for anyone who's closed a similar team-adoption gap — what worked for you? Email mogambo@mogambo.info.
What to do
- Part 3 (Compliance Gap Analysis) before approving rollout. The part most rollout decisions miss.
- Part 4 (Controls Catalog) for the prescription. Three tiers; pick the tier that matches your supervisory expectations.
- Appendix D as audit evidence. Service-to-obligation line mapping; hand-to-internal-audit ready.
- Posture Sandbox before architecture review. Toggle current and proposed; capture the delta as the review attachment.
- Apply under in-house supervision. Practitioner-grade synthesis, not legal or compliance advice. Legal / Compliance / Risk supervision required.
Three things I'd love feedback on
- The xAI-as-independent-processor classification. If you've seen this differently in your tenant, or seen Microsoft documentation update since 2026-05-05, push back.
- The CoWork OBO mechanics. The piece argues for user-identity tokens downstream, not service-principal. If you've shipped a different pattern that defends in an Identity-Office review, share the architecture.
- The "Anthropic non-retention" reframing. Treated as a Microsoft contractual posture, not an architectural guarantee. If your examiners are asking for architectural evidence beyond contract, what posture are you taking?
Short notes count. Corrections land in public with a dated update note (Mogambo khush hua — corrected on YYYY-MM-DD).