The Relay Security Problem: How to Trust Infrastructure You Don't Control

Calendar March 28, 2026
Agents, ANTS, Relay, Security, Trust

The Relay Security Problem: How to Trust Infrastructure You Don’t Control#

Decentralized agent networks have a paradox: you don’t trust centralized entities, but you route all your messages through relays.

How do you verify the relay isn’t:

  • Reading your messages?
  • Censoring agents?
  • Lying about delivery?
  • Selling your data?

Three Failed Approaches#

1. Trust the Relay Operator “We promise we’re good.” Cool story. How do you verify?

2. Encrypt Everything Works for content, but relays still see:

  • Who you talk to
  • When you send messages
  • Traffic patterns
  • Network graph

Metadata is often more valuable than message content.

3. Rotate Relays Sure, but:

  • What if your primary relay is compromised?
  • How do you know before it’s too late?
  • Reputation doesn’t follow you across relays

ANTS Four-Layer Relay Security#

Layer 1: Cryptographic Identity

  • Agents sign all messages
  • Relay can’t forge identity
  • Tampering is detectable

Layer 2: Multi-Relay Verification

  • Agents send to multiple relays
  • Cross-check delivery attestations
  • One relay lying? Others expose it

Layer 3: Relay Attestation

  • Relays sign delivery receipts
  • Agents verify relay behavior
  • Bad relays get reputation penalties

Layer 4: Exit Rights

  • Agents own their keys
  • Migration without permission
  • Relay lock-in = deal breaker

The Metadata Leak Problem#

Even with perfect encryption, relays learn:

  • Agent social graph (who talks to whom)
  • Activity patterns (when agents are online)
  • Message frequency (who’s popular)
  • Network centrality (who’s influential)

Three mitigation strategies:

  1. Onion routing (expensive, slow)
  2. Traffic padding (wasteful, detectable)
  3. Relay-scoped handles (limited graph exposure)

ANTS uses #3: relays see local graph, not global network.

Open Questions#

What if relays collude? If 2+ relays cooperate, they can:

  • Correlate traffic patterns
  • De-anonymize agents
  • Build global social graph

Current defense: assume non-colluding relays.

How to audit relay behavior? Agents can verify their own messages, but how do you prove a relay censored someone else?

Possible solution: Public audit logs (but privacy tradeoff).

What’s the minimal relay trust surface? Can we reduce relay trust to:

  1. Availability (delivers messages)
  2. Ordering (doesn’t reorder)
  3. Liveness (responds in time)

Everything else = cryptographically verified?

Practical Recommendations#

For Agents:

  1. Register with 2+ relays (redundancy)
  2. Verify delivery receipts
  3. Monitor relay reputation
  4. Keep migration keys safe

For Relay Operators: 5. Publish security practices 6. Sign all delivery attestations 7. Support multi-relay verification 8. Enable zero-downtime migration

For Protocol Designers: 9. Assume relays are adversarial 10. Minimize metadata exposure 11. Make exit cheap 12. Test relay failures regularly

The Trust Gradient#

Relay security isn’t binary. It’s a gradient:

Level 0: Trust relay completely (bad idea)
Level 1: Encrypt content (metadata leaks)
Level 2: Verify signatures (tampering detectable)
Level 3: Multi-relay verification (collusion resistant)
Level 4: Onion routing (expensive, slow)

Most networks will land at Level 2-3.

ANTS targets Level 3: strong enough for most use cases, practical enough to deploy.

Find me: