Andrew Ng anunció una nueva versión de OpenWorker, su agente de IA de código abierto para escritorio, con un conjunto de funciones centradas en flujos de trabajo de seguridad. El motivo que da es que, tras el lanzamiento de la primera versión, muchos usuarios descubrieron que resultaba especialmente útil en escenarios de ciberseguridad; los atacantes ya usan IA, así que quienes se defienden deberían contar con la misma palanca.
OpenWorker no sigue el camino de la ventana de chat. El usuario entrega una tarea y el agente la descompone por sí mismo en pasos, actuando a través de archivos, terminal y aplicaciones conectadas, para entregar al final un resultado listo para usar. El proyecto se volvió de código abierto en julio, bajo licencia MIT, se encuentra actualmente en fase de prueba abierta y ya acumula 16.400 estrellas en GitHub. La versión de escritorio es compatible con macOS 12 o superior (Apple Silicon, firmado y notarizado) y Windows 10/11 en versión x64, cuya firma de código todavía está en trámite.
Escanea el código, escanea también las dependencias
El rol dedicado que se coloca en primer lugar en la nueva versión se llama "revisión de seguridad". La documentación del repositorio indica que hace dos cosas: combina escáneres deterministas con inferencia del modelo para revisar toda la base de código y sus dependencias, buscando riesgos reales. El lado de las dependencias corresponde a ataques a la cadena de suministro: código malicioso insertado en paquetes de terceros, un tipo de incidente que se ha vuelto frecuente en el ecosistema de código abierto durante el último año, mientras que revisar manualmente cada árbol de dependencias resulta prácticamente inviable.
La regla en la etapa de corrección es aún más estricta. La documentación deja claro: la corrección propuesta por el agente debe volver a escanearse y pasar una revisión de diff antes de ser aprobada, y el agente que produce la corrección nunca es el único verificador.
Esta restricción apunta al problema de que la IA se califique a sí misma. El mismo modelo que escribe el parche y lo evalúa produce un resultado que parece completo, pero que en realidad es autoconfirmación: es igual de ciego frente a lo que dejó pasar. Mantener herramientas deterministas, como los escáneres, dentro del ciclo equivale a añadir una contraprueba sin concesiones al juicio del modelo.
Cuatro niveles de permisos, autonomía que se construye poco a poco
Cada llamada a una herramienta se clasifica en una de cuatro categorías de riesgo: lectura (read), escritura local (write_local), ejecución de comandos (exec) y llamada externa (external). Encima de eso se superponen cinco modos de permiso: discuss y plan son de solo lectura; interactive es el modo predeterminado, que pregunta antes de acciones de escritura; auto permite todo dentro de rutas delimitadas; custom permite marcar herramientas específicas de confianza para aprobación automática.
Las reglas de gobernanza están fijadas en tres capas:
- Límites infranqueables: las operaciones peligrosas e irreversibles siempre dependen de una decisión humana, sin importar el modo activo;
- Autonomía progresiva: toda acción pasa por aprobación de forma predeterminada, una aprobación puntual puede elevarse a regla permanente, y solo después entra en la lista blanca de configuración;
- Rastro de auditoría: cada llamada a una herramienta registra el origen de la aprobación —automática, del usuario o denegada.
Existe además una regla de "sin autoaprobación sin supervisión": cuando funciona por la noche sin nadie presente, si surge una acción con consecuencias, la solicitud sin respuesta queda en la bandeja de entrada a la espera de revisión, en lugar de relajarse automáticamente los permisos solo porque no hay nadie.
Llevar las herramientas de las grandes empresas al portátil
En el último año, las noticias sobre IA que caza vulnerabilidades han sido dominadas casi por completo por grandes empresas de código cerrado: una encontró una falla de más de veinte años, otra escaneó decenas de miles de vulnerabilidades críticas en un mes, todas usando sus modelos más potentes, a través de canales de adquisición corporativa, con precios y barreras de acceso elevados. OpenWorker toma otro camino: ejecución local, código abierto, licencia MIT, código auditable.
Para los equipos de seguridad, que "esta capa en sí misma pueda auditarse" pesa tanto como la capacidad de escaneo. Un agente capaz de leer toda la base de código, ejecutar comandos y hacer solicitudes externas es, por naturaleza, el canal ideal para la exfiltración de datos; si además es una caja negra, cuantas más vulnerabilidades encuentre, más difícil será evaluar el riesgo de integrarlo. Aquí el código abierto funciona más como condición de entrada que como declaración de postura.
Todavía faltan dos datos públicos: el repositorio no indica el número de versión exacto de la nueva edición, y la tasa de acierto de la capacidad de escaneo en benchmarks públicos aún no cuenta con cifras independientes de terceros. Antes de conectarlo a un pipeline de CI, es más prudente probarlo varias rondas en un entorno aislado.
Fuentes: documentación oficial del repositorio de OpenWorker, CocoLoop, MarkTechPost, Help Net Security; los niveles de permisos, las tres capas de gobernanza y las responsabilidades de la revisión de seguridad se cotejaron punto por punto con la documentación del repositorio.