Applied AI / Model Context Protocol (MCP) / Module 16 · Capstone: Design a Secure Multi-Tenant MCP Platform
Module 16

Capstone: Design a Secure Multi-Tenant MCP Platform

Building Systems Model Context Protocol (MCP)

Module 16 — Capstone: Design a Secure Multi-Tenant MCP Platform

Phase 4 · Enterprise Architecture & Mastery (the finish line). This module isn’t new theory — it’s the proof. You’ll produce one artifact, a full design document for a secure multi-tenant MCP platform, that exercises every concept from Modules 1–15. If you can write and defend this document, you are operating at the architect level you set out to reach: you can “design MCP architecture with entitlement and everything.”

Use this module two ways: as the spec for your capstone deliverable, and as a synthesis checklist that shows how all the pieces connect.

1. The brief

Design the MCP platform for “Helios”, a B2B SaaS company:

  • Multiple tenants (customer orgs), each with users in roles Viewer / Editor / Admin.
  • ~8–12 MCP servers: a documents server, a database/reporting server, a GitHub-integration server, an internal-API server, plus a few tenant-specific ones.
  • Some data is classified PII; one large tenant is regulated (needs stronger isolation).
  • Consumers include interactive users, a CI automation agent, and a customer-built integration.
  • An existing enterprise IdP (assume OIDC-capable: Entra/Okta/Auth0/Keycloak).

Your deliverable: a design doc that a security architect and a platform team would accept.

2. Required sections (map to the modules)

1. Scenario, tenants & roles. Define tenants, the Viewer/Editor/Admin permissions, and the three consumer types. (Modules 4, 11, 13)

2. Server inventory & primitive design. For each server, list its tools (with the read/write/destructive split), resources, and prompts, on the model/app/user control axis. Show 2–3 representative tool schemas (tight inputs, outputSchema, honest annotations). (Module 4) Note any client primitives used — roots for the documents server, sampling for a summarizer, URL-mode elicitation for the payment/OAuth handoff. (Module 5)

3. Transport & lifecycle. State which servers are stdio (local/none here) vs Streamable HTTP (all remote, networked) and why; note version negotiation and capability handling. (Module 3)

4. Authorization design (the core). The full OAuth 2.1 flow: MCP servers as Resource Servers, the IdP as AS, the discovery dance (RFC 9728 → RFC 8414/OIDC), PKCE, audience binding (RFC 8707), CIMD for client identity, and token exchange (RFC 8693) for upstream calls (GitHub, DB). Show how a wrong-audience token is rejected. (Modules 9, 12)

5. Entitlement model. Choose and combine RBAC (tool-level), ABAC (PII classification, environment/time), and ReBAC (document ownership via team membership). Place PEP/PDP/PIP. Write the deny-by-default, tenant-scoped policy for representative calls (e.g. read_document, delete_document, export_dataset) in Rego or Cedar. Map scopes (coarse) vs entitlements (fine). (Modules 10, 11)

6. Multi-tenancy & isolation. Bind tenant from token claims; enforce on every decision and log. Choose isolation per layer (authorization / server / storage) and justify a stronger posture for the regulated tenant (e.g. dedicated server instances + database-per-tenant) vs logical isolation for standard tenants. Address the IDOR risk from model-generated arguments. (Module 12)

7. Gateway, registry, observability. The gateway as central PEP (authN, tool-level authZ, virtual keys per consumer, rate limits/quotas, token exchange, request/response inspection, audit). The private registry with provenance/pinning and group-scoped discovery. Observability: SLOs, the three pillars, end-to-end tracing tied to audit, HA + graceful degradation, Tasks at scale. (Modules 13, 14, 15)

8. Threat model & mitigations. Walk T1–T8 (Module 8); for each, the concrete attack against Helios and the control that addresses it, naming where it’s enforced. Include prompt injection, confused-deputy/passthrough, tool poisoning/rug pull, excess privilege, token theft, supply chain, exfiltration, denial-of-wallet. (Module 8, all of Phase 3)

3. Synthesis — how it all connects (study this map)

The whole curriculum is one chain; the capstone makes you walk it:

 WHY/WHAT (P1)          BUILD (P2)             SECURE (P3)                ARCHITECT (P4)
 ─────────────          ──────────             ───────────                ──────────────
 host/client/server  →  tools/res/prompts   →  threat model (T1–T8)   →  gateway (central PEP)
 JSON-RPC msgs       →  roots/sampling/elic →  OAuth2.1 + audience     →  registry/supply chain
 lifecycle/transport →  build (stdio)       →  authN/authZ/entitle     →  observability/scale
   (Streamable HTTP) →  Tasks/async         →  RBAC/ABAC/ReBAC         →  CAPSTONE design
                                            →  tenancy/isolation/audit

