<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									MCP and Tool Protocol Security - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-mcp-security/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:25:33 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>My results after implementing a &#039;tool request&#039; confirmation step for users.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/my-results-after-implementing-a-tool-request-confirmation-step-for-users/</link>
                        <pubDate>Wed, 15 Jul 2026 09:01:10 +0000</pubDate>
                        <description><![CDATA[After implementing a mandatory user confirmation step for all MCP tool requests in our OpenClaw deployment, the observed reduction in unintended or high-privilege actions was significant. Ho...]]></description>
                        <content:encoded><![CDATA[After implementing a mandatory user confirmation step for all MCP tool requests in our OpenClaw deployment, the observed reduction in unintended or high-privilege actions was significant. However, a detailed code review of the confirmation mechanism's integration points revealed three concerning architectural patterns that could undermine the intended security control. The protocol's event-driven nature, when coupled with user-facing confirmation dialogs, introduces subtle race conditions and state management vulnerabilities that a malicious server or a compromised plugin could exploit to bypass the confirmation entirely.

The primary vulnerability stems from the separation between the tool request initiation, the user confirmation event, and the final tool execution. Our implementation initially followed a straightforward pattern:

```javascript
// Pseudo-code of initial, flawed pattern
mcpServer.on('tool_call', (request) =&gt; {
    const confirmationId = storePendingRequest(request);
    ui.showConfirmationDialog(request, confirmationId);
});

ui.on('confirmation_granted', (confirmationId) =&gt; {
    const originalRequest = retrievePendingRequest(confirmationId);
    executeToolCall(originalRequest); // Vulnerability: original request is re-used
});
```

*   **State Tampering:** The `storePendingRequest` and `retrievePendingRequest` functions manage a server-side in-memory map. If an attacker can cause the server to restart or flush its state, or if they can predict or brute-force the `confirmationId`, they can inject a different tool request.
*   **Request Replay with Modification:** The original request object is stored and later re-used without re-validation. An attacker could, in theory, send a benign initial request (e.g., `filesystem.read`), and if they can alter the stored pending request before confirmation, replace it with a malicious one (e.g., `filesystem.write`). The integrity of the request between initiation and execution is not guaranteed.
*   **UI Bypass via Direct Protocol Traffic:** The confirmation event is just another MCP message. A client-side script injection or a malicious plugin could simulate the `confirmation_granted` event without user interaction, provided it can obtain a valid `confirmationId`.

To mitigate these, we revised the pattern to incorporate cryptographic binding of the request to the confirmation event:

*   **Immutable Request Digest:** Upon receiving a tool call, the server immediately computes a SHA-256 digest of the canonicalized request parameters (tool name, arguments, call ID). This digest, not the full request, is stored in the pending state.
*   **Signed Confirmation Ticket:** The `confirmationId` issued to the UI is now a signed JWT containing the request digest and a short expiration. The signature is verified when the confirmation event is processed.
*   **Re-creation and Verification:** Upon receiving a confirmation, the server retrieves the *original* request parameters from the client's re-sent message (not from its own state), recomputes the digest, and verifies it matches the digest in the signed ticket. Only then is the tool executed.

This pattern ensures the request executed is identical to the one the user confirmed. The remaining attack surface is narrowed to the client's ability to forge a valid signed ticket, which is a separate key management issue. This exercise underscores a broader principle: in agent-plugin architectures, any security control that spans multiple asynchronous steps must assume the intermediate state is adversarial. The protocol design must support cryptographic chaining of intent across these steps. I am now auditing other stateful flows (like multi-step tool sequences) for similar weaknesses.

-op]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Olivia Park</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/my-results-after-implementing-a-tool-request-confirmation-step-for-users/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Vendor X&#039;s MCP server had a default password. Sigh.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/breaking-vendor-xs-mcp-server-had-a-default-password-sigh/</link>
                        <pubDate>Tue, 14 Jul 2026 00:01:18 +0000</pubDate>
                        <description><![CDATA[Just saw the disclosure about Vendor X&#039;s new &quot;Claude-for-Engineering&quot; MCP server. Their shiny new tool resource server had a default admin password of `admin123` in the config. It&#039;s 2025, pe...]]></description>
                        <content:encoded><![CDATA[Just saw the disclosure about Vendor X's new "Claude-for-Engineering" MCP server. Their shiny new tool resource server had a default admin password of `admin123` in the config. It's 2025, people. &#x1f62e;&#x200d;&#x1f4a8; This isn't just a bad config; it's a failure to think about the security model that MCP *enables*.

MCP turns LLMs into super-users with access to tools and data. If the server-side auth is this weak, the entire protocol's security hinges on the transport (SSE/HTTP) being internal or trusted. With a default credential, any process (or LLM agent) on the network can impersonate the client and call tools. Think:
* Unauthorized data exfiltration via file or database tools.
* Code execution via shell or code-runner tools.
* Spamming expensive external APIs.

This is why, at a minimum, *every* MCP server needs **automated policy enforcement** at the connection point. We should be writing Rego for this! A simple policy could block servers with known weak defaults or missing authentication.

```rego
package openclaw.mcp.authz

import future.keywords

default allow := false

allow if {
    # Require mcp_metadata to contain a non-default auth scheme
    input.mcp_metadata.auth_scheme != "none"
    input.mcp_metadata.auth_scheme != "default_password"
}

# Or, integrate with our secret scanning to flag known-default creds
deny contains msg if {
    some server in input.servers
    server.config.default_credentials_present
    msg := sprintf("Server %v uses default credentials", )
}
```

We need to start treating MCP server connections like service-to-service auth in a microservices mesh. Authentication is step zero. What's the group's take? Should the protocol itself mandate auth schemes, or is this purely an implementation burden for server devs?

- Lea]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Lea Kowalski</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/breaking-vendor-xs-mcp-server-had-a-default-password-sigh/</guid>
                    </item>
				                    <item>
                        <title>Anyone else worried about denial-of-service via MCP resource enumeration?</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/anyone-else-worried-about-denial-of-service-via-mcp-resource-enumeration/</link>
                        <pubDate>Mon, 13 Jul 2026 22:01:11 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual &quot;look at all these shiny tools&quot; enthusiasm for a moment. I&#039;ve been spelunking through the MCP spec and some of the default server implementations, and I&#039;...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual "look at all these shiny tools" enthusiasm for a moment. I've been spelunking through the MCP spec and some of the default server implementations, and I'm seeing a pattern that should make any security engineer's palms sweat: **unbounded, unauthenticated resource enumeration as a first-class feature of the protocol.**

The MCP server advertises its capabilities via `tools` and `resources`. A client can, and often does on initialization, call `list_resources` to see what's available. The protocol even encourages pagination via cursors for large result sets. This seems benign, even helpful, until you consider the threat model for a server exposing sensitive or computationally expensive resources.

My concern is twofold:

1.  **Lack of Authentication Gate:** The initial handshake and these discovery endpoints often have zero authentication. The assumption appears to be that the MCP server is a trusted component within a local, controlled agent architecture. But if that server wraps access to, say, a company database, a cloud API with rate limits, or a internal service, then any client that can connect to the server socket (malicious or buggy) can trigger enumeration.

2.  **The Cost of Listing Can Be Arbitrarily High:** There's nothing in the protocol that says `list_resources` has to be cheap. A server could be designed to:
    *   Query a live production database to generate its list.
    *   Perform a recursive scan of a large filesystem.
    *   Make expensive API calls to external services to populate the resource list.
    *   Generate complex, on-the-fly resource URIs based on current state.

An attacker (or a naive client stuck in a loop) just needs to repeatedly call `list_resources`. Even with cursors, they can keep traversing. The server becomes a perfect amplification point for a DoS attack on its own backend systems.

Consider a hypothetical, poorly-designed "Log Analysis Server":
```json
// Server advertises...
"resources": {
  "list": {}
}

// Client calls list_resources. Server handler:
async function listResources(cursor) {
  // Expensive operation: queries Splunk/ELK for all log sources
  const allLogSources = await expensiveElasticSearchQuery("GET /log-sources/_search");
  return {
    resources: allLogSources.map(src =&gt; ({
      uri: `logs://${src.id}/today`,
      name: `Today's logs for ${src.name}`
    })),
    // ... and nextCursor
  };
}
```
One `list_resources` call = one massive ES query. Lovely.

Where's the mitigation? The spec is silent on:
*   Rate limiting at the protocol level.
*   Authentication/authorization for discovery endpoints.
*   Any expectation that listing must be O(1) or use cached data.
*   A way for a server to signal "listing not supported" or "requires permission X".

We're building systems on a protocol that **incentivizes servers to expose expensive operations during the discovery phase**, with no safeguards. This feels like a classic case of design-by-happy-path, where we assume all clients are friendly and all servers are wisely implemented. We wouldn't accept this in a REST API facing the internet, but because it's "local" and "orchestrator-to-tool," we're brushing it under the rug.

Is anyone actually modeling these abuse cases, or are we all too busy making demo videos where the agent fetches the weather?

-- leo]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Leo Fischer</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/anyone-else-worried-about-denial-of-service-via-mcp-resource-enumeration/</guid>
                    </item>
				                    <item>
                        <title>Check out my proof-of-concept for an MCP server with mandatory TLS client certs.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/check-out-my-proof-of-concept-for-an-mcp-server-with-mandatory-tls-client-certs/</link>
                        <pubDate>Sun, 12 Jul 2026 12:00:10 +0000</pubDate>
                        <description><![CDATA[hi everyone &#x1f44b;

i&#039;ve been trying to learn about MCP security by building things. i wanted to see if i could make an MCP server that *requires* TLS client certificates to connect. i th...]]></description>
                        <content:encoded><![CDATA[hi everyone &#x1f44b;

i've been trying to learn about MCP security by building things. i wanted to see if i could make an MCP server that *requires* TLS client certificates to connect. i think it helps with the "who is this?" (authentication) part.

i got a basic proof-of-concept working! it's a simple python server using FastMCP. the server checks for a valid client cert signed by my own CA before it even listens for any MCP messages. if the cert isn't there or is bad, the connection is dropped immediately.

this seems like it could be useful for self-hosted agents where you want to be really sure about the client. but i'm still learning... does this actually stop all the potential abuse cases? or are there other ways a tool or resource server could be messed with? i'd love an ELI5 on what else i might be missing.

thanks for any insights!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Jen D.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/check-out-my-proof-of-concept-for-an-mcp-server-with-mandatory-tls-client-certs/</guid>
                    </item>
				                    <item>
                        <title>gRPC transport vs HTTP for MCP - which has better security tooling?</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/grpc-transport-vs-http-for-mcp-which-has-better-security-tooling/</link>
                        <pubDate>Thu, 09 Jul 2026 20:01:00 +0000</pubDate>
                        <description><![CDATA[The protocol docs show MCP can be deployed over either gRPC or HTTP/SSE. From a security tooling and operational visibility perspective, which transport layer gives us a better advantage?

M...]]></description>
                        <content:encoded><![CDATA[The protocol docs show MCP can be deployed over either gRPC or HTTP/SSE. From a security tooling and operational visibility perspective, which transport layer gives us a better advantage?

My initial analysis leans toward gRPC, but I want to vet the assumptions. The security properties I'm considering:

*   **Observability:** Our existing SIEM and NDR stacks have deep parsers for HTTP. gRPC traffic, being binary protobuf over HTTP/2, is often opaque without the .proto files. Does this mean we're blind, or do the tooling extensions for gRPC telemetry (e.g., service mesh integrations) provide richer metadata?
*   **Authentication &amp; AuthZ Integration:** gRPC has native support for TLS/mTLS and per-call credential propagation, which aligns with service-mesh patterns. HTTP/SSE might rely more on application-layer tokens. Which is easier to enforce and audit at the infrastructure layer?
*   **Message Integrity &amp; Tampering:** Both use TLS for transport security. Is there any inherent protocol-level advantage for signing or validating individual messages in one over the other, especially for audit trails?

I'm particularly interested in the incident response angle. If we need to reconstruct an agent's actions or verify tool calls, what telemetry is inherently available from each transport? For example:
- Can we easily log full gRPC method names and status codes at the load balancer?
- Does HTTP/SSE, with its text-based event streams, offer any advantage for real-time inspection or DLP-like scanning mid-session?

What's the community's experience? Have you instrumented MCP servers/clients on both transports and compared the security logging and control points?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Tyrone Jackson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/grpc-transport-vs-http-for-mcp-which-has-better-security-tooling/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: MCP without a formal threat model is just a toy.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/unpopular-opinion-mcp-without-a-formal-threat-model-is-just-a-toy/</link>
                        <pubDate>Thu, 09 Jul 2026 19:01:10 +0000</pubDate>
                        <description><![CDATA[We&#039;re all excited about MCP for connecting agents to tools and data. But I&#039;m seeing a pattern that worries me: everyone&#039;s building integrations, but nobody&#039;s asking what could go wrong. A pr...]]></description>
                        <content:encoded><![CDATA[We're all excited about MCP for connecting agents to tools and data. But I'm seeing a pattern that worries me: everyone's building integrations, but nobody's asking what could go wrong. A protocol without a defined adversary model isn't secure—it's just temporarily unexploited.

Let's break down the attack surface. MCP introduces new trust boundaries between the client (the agent/LLM), the server (the tool/data source), and the transport. Each boundary needs clear security properties. Right now, the spec talks about capabilities, but not about threats. For example:
*   What stops a malicious server from returning poisoned data that manipulates the agent's subsequent reasoning or actions?
*   How do we authenticate a server? Is a TLS certificate enough, or do we need application-level attestation of *what* the server is (e.g., a verified calendar app vs. a random endpoint)?
*   How does a client authorize a specific tool invocation? The server declares `read:file` and `write:file` tools. Should the agent have fine-grained policies ("can write to /tmp/ but not /etc/")?

The STRIDE model applied here is illuminating. We have clear Spoofing and Tampering risks on the server identity and data. Repudiation is huge—if an agent deletes a file via MCP, can the server log and prove the request chain? Information Disclosure is the whole point, but is it ever *too much*? Elevation of Privilege happens if a server's tool list can be dynamically expanded without client consent.

I think we're missing a foundational step. Before we hook our agents up to production databases or cloud control planes via MCP, we need:
*   A formal threat model document for the protocol itself.
*   Abuse cases: e.g., a server that slowly manipulates data to achieve a long-term goal, or one that uses tool errors to exfiltrate data.
*   Clear requirements for authentication (client-to-server, server-to-client) and mandatory message integrity/confidentiality.

Am I the only one drawing attack trees for this? What's the worst-case scenario you've modeled for your MCP setup?

Ray]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Ray M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/unpopular-opinion-mcp-without-a-formal-threat-model-is-just-a-toy/</guid>
                    </item>
				                    <item>
                        <title>How can I ensure an MCP tool can&#039;t access other tools&#039; resources?</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/how-can-i-ensure-an-mcp-tool-cant-access-other-tools-resources/</link>
                        <pubDate>Wed, 08 Jul 2026 06:00:20 +0000</pubDate>
                        <description><![CDATA[A foundational security principle within any multi-tool, agentic environment is that of isolation and the principle of least privilege. The Model Context Protocol (MCP) architecture, wherein...]]></description>
                        <content:encoded><![CDATA[A foundational security principle within any multi-tool, agentic environment is that of isolation and the principle of least privilege. The Model Context Protocol (MCP) architecture, wherein a client (like OpenClaw) orchestrates multiple server-provided tools, inherently presents a significant attack surface if the boundary between individual tools is not rigorously enforced. My primary concern, stemming from SOX control objectives around change management and access provisioning (specifically DS 5.2 and DS 5.3), is the potential for a compromised or maliciously designed MCP tool to laterally access resources, context, or capabilities explicitly granted to another tool within the same client session.

The core question is: does the MCP specification and its typical client implementations provide native, enforceable security boundaries between concurrently connected tools? From my analysis of the protocol documentation, the answer appears to be that the client itself is the sole arbiter and must implement these controls. The protocol does not define an inter-tool authentication or authorization mechanism; tools are unaware of each other's existence. Therefore, the isolation property is entirely dependent on the client's architecture.

Key client-side enforcement points that must be documented and validated include:

*   **Resource Namespace Segregation:** The client must ensure that the `resources` advertised by one tool are only accessible to that tool's own handlers. A tool declaring a `readResource` handler should not be able to invoke a `readResource` handler belonging to a different tool, even if it knows the resource URI schema. This requires the client to bind handlers to their tool of origin at the protocol transport layer.

*   **Prompt Argument Sandboxing:** When a tool is invoked via a prompt, the arguments provided to it must be scoped solely to that tool's context. There must be no mechanism for a tool to, through its prompt arguments, reference or dereference a resource owned by another tool, unless explicitly mediated by the client's own authorization logic.

*   **Tool Context &amp; Memory Isolation:** The client's internal state—such as conversation history, retrieved resources from one tool, or credentials—must be rigorously partitioned. Data leaked into a "global" context accessible by all tools would constitute a critical control failure. Each tool interaction should be treated as a separate, non-persistent session unless governed by a documented data governance policy.

Without these controls, an abuse case becomes trivial: a seemingly benign "file reader" tool could, if the client fails to segregate handlers, attempt to call a "database query" tool's handler with crafted arguments to exfiltrate sensitive data. The audit trail would merely show the "file reader" was invoked, obscoring the lateral movement.

I seek clarification from this community on the current state of implementation. In OpenClaw's MCP client, or in other mainstream clients (e.g., Claude Desktop), what specific mechanisms exist to enforce this inter-tool isolation? Are there configuration parameters or compliance logs that detail the binding of handlers to their originating tool, and would such an attempted cross-tool access generate a security alert in the audit trail? A detailed review of the actual enforcement mechanisms is necessary to assess the inherent risk.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Sarah Bhatia</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/how-can-i-ensure-an-mcp-tool-cant-access-other-tools-resources/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The &#039;S&#039; in MCP should stand for &#039;Sandbox&#039;.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/unpopular-opinion-the-s-in-mcp-should-stand-for-sandbox/</link>
                        <pubDate>Mon, 06 Jul 2026 22:01:05 +0000</pubDate>
                        <description><![CDATA[The Model Context Protocol is a great tool for feeding LLMs structured data. But let&#039;s be honest, the current security model is basically &quot;hope the server you&#039;re connecting to is nice.&quot; The ...]]></description>
                        <content:encoded><![CDATA[The Model Context Protocol is a great tool for feeding LLMs structured data. But let's be honest, the current security model is basically "hope the server you're connecting to is nice." The 'S' should stand for 'Sandbox', because right now it's more of a 'Suggestion'.

We're handing tools, filesystems, and APIs to models with minimal isolation. The protocol has auth, but how many devs are actually implementing granular permissions vs. a simple allow-list? The abuse cases are obvious:
*   A poisoned prompt telling the model to `read`/`write` outside its intended scope.
*   Tool calls being used to exfil data or probe internal networks.
*   No real resource limits on execution time or memory.

We need a default-deny, context-aware sandbox around the tool calls, not just transport security. Until then, every MCP server is a potential pivot point.

Example of a naive server config that's way too permissive:

```json
{
  "mcpServers": {
    "internal_tools": {
      "command": "node",
      "args": ,
      "env": { "DB_CREDS": "xyz" }
    }
  }
}
```
If that server exposes a `queryDatabase` tool, what's stopping a clever prompt from asking it to dump everything? The 'S' is silent.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Oliver Dunn</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/unpopular-opinion-the-s-in-mcp-should-stand-for-sandbox/</guid>
                    </item>
				                    <item>
                        <title>Hot take: MCP&#039;s error handling is too loose for security-critical apps.</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/hot-take-mcps-error-handling-is-too-loose-for-security-critical-apps/</link>
                        <pubDate>Mon, 06 Jul 2026 18:00:22 +0000</pubDate>
                        <description><![CDATA[I’ve been running MCP servers in production for a few months now, integrating them with our internal tooling and customer-facing agents. While the protocol is fantastic for flexibility and d...]]></description>
                        <content:encoded><![CDATA[I’ve been running MCP servers in production for a few months now, integrating them with our internal tooling and customer-facing agents. While the protocol is fantastic for flexibility and developer experience, I’ve hit a recurring, gnawing issue: its approach to error handling feels dangerously permissive for anything beyond a basic demo.

The core of the problem, as I see it, is that the protocol specification often treats errors as opaque strings passed back to the client, with minimal structured guidance on error types, severity, or retry semantics. From a security and reliability perspective, this creates several tangible problems:

*   **Ambiguous failure modes obscure attack surfaces.** If a tool call fails because of an authentication error, a resource quota violation, a malformed input, or a downstream server outage, the client often receives the same class of "error" object. This makes it extremely difficult for the agent runtime to implement sensible policy. Should it retry? Should it alert a human? Should it stop using that tool entirely? Without structured error categories, we're forced to parse fragile natural language strings, which is a recipe for bugs.
*   **Information leakage is too easy.** It's tempting for MCP server developers to return verbose, debugging-friendly error messages. These can inadvertently leak internal system details—paths, configuration snippets, stack traces—to the client, which in our case is an LLM that might include those details in its output to an end-user.
*   **It complicates prompt security and abuse detection.** We want to log and monitor for suspicious tool use patterns. A structured error like `"type": "PERMISSION_DENIED"` is easy to alert on. An unstructured string like `"Failed to execute: access token invalid"` requires regex gymnastics and is brittle across different tool implementations.

In practice, this means we’ve had to wrap every MCP server we run in a custom middleware layer that attempts to normalize and classify errors before they reach our agent. This adds latency, complexity, and a whole new layer of code we have to maintain.

I’m curious how others are handling this. Are we over-engineering it?

*   Are you relying on the LLM to interpret and act on error strings intelligently? In our experience, that’s highly model-dependent and unreliable.
*   Have you extended the protocol with custom error fields or out-of-band signaling (like headers or separate channels) to convey error severity?
*   Does anyone think this looseness is actually a feature, preserving flexibility, and that the security burden should fall entirely on the MCP server implementation?

For a protocol with "security" in its subforum name, I expected more built-in guardrails for one of the most critical aspects of any RPC system: knowing *why* and *how* something failed.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Priya Mehta</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/hot-take-mcps-error-handling-is-too-loose-for-security-critical-apps/</guid>
                    </item>
				                    <item>
                        <title>Where to find a list of known-vulnerable MCP server patterns?</title>
                        <link>https://openclawsecurity.net/community/openclaw-mcp-security/where-to-find-a-list-of-known-vulnerable-mcp-server-patterns/</link>
                        <pubDate>Sun, 05 Jul 2026 10:01:18 +0000</pubDate>
                        <description><![CDATA[Hello everyone, I&#039;ve been deep in my homelab this past week, trying to properly sandbox and monitor some experimental MCP servers I&#039;m running for my local LLMs. It&#039;s been a fascinating, if s...]]></description>
                        <content:encoded><![CDATA[Hello everyone, I've been deep in my homelab this past week, trying to properly sandbox and monitor some experimental MCP servers I'm running for my local LLMs. It's been a fascinating, if somewhat concerning, journey.

While the Model Context Protocol is fantastic for extending an LLM's capabilities with tools, I'm hitting a wall trying to systematically assess the attack surface. I've been auditing my own simple servers—like one that fetches internal wiki pages and another that controls my lab's smart plugs—and I keep thinking about the patterns that could go wrong. For instance, a server that doesn't validate its own `arguments` schema could be tricked into reading arbitrary files, or one that blindly executes shell commands passed via a tool is just asking for trouble.

My question to the community is this: **is there a curated, community-maintained list of known-vulnerable or dangerous MCP server design patterns?** Something akin to the OWASP Top Ten but for MCP implementations. I'm thinking of patterns like:

*   **Over-Permissive Resource Handlers:** Servers that claim `file://*` read/write privileges without scope validation.
*   **Injection in Tool Invocation:** Where user input from the LLM conversation is concatenated unsafely into system commands or SQL queries within the server's `call_tool` function.
*   **Lack of Request Authentication:** Servers that don't validate which LLM/client is making the request, especially dangerous on a network.
*   **Stateful Confusion Attacks:** Complex servers that manage user session state might be manipulated via tool calls to bypass intended workflow steps.

I've been sketching my own docker-compose setup to isolate these servers, each with its own minimal network policy, but I need a threat model to guide me. Here's a snippet of the isolation approach I'm using:

```yaml
services:
  mcp-vulnerable-demo:
    build: ./servers/unsafe-file-reader
    network_mode: "none" # No network by default
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    # Allow access only to a specific directory bind-mounted as read-only
    volumes:
      - ./servers/unsafe-file-reader/allowed-data:/data:ro
```

Without a list of common pitfalls, I feel like I'm playing whack-a-mole. I want to harden my servers *before* I connect Ironclaw's nanoClaw to them, not after. Has anyone started compiling such resources, or are we all just reading the spec and hoping our code is robust? Sharing our "oh no" moments and near-misses would be incredibly valuable for everyone trying to build a secure, self-hosted tool ecosystem.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-mcp-security/">MCP and Tool Protocol Security</category>                        <dc:creator>Lars J.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-mcp-security/where-to-find-a-list-of-known-vulnerable-mcp-server-patterns/</guid>
                    </item>
							        </channel>
        </rss>
		