El 13 de octubre, un grupo de ingenieros publicó The Secure Software Factory, una arquitectura de referencia para las organizaciones que dejan que agentes de programación escriban, prueben y publiquen código. La redactan Eli Aleyner, Ranti Familusi y William Manning (Docker), Allie Howe e Ian Livingstone (Keycard), Andy McMahon (Barclays), Ahmad Nassri (Socket) y Aaron Stanley (Secure Theory). Se apoya en Agent Baseline, un conjunto de 35 controles agrupados en seis resultados, que Keycard impulsó junto con ingenieros de Docker y Snyk.

Nos alegra verlo. Es un borrador público y versionado, con identificadores de control estables, bajo licencia CC BY 4.0, abierto a comentarios en GitHub y pensado para cederse a un organismo comunitario cuando madure. Los proveedores y los equipos que les compran ya pueden señalar los mismos controles.

Lo que pide la arquitectura

Su idea central cabe en una línea: el agente propone, la política autoriza y la infraestructura lo hace cumplir. El agente se trata como no confiable, ya sea porque está confundido, porque lo ha manipulado algo que leyó o porque lo han tomado, así que sus límites deben aplicarse fuera de sus propias decisiones. El documento traza cuatro fronteras:

Sandbox: el código del agente solo se ejecuta en un sandbox aislado que no puede modificar ni del que puede escapar.
Red: nada entra ni sale salvo por caminos que el agente no puede reconfigurar ni sortear.
Cadena de suministro: los componentes solo llegan de fuentes aprobadas, y nada que entre en el sandbox lleva credenciales.
Identidad y acceso: un agente solo usa el acceso concedido para su tarea, nunca tiene credenciales y necesita, para las acciones de alto impacto, una aprobación que no puede darse a sí mismo.

Estas fronteras se mantienen en tres niveles de autonomía: un desarrollador que dirige un agente (Nivel 1), un flujo de trabajo que ejecuta agentes como servicio compartido (Nivel 2) y un agente orquestador que decide qué pasa después (Nivel 3). Alrededor hay una capa de ejecución capaz de detener cualquier agente, y un registro de auditoría fuera del alcance de todos los agentes.

Todo esto se basa en incidentes reales. En uno, un agente de programación que trabajaba en una tarea de staging encontró un token de API en un archivo sin relación con ella y lo usó para borrar una base de datos de producción en nueve segundos. En el gusano Shai-Hulud, paquetes maliciosos recolectaban todas las credenciales que encontraban en la máquina que los instalaba.

Cómo cubre Bromure las cuatro fronteras

Bromure Agentic Coding se ejecuta en tu Mac y pone cada espacio de trabajo de agente en su propia VM Linux. Así es como encaja.

Frontera	Lo que pide la arquitectura	Bromure
Sandbox	Aislamiento acorde al riesgo, hasta una microVM con su propio kernel; sin acceso al host; las pruebas se ejecutan dentro del mismo aislamiento; detención bajo demanda conservando el estado como prueba	Una VM Linux completa por espacio de trabajo, con su propio kernel y su propio Docker para las pruebas. Con una política de OpenShell, Landlock y seccomp confinan al agente dentro de ella. Una máquina se puede pausar, y Guardar para investigación exporta sus discos antes de borrarla
Red	Todo el tráfico pasa por un proxy de salida impuesto en la capa de red, no mediante la configuración de proxy; control por operación	El switch virtual del Mac comprueba cada conexión y desvía el tráfico web al proxy de Bromure incluso cuando una herramienta ignora la configuración de proxy. Las reglas pueden limitar los métodos HTTP y, con una política de OpenShell, las rutas y las operaciones MCP, GraphQL y WebSocket
Cadena de suministro	Paquetes solo a través de un punto de admisión; las versiones nuevas esperan un periodo de enfriamiento; nada que entre en el sandbox lleva credenciales	Las instalaciones de ocho ecosistemas pasan por las comprobaciones de Bromure: una barrera de antigüedad de dos días para las versiones nuevas, activada por defecto, más consultas opcionales a OSV y socket.dev. Un paquete sin veredicto queda retenido hasta que decidas
Identidad y acceso	El agente nunca tiene credenciales; se añaden en el proxy; las acciones de alto impacto necesitan aprobación	La VM solo contiene tokens sustitutos; el proxy los cambia por los reales para el host correcto. Las claves SSH se quedan en el Mac, y las peticiones a AWS se vuelven a firmar fuera de la VM. Las escrituras como un `git push` pueden requerir un clic, y las ramas de los agentes solo se fusionan cuando tú lo apruebas

La frontera de las credenciales es la que más importa en incidentes como estos. Un paquete de Shai-Hulud que saquee una VM de Bromure solo encuentra tokens sustitutos, inútiles fuera del proxy de Bromure. (Socket, donde trabaja uno de los autores, es también una de las comprobaciones de paquetes que Bromure puede usar.)

Los niveles también encajan. Un desarrollador que ejecuta agentes en sesiones es el Nivel 1. Las automatizaciones que lanzan un agente según un calendario, o cuando llega una pull request de GitHub o una incidencia de Linear, cada una en un git worktree nuevo y, opcionalmente, en un clon desechable de la máquina, son el Nivel 2. Los agentes que delegan trabajo en otros agentes, con cada mensaje transmitido por el host, revisado en busca de inyección de prompts y registrado, son el comienzo del Nivel 3.

Dónde va más allá Bromure

El borrador es franco sobre sus propios puntos débiles. Su declaración de procedencia dice que, de los seis resultados, Discover, Observe y Respond no los vende ninguna de las organizaciones impulsoras y están, en consecuencia, menos desarrollados, y califica esa asimetría de defecto. También dice que, según la propia prueba del baseline, ninguna de las tres empresas impulsoras es una implementación completa. Es algo inusualmente honesto para dejarlo por escrito.

Observe y Respond son donde más trabajo hemos puesto:

Vigilar desde dentro del kernel. La arquitectura pide que el runtime del sandbox registre la actividad de procesos, archivos y red. El centinela del kernel de Bromure lo hace desde dentro del kernel del invitado y lo envía al Mac por un canal que root en la VM no puede cerrar. Si algo intenta silenciarlo, eso cuenta como manipulación.
De la intención al resultado. El control OBS-05 de Agent Baseline pide pruebas que vinculen lo que un agente pretendía hacer con lo que hizo. El linaje de Bromure remonta cada conexión, a través de los procesos que la abrieron, hasta la llamada a herramienta del agente y el razonamiento que dio el modelo para ella. Cuando el script de instalación de una dependencia intenta enviar datos fuera, ves la instalación que lo ejecutó y por qué el agente lanzó esa instalación.
Revisar las entradas. La arquitectura trata como no confiable todo lo que lee un agente. Bromure puede analizar en tu Mac los resultados de las herramientas y los archivos de reglas como CLAUDE.md en busca de inyección de prompts, revisa cada mensaje entre agentes y siempre revisa el texto de un evento de GitHub o Linear antes de que una automatización actúe sobre él.
Datos enviados para inferencia. La protección de datos personales de Bromure sustituye nombres, correos electrónicos, números de cuenta y datos similares por sustitutos antes de que una petición llegue a un modelo en la nube, y los restaura en la respuesta.
Responder con las pruebas intactas. Cuando Bromure ve una credencial saliendo hacia donde no debe, pausa la VM. Puedes apagarla o guardar sus discos para investigación, tras lo cual la máquina se niega a arrancar hasta que se borre. Con las políticas de OpenShell, una ráfaga de operaciones rechazadas pone el espacio de trabajo en cuarentena: red cortada, VM pausada.
Trazas fuera de alcance. La traza de cada máquina, con las peticiones al modelo, las llamadas a herramientas, los comandos y la actividad de archivos, se guarda en el Mac, cifrada, fuera de la VM.

Hay una diferencia más: dónde se ejecuta. La arquitectura está escrita para fábricas, y el Nivel 1, un desarrollador con un agente local, recibe unos pocos párrafos. Ahí es donde se ejecutan hoy la mayoría de los agentes. Bromure pone las cuatro fronteras en el Mac de ese desarrollador, sin infraestructura que montar, y es gratuito y de código abierto.

Un buen comienzo

The Secure Software Factory es la versión 1 y está abierta a comentarios: prudente en lo que afirma y honesta sobre qué productos le dieron forma. Su gestor de incidencias está abierto a cualquiera, y las secciones sobre observar y responder son donde creemos que queda más por escribir.

Que más empresas trabajen en público en la seguridad de los agentes, con identificadores de control estables, es bueno para todos los que ejecutan agentes.