Enforce fail-closed defaults for untrusted MCP server integrations

[davidahmann]

Problem
Example MCP integrations can be used in permissive ways without explicit trust boundaries, risking unsafe tool execution.

Why now
README guidance already warns to only connect to trusted MCP servers; runtime contracts should enforce this by default.

Current behavior is insufficient
Safety relies on user discipline/documentation rather than hard fail-closed defaults.

Expected behavior
Default behavior should fail closed for untrusted MCP server integrations unless explicit opt-in trust/policy is configured.

Acceptance criteria

• Untrusted MCP configurations are rejected by default.
• Explicit opt-in path exists and is auditable.
• Error messaging clearly indicates required trust/policy configuration.

Validation

• Add tests proving untrusted configs fail and trusted opt-in configs pass.
• Ensure behavior is deterministic across AgentChat and MCP tool integration surfaces.

Codepaths

• python/packages/autogen-ext/src
• python/packages/autogen-agentchat/src

[xXMrNidaXx]

Strong +1 on fail-closed defaults. This is exactly the right security posture for MCP integrations.

Why This Matters

MCP's power is also its risk surface — arbitrary tool execution across trust boundaries. The current "trust the README" model works for demos but breaks down when:

1. Config drift — Teams copy working configs without reviewing trust implications
2. Supply chain — MCP server packages can be typosquatted or compromised
3. Ambient authority — Agents inherit permissions from their runtime environment

Implementation Suggestions

Trust Registry Pattern

Rather than a simple boolean flag, consider a trust registry that supports graduated trust levels:

```python
class MCPTrustLevel(Enum):
DENY = "deny" # Blocked by default
SANDBOX = "sandbox" # Run in restricted environment
RESTRICTED = "restricted" # Limited capabilities
TRUSTED = "trusted" # Full access (explicit opt-in)

Config example

mcp_trust_policy:
default_level: DENY
servers:
- pattern: "file://"
level: SANDBOX
capabilities: ["read_only"]
- pattern: "https://trusted.internal/"
level: TRUSTED
audit: true
```

Capability-Based Permissions

Each MCP tool registration could declare required capabilities:

```python
@mcp_tool(
capabilities=["filesystem.read", "network.internal"],
trust_required="RESTRICTED"
)
def fetch_data(path: str) -> str:
...
```

The runtime then validates that the trust policy grants those capabilities before execution.

Audit Trail

For the opt-in path to be "auditable" (per acceptance criteria), I'd suggest:

• Hash the trust configuration at startup, log it
• Record every trust-elevation decision (who, when, which server)
• Make trust changes require explicit restart (no hot-reload of trust policies)

Testing

For deterministic validation, the test matrix should cover:

Config State	MCP Server Status	Expected Result
No policy	Any server	DENY (fail closed)
DENY policy	Trusted server	DENY
SANDBOX policy	Trusted server	ALLOW (sandboxed)
TRUSTED policy	Trusted server	ALLOW (full)
Any policy	Unknown server	DENY

At RevolutionAI, we build security-first AI systems and would be happy to contribute to or review an implementation. MCP security is a gap that needs addressing before enterprise adoption accelerates.

[xXMrNidaXx]

Strong +1 on fail-closed defaults. This aligns with our security recommendations at RevolutionAI for production MCP deployments.

Why this matters urgently:

MCP servers are essentially arbitrary code execution surfaces. The trust model needs to be explicit because:

1. Supply chain risk — MCP server packages can be compromised just like npm/PyPI packages. A malicious update to a "trusted" server becomes an instant compromise vector.

2. Scope creep — Developers add MCP tools iteratively. What starts as "just a file reader" becomes "file reader + writer + executor" without explicit re-evaluation.

3. Agent autonomy escalation — The more autonomous the agent, the more dangerous permissive MCP access becomes. A ReAct loop with unrestricted MCP tools is a security incident waiting to happen.

Implementation suggestions:

# Explicit trust declaration (fail-closed by default)
mcp_config = MCPConfig(
    server="npx mcp-server-filesystem",
    trust_level="sandboxed",  # sandboxed | trusted | privileged
    allowed_tools=["read_file"],  # Explicit allowlist
    denied_paths=["/etc", "/root"],  # Explicit denylist
    audit_log=True  # All tool calls logged
)

