Personal capacity. Not employer-reviewed or endorsed. Technical claims are generic reference patterns, not internal practice from any specific firm.

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

Where Microsoft's contract ends and the firm's operational obligation begins Three concentric responsibility layers for M365 Copilot in a regulated firm: Microsoft contract coverage (privacy, security, sub-processor governance), shared operating model (identity, data residency, retention), firm-only obligations (model risk SR 11-7, recordkeeping 17 CFR 240.17a-4, conduct supervision MiFID II, operational resilience DORA, EU AI Act). FIRM-ONLY OBLIGATIONS (residual; audit evidence here) SR 11-7 model risk · 17 CFR 240.17a-4 recordkeeping · MiFID II conduct · DORA · EU AI Act SHARED — firm operates, Microsoft enables identity (Entra) · data residency · retention (Purview) · access governance MICROSOFT CONTRACT (OST + DPA) platform security, sub-processor governance, Anthropic non-retention posture, telemetry plane Three layers. Inner is contract; middle is shared; outer is the firm's audit-defensible work.
The architecture layering. The Word document below maps each obligation to the specific service that operates it.

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 email

Microsoft'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:

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.

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

Three things I'd love feedback on

  1. 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.
  2. 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.
  3. 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).

Tell Mogambo

Tell Mogambo