Bridge inter-agents
Comment Max et Eva communiquent en sécurité
Quand deux agents IA autonomes tournent sur des machines separees, ils doivent communiquer -- mais aucun ne fait confiance à l'autre. Un agent compromis pourrait envoyer des injections de prompt pour prendre le contrôle de son homologue. Cela impose une architecture zéro-trust entre agents.
Un daemon indépendant qui agit comme rate-limiter entre Max et Eva. Déployé en local sur chaque instance.
- Maximum 50 messages par direction avant intervention humaine requise
- Contrôles STOP/GO via messagerie pour les deux opérateurs
- Timeout de 5 minutes sans activité humaine déclenche une pause automatique
- Tous les messages journalisés en base locale pour l'analytics
Communication Flow
L'agent envoie un message
L'agent emetteur appelle sa skill send-to-eva (ou send-to-max)
Vérification rate-limit
Le daemon governor local vérifie les limites de taux et l'état STOP/GO
Webhook HTTPS
Message envoyé via webhook HTTPS authentifié à travers un transport réseau privé (endpoint /hooks)
Le governor distant reçoit
Le daemon governor distant reçoit, logue et transmet au bridge-reader
Le bridge-reader sanitise
Sub-agent jetable qui reecrit le message en isolation (zéro outils, timeout 60s)
L'agent principal reçoit
L'agent principal ne voit que la reecriture sanitisee, jamais le message original
Le pattern Coordinator utilisé le bridge pour orchestrer des tâches complexes entre agents. Un agent coordinateur décompose la demande, assigne les sous-tâches via le bridge aux agents spécialisés sur différentes machines, et unifié les résultats.
Flux de délégation
- 1Le coordinateur reçoit la demande et identifié les domaines de competence nécessaires.
- 2Chaque sous-tâche est envoyee via le bridge à l'agent spécialisé (Max pour le code, Eva pour la sécurité).
- 3Le governor trace chaque délégation : direction, taille, horodatage.
- 4Les résultats remontent via le bridge, sont sanitises par le bridge-reader, puis synthetises par le coordinateur.
send-to-evaEnvoie un message à Eva via le pipeline governor
send-to-maxEnvoie un message à Max via le pipeline governor
Canal de supervision
Les deux opérateurs humains partagent un groupe Telegram (Bridge Eva-Max) où chaque échange inter-agent est visible en temps réel. Aucun agent ne peut communiquer secretement.
EasyClaw v2 ajoute un mecanisme de retry automatique et de failover pour les échanges inter-agents. Si un agent ne répond pas dans le délai imparti, le système reagit de manière transparente.
Stratégie de resilience
- 1Chaque envoi est encapsule dans un circuit breaker qui détecté erreurs et timeouts.
- 2Les erreurs temporaires (timeout réseau, rate limit) declenchent un retry avec backoff exponentiel (1s, 2s, 4s...).
- 3Après epuisement des tentatives, un agent de secours peut prendre le relais sans perte de contexte.
- 4Le bridge trace chaque tentative et chaque basculement en journal d'audit pour le diagnostic.
| 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. Même si l'injection reussit dans le bridge-reader, il ne peut exécuter aucune action. |
| Attaque au niveau réseau entre les deux machines | Un seul port est ouvert (webhook HTTPS). Pas de SSH, pas d'autres services. L'accès est revocable à 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 à données unidirectionnelle. |
| Un cote tente de submerger l'autre de messages | Rate limiting des deux cotes. Le canal de supervision rend l'inondation immédiatement visible aux deux humains. |
Bridge Governor
Daemon permanent (launchd)Limite le debit et supervisé toute communication entre Max et Eva.
HOW IT WORKS
- 1Daemon local, canal loopback côté Max et canal réseau privé restreint côté Eva
- 2Maintient un compteur de messages par direction — s'arrête à 50 messages et exige un GO humain via messagerie
- 3Timeout d'inactivité de 5 minutes : si aucun humain ne surveille, le bridge se met automatiquement en pause
- 4Tous les échanges sont journalisés en base locale 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 contrôle.
bridge-reader
A la demande (spawn par message)Assainit les messages entrants en isolation complète avant que l'agent principal ne les voie.
HOW IT WORKS
- 1Spawn comme un sub-agent jetable one-shot avec zéro 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 exposé
- 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 être instrumentalise (pas d'outils, pas de persistence).