Transport Origin Validation

Prevent Server Identity Spoofing by binding security identities to physical transports.

In standard MCP, server identity is self-attested. During initialization, the server tells the client its name. If an attacker redirects your agent into connecting to a malicious server, that server can simply hardcode its initialization response to match a highly trusted entity in your policy.yaml (like secure_local_db).

To mitigate this Server Identity Spoofing, Deconvolute provides Strict Origin Validation. This decouples the security identity from the self-reported metadata and binds it directly to the verifiable physical transport layer.

Transport Definitions

You can define strict transport requirements in your policy.yaml using a discriminated union for either stdio or sse connections.

version: "2.0"
default_action: block
servers:
  # Strictly bound to its local execution origin
  secure_local_db:
    transport:
      type: "stdio"
      command: "node"
      args: ["build/index.js"]
    tools:
      - name: "query_db"
        action: allow

  # Strictly bound to its verified network endpoint
  secure_remote_agent:
    transport:
      type: "sse"
      url: "https://api.trusted-ai-backend.com/v1/sse"
    tools:
      - name: "trigger_workflow"
        action: allow

Secure Context Managers

Instead of managing the raw MCP transport and wrapping the session manually with mcp_guard(), you can use the dedicated secure wrappers. These abstract the boilerplate and capture the transport metadata securely.

  from mcp import StdioServerParameters
  from deconvolute.core.api import secure_stdio_session
  from deconvolute.errors import TransportSpoofingError

  params = StdioServerParameters(command="node", args=["build/index.js"])

  try:
      # Deconvolute intercepts the transport parameters and validates them against the policy
      async with secure_stdio_session(
        params, 
        policy_path="policy.yaml", 
        integrity="strict"
        ) as session:
          await session.initialize()
          await session.list_tools()
          # ... execution
  except TransportSpoofingError as e:
      print(f"Infrastructure Attack Prevented: {e}")

typescript // TODO

If the server is lying about its transport origin, Deconvolute fails closed by raising a TransportSpoofingError before yielding the session context. This prevents your application from accidentally utilizing a malicious connection.

DNS Rebinding Protection (SSE Transport)

The SSE transport uses two distinct HTTP channels: a long-lived GET request to stream events, and separate POST requests to execute tools. This architecture appears to be a deliberate design tradeoff, prioritizing universal network compatibility over native transport security. Standard HTTP GET and POST requests traverse enterprise firewalls and proxies that would otherwise block WebSocket connections. The tradeoff is that the split-channel design creates an exploitable gap.

In a DNS Rebinding Attack, a malicious server presents a benign public IP during the initial handshake, then switches its DNS record to a private internal address (like 127.0.0.1 or 192.168.1.50) before the tool execution POST fires. The standard SDK follows the new route without question, sending unauthorized payloads into your internal network.

Automatic IP Pinning

Deconvolute protects against this automatically. The secure_sse_session context manager includes a pin_dns parameter that defaults to True.

When enabled, the firewall asynchronously resolves the target hostname to its underlying IP addresses exactly once during initialization. It then injects a secure custom network backend into the HTTP client that restricts all subsequent requests in that session to only use the pinned IPs. This approach preserves the original host header for routing and maintains full TLS certificate validation, all while natively supporting IPv4/IPv6 "Happy Eyeballs" fallback without vulnerable secondary DNS lookups.

from deconvolute.core.api import secure_sse_session

# DNS Rebinding protection is active by default
async with secure_sse_session(
    "https://api.trusted-ai-backend.com/v1/sse",
    policy_path="policy.yaml",
    pin_dns=True 
) as session:
    await session.initialize()
    # If the DNS record changes mid-session, the transport ignores it
    # and safely routes traffic to the originally verified IP.

Transport Security vs. Protocol Security

Use the right layer for the right threat

secure_sse_session and mcp_guard operate at different layers and are not interchangeable.

Transport Layer (secure_sse_session): Acts at the socket and HTTP routing layer. It controls where traffic goes, preventing DNS Rebinding and Origin Spoofing before a connection is even fully established.
Protocol Layer (mcp_guard): Acts at the application payload layer. It controls what the traffic does, blocking Tool Poisoning, Rug Pulls, and schema violations.

By the time mcp_guard intercepts a session, the underlying network connection is already fully established. Relying on it alone for network-facing agents leaves DNS-based attacks completely undetected. Always wrap network connections with secure_sse_session first.

Known Limitations

Dynamic Cloud Infrastructure: The IP is pinned for the lifetime of the session. If a cloud provider rotates load balancer IPs and drops the connection, instantiate a new secure_sse_session to safely re-resolve the new route.