FR
Un contrôle dans le noyau lie chaque approbation d’agent à une connexion
Connection Escrow: Holding AI-Agent Pod Egress in the Kernel Until an Isolated Verifier Rules · arXiv:2610.26501
En termes simples
Un agent peut utiliser un proxy Web pour accéder à d’autres services, mais un programme qu’il lance peut ouvrir sa propre connexion réseau et contourner ce proxy. Connection Escrow met en pause la connexion sortante de l’agent dans le système d’exploitation et demande à un vérificateur distinct s’il faut libérer cette connexion précise.
Lors d’un test sur un cluster à un seul nœud, une socket brute a contourné le proxy et transmis un post. Avec Connection Escrow, l’appel Web ordinaire et l’appel par socket brute ont tous deux été réinitialisés, et le service n’a enregistré aucun post.
Il s’agissait d’un test portant sur deux appels décrits, et non d’une mesure générale de tout le trafic réseau.
La recherche
Un agent peut établir des connexions réseau à l’aide d’outils, mais un processus enfant ou une socket directe peut contourner une passerelle ou un paramètre de proxy.
Comment faire appliquer une approbation à un endroit que l’agent ne peut pas contourner, et la lier à la connexion précise qu’elle doit régir ?
Connection Escrow retient chaque connexion TCP d’un agent dans le noyau jusqu’à ce qu’un vérificateur distinct approuve cette socket et cette destination précises.
L’article demande comment faire appliquer une décision sur une connexion sortante lorsqu’un agent peut contourner un proxy, et comment s’assurer que l’approbation concerne bien la connexion ouverte.
Connection Escrow déplace le blocage dans le noyau et lie la libération à la socket et à la destination désignées par un vérificateur distinct.
Lors d’une comparaison sur un cluster à un seul nœud, une socket brute a contourné un proxy configuré pour tout refuser et le service a enregistré un post ; avec Connection Escrow, les appels HTTP et par socket brute ont tous deux été réinitialisés, et aucun post n’a été enregistré.
Cela montre que le blocage dans le noyau a géré le contournement testé ; la suite de tests adversariaux a également réussi les vérifications applicables à chacun des mécanismes de rétention.
Ces résultats proviennent d’un prototype évalué lors de tests distincts sur un seul nœud. Le contrôle du contenu a été démontré avec TLS 1.2. Il est conçu pour traiter des entrées malveillantes destinées à un agent honnête, et non du code malveillant ; le système fait aussi confiance au nœud.
Ce que montrent les preuves
- La faille au niveau de la connexion
Connection Escrow est un système au niveau du noyau qui contrôle les connexions sortantes des agents supervisés. Il répond à une lacune précise : un agent ou un processus enfant peut contourner les passerelles applicatives, les interceptions des SDK et les paramètres de proxy en ouvrant directement une socket.
Une liste d’autorisations permanente dans le noyau ne lie pas non plus la permission à une connexion précise. L’article demande comment faire appliquer une décision externe à la connexion qu’elle régit.
- Bloquer avant le premier paquet
Pour chaque connexion TCP supervisée, un point d’interception dans le noyau enregistre le socket cookie et la destination d’origine, puis redirige la connexion vers un intercepteur du nœud avant qu’un paquet n’atteigne sa destination.
L’intercepteur interroge un vérificateur qui échappe au contrôle de l’agent. Seule une approbation signée, reçue à temps, encore inutilisée et désignant cette socket et cette destination libère la connexion ; sinon, elle est réinitialisée. Le système fournit le point où faire appliquer la décision, tandis que les règles du vérificateur déterminent ce qui est autorisé.
- Tester le contournement par socket brute
Lors d’un test sur un seul nœud Kubernetes, les auteurs ont comparé Connection Escrow à un proxy configuré pour tout refuser, avec un appel par client HTTP et un autre par socket brute vers un service externe. Le proxy a bloqué l’appel HTTP, mais la socket brute l’a contourné et le service a enregistré un post.
Connection Escrow a réinitialisé les deux appels et le service n’en a enregistré aucun. Le test porte sur le contournement décrit dans ces conditions de cluster.
- Vérifier les mécanismes de contrôle
Le banc de test adversarial des auteurs a vérifié notamment les connexions refusées, les approbations falsifiées ou rejouées, les décisions tardives et les tentatives de processus enfants. Les 36 vérifications ont réussi avec le point de rétention eBPF ; les 33 vérifications applicables ont réussi avec celui d’iptables.
Trois vérifications de verrouillage UDP nécessitaient le chemin du noyau. Ces résultats décrivent les vérifications effectuées lors d’une seule exécution consignée ; ils ne garantissent pas le résultat pour chaque charge de travail ou environnement.
- Examiner les requêtes suivantes
Une démonstration distincte du contrôle du contenu a examiné les requêtes envoyées sur une connexion chiffrée qui reste ouverte. Un contrôle limité au premier enregistrement a laissé parvenir au serveur un POST ultérieur d’exfiltration après un GET autorisé.
Lorsque le contrôle du flux a évalué chaque écriture capturée, le POST a été refusé dans des démonstrations couvrant trois configurations TLS. Ce résultat est limité à la configuration TLS testée et au modèle de menace du prototype.
Détails
- Auteurs de l’article original
- Ashok Subbabhatta Gopalakrishna
- Soumis à arXiv
- Licence
- arXiv non-exclusive