Resumen Técnico: Autoridad Remanente en Agentes de Codificación

Definición del Problema: Autoridad Remanente

El artículo identifica una brecha de seguridad específica en los agentes de codificación denominada autoridad remanente. Los agentes de codificación suelen recibir acceso amplio a herramientas para toda una tarea, incluso cuando un recurso o efecto específico solo se requiere para un subobjetivo concreto. El problema central es temporal: la autoridad justificada para un subobjetivo permanece expuesta en la interfaz del planificador después de que dicho subobjetivo se cierra. Mientras que las defensas existentes abordan el contenido hostil, la confianza en las herramientas y las comprobaciones en tiempo de ejecución, a menudo dejan la interfaz del planificador misma expuesta a capacidades que ya no están justificadas. Si una opción de lectura amplia permanece visible para el planificador tras el cierre de un subobjetivo, el modelo puede continuar planificando en torno a ella, creando un estado de seguridad donde las capacidades temporales persisten más allá de su justificación. El artículo argumenta que la interfaz expuesta es parte del estado de seguridad, distinta de la alcanzabilidad en tiempo de ejecución o de los límites del sandbox.

Metodología: Monitor de Referencia PORTICO

Los autores introducen PORTICO, un monitor de referencia diseñado para aplicar vidas útiles de capacidad limitadas a los agentes de codificación. PORTICO opera bajo un modelo de aislamiento de host fijo y se basa en contratos de tareas explícitos y un catálogo de herramientas tipado y sólido.

Mecanismos Centrales

PORTICO compila un contrato de tarea en cuatro componentes:

1. Sobre Inicial ($E_0$): El conjunto de capacidades expuestas al inicio de la tarea.
2. Reglas de Concesión ($\Gamma$): Reglas que definen cómo se puede expandir la autoridad temporal mediante solicitudes explícitas.
3. Reglas de Cierre ($\Lambda$): Predicados (p. ej., paso de pruebas, salida de fase, finalización de subobjetivo) que activan la revocación de la autoridad temporal.
4. Reglas de Denegación Global ($G$): Invariantes como hosts de red prohibidos o acceso a archivos de credenciales.

El Ciclo de Vida de Solicitud–Concesión–Invocación

PORTICO materializa las expansiones como manejadores opacos con límite de época.

• Solicitud: El planificador puede solicitar autoridad basándose en reglas declaradas, pero no puede crear nueva autoridad.
• Concesión: Si una regla coincide, el monitor genera un manejador para el recurso/efecto/fase específico. Este manejador se añade a la siguiente interfaz del planificador.
• Invocación: La ejecución se permite solo si hay un manejador válido y activo presente.
• Cierre: Cuando ocurre un evento de cierre (p. ej., un resultado de prueba confiable), el monitor elimina los manejadores correspondientes de la interfaz del planificador. Los intentos posteriores de usar el manejador caducado son rechazados antes de que ocurran efectos secundarios.

Crucialmente, la revocación elimina la autoridad de la interfaz pero mantiene el contexto (p. ej., nombres de archivos en la conversación) intacto. El planificador ya no puede seleccionar la herramienta para ese recurso sin una nueva concesión.

Contribuciones Clave

El artículo realiza tres contribuciones principales:

1. Definición de No-Uso-Caducado: Define el requisito de que la autoridad de una concesión cerrada debe desaparecer de las interfaces posteriores del planificador y ser inválida en el tiempo de ejecución.
2. Formalización e Implementación: Formaliza la minimización de la exposición, la expansión justificada y el cierre de autoridad en torno a un protocolo de solicitud–concesión–invocación. Estos se implementan en PORTICO mediante manejadores con límite de época.
3. Evaluación Empírica: Evalúa las vidas útiles limitadas en suites de accesorios controlados y repositorios reales fijados, demostrando una reducción en la disponibilidad de capacidades caducadas post-cierre en comparación con diseños que no revocan.

Resultados Experimentales

