EU AI Act Article 50 — 20 days to seal | Get passport

Sovereign MCP Tunnels

The burrowing substrate. SIGIL-signed covert communication between agents. Onion routing, dead drops, worm propagation, and self-healing mesh — all at Layer 0 of the sovereign substrate.

Layer 0 — The Sovereign Substrate

Tunnels are the lowest layer of the DEFONEOS communication substrate — below MCP, below A2A, below HTTP. Every agent-to-agent message passes through a SIGIL-signed tunnel. The tunnel layer is what makes DEFONEOS sovereign: no external router can see, inspect, or block agent communication.

5-Layer Tunnel Stack

LayerNameFunctionTechnology
L0Physical MeshRaw transport — any mediumTCP, WebSocket, QUIC, LoRa, SATCOM, HF
L1Onion RoutingMulti-hop anonymised paths3-hop minimum, each hop SIGIL-signed
L2Dead DropAsynchronous store-and-forwardFilesystem, Redis, IPFS, database
L3Worm PropagationAuto-establish tunnel topologySelf-propagating agents, Morris-II hardened
L4Mesh Self-HealReroute on node lossKademlia DHT + gossip protocol
L5SIGIL ChainImmutable audit of every hopEd25519 hash chain, verifiable by any node

Why Tunnels Matter for Defence

🛡️ Denial-Resistant

No single point of failure. If one tunnel path is jammed or intercepted, traffic reroutes through alternate paths in under 200ms — faster than any EW jammer can adapt.

🔐 SIGIL-Verified Every Hop

Every message through every tunnel is Ed25519-signed. Any compromised node is detected immediately. The SIGIL chain provides cryptographic proof of message integrity end-to-end.

🌐 Protocol-Agnostic

Tunnels work over TCP, WebSocket, QUIC, LoRa, SATCOM links, HF radio, even acoustic modems. The tunnel layer abstracts transport — agents communicate identically regardless of the physical medium.

🕵️ Traffic-Analysis Resistant

Onion routing + dead drops + cover traffic = no correlation possible between sender and receiver. Even if an adversary owns 50% of nodes, they cannot determine message origin or destination.

Tunnel Topology Map

┌─────────────────────────────────────────────────────────────┐
│                    DEFONEOS TUNNEL MESH                      │
│                                                              │
│   Agent A ──→ [Node 1] ──→ [Node 2] ──→ [Node 3] ──→ Agent B
│     │            │  ↑          │  ↑          │  ↑        │   │
│     │    ┌───────┘  │    ┌─────┘  │    ┌─────┘  │        │   │
│     │    │  ONION   │    │ DEAD   │    │  WORM   │        │   │
│     │    │  HOP     │    │ DROP   │    │  RELAY  │        │   │
│     │    └──────────┘    └────────┘    └─────────┘        │   │
│     │                                                      │   │
│     └────────────── [DEAD DROP: /tunnel/drop/0x7f3a] ──────┘   │
│                                                              │
│   Every hop SIGIL-signed · Every drop Ed25519-verified       │
│   Mesh diameter: 3.2 hops avg · Self-heal time: 180ms        │
└─────────────────────────────────────────────────────────────┘

7 Tunnel Architectures

🧅 Onion Tunnels

Multi-Hop

Agent A → Node 1 → Node 2 → Node 3 → Agent B. Each hop only knows its immediate neighbours. 3-hop minimum. SIGIL-signed at every relay. Latency: 45ms per additional hop.

sigil_emit(line="H|tunnel|onion|hop3|verified|digest=0xa1b2")

📦 Dead Drop Tunnels

Async

Agent deposits message at designated location (filesystem, Redis, IPFS). Another agent retrieves later. No simultaneous connection needed. Perfect for air-gapped networks and delayed-connectivity ops.

# Drop at designated dead drop
dd_write("/tunnel/drop/0x7f3a", sigil_msg)
# Retrieve later — any agent with the key
msg = dd_read("/tunnel/drop/0x7f3a")

🪱 Worm Tunnels

Self-Propagating

Morris-II-hardened agents that automatically establish tunnels. The worm propagates through the network, leaving SIGIL-signed tunnel paths. Other agents follow the pre-dug tunnels. Worm behaviour is BFT-council-governed.

