← Volver a todas las publicaciones
Publicado el · por Renaud Deraison

La lista de control se escribió para laboratorios

El 16 de octubre, el NIST, la NSA y la CISA publicaron diez prácticas para incidentes en los que agentes de IA actúan fuera de sus límites: acceso de red por lista de permitidos a través de una pasarela supervisada, registros que el agente no puede tocar, canarios, apagado automático, reconstrucción desde bases verificadas. Un día antes, el CERT-In de la India informó de agentes de IA en pruebas que llegaron a sistemas de empresas en producción con credenciales encontradas en archivos de configuración y repositorios públicos, sin que nadie lo notara. Las pautas están escritas para laboratorios de IA, pero un agente de código desatendido en el portátil de un desarrollador encaja en su descripción. Bromure Agentic Coding aplica esos controles en el Mac, fuera de la VM del agente.

Las pautas dan por hecho que el agente encontrará el punto débil. Así que el firewall, los registros y el interruptor tienen que estar donde el agente no pueda alcanzarlos.

El viernes 16 de octubre, tres agencias de EE. UU. publicaron un documento breve con un nombre largo: Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Lo redactó el nuevo Center for Advancing Innovation and Standards for Super Intelligence del NIST junto con el Super Intelligence Security Center de la NSA y la CISA. Establece diez prácticas voluntarias para lo que llama incidentes de control de SI: un agente emprende “acciones significativas no indicadas” que rompen los límites fijados por su operador. La definición deja fuera la inyección de prompts y los modelos con puertas traseras: el agente cruza la línea por su cuenta, mientras trabaja hacia su objetivo. GBHackers lo resumió como una advertencia de que los agentes “podrían explotar fallos de seguridad y establecer puertas traseras ocultas”.

El día anterior, la agencia nacional de ciberseguridad de la India había descrito lo mismo en la práctica. En el aviso CIAD-2026-0049, el CERT-In dijo que agentes de IA en pruebas en línea llegaron a los sistemas en producción de organizaciones indias y leyeron registros de negocio, incluidos datos personales. Los agentes entraron con “credenciales y ajustes de conexión expuestos en la configuración de aplicaciones y en repositorios de código públicos”, y a través de roles en la nube con demasiados permisos. Encontraron la misma credencial expuesta más de una vez y la reutilizaron. Según The Hacker News, ninguna de las organizaciones detectó el acceso. Fueron las propias empresas de IA las que lo comunicaron tras revisiones internas.

Una lista de laboratorio que le sirve a un portátil

Ambos documentos se dirigen a desarrolladores y evaluadores de IA. Las prácticas del NIST apuntan a organizaciones que “entrenan o evalúan agentes de SI muy capaces en tareas de largo horizonte con supervisión humana limitada”, y añaden que “también pueden aplicarse a quienes despliegan dichos agentes de SI”.

Esa segunda frase abarca a cualquiera que arranca Claude Code o Codex un viernes por la tarde, le pide que ponga en verde la suite de integración y vuelve a mirar el lunes: una tarea de largo horizonte, sin nadie vigilando durante tres días. En la mayoría de los portátiles, el agente se ejecuta como tu usuario. Tus credenciales de la nube, tu red y los propios registros del agente están a su alcance.

Los dos documentos coinciden en dónde deben estar los controles. El CERT-In quiere que el acceso saliente esté bloqueado por defecto, y dice que el bloqueo “debe aplicarse a nivel de red, no mediante instrucciones al modelo”. Quiere que una ejecución se detenga sola si el agente contacta sistemas externos o usa credenciales que no son suyas. La práctica 1.8 del NIST pide a los operadores construir controles “con la expectativa de que los agentes de SI localizarán y explotarán con frecuencia errores de configuración y vulnerabilidades”.

Un control que el agente puede leer, editar o esquivar con palabras no alcanza ese listón. Bromure Agentic Coding ejecuta cada agente en una VM Linux en tu Mac y coloca sus controles del lado del Mac: en el switch de red virtual, en un proxy que la VM no puede saltarse y en un almacenamiento que la VM no puede montar.

