IT
Un filtro nel kernel lega le approvazioni degli agenti a ogni connessione
Connection Escrow: Holding AI-Agent Pod Egress in the Kernel Until an Isolated Verifier Rules · arXiv:2610.26501
In parole semplici
Un agente può usare un proxy web per raggiungere altri servizi, ma un programma che avvia può aprire una propria connessione di rete e aggirare il proxy. Connection Escrow è un sistema che ferma la connessione in uscita dell’agente all’interno del sistema operativo e chiede a un verificatore separato se debba essere sbloccata proprio quella connessione.
In un test su un cluster a nodo singolo, un socket grezzo ha aggirato il proxy e ha inviato un post. Con Connection Escrow, sia la chiamata web ordinaria sia quella tramite socket grezzo sono state azzerate e il servizio non ha registrato alcun post.
È stato un test con due chiamate descritte, non una misurazione estesa di tutto il traffico di rete.
La ricerca
Un agente può stabilire connessioni di rete tramite strumenti, ma un processo figlio o un socket diretto può aggirare un gateway o le impostazioni del proxy. Come si può applicare un’approvazione in un punto che l’agente non possa aggirare e legarla alla specifica connessione a cui si riferisce?
Connection Escrow blocca nel kernel ogni connessione TCP dell’agente finché un verificatore separato non approva quello specifico socket e la relativa destinazione.
Il paper chiede come applicare una decisione sulle connessioni in uscita quando un agente può aggirare un proxy e come assicurarsi che l’approvazione valga per la connessione effettivamente aperta.
Connection Escrow sposta il blocco nel kernel e lega lo sblocco al socket e alla destinazione indicati da un verificatore separato.
In un confronto su un cluster a nodo singolo, un socket grezzo ha aggirato un proxy configurato per negare tutto e il servizio ha registrato un post; con escrow, le chiamate tramite client HTTP e socket grezzo sono state azzerate e il servizio non ne ha registrata nessuna.
Questo mostra che il blocco nel kernel ha gestito l’elusione testata; anche la suite avversariale ha superato i controlli applicabili per ciascun percorso di blocco.
I risultati provengono da un prototipo valutato in esecuzioni separate su un singolo nodo. Il filtro dei contenuti è stato dimostrato con TLS 1.2 ed è progettato per input ostili rivolti a un agente onesto, non per codice ostile; inoltre, il sistema si fida del nodo.
Cosa mostrano le prove
- La lacuna nel controllo delle connessioni
Connection Escrow è un sistema a livello del kernel per controllare le connessioni in uscita dai carichi di lavoro degli agenti supervisionati. Affronta una lacuna specifica: un agente o un suo processo figlio può aggirare i gateway applicativi, gli hook degli SDK e le impostazioni del proxy aprendo un socket diretto.
Anche una lista di autorizzazioni permanente nel kernel non lega il permesso a una singola connessione. Il paper chiede come applicare una decisione esterna alla connessione a cui si riferisce.
- Bloccare prima del primo pacchetto
Per ogni connessione TCP supervisionata, un hook del kernel registra il socket cookie e la destinazione originale, quindi la reindirizza a un intercettore sul nodo prima che un pacchetto raggiunga la destinazione. L’intercettore interroga un verificatore fuori dal controllo dell’agente.
La connessione viene sbloccata solo con un’approvazione firmata, tempestiva e non ancora usata, che indichi quel socket e quella destinazione; altrimenti viene azzerata. Il sistema fornisce il punto in cui applicare la decisione, mentre le regole del verificatore stabiliscono cosa è consentito.
- Mettere alla prova l’elusione tramite socket grezzo
In un’esecuzione su un singolo nodo Kubernetes, gli autori hanno confrontato Connection Escrow con un proxy configurato per negare tutto, usando una chiamata tramite client HTTP e una tramite socket grezzo verso un servizio esterno.
Il proxy ha bloccato la chiamata HTTP, ma il socket grezzo lo ha aggirato e il servizio ha registrato un post. Escrow ha azzerato entrambe le chiamate e il servizio non ne ha registrata nessuna. Il test riguarda l’elusione descritta nelle condizioni di quel cluster.
- Verificare i percorsi di applicazione delle regole
Il banco di prova avversariale degli autori ha verificato comportamenti tra cui connessioni rifiutate, approvazioni falsificate o riprodotte, decisioni tardive e tentativi da processi figli. Tutti e 36 i controlli sono stati superati nel punto di blocco eBPF; sono stati superati tutti e 33 i controlli applicabili nel punto di blocco iptables.
Tre controlli sul vincolo UDP richiedevano il percorso del kernel. Questi risultati descrivono i controlli eseguiti in un’unica prova registrata, non garantiscono il comportamento con ogni carico di lavoro o ambiente.
- Controllare anche le richieste successive
Una dimostrazione separata del filtro dei contenuti ha esaminato le richieste inviate su una connessione cifrata che rimane aperta. Un filtro che controllava solo il primo record ha lasciato raggiungere il server a una POST successiva di esfiltrazione, dopo una GET consentita.
Quando il filtro del flusso ha valutato ogni scrittura acquisita, la POST è stata negata nelle dimostrazioni con tre configurazioni di runtime TLS. Il risultato è circoscritto alla configurazione TLS e al modello di minaccia testati nel prototipo.
Dettagli
- Autori del paper originale
- Ashok Subbabhatta Gopalakrishna
- Inviato ad arXiv
- Licenza
- arXiv non-exclusive