ES
Un control en el núcleo vincula las aprobaciones a cada conexión del agente
Connection Escrow: Holding AI-Agent Pod Egress in the Kernel Until an Isolated Verifier Rules · arXiv:2610.26501
En palabras sencillas
Un agente puede usar un proxy web para llegar a otros servicios, pero un programa que inicia podría abrir su propia conexión de red y saltarse ese proxy. Connection Escrow pausa la conexión saliente del agente dentro del sistema operativo y pregunta a un verificador separado si debe liberar esa conexión concreta.
En una prueba de un clúster de un solo nodo, un socket sin procesar eludió un proxy y entregó una publicación. Con Connection Escrow, se reiniciaron tanto la llamada web habitual como la llamada mediante socket sin procesar, y el servicio no almacenó ninguna publicación. Fue una prueba con dos llamadas descritas, no una medición amplia de todo el tráfico de red.
La investigación
Un agente puede conectarse a la red mediante herramientas, pero un proceso hijo o un socket directo podría eludir una pasarela o la configuración de un proxy. ¿Cómo se puede exigir una aprobación en un punto que el agente no pueda esquivar y vincularla a la conexión concreta que debe controlar?
Connection Escrow retiene cada conexión TCP del agente en el núcleo hasta que un verificador separado aprueba ese socket y destino concretos.
El artículo pregunta cómo aplicar una decisión sobre una conexión saliente cuando un agente puede eludir un proxy, y cómo garantizar que la aprobación corresponda a la conexión que realmente se abre.
Connection Escrow traslada la retención al núcleo y vincula la liberación al socket y al destino indicados por un verificador separado.
En una comparación en un clúster de un solo nodo, un socket sin procesar eludió un proxy configurado para denegar todo y el servicio almacenó una publicación; con Connection Escrow, se reiniciaron tanto la llamada HTTP como la llamada mediante socket sin procesar, y no se almacenó ninguna. Esto muestra que la retención en el núcleo respondió al intento de elusión probado; además, la batería adversarial superó las comprobaciones aplicables a cada ruta de retención.
Los resultados proceden de un prototipo evaluado en ejecuciones separadas en un solo nodo. La barrera de contenido se demostró con TLS 1.2 y está diseñada para entradas hostiles dirigidas a un agente honesto, no para código hostil; además, el sistema confía en el nodo.
Qué muestran las pruebas
- La brecha en el control de conexiones
Connection Escrow es un sistema a nivel del núcleo del sistema operativo que controla las conexiones salientes de cargas de trabajo de agentes supervisadas. Aborda una brecha concreta: un agente o un proceso hijo puede eludir las pasarelas de aplicaciones, los controles de los SDK y la configuración del proxy si abre un socket directo.
Una lista de permisos permanente en el núcleo tampoco vincula el permiso a una conexión concreta. El artículo pregunta cómo aplicar una decisión externa a la conexión que esa decisión debe controlar.
- Retener antes del primer paquete
Para cada conexión TCP supervisada, un punto de control del núcleo registra el identificador del socket y el destino original, y la redirige a un intermediario del nodo antes de que ningún paquete llegue al destino. El intermediario consulta a un verificador que está fuera del control del agente.
La conexión solo se libera si la aprobación es oportuna, está firmada, no se ha usado y especifica ese socket y destino; de lo contrario, se reinicia. El sistema proporciona el punto de control, mientras que las reglas del verificador determinan qué se permite.
- Probar la elusión mediante socket
En una ejecución de Kubernetes en un solo nodo, los autores compararon Connection Escrow con un proxy configurado para denegar todo, usando una llamada mediante cliente HTTP y otra mediante socket sin procesar a un servicio externo.
El proxy bloqueó la llamada HTTP, pero el socket sin procesar lo eludió y el servicio almacenó una publicación. Connection Escrow reinició ambas llamadas y el servicio no almacenó ninguna. La prueba evalúa el intento de elusión descrito en esas condiciones del clúster.
- Comprobar las rutas de control
El banco de pruebas adversariales de los autores comprobó conductas como conexiones rechazadas, aprobaciones falsificadas o reutilizadas, decisiones tardías e intentos desde procesos hijos. Pasaron las 36 comprobaciones en el punto de retención eBPF y las 33 comprobaciones aplicables en el punto de retención iptables.
Tres comprobaciones de fijación de UDP requerían la ruta del núcleo. Estos resultados corresponden a las comprobaciones realizadas en una ejecución registrada, no garantizan el comportamiento con todas las cargas de trabajo o entornos.
- Inspeccionar solicitudes posteriores
Una demostración separada de la barrera de contenido examinó solicitudes enviadas por una conexión cifrada que permanece abierta. Una barrera que solo comprobaba el primer registro dejó que una solicitud POST posterior para exfiltrar datos llegara al servidor después de permitir un GET.
Cuando la barrera de flujo evaluó cada escritura capturada, denegó el POST en demostraciones con tres configuraciones de ejecución TLS. El alcance de este resultado se limita a la configuración TLS y al modelo de amenazas probados con el prototipo.
Detalles
- Autores del paper original
- Ashok Subbabhatta Gopalakrishna
- Enviado a arXiv
- Licencia
- arXiv non-exclusive