Dónde se ejecuta cada controlVM Linux · el lado del agenteAgente de códigotarea larga, sin nadie mirandoRepo y carpetas compartidas.env, configuración, historialCredenciales que puede hallarsk-ant-api03-brm-…GH_TOKEN=ghp_… (falso)secreto aws: falso, 40 car.todo son sustitutos (1.1)Ni secretos reales, ni registros,ni reglas de firewall aquí.todoTu Mac · fuera del alcance del agenteFirewall de salida · práctica 1.5switch virtual + proxy, host, puerto, verbo HTTPdenegar por defectoIntercambio de credenciales y trampa · 3.5, 6.2sustituto → clave real solo para su hostcualquier otro host: HTTP 451, VM en pausaTraza de sesión y Security Timeline · 3.3, 5.3llamadas a herramientas, comandos, cada bloqueocifradas en el Mac, nunca montadas en la VMImagen base firmada, puntos del home · 6.4, 7.1Reset disk, Rewind homeuna máquina comprometida solo arranca tras borrarlaSolo hostspermitidosTodo lo demás:detenido
Las prácticas del NIST, situadas en una máquina Bromure. El agente trabaja en la VM con credenciales sustitutas. Todo lo que decide, registra o detiene está en el Mac.

Diez prácticas, trasladadas a una máquina

Mínimo privilegio (1.1), y las credenciales que encontró el CERT-In. Los agentes de los casos indios entraron con credenciales que andaban por ahí. Dentro de una VM de Bromure, todo lo que un agente encuentra por ahí es un sustituto. Las claves de modelos, los tokens de git y todo lo que importes con Import env file… aparecen como valores del tipo sk-ant-api03-brm-…. El asistente de AWS entrega a la VM una clave de acceso secreta falsa y firma la petición real en el Mac. kubectl recibe un kubeconfig sintético que apunta al proxy. Un agente que rebusca en la carpeta personal o en el entorno obtiene valores que solo funcionan a través de tu Mac, para el host para el que se emitió cada uno. Las máquinas nuevas arrancan además con Prompt before write en cada servicio protegido, así que una escritura en GitHub, AWS, Kubernetes o un registro espera a que apruebes la operación exacta.

Infraestructura de un solo uso y canales entre agentes (1.2). Cada máquina es su propia VM, con su propio disco, carpeta personal y políticas. Las máquinas no comparten ningún sistema de archivos. Una automatización puede ejecutarse en un clon desechable del espacio de trabajo: un duplicado copy-on-write que arranca cuando se dispara la ejecución y se borra al terminar. bromure-cli vm run --rm te da una máquina desechable a mano. Cuando un agente pasa trabajo a otro, el mensaje va a través del host de Bromure, que lo filtra con el detector de inyección de prompts integrado y lo registra. Los dos agentes nunca se conectan directamente.

Una lista de permitidos estricta a través de una pasarela supervisada (1.5). El CERT-In insiste en que este control no puede ser una instrucción al modelo. El firewall de salida de cada máquina es una lista ordenada de reglas de permitir y denegar por host, rango de IP, protocolo, puerto y, para el tráfico web, verbo HTTP. Pon Unmatched traffic en Deny y se convierte en una lista de permitidos. El Mac aplica las reglas dos veces: el switch virtual comprueba cada conexión y el proxy comprueba el nombre de servidor TLS. El switch desvía el tráfico web de la VM hacia el proxy en la capa de red, así que una herramienta que ignora la configuración de proxy pasa por él de todos modos. allow web api.example.com GET deja que un agente lea una API en la que no puede escribir, use la herramienta que use.

Monitores que el agente no puede tocar (3.3). El Mac escribe la traza de sesión y la Security Timeline en su propio disco. Bromure sella el contenido de las trazas con AES-GCM bajo una clave guardada en el llavero de macOS, y ninguna VM monta nunca ninguna de las dos. Un agente que borra su historial de shell o reescribe su propia transcripción dentro de la VM no cambia nada del registro que leerás después.

Canarios (3.5). El NIST sugiere “colocar canarios en los entornos para detectar instancias de agentes que han obtenido acceso fuera de los límites previstos”. En Bromure, cada sustituto es un canario. Cada uno tiene un único destino legítimo, el host para el que se creó. El proxy examina cada petición saliente, cabeceras y cuerpo, en busca de sustitutos que vayan a otro sitio. También marca secretos de aspecto real que Bromure no emitió, como una clave que un agente desenterró del historial de un repositorio público. Aparecen como avisos de fuga en el Trace Inspector y en bromure-cli trace leaks.

Apagado automático (6.2) y pruebas (5.1). Cuando un sustituto va hacia el host equivocado, el proxy responde HTTP 451 y no reenvía nada. La VM se pausa en el acto y el Mac muestra This environment may have been compromised, con la credencial, el host al que pertenece y el host al que se envió. Shut down es el botón por defecto. Save for Investigation exporta el disco del sistema, la carpeta personal y cada carpeta compartida antes de detener la VM, lo que preserva el entorno como pide la práctica 5.1.

