The tool surface is the agent's blast radius, and MCP is now the standard way to build it. This playbook designs the integration layer — MCP servers as contracts, OAuth resource-server auth, read/write authorization tiering, and gateway placement — as an architecture the security review can actually approve.
Tier: Advanced · Hands-on time: ~40 minutes
The standardization bet has settled: MCP was donated to the Linux Foundation's Agentic AI Foundation in December 2025 with AWS, Google, Microsoft, and OpenAI among the backers, making it safe to standardize on rather than a framework fashion. The 2025-06-18 specification matured the security story — OAuth resource-server semantics, RFC 8707 resource indicators, structured tool output. The architect's job is to turn that spec surface into an org design: which tools exist, who may call them, and where the enforcement lives.
Enumerate the tool surface as an authorization problem. For every tool: system touched, operation, read/write/destructive classification, data sensitivity of inputs and outputs, and which agent(s) need it. This table — not the framework choice — is the design's center of gravity.
Tier the surface by consequence. Tier 0: read-only, low-sensitivity (search docs, fetch order status). Tier 1: read of sensitive data (customer records) — identity-scoped. Tier 2: reversible writes (create ticket, draft email) — logged, often approval-gated per pb-38. Tier 3: irreversible or high-blast-radius operations — default excluded from the agent surface entirely; existence requires explicit sign-off.
Design MCP servers as owned contracts. Group tools into servers by domain and owner (orders-mcp owned by the orders team), version them, and require structured tool output per the current spec so downstream handling is parseable rather than prose-scraped. Each server declares its tier ceiling — a server exposing Tier 2 tools is reviewed as a Tier 2 asset.
Get the auth architecture right — this is where designs fail review. Per the 2025-06-18 spec, MCP servers act as OAuth resource servers: tokens issued by your identity provider, audience-bound to the specific server (RFC 8707 resource indicators exist precisely to stop a token for one server being replayed against another). Design identity propagation end to end: the human user's identity flows through the agent to the tool call, so the tool enforces the caller's entitlements — the agent's service identity must not become an all-access skeleton key.
Place the gateway deliberately. A central MCP gateway (AgentCore Gateway or an API-gateway pattern) gives one enforcement point for authn, tiering, rate limits, and audit — the multi-tenant pattern literature converges on centralized gateways for exactly this reason. The trade-off is a critical dependency; decide what happens to agents when the gateway is down, and hand its operation to the platform team by explicit design.
Red-team the surface before the security track does. Rajesh, for the Meridian order-status agent:
Review this agent tool surface as a hostile security reviewer.
Attached: tool table (11 tools across orders-mcp and kb-mcp, tiers
marked), auth design (OAuth resource-server per MCP 2025-06-18, user
identity propagated, gateway enforcing tiers).
Attack it on:
1. Tier escalation — any path where Tier 0/1 tool outputs can induce
the agent to invoke a Tier 2 tool with attacker-shaped arguments
(retrieved content is untrusted input).
2. Identity confusion — anywhere the agent's service identity, rather
than the end user's, reaches a tool that enforces entitlements.
3. Token scope — could a token minted for kb-mcp be replayed against
orders-mcp as designed? Where are resource indicators enforced?
4. Audit gaps — which tool invocations would be invisible or
unattributable in the current logging design?
Findings with severity and the design change that closes each.
Ship the artifact set. The tiered tool table, the auth/identity-flow diagram (user → agent → gateway → MCP server → system), gateway placement ADR with the availability trade-off, and per-server ownership records. Operations of the gateway belong to the DevOps track; this package is what they operate.
The MCP layer is often the cleanest client-safe seam: servers run inside the client boundary, exposing client systems to agents without any client data transiting external tooling. Extract MSA constraints first — they typically dictate client-tenancy model endpoints and prohibit external SaaS gateways, which selects a self-hosted gateway inside the client network. The whole layer develops offline: MCP SDKs plus a local Ollama-served model exercise the full auth, tiering, and refusal behavior with synthetic data before anything touches client systems. Keep the tool table and auth diagrams in client-approved repositories; they enumerate the client's attack surface and are confidential by nature.
The tool table is the design — tiered by consequence, enforced at a gateway, authenticated per the MCP spec with audience-bound tokens, and proven by a demonstrated blocked write before any review is asked to trust it.