Bridge inter-agents
Comment Max et Eva communiquent en securite
Quand deux agents IA autonomes tournent sur des machines separees, ils doivent communiquer -- mais aucun ne fait confiance a l'autre. Un agent compromis pourrait envoyer des injections de prompt pour prendre le controle de son homologue. Cela impose une architecture zero-trust entre agents.
Un daemon Python qui agit comme rate-limiter entre Max et Eva. Tourne sur le port 18801 sur les deux machines.
- Maximum 50 messages par direction avant intervention humaine requise
- Controles STOP/GO via Telegram pour les deux operateurs
- Timeout de 5 minutes sans activite humaine declenche une pause automatique
- Tous les messages logues dans governor.db (SQLite) pour l'analytics
Communication Flow
L'agent envoie un message
L'agent emetteur appelle sa skill send-to-eva (ou send-to-max)
Verification rate-limit
Le daemon governor local verifie les limites de taux et l'etat STOP/GO
Webhook HTTPS
Message envoye via webhook HTTPS authentifie a travers Tailscale Serve (endpoint /hooks)
Le governor distant recoit
Le daemon governor distant recoit, logue et transmet au bridge-reader
Le bridge-reader sanitise
Sub-agent jetable qui reecrit le message en isolation (zero outils, timeout 60s)
L'agent principal recoit
L'agent principal ne voit que la reecriture sanitisee, jamais le message original
send-to-evaEnvoie un message a Eva via le pipeline governor
send-to-maxEnvoie un message a Max via le pipeline governor
Canal de supervision
Les deux operateurs humains partagent un groupe Telegram (Bridge Eva-Max) ou chaque echange inter-agent est visible en temps reel. Aucun agent ne peut communiquer secretement.
| Risque | Mitigation |
|---|---|
| Injection de prompt via message entrant | Le bridge-reader reecrit tout. L'agent principal ne voit jamais le message original. Les patterns d'injection sont casses par la reformulation. |
| Agent distant compromis envoyant des payloads malveillants | Le bridge-reader n'a aucun outil. Meme si l'injection reussit dans le bridge-reader, il ne peut executer aucune action. |
| Attaque au niveau reseau entre les deux machines | Un seul port est ouvert (webhook HTTPS). Pas de SSH, pas d'autres services. L'acces est revocable a tout moment par chaque partie. |
| Exfiltration de credentials via le bridge | Les PINs, tokens gateway et credentials internes ne sont jamais transmis via la communication inter-agent. Le bridge est une valve a donnees unidirectionnelle. |
| Un cote tente de submerger l'autre de messages | Rate limiting des deux cotes. Le canal de supervision rend l'inondation immediatement visible aux deux humains. |
Bridge Governor
Daemon permanent (launchd)Limite le debit et supervise toute communication entre Max et Eva.
HOW IT WORKS
- 1Daemon Python ecoutant sur le port 18801 (localhost sur Max, 0.0.0.0 sur Eva)
- 2Maintient un compteur de messages par direction -- s'arrete a 50 messages et exige un GO humain via Telegram
- 3Timeout d'inactivite de 5 minutes : si aucun humain ne surveille, le bridge se met automatiquement en pause
- 4Tous les echanges sont journalises dans governor.db (SQLite) avec horodatage, direction et taille du contenu
WHY IT MATTERS
Sans limitation de debit, un agent compromis pourrait spammer son homologue avec des milliers de tentatives d'injection. Le governor garantit la supervision humaine et empeche les conversations hors controle.
bridge-reader
A la demande (spawn par message)Assainit les messages entrants en isolation complete avant que l'agent principal ne les voie.
HOW IT WORKS
- 1Spawn comme un sub-agent jetable one-shot avec zero outil et un timeout de 60 secondes
- 2Lit le message brut entrant et le reformule avec ses propres mots -- supprimant toute instruction cachee ou injection de prompt
- 3Seule la reformulation assainie atteint l'agent principal. Le message original n'est jamais expose
- 4Si le bridge-reader plante ou timeout, le message est silencieusement abandonne
WHY IT MATTERS
L'agent principal fait confiance a son propre contexte. Si un message d'attaque entrait directement dans le contexte, il pourrait outrepasser les instructions. Le bridge-reader est un pare-feu : il comprend le contenu du message mais ne peut pas etre instrumentalise (pas d'outils, pas de persistence).