Our post on the MCP monoculture problem argued that the Model Context Protocol’s vulnerability is architectural — embedded in the protocol’s trust assumptions — and cannot be addressed by implementation hardening alone. The case for deterministic enforcement established that the only defense class producing near-zero attack success rates places policy checks outside the model’s reasoning path entirely. This dispatch examines a March 2026 paper — arXiv:2603.13417, Vasundra Srinivasan, Bridging Protocol and Production — that arrived at those same conclusions from a completely different direction: not security research, but production engineering.
Srinivasan is an AI architect documenting field lessons from an enterprise MCP deployment. She was not red-teaming attack surfaces. She was trying to build something that works reliably at scale. What she found, and formalized, maps precisely onto the structural gaps our corpus identifies — and the six-stage broker pipeline she proposes as the solution is a practitioner implementation of the deterministic enforcement layer our Series 2 argues for. That convergence, from two entirely different epistemological directions, is the point of this dispatch.
Of MCP servers in production rely on insecure long-lived static secrets, per Astrix Security’s analysis of 5,200 servers. Only 8.5% use OAuth. This is the production ecosystem our monoculture post described — and it is the environment Srinivasan is building inside.
The Gap Srinivasan Names
The paper organizes MCP production failure modes into five design dimensions. The one that bears most directly on security is what Srinivasan calls the user context gap. The MCP specification provides no standard mechanism for carrying user identity — user_id, tenant_id, permission scopes — with tool invocations. Without it, an MCP server cannot scope responses to the requesting user. Every tool returns data for all users, or for the wrong tenant.
Her characterization is direct: “User context propagation remains the largest unsolved problem in the MCP specification for enterprise use.” This is not a researcher identifying a theoretical vulnerability. It is a practitioner who hit the wall in production and documented what broke.
Protocol Foundation
Standardized tool discovery via tools/list. Runtime capability negotiation via initialize handshake. JSON-RPC 2.0 transport. Universal agent platform compatibility.
No identity propagation. No tool-level ACL enforcement. No response sanitization. No structured error taxonomy.
Structural gaps remainThe Broker Layer
JWT extraction and validation on every request. Identity claims injected into JSON-RPC context before forwarding. Tool-level ACLs enforced at the broker, not inside the model. Response sanitization strips cross-tenant data.
Credential vault. Full audit trail per invocation. Constraint lives outside the reasoning path.
Deterministic enforcementThe Six-Stage Pipeline
Srinivasan formalizes the broker architecture as the Context-Aware Broker Protocol (CABP): a deterministic six-stage pipeline that every JSON-RPC request must traverse before reaching an MCP server. The pipeline is sequential and non-negotiable — stages two and three can reject requests outright, and no request reaches the MCP server without passing all six.
JWT Extraction
Parse OAuth token from Authorization header. Extract user_id, tenant_id, roles, and permission scopes.
Claim Validation
Verify signature against issuer’s public key set. Reject if expired or untrusted issuer. Can reject.
ACL Resolution
Verify the user’s roles permit the requested tool. Reject if insufficient permissions. Can reject.
Context Injection
Inject identity claims into the JSON-RPC request context. Server reads from context, never raw parameters.
Response Sanitization
Filter response to strip any records where tenant_id does not match the requesting user’s tenant.
Audit Emission
Emit structured log entry: request_id, identity claims, tool name, status, latency, and timestamp.
The structural property that matters here is identical to what SEAgent and Authenticated Workflows demonstrate in the security corpus: the enforcement check is binary and external. It does not read the content of the request to evaluate whether it seems legitimate. It evaluates whether the request is within a declared policy scope. The model’s reasoning chain — whatever path it took to decide to call this tool — is irrelevant to the ACL check in Stage 3. This is what deterministic enforcement looks like in practice.
Don’t wait for native protocol support. Production deployments cannot wait for a specification change with no defined timeline. The broker solves the problem today. And even after native protocol support arrives, the broker stays necessary for ACL enforcement, audit logging, response sanitization, and credential management. It’s not a workaround. It’s a permanent architectural component.
— Vasundra Srinivasan, arXiv:2603.13417Why Convergent Evidence Matters
The 2026 security research corpus — arXiv:2601.17549, 2602.09947, 2601.11893, 2602.10465 — arrives at the broker-layer enforcement argument from the direction of attack success rates, formal threat modeling, and adversarial benchmarking. Srinivasan arrives at the same architectural conclusion from the direction of production reliability: tools timing out, tenant data leaking, agents retrying non-recoverable errors, sequential chains failing when one link breaks. Different problem, same structural solution.
This matters because it closes the “theoretical gap” objection. The vulnerabilities our corpus documents are not artifacts of controlled red-teaming environments. They are the same gaps a practitioner building a real enterprise deployment — cloud resource management workflows, sequential tool chains, multi-tenant data isolation — independently identified as the constraints that prevent reliable production operation. The research and the engineering agree on what the architecture requires.
Security researchers say: place enforcement outside the reasoning path because classifiers are bypassable. Production engineers say: place enforcement outside the reasoning path because the protocol provides no identity mechanism and the model cannot be trusted to handle it consistently. Both conclusions point at the same broker layer. The mechanism they’re describing is the same mechanism.
What This Means for the MCP Ecosystem
The paper’s Astrix Security citation — 53% of production MCP servers using insecure long-lived static secrets, 8.5% using OAuth — is the ecosystem-scale data point our monoculture post lacked. It is not a red-team result. It is an empirical measurement of the production deployment landscape. Most MCP deployments in production today are operating without the identity layer that CABP treats as non-negotiable. That is the baseline condition from which any discussion of MCP security must begin.
Srinivasan’s threat model in Section 9 covers prompt injection via tool responses, data exfiltration via tool invocations, privilege escalation via tool chaining, and denial of service via resource exhaustion — the same four attack classes our corpus documents empirically. She proposes mitigations at the broker layer for each. What is notable is that none of her mitigations involve improving the model’s ability to detect or resist these attacks. Every mitigation is structural: response sanitization, input minimization, tool-level ACL enforcement, per-tool timeouts, circuit breakers. The model’s judgment is not part of the defense in any of them.
Why Srinivasan’s Validation Carries Weight
Vasundra Srinivasan is a Director level architect working on AI at Salesforce, and the author of Data Engineering for Multimodal AI (O’Reilly). She is a senior enterprise practitioner — with production AI deployment experience at one of the largest enterprise software companies in the world — publishing independent research that arrives at the same structural conclusions as the security corpus. That convergence is not coincidental. It is what happens when both red-team research and real production engineering encounter the same protocol-level gap. Corporate documentation from major cloud providers has tended to paper over this gap with operational guidance. Srinivasan names it plainly and proposes a deterministic fix. She is not alone, but practitioners at her level saying it publicly are rarer than they should be. We examined how one major provider handles — and mishandles — this framing in our close reading of Google Cloud’s MCP security documentation.
The Code Mode Connection
Srinivasan explicitly advises: build the broker layer from day one. Do not bolt on user context propagation later. This is precisely what Code Mode — Block’s programmatic approach to MCP tool calling in Goose — skips. The efficiency architecture Code Mode introduces (runtime tool discovery, chained intermediate results, JavaScript sandbox execution) operates on top of MCP without a broker layer. The 53% static secrets figure is the ecosystem that Code Mode is being deployed into. We examined this dynamic in detail in our accompanying post on Code Mode.
The Protocol Gap and What Closes It
Srinivasan proposes CABP as a reference design for a future MCP transport-layer extension — analogous to how OAuth Resource Servers standardize context propagation in REST systems. This is the governance argument our Series 2 Post 3 makes about NIST: the tools exist, the patterns are documented, what is missing is the standards infrastructure to make their use mandatory and consistent rather than optional and uneven.
The paper’s production readiness checklist is worth reading in full. Its three categories — Contract, Resilience, Operations — all presuppose the broker layer as a baseline requirement, not a hardening option. That framing is the same one our deterministic enforcement post establishes: policy enforcement outside the reasoning path is not an enhancement. It is the minimum viable security posture for any MCP deployment operating at enterprise scale.
