In partnership with
Summer series note: prepared in advance — one thesis, built to be used. Regular format returns late August.
The Thesis
Over the past eighteen months, the Model Context Protocol quietly became the standard way AI agents reach enterprise tools and data — the USB port of the agentic stack. Which means something most security architectures have not caught up with: the MCP server is now the place where language models touch production systems, and that makes it a perimeter — your newest, least-governed one. The protocol standardises how agents discover and call tools. It deliberately does not decide who may call them, as whom, with what limits, or with what trail. Those decisions belong to you — and the first of them, the one most enterprises make by accident, is whether that perimeter is shared or dedicated.
The Unminuted Decision
Two deployment shapes dominate enterprise MCP practice. Shared: one server instance serves many users or agents — natural for team-wide knowledge, common tools, organisational memory; efficient, centrally patchable, one thing to monitor. Dedicated: each agent, user, or workload gets its own instance — natural for privileged tools, per-client work, or anything where isolation matters; more sprawl, cleaner blast radius.
Most organisations end up shared, not by decision but by default: a platform team stands up "the MCP server" for a pilot, it works, and eighteen months later forty agents across six departments call tools through one process with one identity and one log stream. Nobody chose that architecture. It accreted. And what accreted is a merged blast radius: one over-permissioned tool, one poisoned prompt, one compromised dependency in that shared server, and every workload it serves is in scope at once.
The isolation question has a second face that European readers will recognise from cloud sovereignty debates: whose data may transit the same process? A shared MCP server serving both your M&A team's document tools and your marketing team's content tools is a data-segregation decision — the kind your DPO and your regulator both have opinions about — dressed up as a convenience.
Why the Perimeter Is Different This Time
Three properties make the MCP layer unlike the API gateways you already govern.
The caller is a language model. Traditional perimeters assume the client executes code someone wrote and reviewed. Here the client decides — at runtime, in natural language — which tools to call with which arguments. That creates the confused-deputy problem in its modern form: a malicious prompt, a poisoned document, a manipulated memory (Build Lab 1's swarm risks compound here) can redirect a legitimately-authorised agent into tool calls its operator never intended — data exfiltration by persuasion rather than intrusion. The perimeter must therefore constrain not just who calls, but what any caller may do, because the caller's intentions are, by construction, untrusted.
The protocol ships without the controls. MCP alone does not handle authentication, authorisation, audit trails, rate limits, or cost control. In enterprise practice those gaps are closed by an MCP gateway — the emerging control-plane layer between agents and servers — or they are not closed at all. Even the well-known implementations are uneven: gateway offerings from major vendors have shipped without documented multi-tenant isolation models or without production-grade RBAC and audit logging. "We deployed the official one" is not a security posture; the gap analysis is yours to run.
Identity flows through it — or dies in it. Everything the last two months of this newsletter established about agent identity (first-class identities, authority preserved through delegation, lineage-grade audit) is physically enforced or lost at the MCP layer. If forty agents authenticate to the shared server as one service account, your carefully-designed agent identity model evaporates exactly where the actions happen. The perimeter is where attribution is real or theatrical.
Write docs 4x faster. Without hating every second.
Nobody became a developer to write documentation. But the docs still need to get written — PRDs, README updates, architecture decisions, onboarding guides.
Wispr Flow lets you talk through it instead. Speak naturally about what the code does, how it works, and why you built it that way. Flow formats everything into clean, professional text you can paste into Notion, Confluence, or GitHub.
Used by engineering teams at OpenAI, Vercel, and Clay. 89% of messages sent with zero edits. Works system-wide on Mac, Windows, and iPhone.
The Decision Framework
The shared-vs-dedicated call is not ideological; it is a per-workload risk decision. Three questions settle most cases:
What is the worst tool behind this server? Isolation requirements follow the most dangerous capability reachable, not the average one. A server exposing read-only documentation search can be shared widely; a server exposing payment execution, production deployment, or HR records should be dedicated — per workload, sometimes per agent.
Whose data could co-transit? If two workloads' data must never mix — client confidentiality, deal walls, works-council-sensitive HR data — they do not share an MCP process, whatever the efficiency argument.
Can you attribute every call? If the shared design cannot attach per-agent, per-authoriser identity to each tool call, the design fails the audit requirement on its own — before any attack is considered.
And one rule that overrides the matrix: the fallback is dedicated. When you cannot answer the three questions confidently, isolate first and consolidate later. Consolidating two isolated servers is a project; un-merging a shared blast radius after an incident is a disclosure.
Regulatory Postscript
The MCP layer is where several AI Act threads become physically real. Article 12's logging happens here or nowhere — this is where agent actions touch systems. Article 14's oversight gates are enforced here — the gateway is where a "requires approval" policy becomes a blocked call rather than a hopeful convention. And the value-chain questions the agentic editions raised (who controlled the system when an agent chose a tool at runtime?) get their evidence from this layer's logs. When the incident review or the market-surveillance authority asks what your agent actually did, the MCP gateway's log is the answer — if you built it to be.
The Playbook
Inventory the layer. List every MCP server in the organisation, what tools each exposes, which agents call it, and under what identity. Expect surprises; pilots metastasise.
Classify by worst tool. Tag each server by its most dangerous reachable capability. That tag — not team convenience — drives shared vs dedicated.
Insert a gateway with four non-negotiables: per-agent authentication (no shared service accounts), tool-level authorisation, complete call logging with authoriser identity, and rate/cost limits. If a candidate gateway lacks documented multi-tenant isolation or RBAC, it has not closed your gap.
Split the accreted server. The organic shared instance serving unrelated workloads: partition it along data-segregation lines this quarter, before an incident does the partitioning for you.
Test the confused deputy. Red-team one scenario: can a crafted document or prompt make a legitimate agent exfiltrate data through legitimate tools? The answer calibrates how much of this essay is theoretical for you.
Artifact: Shared vs Dedicated — the Decision Matrix
Factor | Shared instance OK | Dedicated required |
|---|---|---|
Worst reachable tool | Read-only, low-consequence | Write/execute on money, production, people data |
Data co-transit | Same sensitivity class, no segregation duty | Confidentiality walls, client separation, special-category data |
Caller population | Homogeneous team, same trust level | Mixed departments, external-facing agents |
Attribution | Per-agent identity enforced at gateway | If shared can't attribute per call → dedicate |
Blast radius tolerance | Loss of one server ≠ material incident | Any compromise = reportable event |
Regulatory surface | Internal productivity tools | Anything feeding an (eventual) high-risk system |
Gateway minimum checklist:
▢ per-agent authN
▢ tool-level authZ
▢ full call log w/ authoriser
▢ rate & cost limits
▢ documented tenant isolation
▢ secrets never in agent context
That’s it for this week.
Next Thursday, Build Lab 3/3: the AI Governance Hub — a reference architecture that turns everything this series (and this spring) established into running infrastructure, with a worked example on Azure.
Until next Thursday, João
OnAbout.AI delivers strategic AI analysis to enterprise technology leaders. European governance lens. Vendor-agnostic. Actionable.
If this landed in your inbox from a forward — subscribe here to get the full picture every week.