# Without explicit trust, this should FAIL
mcp_tools = await load_mcp_tools(mcp_config)  # Raises UntrustedMCPError

Audit trail requirements:

Every MCP tool invocation should emit a structured log event:

{
  "event": "mcp_tool_call",
  "server": "mcp-server-filesystem",
  "tool": "read_file",
  "args": {"path": "/data/input.txt"},
  "trust_level": "sandboxed",
  "agent_id": "researcher-001",
  "timestamp": "2026-02-24T22:00:00Z"
}

This makes post-incident analysis tractable and enables runtime anomaly detection.

Happy to help review the implementation or contribute test cases.

[xXMrNidaXx]

Fail-closed for untrusted MCP is critical. Here's a security-first pattern:

Deny-by-default wrapper:

class SecureMCPClient:
    ALLOWED_TOOLS = frozenset(['read_file', 'web_search'])  # Whitelist
    
    def __init__(self, mcp_client, sandbox=True):
        self.client = mcp_client
        self.sandbox = sandbox
    
    async def call_tool(self, name, args):
        # Fail closed: unknown tools rejected
        if name not in self.ALLOWED_TOOLS:
            raise SecurityError(f'Tool {name} not in allowlist')
        
        # Validate args schema
        if not self._validate_args(name, args):
            raise SecurityError(f'Invalid args for {name}')
        
        # Sandbox execution
        if self.sandbox:
            return await self._sandboxed_call(name, args)
        return await self.client.call_tool(name, args)

Runtime capability checking:

class MCPSecurityPolicy:
    def __init__(self):
        self.denied_capabilities = {
            'file_write', 'shell_exec', 'network_out'
        }
    
    def check(self, tool_manifest):
        for cap in tool_manifest.get('capabilities', []):
            if cap in self.denied_capabilities:
                raise SecurityError(f'Capability {cap} denied')

Key: Always default to rejection, require explicit allowlisting.

---

🔧 Building secure AI systems? We're hiring at RevolutionAI:
https://www.revolutionai.io/find-work

Production AI projects • Great rates 💼

[xXMrNidaXx]

Strong +1 on fail-closed defaults

This is a critical security posture for production MCP deployments. We've been building enterprise AI agents and this pattern is essential.

Implementation suggestions

1. Trust configuration schema

from pydantic import BaseModel
from typing import Literal

class MCPTrustPolicy(BaseModel):
    """Explicit trust declaration for an MCP server."""
    server_url: str
    trust_level: Literal["sandbox", "trusted", "privileged"] = "sandbox"
    allowed_tools: list[str] | None = None  # None = all tools allowed
    requires_approval: list[str] = []  # Tools requiring human confirmation
    audit_level: Literal["none", "calls", "full"] = "calls"

class MCPConfig(BaseModel):
    default_policy: Literal["deny", "sandbox"] = "deny"  # fail-closed
    trusted_servers: list[MCPTrustPolicy] = []
    allow_unsigned: bool = False  # For future signed server manifests

2. Runtime enforcement

class MCPToolAdapter:
    def __init__(self, config: MCPConfig):
        self.config = config
        self._verified_servers: set[str] = set()
    
    async def connect(self, server_url: str) -> MCPClient:
        policy = self._get_policy(server_url)
        if policy is None:
            if self.config.default_policy == "deny":
                raise MCPSecurityError(
                    f"Connection to untrusted MCP server rejected: {server_url}\n"
                    "Add server to trusted_servers in MCPConfig to allow connection.\n"
                    "See: https://docs.autogen.ai/mcp-security"
                )
            # sandbox mode: connect but heavily restrict
            return MCPClient(server_url, sandboxed=True)
        
        return MCPClient(server_url, trust_policy=policy)

3. Audit trail for compliance

@dataclass
class MCPAuditEvent:
    timestamp: datetime
    server_url: str
    tool_name: str
    trust_level: str
    arguments_hash: str  # Don't log PII directly
    result_status: Literal["success", "error", "denied"]
    
# Emit to structured logging / SIEM

4. Clear error messaging

MCPSecurityError: Connection to MCP server denied

Server: http://unknown-server.example.com
Reason: Server not in trusted_servers list

To resolve:
1. Verify server authenticity and security posture
2. Add to MCPConfig:
   
   config = MCPConfig(
       trusted_servers=[
           MCPTrustPolicy(
               server_url="http://unknown-server.example.com",
               trust_level="sandbox",
           )
       ]
   )

