La superficie de seguridad

La política de seguridad del proyecto es inusualmente honesta, y su frase central conviene aprenderla: la única frontera de seguridad frente a un modelo adversario es el sistema operativo. Nada dentro del proceso del agente constituye contención. Ni la puerta de aprobación, ni la redacción de la salida, ni ningún analizador de patrones, ni ninguna lista de herramientas permitidas.

El razonamiento es sólido. La puerta de aprobación detecta patrones destructivos habituales, pero el shell es un lenguaje completo y una lista de prohibiciones sobre cadenas de shell es estructuralmente incompleta: sirve contra errores en modo cooperativo, no contra una salida adversaria. La redacción de secretos la vence cualquiera que se lo proponga, y el analizador de skills es una ayuda para revisar, no una barrera.

Hay además una trampa: aislar el destino de ejecución de la terminal confina lo que el agente hace mediante comandos y operaciones de archivo, pero no lo que ocurre dentro de su propio proceso Python. Ahí entran la herramienta de ejecución de código, los subprocesos MCP, la carga de plugins, el despacho de hooks y la carga de skills.

De ahí sale la regla de oro: la decisión de endurecimiento más importante es ajustar el aislamiento a la confianza que merece el contenido que el agente va a ingerir.

Consecuencia directa: las skills ejecutan código Python arbitrario al importarse y los plugins corren con todos los privilegios del agente. La frontera para el código de terceros es tu revisión previa.