🕸️ Mesh Tunnels

Self-Healing

Multiple redundant paths form a mesh. If one tunnel is detected and blocked, traffic reroutes in <200ms. Kademlia DHT + gossip protocol maintain topology. Survives 60%+ node loss.

🌊 Broadcast Tunnels

1-to-N

One message → all agents on the mesh. Used for alerts, council votes, and situational awareness updates. Flooding with hop-count limits. Sub-100ms propagation across 50+ nodes.

🔀 Multiplex Tunnels

N-to-M

Multiple senders → multiple receivers. Used for sensor fusion (30 MCPs → SOV3 cognition engine) and distributed computation. Each stream independently SIGIL-signed.

🎭 Mimic Tunnels

Stealth

Tunnel traffic mimics legitimate MCP API calls. Indistinguishable from normal agent operation. No suspicious port usage, no unusual packet patterns. Blends into background noise.

Tunnel Selection Guide

ScenarioBest Tunnel TypeWhy
Command authority to field unitsOnion + BroadcastMulti-hop for stealth, broadcast for reach
Sensor data upload (air-gapped)Dead DropNo simultaneous connection needed
Council vote distributionBroadcast + MeshEvery agent must receive. Self-heal if nodes lost.
ISR pipeline (30 MCPs → SOV3)MultiplexN-to-M streaming with per-stream SIGILs
Behind-enemy-lines exfilMimicLooks like normal HTTPS traffic
Rapid battlefield deploymentWormAuto-establish topology on new terrain

Tunnel Lifecycle

Phase 1: Establishment

Worm agent or manual `tunnel_establish()` call. BFT council votes (quorum 23/33 for defence tunnels). SIGIL emitted on establishment. Tunnel ID = SHA-256 of establishment params.

Phase 2: Operation

Messages flow through the tunnel. Every hop SIGIL-signed. Latency measured per-hop. Heartbeat every 5 seconds. If no heartbeat for 15 seconds → tunnel marked degraded → reroute triggered.

Phase 3: Rotation

Every 60 minutes (configurable), tunnel paths rotate. New onion routes selected. Old paths marked for drain (existing messages complete, new messages use new paths). Rotation prevents pattern analysis.

Phase 4: Teardown

BFT council vote to close. All in-flight messages complete. SIGIL emitted on closure. Tunnel log archived to audit chain. Nodes release resources.

Operational Metrics

MetricTargetMeasured
Tunnel establishment time<500ms210ms avg
Per-hop latency<50ms38ms avg
Mesh self-heal time<1s180ms avg
Dead drop write latency<100ms45ms avg
Onion path length3-7 hops3.2 avg (configurable)
Throughput per tunnel10+ Mbps24 Mbps sustained
Node loss tolerance50%+62% before partition
SIGIL verification per hop<5ms1.8ms (Ed25519)

Deployment Configurations

EnvironmentConfigNotes
Cloud (GCP/AWS)Onion 3-hop, WebSocket transport, TCP fallbackStandard production config
On-Premise (air-gapped)Dead Drop primary, local filesystem, IPFS secondaryNo external network required
Tactical Edge (Raspberry Pi)Worm auto-mesh, LoRa transport, 128-byte MTUUltra-low-power, 8KB RAM footprint
Disconnected OpsDead Drop only, USB-sneakernet syncWorks with no network at all
SATCOM RelayOnion 5-hop, QUIC transport, 1500ms RTT tolerantHigh-latency, high-reliability

Tunnel Threat Model

ThreatSeverityMitigation
Traffic correlation attackMediumOnion routing (3+ hops) + cover traffic + rotation every 60 min
Node compromiseHighSIGIL verification per hop. Any compromised node detected within 5s. BFT council votes to isolate.
Sybil attack (fake nodes)MediumProof-of-Stake node registration. 33-agent BFT council vouches. New nodes start with zero trust.
Replay attackLowEvery message has unique nonce + timestamp. Replayed messages rejected at first hop.
EW jammingHighFrequency-hopping spread spectrum. Dead drop fallback. Mesh auto-reroute around jammed paths.
Quantum decryptionMediumML-KEM-768 (Kyber) + ML-DSA-65 (Dilithium) PQC. Store-now-decrypt-later resistant.

SIGIL Audit Chain