Key seams to articulate in your defense (these are the “aha” connections an interviewer probes):

  • The read/write split (M4) becomes the entitlement boundary (M11) enforced at the gateway PEP (M13).
  • Streamable HTTP (M3) is the surface OAuth secures (M9) and the transport that makes the gateway scalable/HA (M15).
  • Audience binding + token exchange (M9, M12) is the structural defense against confused deputy (M8 T2).
  • The host’s non-delegables (M8 §3) become the gateway’s responsibilities (M13) — identity, consent, authZ, audit.
  • URL-mode elicitation (M5) is the UX vehicle for the OAuth human leg (M9).
  • Tasks (M7) + sampling-with-tools (M5) are the agentic substrate that observability/scale (M15) must operate.

4. Defense questions (be ready to answer these)

A capstone you can’t defend isn’t done. Rehearse:

  1. Why is the MCP server a Resource Server and not an Authorization Server — and what would break if you merged them?
  2. Walk the discovery dance and name every RFC. Where exactly is a wrong-audience token rejected?
  3. Your server must call GitHub for the user — why not forward the user’s token? What do you do instead?
  4. A get_document(id) is called with another tenant’s id (model picked it from injected content). Where is it stopped, and why not at the upstream?
  5. When do you use RBAC vs ABAC vs ReBAC — give a Helios example of each, and explain scopes vs entitlements.
  6. Justify the gateway despite it being a choke point. How is it not a SPOF?
  7. How do you detect a rug-pull and an exfiltration attempt in production?
  8. What changes for the regulated tenant, across all three isolation layers?

If your answers are crisp and reference the right mechanisms, you’ve reached expert level.

5. Final milestone — the deliverable

Produce the Helios design document covering all eight sections in §2, with:

  • At least 3 concrete tool schemas with the read/write/destructive split and honest annotations.
  • The full OAuth flow diagrammed with RFCs, audience binding, and token exchange for upstreams.
  • A deny-by-default, tenant-scoped policy in Rego/Cedar combining RBAC + ABAC + ReBAC for read/delete/export operations, with PEP/PDP/PIP placed.
  • Isolation decisions per layer, with the regulated tenant stronger, and the IDOR defense located in the PEP/PDP.
  • A reference architecture diagram: hosts → gateway → servers → upstreams, with IdP and PDP as separate components, plus registry and observability.
  • A T1–T8 threat table mapping each threat to a Helios attack and an enforced control.
  • You can answer all eight defense questions in §4 without notes.

When that document exists and you can defend it, you have completed the roadmap — zero to MCP architect, including entitlements and everything around them.

6. Where to go next (staying expert)

Mastery in a fast-moving protocol is a habit, not a finish line:

  • Track 2026-07-28 as it finalizes — the largest revision since launch, hardening authorization; re-validate Modules 9–12 against it. The concepts are stable; specific requirements tighten.
  • Read the spec changelogs each release; diff against this roadmap.
  • Build and break — stand up real servers, put them behind a real gateway and IdP, and attack your own deployment against T1–T8.
  • Follow the ecosystem — gateways, registries, and policy engines evolve quickly; re-evaluate tools against the requirements checklists (Modules 13–15) rather than fixed product lists.
  • Teach it — explaining the discovery dance or the PEP/PDP split to someone else is the final test of whether you own it.

Quick reference — Module 16 (capstone) checklist

  • Eight sections: scenario/roles · servers & primitives · transport/lifecycle · OAuth/authorization · entitlement model · tenancy/isolation · gateway/registry/observability · threat model.
  • Must demonstrate: read/write split → entitlement boundary; OAuth audience binding + token exchange; RBAC+ABAC+ReBAC, deny-by-default, tenant-scoped; PEP/PDP/PIP; per-layer isolation with stronger regulated tenant; gateway as central PEP; private registry + pinning; observability with security alerts; T1–T8 mitigations.
  • Done when: the Helios design doc exists and you can answer all eight defense questions without notes.
← Module 15: Observability, Reliability & Scale
🎉 You've finished Model Context Protocol (MCP)!
↑ Back to overview
Next tutorial →