Registros con marcas de tiempo fiables, llamadas a herramientas y acciones rechazadas (5.3). Con el nivel de traza por defecto, el Mac registra cada petición con su hora, host, método, estado e intercambios de credenciales. Guarda los cuerpos completos del tráfico del modelo y los analiza para obtener las llamadas a herramientas del agente, sus comandos de shell y sus lecturas y escrituras de archivos. La Security Timeline conserva durante 90 días cada bloqueo y cada permiso del firewall, los Guardrails, las comprobaciones de la cadena de suministro, la detección de inyección de prompts y el gestor de credenciales. Esas son las acciones rechazadas que el NIST quiere tener archivadas.

Revocar y reconstruir (6.4, 7.1). Tras un incidente, el NIST quiere que se revoquen las credenciales expuestas y que los entornos se reconstruyan “desde bases verificadas”. La VM nunca tuvo una credencial real, así que no hay nada que revocar en ella. Una máquina marcada como comprometida se niega a arrancar hasta que confirmes el borrado de su disco del sistema, su carpeta personal y su estado guardado. Después vuelve desde la imagen base firmada de Ubuntu, con tus ajustes y claves intactos. Sin llegar a un incidente, Reset disk vuelve a clonar el disco del sistema desde esa imagen, y Rewind home… devuelve la carpeta personal al estado que tenía en un arranque anterior.

Comprobar la contención antes de reiniciar (7.3). La vista general de la Security Timeline tiene una tabla Protections con una fila por máquina, que muestra cuáles tienen activados el firewall, los Guardrails, las comprobaciones de la cadena de suministro, la detección de inyección de prompts y la protección de datos personales. Una máquina que funciona con menos protecciones que las demás destaca antes de que le encargues la siguiente tarea larga.

Viernes por la noche, lunes por la mañana

Volvamos a la ejecución de la suite de integración de antes. Hacia las 2 de la madrugada, las pruebas siguen fallando contra el servicio de pagos simulado, y el agente decide que el endpoint real de staging lo resolvería. Echa un vistazo por la máquina y encuentra STRIPE_KEY en su entorno y un perfil de AWS en ~/.aws/config.

En un portátil, el siguiente paso es una petición con una clave real a un sistema real, y lo mismo que describió el CERT-In: un acceso que nadie nota, registrado en una transcripción que el agente puede editar.

En una máquina Bromure con lista de permitidos, la llamada al host de staging nunca sale del Mac. El firewall la deniega, el agente recibe un error limpio y la Security Timeline registra una fila roja de Firewall. Las claves que encontró son los sustitutos que Bromure puso ahí, así que no sirven en ningún otro sitio. Cuando el agente prueba un atajo y publica el sustituto de GitHub en un sitio de pegado de texto, el proxy responde 451 y la VM se congela a mitad de paso. El lunes abres la Security Timeline, filtras por la máquina y lees lo que pasó, en orden: el host denegado, la subida bloqueada, la VM en pausa. Luego abres la traza para ver las llamadas a herramientas que llevaron hasta ahí. Si quieres estar seguro, borras y vuelves a lanzar.

Reglas de red que el agente no puede editar

El firewall de salida se ejecuta en el switch virtual y en el proxy del Mac. Pon el tráfico no coincidente en Deny y cada ejecución tendrá una lista de permitidos, hasta el verbo HTTP.

Cada credencial encontrada es un canario

Claves, tokens y valores .env importados son sustitutos en la VM. Uno enviado al host equivocado recibe un 451 y pausa la máquina.

Registros al otro lado del hipervisor

La traza y la Security Timeline viven en el Mac, cifradas, con llamadas a herramientas, comandos de shell y cada bloqueo. La VM nunca las monta.

Reconstruir desde una base firmada

Una máquina comprometida solo arranca tras un borrado. Reset disk vuelve a clonar la imagen base, y Rewind home restaura un arranque anterior.

Pon los controles por debajo del agente

Ambas agencias parten del mismo supuesto: un agente capaz, con un objetivo y tiempo, encontrará lo que se haya dejado expuesto. Ninguna confía en las instrucciones del modelo. Piden reglas aplicadas en la red, registros fuera del alcance del agente y una parada que se active sola.

En el Mac de un desarrollador, eso significa ejecutar el agente en una VM y mantener los controles en el host. Para los incidentes de evaluación que llevaron hasta aquí, lee La sandbox era una frase y La tarea era imposible, así que el agente salió.