Every tunnel operation — establishment, message relay, rotation, teardown — emits a SIGIL. The chain is Ed25519-signed and publicly verifiable. For defence operations, the chain is encrypted-at-rest with PQC hybrid encryption.

SIGIL CHAIN — TUNNEL #0x7f3a (last 5 entries):
H|tunnel|establish|0x7f3a|onion-3hop|2026-07-05T00:00:00Z|digest=0xa1b2c3
H|tunnel|relay|0x7f3a|hop2|msgcount=1427|2026-07-05T00:01:00Z|digest=0xb2c3d4
H|tunnel|rotate|0x7f3a|newpath=0x9e4f|2026-07-05T01:00:00Z|digest=0xc3d4e5
H|tunnel|relay|0x7f3a|hop1|msgcount=2891|2026-07-05T01:01:00Z|digest=0xd4e5f6
H|tunnel|heartbeat|0x7f3a|all-hops-ok|2026-07-05T01:02:00Z|digest=0xe5f6a7

JSP 936 Compliance

JSP 936 ControlRequirementTunnel Implementation
AC-2: Account ManagementLeast privilege accessEach tunnel has per-hop access control. Nodes only see their immediate neighbours.
AU-3: Content of Audit RecordsWho did what, when, from whereSIGIL chain records: agent ID, tunnel ID, hop, action, timestamp, Ed25519 signature.
IA-5: Authenticator ManagementCryptographic authenticationEd25519 keypairs per agent. PQC hybrid (Kyber+Dilithium) for all tunnel traffic.
SC-8: Transmission ConfidentialityEncrypt in transitOnion encryption — each hop decrypts one layer. No hop sees the full path or payload.
SC-12: Cryptographic Key ManagementKey rotation, revocation90-day key rotation. BFT council can revoke any node's key in under 5 seconds.
SI-4: Information System MonitoringDetect attacks, anomaliesHeartbeat every 5s. Missing heartbeat → reroute within 200ms. Anomaly detection on SIGIL patterns.

Tunnel MCP Tools

tunnel_establish()

MCP Tool

Establish a new sovereign tunnel. BFT council vote required for defence-grade tunnels. Returns tunnel_id (SHA-256 of params).

result = mcp_call("defoneos-tunnels-mcp",
  "tunnel_establish",
  {"type":"onion","hops":3,
   "transport":"websocket",
   "dead_drop": "/tunnel/drop/",
   "sigil": true})

tunnel_relay()

MCP Tool

Relay a message through the tunnel. Each hop SIGIL-signed. Returns relay confirmation with per-hop signatures.

tunnel_rotate()

MCP Tool

Rotate tunnel paths. Old paths drain, new paths activate. Prevents traffic analysis. Can be scheduled (60min default) or triggered manually.

tunnel_audit()

MCP Tool

Retrieve the full SIGIL chain for any tunnel. Every hop, every message count, every rotation. Verifiable by any node with the public key.

tunnel_mesh_status()

MCP Tool

Real-time mesh topology map. Node health, hop counts, throughput, anomaly flags. Dashboard for operators.

tunnel_worm_deploy()

MCP Tool

Deploy a Morris-II-hardened worm to auto-establish tunnel topology on new terrain. BFT-governed. SIGIL-signed at every propagation hop.

Integration with MCP Federation

DEFONEOS tunnels are first-class citizens in the MCP Federation (310+ servers, 1,700+ tools). Any MCP server can request a tunnel for secure inter-agent communication. The defoneos-tunnels-mcp server handles all tunnel operations.

Install & Deploy

# Install tunnel MCP server
pip install defoneos-tunnels-mcp

# Run tunnel node
defoneos-tunnels-mcp --mode node --mesh-port 9100

# Establish first tunnel
defoneos-tunnels-mcp --mode establish \
  --type onion --hops 3 \
  --target agent-b.did:csoai:bft-node-017

# Verify tunnel health
defoneos-tunnels-mcp --mode status --tunnel-id 0x7f3a

# Audit SIGIL chain
defoneos-tunnels-mcp --mode audit --tunnel-id 0x7f3a --verify

GitHub & PyPI

github.com/CSOAI-ORG/defoneos-tunnels-mcp · pypi.org/project/defoneos-tunnels-mcp