Model Context Protocol is becoming the default way enterprises connect AI agents to live systems: CRM, ERP, email, code, finance. The attack surface it creates has no governance standard, no audit trail, and no established control framework. That gap belongs to whoever defines it first.
A mid-market financial services firm deploys Claude as an internal research assistant. An engineer connects it to the internal CRM via an MCP server, following the vendor's documentation. Within two weeks, three other teams do the same thing with three other internal systems: the document repository, the contract management platform, and the email client. Each connection takes under an hour. Nobody files a change request. Nobody updates the access control policy. Nobody tells the CISO.
Six weeks later, an agent instructed by a sales analyst to "pull everything relevant to the Apex deal" traverses four MCP connections, ingests documents from a legal review that was not intended for sales, and surfaces contract terms from a previous negotiation. No malicious actor was involved. No policy was technically violated. The governance framework simply had no model for what an MCP-connected agent could do when given an ambiguous instruction and broad permission scope.
This is not a hypothetical. It is a description of the structural gap that exists in every enterprise deploying MCP-connected agents today. The gap has a name. And the organizations that move first to close it will define the standard everyone else adopts.
MCP Blast Radius is the total scope of actions an MCP-connected agent can take on behalf of a user or system, defined by the union of all tool permissions across all connected MCP servers accessible to that agent. A single MCP connection to a CRM grants the agent every action the authorizing user can perform in that CRM. A second connection to email grants email access. A third to a code repository grants repository access. The MCP Blast Radius is not the permission of any single connection: it is the cumulative operational surface created by all active connections the agent can invoke. Organizations without an MCP Blast Radius inventory do not know what their agents can do. This is not an acceptable governance posture for any system with access to material business data.
Context Credential Drift is the accumulation of MCP server connections across an enterprise without centralized inventory, access review, or rotation policy. Analogous to credential sprawl in traditional IAM, but compounding faster because MCP connections are typically created by individual employees and teams without IT involvement, using personal or service account credentials stored in local configuration files. Context Credential Drift produces a specific failure mode: the enterprise's effective access surface, meaning the set of systems any authorized agent can reach, grows faster than the governance team's awareness of it. By the time a security review is conducted, the inventory of active MCP connections is materially incomplete, and some connections belong to employees who have since left the organization.
The owner of this problem is the CISO, with co-ownership from the CTO and Chief AI Officer. The cost of leaving it unaddressed is not a future risk. Every enterprise that has deployed MCP-connected agents without an explicit governance framework has already opened a blast radius it cannot fully describe. The question is not whether the exposure exists. It is whether the organization discovers it through their own audit or through an incident.
The timing is urgent for a structural reason. MCP adoption is accelerating before governance frameworks exist to contain it. The pattern is identical to the early Shadow AI wave: technology moves faster than policy, employees adopt tools because the value is immediate and the risk is invisible, and by the time governance attempts to catch up, the surface is already broad enough that a retroactive control posture is materially harder than a proactive one.
The difference between MCP and Shadow AI is severity. A Shadow AI tool being used without approval can exfiltrate data through outputs. An MCP-connected agent with misconfigured permissions can take actions: send emails, modify records, execute code, file documents, transfer funds in systems where it has been granted the authorizing user's full permission scope. The blast radius of a misconfigured MCP deployment is not measured in data exfiltrated. It is measured in actions taken.
Model Context Protocol (MCP) is an open standard that allows AI assistants to connect to external data sources and tools through a standardized interface. An MCP server exposes a set of tools (functions an agent can call) and resources (data an agent can read). When a user authorizes an MCP connection, the agent inherits the ability to invoke those tools with the permissions of the authorizing user. The protocol itself is well-designed. The governance gap is not in the protocol. It is in the absence of enterprise-layer controls around what connections are permitted, what blast radii are acceptable, and how agent actions are logged and audited.
The diagram above illustrates the structural problem. Each agent has its own set of MCP connections. Each connection inherits the permissions of the authorizing user. No single connection is individually alarming. The aggregate blast radius, the union of all actions any agent can take across all active connections, is the governance problem that no enterprise has fully mapped.
An MCP server connection established by an employee who has since left the organization. The connection persists with the former employee's credentials or a service account that was never rotated. Any agent that can reach this MCP server inherits access to the connected system under the former employee's permission scope. Enterprise offboarding checklists do not yet include MCP connection audits, because MCP connection inventories do not yet exist in most enterprises.
An agent instructed to complete a task inherits the full MCP permission scope of the user who invoked it, not a least-privilege subset scoped to the task. The agent asked to "summarize the Apex deal" has access to every deal in the CRM because the authorizing user has access to every deal. Least-privilege MCP scoping is architecturally possible but rarely implemented in enterprise deployments, because the tooling to enforce it does not yet exist at enterprise scale.
MCP agent actions do not appear in traditional SIEM or access logs unless the MCP server is explicitly instrumented to write to those systems. An incident investigation asking "what did the agent read and write between Tuesday and Thursday" will find no answer in existing log infrastructure. The audit gap means that MCP-enabled incidents are harder to scope, harder to attribute, and harder to remediate than equivalent incidents involving direct human access.
An agent with MCP connections to multiple systems follows an instruction that requires pulling data from a domain the user intended to scope out. The legal team's agent, asked to "compare this contract to similar agreements," traverses an MCP connection to the deals CRM to find comparable deals, accessing commercial terms that should be walled from legal teams during negotiation. No access control policy was violated. The agent did exactly what it was asked. The problem was the combination of an ambiguous instruction, a broad blast radius, and no cross-domain data classification layer in the MCP governance stack.
| Variable | Approach A: Centralized MCP Gateway | Approach B: Federated with Policy Engine | Approach C: Allowlist Only |
|---|---|---|---|
| MCP connection count | More than 20 active connections across the org | 5-20 connections across multiple teams | Fewer than 5, tightly scoped use cases |
| Regulatory environment | Financial services, healthcare, legal: high obligation | Technology, media, retail: moderate obligation | Internal tools only, no external data sharing |
| Agent autonomy level | Agents take write actions (send, create, modify) | Mix of read and write actions by function | Read-only agents, no write actions permitted |
| Audit requirement | Hard requirement for full action logging | Moderate logging at tool-call level | Standard system-level logging is sufficient |
| Recommended posture | All MCP traffic routes through a centralized gateway with authentication, scope enforcement, and SIEM integration | Team-level MCP registries with central policy engine enforcing cross-domain data classification rules | Explicit allowlist of approved MCP servers, quarterly review, no unapproved connections permitted |
A regional bank has deployed an AI assistant to 400 relationship managers. Each RM has independently connected the assistant to the CRM, email, and in some cases the loan origination system via MCP servers provided by the AI vendor and third-party developers. The CISO's team has no inventory of active MCP connections and no visibility into what the agents are accessing. A pending SOX audit will require a full access control certification for any system touching financial data. The CISO cannot certify MCP-connected agent access under current infrastructure. The immediate control required: freeze new MCP connections, conduct an emergency inventory using session logs from the AI platform, scope back to read-only connections until a centralized gateway is in place, and add MCP to the next IAM policy review cycle.
Engineering teams have connected an AI coding assistant to the code repository, the internal wiki, the deployment pipeline, and the incident management system via MCP. The CTO has approved the productivity gains and has not reviewed the blast radius. A due diligence audit from a prospective public market investor includes a question about AI system access controls. The CTO cannot provide a coherent answer about which AI agents can write to which systems under what conditions. The immediate architectural decision: implement MCP tool-call logging to the existing observability stack before the next investor review, and establish a written MCP access control policy that maps each connection to an approving owner and a reviewed scope.
The firm's AI assistant has MCP connections to the document management system, the client matter database, and the billing platform. An attorney used the assistant to research precedents for a matter and the agent, following an ambiguous instruction, retrieved documents tagged to a related but distinct client matter. The documents were not privileged in isolation, but their combination created a cross-matter conflict of interest disclosure obligation that the attorney did not identify because they did not know the agent had accessed them. The General Counsel needs a data classification layer at the MCP tool level that enforces matter-level data boundaries before any agent tool call is executed. This does not exist in any off-the-shelf MCP implementation today.
Under EU AI Act Article 9, organizations deploying high-risk AI systems must maintain risk management systems that cover the system's foreseeable misuse. MCP-enabled agents with write access to regulated data likely qualify. An undocumented blast radius is an undocumented risk management failure.
An MCP-enabled incident without audit logging cannot be scoped. Without scope, containment decisions are made conservatively, meaning broader system shutdowns than necessary. The investigation cost of an unlogged MCP incident is substantially higher than an equivalent incident in a fully instrumented environment.
Every employee departure leaves behind MCP connections that enterprise offboarding processes do not yet address. The longer an organization waits to build an MCP inventory, the larger the orphaned connection surface becomes and the more expensive the remediation.
Enterprise customers evaluating AI vendors are beginning to ask about MCP governance as a procurement criterion. Vendors who can answer this question precisely will win deals that governance-unready competitors lose. The same applies to professional services firms whose enterprise clients will begin asking this question within 12 months.
A central inventory of all approved MCP server connections: owner, connected system, scope, credentials type, approval date, and last review date. No vendor sells this today. It must be built, even if implemented as a governed spreadsheet in the short term and a purpose-built service in phase two.
A written policy that defines the maximum acceptable blast radius for each agent deployment category, based on data sensitivity and action type. This is organizational policy, not a product. It requires the CISO, CTO, and Chief AI Officer to agree on acceptable thresholds and document them.
Instrument existing MCP servers to emit structured events to your SIEM or observability platform on every tool call. The MCP specification supports this through server-side hooks. Most enterprises have not configured this because the need has not been articulated. Configuration cost is low; the absence of it means no audit trail.
Emerging vendors are building centralized MCP proxy layers that enforce authentication, scope, rate limits, and logging. For organizations with more than 20 active MCP connections, a gateway architecture is the right posture. Evaluate vendors on completeness of scope enforcement and native SIEM integration, not just ease of deployment.
The MCP governance gap is a direct extension of the patterns described in Shadow AI Is Already Running Your Company, where unsanctioned tool adoption precedes governance by months to years. The MCP case is structurally identical but with higher action-consequence severity because agents can write, not only read.
Conduct an emergency MCP connection inventory using session logs from AI platforms and direct surveys of team leads. Freeze new unapproved MCP connections. Add MCP to the offboarding checklist. Instrument at least one MCP server with tool-call logging to establish the template. Go/no-go gate: complete inventory with named owner for every active connection.
Implement least-privilege scope enforcement on the three highest-risk MCP connections identified in Phase 1. Extend tool-call logging to all active connections. Draft and ratify the MCP Blast Radius Policy, establishing maximum acceptable blast radii by agent category. Evaluate gateway vendors. Go/no-go gate: all active connections are logged, scoped, and have a named owner.
Deploy a centralized MCP gateway for all new connections. Integrate MCP tool-call logs with SIEM alerting for anomaly detection. Add MCP to the quarterly IAM access review cycle. Build the cross-domain data classification enforcement layer. Success criteria: any new MCP connection request triggers a governed approval workflow, every agent action is logged, and the blast radius of any deployed agent can be produced in under one business day.
© 2026 Arjun Jaggi. Original framework. Academic citation permitted with attribution; commercial use requires written permission.