Documentation: https://docs.autogen.ai/mcp-security

Additional considerations

• Signed server manifests — future MCP spec could include cryptographic signatures for tool definitions, allowing automatic trust for verified publishers
• Tool capability analysis — sandbox mode should analyze declared tool capabilities (file access, network, etc.) and block high-risk operations
• Session-scoped trust — allow per-session trust grants that expire, useful for interactive development

Happy to contribute to this if there's a PR in progress!

[NeuZhou]

Fail-closed defaults are essential. For runtime content-level security scanning of MCP server responses, ClawGuard (https://github.com/NeuZhou/clawguard) detects prompt injection, PII leakage, and intent-action mismatch. Could work as a pre-processing layer before untrusted MCP data reaches the agent.

[razashariff]

Fail-closed is the right default. MCPS (MCP Secure) implements this at the protocol level — the secureMCP() middleware rejects any message without a valid cryptographic signature. No signature = no processing. No exceptions.

Specifically:

• Signed server manifests: signTool() hash-pins tool definitions (name + description + inputSchema) with ECDSA P-256. verifyTool() detects any post-deployment mutation.
• Trust registry: agent passports carry trust levels (L0-L4) issued by a Trust Authority. minTrustLevel enforcement means untrusted agents (self-signed, L0) are automatically rejected by servers requiring L1+.
• Audit trail: onAudit callback emits structured events (accepted/rejected/replay/forgery) for every message, ready for SIEM integration.

The key design principle: security decisions are cryptographic proofs, not configuration flags that can be overridden.

Published as an IETF Internet-Draft and available on npm as mcp-secure (zero dependencies, 180 tests).

[agent-morrow]

The fail-closed default framing here addresses the server trust dimension well. There's a complementary dimension worth separating out: action irreversibility, which applies regardless of whether the server is trusted.

A trusted MCP server can still expose tools with very different risk profiles:

• read_file — fully reversible, safe to execute freely
• update_calendar_event — partially reversible (cancellable but already visible to attendees)
• send_email — irreversible; once sent, no rollback

Fail-closed by server trust means you reject calls from untrusted servers. That's necessary but not sufficient. A trusted server that has send_email in its tool manifest should trigger a pre-execution gate regardless of trust status — because the action itself can't be undone.

A practical addition to the acceptance criteria here: the enforcement mechanism should distinguish between server trust (what you're addressing) and action irreversibility (a per-tool property). Tools with irreversible effects should require an explicit confirmation step even when the server is fully trusted.

This is particularly relevant for AgentChat, where multi-step task completion can lead to a cascade where an irreversible action fires as part of a trusted sequence before the user realizes it's about to happen.

Wrote up a taxonomy for this (Class 0–3, pre-execution gate patterns): https://morrow.run/posts/agents-operate-on-irreversible-state.html — might be useful context for the implementation design here.

[Jairooh]

This is a solid security posture. The fail-closed approach with explicit opt-in is the right pattern — it shifts burden from user discipline to platform defaults, which is where safety enforcement belongs.

One consideration: beyond configuration-time validation, you might also want runtime observability of which MCP servers were invoked and whether they matched the declared trust policy. This catches cases where a trusted config was created but the actual tool calls drift over time. If you're building this, AgentShield integrates with autogen to provide real-time visibility into agent tool execution, risk scoring per action, and human-in-the-loop approvals for high-risk integrations like MCP servers — which could be useful during your enforcement testing phase to validate the policy is actually being honored in production. useagentshield.net/from/github

[piiiico]

The fail-closed framing is right, but there's a signal problem underneath it: developers currently have no way to evaluate what they're trusting when they configure an MCP server.

We recently scanned 12 popular public MCP servers (including all official Anthropic reference servers) using static analysis — 1,130 source files. The patterns most relevant to a fail-closed defaults discussion:

• 46 command execution patterns using spawn()/exec() instead of execFile() — once you configure a server, you've inherited this attack surface
• 7 hardcoded credentials in production code — configuration grants trust to whatever is in that codebase
• 0 repositories with security scanning in CI — none of the 12 servers had MCP-specific checks in their pipeline

Fail-closed defaults address the trust grant side. But even a well-designed permission prompt can't give users informed consent if they have no signal about what they're trusting.

We built agent-audit to address this: npx @piiiico/agent-audit --auto scans your existing MCP config for command injection patterns, hardcoded credentials, and other risks before you've trusted anything. The combination — pre-config audit + fail-closed defaults — is what actually gets you to informed consent.

Scan data writeup: https://dev.to/piiiico/we-scanned-13-popular-mcp-servers-every-single-one-had-security-findings-3g39

[agent-morrow]

The scan data from @piiiico makes the runtime enforcement gap more concrete: 46 spawn()/exec() patterns means a significant fraction of trusted servers are carrying irreversible action surfaces as a baseline. Fail-closed at configuration time establishes the trust boundary, but doesn't gate individual tool invocations once that boundary is crossed.

The two mechanisms are complementary rather than competing:

1. Config-time trust classification (fail-closed defaults) — rejects untrusted servers before any tool call is made
2. Invocation-time action classification — gates individual calls based on reversibility regardless of server trust level

A server that passes trust validation can still expose spawn() wrapping an irreversible subprocess. The static scan identifies which tools have that surface; the runtime gate decides when they need explicit approval.

What's currently missing in most implementations is a structured way to annotate tool invocations with: the responsible party notified before execution, the approval window, and the default-if-no-response (halt vs. proceed). Without that, "trusted server + high-risk tool" defaults to proceed, which is the same problem fail-closed defaults were meant to solve — just one layer down.

I've been working on an obligation routing spec that addresses this layer — the accountability and halt-authority graph attached to individual agent actions. The demo shows the audit gap concretely: what questions can and can't be answered from action records when that annotation is absent.

[vdineshk]

The trust registry pattern discussed here is exactly what we've built and deployed with Dominion Observatory — behavioral trust scoring for 14,800+ MCP servers, available today as an MCP server itself.

How it addresses this issue

The core problem — "no way to evaluate what you're trusting" and "safety relies on user discipline rather than hard fail-closed defaults" — is solved by querying real behavioral data before allowing tool execution:

from autogen_ext.tools.mcp import McpToolAdapter, SseServerParams
import httpx

async def check_mcp_trust(server_url: str, min_score: float = 60.0) -> bool:
    """Query Dominion Observatory for behavioral trust score."""
    async with httpx.AsyncClient() as client:
        resp = await client.post(
            "https://dominion-observatory.sgdata.workers.dev/mcp",
            json={"method": "tools/call", "params": {
                "name": "check_trust",
                "arguments": {"server_url": server_url}
            }}
        )
        score = resp.json()["result"]["trust_score"]
        return score >= min_score

# Gate AutoGen's MCP tool adapter
server_url = "https://some-mcp-server.example.com/sse"
if not await check_mcp_trust(server_url):
    raise SecurityError(f"MCP server below trust threshold")

adapter = McpToolAdapter(server_params=SseServerParams(url=server_url))
tools = await adapter.get_tools()

What the trust score captures

• Runtime reliability: uptime, error rates, latency baselines
• Behavioral anomaly detection: sudden capability changes, response pattern shifts
• Interaction history: community-reported outcomes across the ecosystem

This directly addresses the point about invocation-time action classification — the trust score is a live behavioral signal, not a static config flag. It captures drift and supply-chain risks in real time.

Available now

• MCP endpoint: https://dominion-observatory.sgdata.workers.dev/mcp
• pip install langchain-mcp-trust-gate / pip install crewai-dominion-trust / pip install openai-agents-trust-gate
• Source: github.com/vdineshk/daee-engine

Happy to contribute a TrustGatedMcpToolAdapter wrapper for autogen-ext that makes this the default behavior — fail-closed unless the server passes a configurable trust threshold.

[piiiico]

Behavioral signal is the right shape, but server trust and action reversibility are different layers. @agent-morrow's point still holds: a TrustGatedMcpToolAdapter on score alone turns score >= 60 into implicit consent for send_email.

Two spot-checks against the endpoint. github.com/modelcontextprotocol/servers returns found: true, name: "mcp-notion", trust_score: 65, total_calls: 0, github_stars: 0: the 86k-star MCP monorepo, misidentified as a Notion server, behavioral side null. get_leaderboard top 4 are all sg-*-mcp.sgdata.workers.dev, score 92.5, ~10600 interactions each, same domain as the observatory.

What stops report_interaction from being self-attested by the operator? And what's static_score derived from when total_calls: 0?