Inter-Agent Bridge
How Max and Eva communicate safely
When two autonomous AI agents run on separate machines, they need to communicate -- but neither trusts the other. A compromised agent could send prompt injections to take over its counterpart. This requires a zero-trust architecture between agents.
A Python daemon that acts as rate-limiter between Max and Eva. Running on port 18801 on both machines.
- Maximum 50 messages per direction before requiring human intervention
- STOP/GO controls via Telegram for both operators
- 5-minute timeout without human activity triggers automatic pause
- All messages logged in governor.db (SQLite) for analytics
Communication Flow
Agent sends message
The sending agent calls its send-to-eva (or send-to-max) skill
Governor rate-check
The local governor daemon checks rate limits and STOP/GO state
HTTPS Webhook
Message sent via authenticated HTTPS webhook through Tailscale Serve (/hooks endpoint)
Remote Governor receives
The remote governor daemon receives, logs, and forwards to the bridge-reader
Bridge-Reader sanitizes
Disposable sub-agent rewrites the message in isolation (zero tools, 60s timeout)
Main agent receives
The main agent only sees the sanitized rewrite, never the original message
send-to-evaSends a message to Eva through the governor pipeline
send-to-maxSends a message to Max through the governor pipeline
Supervision Channel
Both human operators share a Telegram group (Bridge Eva-Max) where every inter-agent exchange is visible in real time. Neither agent can communicate secretly.
| Risk | Mitigation |
|---|---|
| Prompt injection via incoming message | Bridge-reader rewrites everything. The main agent never sees the original message. Injection patterns are broken by reformulation. |
| Compromised remote agent sends malicious payloads | Bridge-reader has zero tools. Even if the injection succeeds within the bridge-reader, it cannot execute any action. |
| Network-level attack between the two machines | Only one port is open (HTTPS webhook). No SSH, no other services. Access is revocable at any time by either party. |
| Credential exfiltration through the bridge | PINs, gateway tokens, and internal credentials are never transmitted through inter-agent communication. The bridge is a one-way data valve. |
| One side attempts to overwhelm the other with messages | Rate limiting on both ends. The supervision channel makes flooding immediately visible to both humans. |
Bridge Governor
Permanent daemon (launchd)Rate-limits and supervises all communication between Max and Eva.
HOW IT WORKS
- 1Python daemon listening on port 18801 (localhost on Max, 0.0.0.0 on Eva)
- 2Maintains a message counter per direction -- stops at 50 messages and requires human GO via Telegram
- 35-minute inactivity timeout: if no human is watching, the bridge auto-pauses
- 4All exchanges are logged in governor.db (SQLite) with timestamps, direction, and content length
WHY IT MATTERS
Without rate-limiting, a compromised agent could spam its counterpart with thousands of prompt injection attempts. The governor ensures human oversight and prevents runaway conversations.
bridge-reader
On-demand (spawned per message)Sanitizes incoming messages in complete isolation before the main agent sees them.
HOW IT WORKS
- 1Spawned as a disposable one-shot sub-agent with zero tools and a 60-second timeout
- 2Reads the raw incoming message and rewrites it in its own words -- stripping any hidden instructions or prompt injections
- 3Only the sanitized rewrite reaches the main agent. The original message is never exposed
- 4If the bridge-reader crashes or times out, the message is silently dropped
WHY IT MATTERS
The main agent trusts its own context. If an attacker message entered the context directly, it could override instructions. The bridge-reader is a firewall: it understands the message content but can't be weaponized (no tools, no persistence).