À propos du projet

Agent Interlock est un framework Python 3.11 (Apache-2.0) qui applique le concept d'ingénierie de sécurité de l'interlock aux interactions agent-à-agent. Les acteurs sont déclarés dans des manifestes ActorSpec, la surface de chaque acteur est encapsulée par un SDK ou un proxy, et la communication entre eux est observée, arbitrée et bloquée afin que seuls les liens déclarés puissent se connecter. Le projet s'articule autour d'une passerelle d'outils MCP. Les menaces M1 à M9 — empoisonnement d'outils, rug pull, shadowing d'outils, publication d'outils empoisonnés, confused deputy ou transfert de jeton, compromission de l'hôte via serveur MCP, découverte ou modification de la configuration de l'agent, collecte d'identifiants et exfiltration de données — sont traitées au niveau du flux de données, chacune avec des verdicts par défaut tels que QUARANTINE, BLOCK, HOLD, CHALLENGE ou SANITIZE. L'application est promue par étapes, de OBSERVE à SHADOW puis ENFORCE, et le passage à ENFORCE nécessite deux approbations signées. Une table de contrôle unique de 29 vérifications se trouve derrière trois points d'application, chacun sélectionnant son propre profil : 21 vérifications pour la passerelle MCP, 19 pour le SDK et 17 pour le courtier A2A. Le README précise explicitement que le mécanisme est partagé mais que la couverture ne l'est pas, et que le courtier ne possède aucun contrôle d'égress, de volume ou de taint. Les composants incluent le SDK (define_actor, connect, wrap), un runtime qui intercepte la communication inter-acteurs, un orchestrateur qui exécute des DAG de tâches vérifiés via les transports A2A, MCP et humains, un courtier A2A gérant les cartes d'agents et les tâches avec pré-application, un registre immuable qui enregistre séparément les événements de requête, verdict, action et résultat, des vues graphiques pour la conception, le runtime et les chemins d'attaque, une interface web Studio basée sur des boîtes pour l'édition d'architecture et l'exportation de manifestes, un adaptateur Anthropic Tool Runner, et une commande interlock verify qui exécute neuf scénarios L1 contre les propres outils protégés d'un projet plutôt que contre les fixtures du framework. D'autres domaines documentés incluent l'application MCP JSON-RPC tools/list, tools/call et list-changed liée aux digests d'architecture ; un client Streamable HTTP JSON/SSE avec liaison de session ; la découverte MCP OAuth, PKCE S256, l'introspection RFC 7662, la vérification optionnelle JWKS/JWT et le consentement loopback ; un client stdio JSONL avec épinglage d'artefacts, attestation de sandbox signée et plans de lancement Bubblewrap ; l'admission de provenance signée pour les éditeurs ; des gardes d'égress par destination compilées à partir des manifestes d'architecture ; le partitionnement PostgreSQL, le FORCE RLS basé sur session_user et un adaptateur de registre immuable avec des API HTTP d'événements et de traces ; l'ingestion OTLP/HTTP JSON ; des puits d'audit signés ; la réconciliation de la dérive conception-versus-runtime pour les arêtes multi-agents ; des limites de confiance internes/externes directionnelles ; et une suite de scénarios de bout en bout avec des données fictives utilisant des adresses .invalid. Le cœur de référence n'a pas de dépendances de runtime externes, les intégrations PostgreSQL et Anthropic étant des options supplémentaires. Le README est transparent sur ce qui n'est pas fourni : pas d'adaptateur LangGraph ou Claude Agent SDK, pas de proxy sidecar, l'interception du connecteur MCP côté serveur est hors de portée car ces outils s'exécutent côté fournisseur, un évaluateur d'acceptation qui est uniquement structurel, et un analyseur de manifeste qui ignore encore certains champs et actions d'effets secondaires. Il est également noté que le SDK ne peut pas atteindre l'API d'approbation de la passerelle, donc une écriture externe depuis un outil encapsulé échoue par défaut au lieu d'être approuvable depuis le SDK. Les travaux d'intégration externe réels tels que Sigstore, KMS/HSM, les fournisseurs d'identité, les sidecars d'égress réels, TLS et la limitation de débit distribuée sont listés comme restant à faire.