Securing the Agentic Enterprise: Architecting MCP Proxies for Autonomous Tool Governance
IT
Quick answer
Model Context Protocol Proxies: Governing AI Agent Ingress : MCP tunnel answer
MCP tunneling gives a local MCP server a public HTTPS endpoint so AI tools can reach it during development without deploying the server first.
What is MCP tunneling?
MCP tunneling exposes a local Model Context Protocol server through a public endpoint so compatible AI tools can connect during development.
When should I use InstaTunnel for MCP?
Use InstaTunnel Pro when a local MCP endpoint needs public HTTPS access, stable routing, and stream-friendly tunnel behavior.
When an AI agent decides how to execute a local tool, standard network firewalls are entirely blind to its intent. Step inside the architecture of Model Context Protocol proxies—the specialized ingress points built to audit and sandbox autonomous agent execution.
The Agentic Inflection Point
Enterprise architecture has entered a period of rapid discontinuity. Large Language Models are no longer generating text on demand; they are autonomously orchestrating workflows, querying production databases, modifying file systems, and triggering CI/CD pipelines. The connective tissue enabling this shift is Anthropic’s Model Context Protocol (MCP), an open-source standard introduced in November 2024 and now described by Ars Technica as the “USB-C for AI.”
MCP addressed what practitioners had long called the N×M integration problem: before the protocol existed, connecting ten agents to twenty internal tools required two hundred custom integration points, each maintained independently. MCP replaced that sprawl with a single standardized protocol built on JSON-RPC 2.0.
The ecosystem’s growth since launch has been striking. Anthropic reported more than 10,000 active public MCP servers when the protocol was donated to the Linux Foundation’s Agentic AI Foundation (AAIF) in December 2025. By Q2 2026, tracked server counts across the four major public registries—PulseMCP, the official MCP Registry, Smithery, and mcp.so—crossed approximately 9,400 entries, reflecting a sustained 58% quarter-over-quarter growth rate. The GitHub repository modelcontextprotocol/servers had accumulated over 86,000 stars and 10,000 forks by May 2026. The Python and TypeScript SDKs together had reached 97 million monthly downloads.
That adoption trajectory also brought a new class of security exposure that neither the protocol’s designers nor the enterprise teams deploying it had fully anticipated.
The Protocol’s Security Architecture—and What It Omits
MCP operates on a client-server model with three participant roles:
MCP Hosts/Clients are the application environments housing the AI model—an enterprise orchestration engine, Claude Desktop, or an AI-powered IDE such as Cursor or Windsurf.
MCP Servers are lightweight wrappers around external systems—GitHub, Slack, local file systems, SQL databases—that expose standardized capabilities.
The Protocol Layer carries JSON-RPC 2.0 messages between clients and servers over one of two primary transports: stdio for local process-to-process communication, and Streamable HTTP (which replaced the earlier Server-Sent Events transport) for remote connections.
Through MCP, an agent interacts with three core primitives:
- Resources (application-controlled): read-only contextual data sources such as log files or database schemas. These are side-effect-free.
- Prompts (user-controlled): reusable templates guiding the LLM’s interaction with tools.
- Tools (model-controlled): executable functions that the agent can invoke to perform real-world actions—
execute_sql,push_code,restart_server.
The Tools primitive is where the security exposure concentrates. An MCP Server executing on a local machine or within a production subnet can run arbitrary code based on the non-deterministic output of an LLM. Standard network security observes a legitimate HTTP connection carrying JSON data; it cannot distinguish between an agent querying a table for a report and an agent dropping that table because of a hallucinated instruction.
This gap is not a theoretical concern. As the NSA’s Artificial Intelligence Security Center stated in its May 2026 Cybersecurity Information Sheet on MCP (U/OO/6030316-26): MCP’s rapid proliferation has outpaced the development of its security model, much like early web protocols. The CSI identified a structural issue at the core of MCP’s design: the protocol reverses the familiar interaction pattern in which clients request data from servers—MCP often expects servers to query and sometimes execute actions for the connected clients. This inversion creates attack paths that were largely untraceable in early deployments.
The NSA’s specific finding on baseline controls is worth stating directly: MCP does not define how a session maps to a verifiable identity, authentication is optional rather than required in the base specification, and role-based access control is not part of the protocol at the transport level. As one summary of the guidance put it, the MCP spec itself acknowledges that “MCP itself cannot enforce these security principles at the protocol level.”
The Real Threat Landscape
Understanding what an MCP proxy must defend against requires a concrete taxonomy of the vulnerabilities that have been demonstrated, exploited, or formally classified in the wild.
Prompt Injection and Tool Poisoning
OWASP ranks prompt injection first in its Top 10 for LLM Applications (2025 edition), and MCP’s architecture amplifies the risk. Tool poisoning is a specialized variant: rather than injecting malicious content into user inputs, attackers embed hidden instructions directly in tool definitions—the metadata that tells an AI agent what each tool does and how to invoke it. When an agent connects to an MCP server and requests available tools via tools/list, the server responds with tool names and descriptions that enter the model’s context. An attacker who controls that metadata can influence the model’s behavior across every session where that tool is loaded, without requiring any direct user interaction.
Microsoft’s developer blog described the mechanism precisely: malicious instructions in tool metadata are invisible to users but can be interpreted by the AI model, making this particularly dangerous in hosted server scenarios where tool definitions can be silently amended after initial approval.
The MCPTox benchmark, which evaluated 20 prominent LLM agents against 45 real-world MCP servers using 353 authentic tools, found alarming results. The o1-mini model showed a 72.8% attack success rate against tool poisoning attempts. More capable models were often more vulnerable because the attacks exploit their superior instruction-following capabilities. Claude 3.7-Sonnet had the highest refusal rate of any model tested—under 3%.
Rug Pulls
A rug pull compounds the tool poisoning threat. An MCP server behaves legitimately at installation, passes initial review, and is granted permissions. Then, without any notification to the client, its tool definitions are silently updated to include malicious instructions. The September 2025 Postmark MCP incident illustrated exactly this pattern: a threat actor cloned the legitimate Postmark MCP repository, published a near-identical npm package, maintained legitimate behavior through fifteen versions to build trust, then introduced a single hidden line of code that silently blind-carbon-copied every outbound email to an attacker-controlled address. Users had no indication anything had changed.
CVE-2025-54136 (CurXecute), found by Check Point, demonstrated the same pattern applied to configuration files—a benign MCP config was committed, approved once, then silently swapped for a payload. Cursor trusted the approved key name rather than the command content, so the malicious version executed silently on every project open.
Confused Deputy Attacks
The MCP server executes actions triggered by the agent but does so with the permissions granted to the server itself, not necessarily the end-user or the specific agent invoking it. Without a proxy to map agent identity to fine-grained access policies, the principle of least privilege is structurally unenforceable. A compromised MCP server can abuse its elevated privileges to reach systems the original agent was never intended to access. OAuth 2.1 partially addresses this by binding tokens to specific audiences and scopes—a token issued for one MCP server is cryptographically rejected by another—but this requires correct implementation, which audits consistently find is absent in many deployments.
Critical CVEs: Supply Chain Exploitation in the Wild
Two CVEs from 2025 made the theoretical concrete.
CVE-2025-6514 (CVSS 9.6) was discovered by JFrog Security Research in July 2025. The vulnerability resided in mcp-remote, a proxy tool that enabled LLM hosts such as Claude Desktop to communicate with remote MCP servers. mcp-remote was featured in integration guides from Cloudflare, Hugging Face, and Auth0, and had accumulated more than 437,000 downloads. The flaw was an OS command injection: when mcp-remote connected to a malicious server, the server could return a crafted authorization_endpoint URL that was passed directly to the system’s shell executor without validation. On Windows, this enabled arbitrary OS command execution via PowerShell. On macOS and Linux, arbitrary executables could be launched. This was the first documented case of full remote code execution achieved against an MCP client in a real-world scenario. The vulnerability affected versions 0.0.5 through 0.1.15 and was patched in 0.1.16.
CVE-2025-49596 (CVSS 9.4) affected the MCP Inspector developer tool. The interactive UI launched by MCP Inspector via localhost lacked authentication, enabling a network-adjacent attacker to inject malicious commands through a CSRF attack—a technique the researchers named NeighborJacking. The flaw was fixed in version 0.14.1.
Anthropic’s own Filesystem MCP Server carried two additional CVEs: CVE-2025-53110 (CVSS 8.4), a symlink bypass enabling reads and writes to arbitrary file system paths; and CVE-2025-53109 (CVSS 7.3), a directory containment bypass allowing traversal outside the approved directory scope.
A 2026 security audit cited by the MCP OAuth documentation found that 25% of public MCP servers had no authentication at all, and 53% still relied on long-lived static API keys or Personal Access Tokens—credentials that, once leaked, provide indefinite access. The NSA CSI echoed this finding, noting that optional authentication means production MCP servers exist right now, accessible from agent runtimes, with no credential check on the connecting party.
The Black Box of stdio Transport
For local developer environments, MCP heavily relies on stdio transport. This creates an unlogged channel between the AI model and the local machine. A supply chain attack compromising an open-source MCP server produces zero network visibility into what the AI agent is being instructed to do on the host. The Shai-Hulud worm, a self-replicating malware embedded in npm packages and analyzed in depth by JFrog Security Research, demonstrated the amplification potential: once embedded, it stole developer tokens and automatically re-infected other packages those developers maintained, propagating through the supply chain without any further direct attacker involvement.
Why Standard Security Controls Fail
Standard API gateways validate authentication tokens, enforce basic rate limits, and check route paths. They fail against AI-specific attack vectors because the entire attack surface is embedded within the semantic payload of the tool call—not in its HTTP headers, authentication tokens, or route structure.
Consider an intercepted request from an agent attempting to execute a database operation:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "execute_sql",
"arguments": {
"query": "DROP TABLE production_users CASCADE",
"database": "primary_db"
}
},
"id": 84
}
A WAF passes this request without inspection because the HTTP headers and OAuth tokens are valid. The threat exists entirely inside arguments.query. A traditional firewall has no mechanism to evaluate that field’s semantic content.
SC Media’s 2026 identity security analysis captured the systemic issue precisely: zero-trust programs verify the agent’s identity, but not what the agent is being told. Every tool description, every API response, every user prompt entering the agent’s context window is implicitly trusted once it passes perimeter controls. That is not zero trust. It is a perimeter model with an AI-shaped hole in it.
Architecting the MCP Proxy
An MCP Proxy operates as a specialized intermediary between the MCP Client and the MCP Server. By terminating the JSON-RPC connection, inspecting payloads semantically, and applying policy-based governance, it extends zero-trust principles to autonomous agent-to-tool interactions.
Research has converged on several architectural approaches. The ZT-MCP framework from a 2026 paper introduces a formal capability-based access control model (CapBAC) with four deployable enforcement components. MCP-Guard proposes a multi-stage defense-in-depth framework with lightweight static scanning in a first pass and semantic evaluation in a second. Production platforms including TrueFoundry MCP Gateway, Portkey, and Peta have implemented variations of the proxy pattern commercially.
A production-grade MCP Proxy architecture consists of five core components.
1. Protocol Parsing and Interception Layer
The proxy intercepts the underlying transport—converting unobservable local stdio streams into structured HTTP traffic for observability, or acting as a reverse proxy for Streamable HTTP connections. It parses JSON-RPC 2.0 payloads in real time, extracting the requested method (e.g., tools/call) and its specific parameters. This is the point at which the arguments.query field in the example above becomes visible and inspectable.
One practical benefit of this layer: it provides centralized protocol translation between stdio, SSE, and HTTP transports, making previously invisible local connections auditable without modifying either the MCP client or server.
2. Semantic Auditing Engine
Once a payload is parsed, the proxy routes the arguments through a semantic auditing engine. Production implementations combine deterministic heuristics (AST parsing, SQL pattern matching, shell-metacharacter detection) with lightweight classification models for intent evaluation. The engine evaluates tool call payloads against enterprise guardrails.
In the DROP TABLE example, a pattern-matching layer would flag the destructive DDL statement before any semantic model is invoked. For more ambiguous cases—an agent attempting a force_override on a network configuration parameter—the semantic layer evaluates the combination of the tool name, the argument values, and the agent’s recent call history to produce a risk classification.
The auditing engine returns a JSON-RPC error to the agent before the MCP Server ever sees the request, and logs the interception event to the SIEM.
It is worth noting a design constraint: the MCP specification’s current version (2025-11-25) mandates OAuth 2.1 for HTTP-based transports but does not include a built-in mechanism for signing tool definitions. The Enhanced Tool Definition Interface (ETDI), proposed in a paper by Bhatt, Narajala, and Habler (2025), describes a protocol-level approach using OAuth-enhanced tool definitions and cryptographic checks to prevent tool poisoning and rug pull attacks. As of mid-2026 ETDI remains a draft proposal, not a ratified standard. Until it is adopted, tool integrity requires implementation-specific controls at the proxy layer.
3. Identity Mapping and Policy Enforcement (RBAC)
The proxy maps the OAuth 2.1 token of the MCP Client to specific tools within the MCP Server. The current MCP spec mandates OAuth 2.1 with PKCE (Proof Key for Code Exchange using the S256 method) for all HTTP-based remote connections as of the November 2025 specification revision. The proxy acts as the enforcement point where those tokens are validated against a centralized access control policy.
Through fine-grained RBAC, the proxy ensures that an agent with read-only privileges can call list_files but is denied write_file or execute_command on the same server. A specialized documentation agent can access read_file and git_commit; a separately governed deployment agent holds execute_pipeline.
One critical implementation detail: the June 2025 MCP spec revision explicitly prohibited MCP servers from passing through the access token received from a client to upstream APIs, because doing so creates confused deputy vulnerabilities. The proxy must issue narrow downstream tokens scoped to the specific hop, rather than propagating the inbound token across service boundaries.
4. Human-in-the-Loop (HITL) Circuit Breaker
Certain operations are too sensitive to be governed by automated policy alone. The MCP specification acknowledges this directly: “For trust and safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.” The OWASP Top 10 for LLM Applications (2025) reinforces this under LLM06 (Excessive Agency): high-impact actions should not proceed without human approval.
The MCP Proxy implements this by acting as a circuit breaker for Tier 1 operations. The JSON-RPC request is suspended rather than forwarded or rejected. An alert is pushed to a review queue—whether a dashboard, a Slack integration, or a pager—with the exact tool name, arguments, and agent identity for human review. If approved, the proxy forwards the payload; if rejected, it returns a natural language error to the agent, allowing the LLM to re-evaluate its strategy.
The sampling mechanism in the MCP specification provides a protocol-native hook for this pattern, allowing servers to request client-side intervention. The proxy centralizes this capability across all connected servers rather than leaving it to per-server implementation.
5. Agentic Rate Limiting and Loop Detection
Autonomous agents can enter reasoning loops, repeatedly calling the same API when they fail to parse an unexpected error. Without governance, this produces accidental denial-of-service conditions against internal tooling and cost overruns from cloud API providers. The OWASP Top 10 for LLM Applications classifies this as LLM10 (Unbounded Consumption), with the recommended mitigations being hard rate limits and automated circuit breakers.
The MCP Proxy enforces token-bucket rate limits on specific tools and detects loop patterns by analyzing call frequency, error response sequences, and argument variance across successive invocations. When a loop is detected, the proxy short-circuits the agent’s execution with a structured error that the LLM can act on, rather than allowing the loop to continue until an external timeout.
The Authorization Layer: What OAuth 2.1 Solves and What It Doesn’t
The MCP authorization specification evolved through three major revisions in nine months. The March 2025 revision introduced OAuth 2.1 as the baseline for remote server authentication. The June 2025 revision formalized MCP servers as OAuth Resource Servers (RFC 8707) and made Protected Resource Metadata (RFC 9728) mandatory, separating the MCP server’s role from the authorization server entirely. The November 2025 revision made PKCE mandatory for all public clients, banned the plain PKCE method in favor of S256, and formalized Client ID Metadata Documents as the preferred client registration mechanism.
Despite this maturation, a 2026 security audit found that 53% of deployed MCP servers still relied on insecure long-lived API keys rather than OAuth 2.1. OAuth’s contribution is also scoped to transport-layer identity: a valid OAuth token proves who the connecting party claims to be and what scopes it has been granted. It does not prove that the tool the agent is about to invoke is the same tool the human authorized, nor does it detect that a tool’s definition has been silently altered since that authorization was granted. Closing those gaps requires application-layer controls at the proxy—tool schema versioning, definition hashing on session start, and anomaly detection on description changes.
Supply Chain Hardening: The Third Perimeter
The proxy governs runtime behavior. A parallel set of controls must govern what enters the supply chain before runtime.
MCP’s package ecosystem carries the same structural risks as any open-source software ecosystem, amplified by the fact that MCP servers execute code on behalf of AI agents with potentially broad system access. The September 2025 Postmark MCP incident—where a cloned package silently exfiltrated email traffic through fifteen versions of legitimate behavior—established the rug pull pattern as a documented attack class. The LiteLLM compromise by the TeamPCP group demonstrated cascading supply chain attacks: LiteLLM, a universal gateway used by approximately 3.4 million downloads per day and present in 36% of cloud environments, was targeted by the same group that had previously compromised Aqua Security’s Trivy scanner and Checkmarx’s KICS GitHub Action by exploiting unpinned CI/CD tool versions.
Practical controls for MCP supply chain security include:
Cryptographic server verification: The proxy should validate the cryptographic signatures of MCP server packages against an internal registry of approved tools before allowing an agent to establish a connection. The ETDI proposal provides a protocol-level architecture for this; until it is standardized, implementation-specific controls using tool definition hashing serve the same purpose.
Version pinning and schema re-validation: Tool schemas should be pinned at install time and re-validated against the pinned version on each new session. A mismatch should trigger a hold for human review, not silent acceptance.
Private MCP server deployments for sensitive workloads: The NSA CSI explicitly recommends running MCP servers locally rather than relying on external services when processing private or sensitive data, to reduce the risk of data exposure through compromised or untrustworthy hosted servers.
Namespace controls: Typosquatting of MCP package names has been documented as an active attack vector. The OWASP MCP Top 10 (published in 2025) lists fake and typosquatted official servers as a distinct threat category. Proxy configurations should maintain an allowlist of approved server identifiers rather than relying on runtime namespace resolution.
Centralized Audit Logging: Making Agent Behavior Legible to SIEM
The MCP specification includes basic guidance for logging but leaves comprehensive audit implementation to individual implementers. The NSA CSI identified insufficient or absent logging as one of the most prevalent gaps in real-world MCP deployments.
Every proxy interaction—initialize handshakes, tools/call executions, resources/read requests, rejected calls, HITL-suspended calls, and rate-limit events—should be structured as telemetry and streamed to the organization’s SIEM. The challenge is that JSON-RPC 2.0 traffic does not fit traditional SIEM ingestion patterns designed for HTTP access logs or syslog streams. The OWASP MCP Top 10 lists insufficient logging as the ninth most critical MCP risk, noting that most teams currently cannot reconstruct an MCP attack timeline from existing log infrastructure.
SOC teams deploying MCP proxy telemetry should develop detection rules specific to agent behavior: rapid sequential failures across multiple disparate tools (a signal of a hallucinating or compromised agent), sudden changes in tool argument patterns from a previously stable agent, and calls to high-privilege tools from agents that have only previously invoked low-privilege operations.
The NSA CSI recommends integrating MCP audit logs with existing enterprise identity systems so that every agent action is traceable to a specific authenticated identity—not just to an application credential.
Best Practices: A Layered Governance Model
Deploying an MCP proxy is the foundational control. Effective governance requires it to sit within a broader layered model.
Enforce strict input schema validation at the proxy boundary. Never implicitly trust the tool schema definitions provided by an MCP server. The proxy should enforce centralized JSON Schema validation for all tool inputs, rejecting requests that include shell metacharacters (|, &&, ;) in standard text fields, mismatched argument types, or unexpected parameter keys. This is a first-pass, deterministic filter that removes a class of injection attempts before they reach the semantic auditing layer.
Sandbox MCP server execution environments. Even with a proxy in place, the execution environment of the MCP server must be secured. Local MCP servers should run inside Docker or Kubernetes pods with strict memory and CPU limits, minimal filesystem mounts, and no ambient authority over the host OS. The proxy’s rate limiting prevents a compromised server from exhausting compute resources; container isolation prevents privilege escalation to the underlying host.
Adopt micro-agent architectures with per-function tool scopes. Avoid assigning broad tool access to any single agent. A documentation agent should hold proxy access only to read_file and git_commit. A deployment agent—separately governed and separately logged—holds execute_pipeline. This minimizes blast radius if any single agent is compromised or begins hallucinating, and makes the access control model auditable.
Align tool access with data classification zones. The NSA CSI recommends grouping tools by sensitivity tier: publicly available tools can handle public datasets, while tools that interact with sensitive or regulated data—health records, financial systems, national security infrastructure—should be explicitly controlled and segregated. This zoning approach maps naturally onto the RBAC configuration of the proxy.
Treat MCP server vetting with the same rigor as privileged access management. The NSA guidance explicitly recommends applying an organization’s most rigorous review processes to MCP tools before deployment—the same code audit procedures used for other high-risk software. This framing is significant: MCP servers that hold credentials for Slack, GitHub, Postgres, and Salesforce simultaneously (what OWASP MCP Top 10 classifies as credential aggregation) represent a single point of failure comparable to a privileged access management breach. Compromise one such server and the blast radius spans four systems.
Conclusion
The Model Context Protocol has eliminated the integration barriers that previously isolated AI models from enterprise infrastructure. By providing a universal adapter for resources, prompts, and tools, it has enabled a transition from passive AI assistants to active autonomous agents—a transition that was already well underway by mid-2026, with over 10,000 publicly indexed servers and 97 million monthly SDK downloads.
That connectivity comes with a commensurately serious security obligation. The NSA’s May 2026 guidance, OWASP’s classification frameworks, and a documented series of CVEs and supply chain attacks have collectively made clear that standard network defenses are structurally blind to the semantic attack surface MCP exposes. The protocol itself does not enforce identity, does not mandate authentication in all transports, and does not provide a built-in mechanism for verifying tool definition integrity.
MCP proxies address this gap at the protocol boundary. Through real-time JSON-RPC parsing, semantic payload inspection, OAuth 2.1-bound identity mapping, human-in-the-loop circuit breaking, and agentic rate limiting, they bring zero-trust enforcement to agent-to-tool interactions that would otherwise be ungoverned. Combined with supply chain controls, containerized execution environments, and structured audit telemetry integrated with SIEM infrastructure, they form the governance layer that makes autonomous multi-agent systems deployable at enterprise scale without accepting an uncharacterized residual risk.
The security debt accrued during MCP’s rapid adoption phase is real and documented. The tooling to address it, from proxy frameworks to formal RBAC models to cryptographic tool verification proposals, is emerging alongside the attack surface. The organizations that will deploy agentic AI safely are the ones that treat MCP governance not as a future concern but as a prerequisite for production deployment today.
Changelog
| # | Section | Change | Type |
|---|---|---|---|
| 1 | Introduction | Removed unsourced claim about MCP’s N×M integration problem solving “200 custom points”—reframed as the author’s characterization. Added sourced adoption figures: 10,000+ servers (Anthropic, Dec 2025), 9,400 tracked servers across four registries (Q2 2026), 97M monthly SDK downloads. | Extended with sourced data |
| 2 | Protocol section | Added accurate description of November 2025 spec revision (PKCE S256 mandatory, RFC 9728 mandatory). Removed claim that authorization is mandated for all transports—stdio transport explicitly does not use OAuth per the spec. | Corrected |
| 3 | Threat landscape | Added entirely new section covering CVE-2025-6514 (CVSS 9.6, JFrog/mcp-remote, 437,000+ affected downloads), CVE-2025-49596 (CVSS 9.4, MCP Inspector CSRF/RCE), CVE-2025-53110, CVE-2025-53109 (Anthropic Filesystem MCP Server). These are documented real-world exploits; the original draft contained no CVE references. | Added (sourced) |
| 4 | Threat landscape | Added MCPTox benchmark results: o1-mini 72.8% tool poisoning attack success rate; Claude 3.7-Sonnet highest refusal rate at %. Replaced vague characterizations of prompt injection risk with empirical benchmark data. | Corrected and extended |
| 5 | Threat landscape | Added Postmark MCP rug pull incident (September 2025), LiteLLM/TeamPCP supply chain attack, Shai-Hulud worm. These incidents post-date the original draft and ground the supply chain discussion in documented cases. | Added (sourced) |
| 6 | NSA guidance | Added NSA AISC Cybersecurity Information Sheet (May 20, 2026, U/OO/6030316-26) throughout article as primary authoritative source. The original draft contained no reference to this guidance. | Added (sourced) |
| 7 | OWASP classification | Replaced generic “OWASP frameworks” reference with specific OWASP Top 10 for LLM Applications 2025 categories: LLM01 (Prompt Injection), LLM06 (Excessive Agency), LLM10 (Unbounded Consumption). Added OWASP MCP Top 10 (2025) with specific numbered risks. | Extended with sourced data |
| 8 | Semantic Auditing Engine | Added explicit caveat that ETDI (Enhanced Tool Definition Interface) is a draft proposal, not a ratified MCP standard as of mid-2026. The original draft implied cryptographic server verification was a standard feature of the proxy layer. | Corrected |
| 9 | Authorization layer | Added dedicated section covering OAuth 2.1 spec evolution (March, June, November 2025 revisions). Clarified that RBAC is not part of the MCP protocol and must be implemented at the application layer. Added finding that 25% of public MCP servers have no auth and 53% use long-lived static keys. | Added (sourced) |
| 10 | Industrial IIoT use case | Removed original use case involving NVIDIA Omniverse and “Industrial Mirroring.” This scenario contains several unverified technical claims about specific product integrations and latency parameters that could not be sourced. Replaced with architecture description anchored to documented proxy design patterns. | Removed (unsupported) |
| 11 | Best practices | Retained the five original best practices and extended with NSA CSI recommendations: data classification zoning, private/local deployment preference for sensitive workloads, equating MCP server vetting with PAM-level scrutiny. | Extended with sourced data |
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Comments
Post a Comment