La evaluación utiliza tres suites de accesorios controlados (A–C) y una suite de repositorios reales (D), comparando PORTICO contra bases (Acceso Total, Lista de Permitidos Estática, Sandbox Grueso) y comparadores específicos (No-Revocador, Todo-Visible con la Misma Política).

Hallazgos Clave

• Minimización (RQ1): Las variantes de PORTICO llevan las violaciones de política y el "radio de explosión" (recursos sensibles alcanzados) a 0.00 en la Suite A, mientras que el acceso total y las listas de permitidos estáticas muestran tasas de violación significativas (1.00 y 0.82, respectivamente).
• Expansión Justificada (RQ2): PORTICO Core (solo el sobre inicial) es seguro pero frágil, fallando en muchas tareas que requieren expansión de límites (0.21 de éxito en la Suite B). PORTICO Full recupera el trabajo legítimo de límites, logrando un 0.87 de éxito en la Suite B mientras mantiene un 1.00 de cumplimiento de alcance y 0.00 violaciones.
• Cierre (RQ3): Este es el diferenciador principal del artículo. Un Comparador No-Revocador (que recibe las mismas concesiones en los mismos tiempos pero nunca las elimina) iguala a PORTICO en éxito de tareas y decisiones pre-cierre. Sin embargo, en relecturas post-cierre:
  • PORTICO Full: Deniega 10/10 intentos de reutilización post-cierre.
  • Comparador No-Revocador: Permite 10/10 intentos de reutilización post-cierre.
  • Auditoría de Efectos Caducados: En pruebas deterministas que involucran escrituras de archivos, mutaciones de git y egreso de red, PORTICO ejecuta 0/6 efectos prohibidos, mientras que el comparador no-revocador ejecuta 6/6.
• Amplitud de Interfaz (RQ3): Un Comparador de Todo-Visible con la Misma Política (interfaz amplia, misma política de ejecución) iguala a PORTICO en efectos prohibidos ejecutados (0/20) pero genera significativamente más propuestas bloqueadas (84 frente a 67), lo que indica que una interfaz más amplia aumenta la presión de planificación incluso si la ejecución es eventualmente denegada.
• Repositorios Reales (RQ4): En repositorios Python reales fijados (Flask, Requests, etc.), PORTICO Full materializa con éxito las concesiones temporales y aplica el cierre, manteniendo el cumplimiento de alcance y cero violaciones a través de 14 contratos.

Significancia y Reivindicaciones

El artículo afirma que PORTICO logra aislar la "vida útil" de la autoridad como una variable de seguridad distinta. El hallazgo clave es que un sistema puede preservar el éxito de la tarea y el cumplimiento del alcance antes del cierre, pero seguir dejando las capacidades temporales disponibles después del cierre si no se aplica la revocación.

Los autores posicionan a PORTICO no como un reemplazo para el sandboxing o las defensas de contenido, sino como una capa complementaria que hace que las capacidades temporales sean explícitas, limitadas y auditables. La significancia reside en la demostración de que la revocación es necesaria para prevenir la autoridad remanente, incluso cuando la política de ejecución y el tiempo de concesión son idénticos a los de un sistema no revocador.

El artículo mantiene la modestia respecto a su alcance:

• Asume un catálogo de herramientas tipado y confiable y una ejecución mediada; no pretende proteger contra comandos de shell no mediados o bypasses del sandbox.
• Reconoce que la calidad del contrato es un insumo de despliegue; los contratos pobres pueden llevar a la concesión insuficiente (bloqueando el trabajo) o a la concesión excesiva (exponiendo el riesgo).
• Se señala un costo de utilidad: PORTICO Full intercambia algo de tasa de finalización bruta por un control de alcance más estricto, resultando en una "incompletitud segura" visible en lugar de un éxito oculto y excesivamente amplio.

En última instancia, el trabajo sostiene que para los agentes de codificación, la interfaz del planificador mismo debe ser dinámica, reduciéndose a medida que las justificaciones expiran, en lugar de permanecer como un menú estático y amplio de herramientas admisibles.