La infraestructura de agentes de Mozilla AI pone las reglas por encima del criterio del modelo
Mozilla AI ha cuestionado una premisa central detrás de los agentes de programación: un mejor criterio del modelo por sí solo no puede hacer seguro el trabajo de software delegado.
Su argumento sobre la infraestructura de agentes llega mientras los agentes adquieren autoridad para inspeccionar repositorios, editar código, ejecutar pruebas y preparar pull requests. Estas capacidades pueden condensar horas de trabajo en minutos. También dan a sistemas probabilísticos acceso a operaciones con consecuencias duraderas.
La tesis de Mozilla AI sobre la infraestructura de agentes transforma la competencia entre capacidades en una entre instrucciones y control aplicable. Un archivo AGENTS.md puede decirle a un agente qué debe hacer. Solo la infraestructura puede impedir las acciones que jamás debe realizar.
Esa distinción presiona a toda organización que amplía la autonomía de sus agentes. OpenAI, Anthropic, Google, GitHub y desarrolladores independientes ofrecen experiencias de agentes distintas. Sin embargo, toda implementación termina enfrentando la misma pregunta: ¿qué sigue siendo cierto cuando el modelo malinterpreta una regla?
Qué cambia la infraestructura de agentes de Mozilla AI
Mozilla AI está alejando el debate sobre los agentes de la inteligencia del modelo y llevándolo hacia los sistemas que rodean cada decisión del modelo.
Los agentes de programación ya no operan únicamente como interfaces de chat. Pueden buscar en una base de código, modificar varios archivos, ejecutar comandos de shell, lanzar una suite de pruebas y preparar un cambio propuesto. Algunos sistemas pueden seguir trabajando mientras un desarrollador atiende otra tarea.
Ese alcance más amplio convierte la infraestructura en parte del producto, en lugar de un detalle de implementación. Una respuesta incorrecta en una ventana de chat crea un tipo de riesgo. Un comando equivocado con acceso a repositorios, red o credenciales crea otro.
La intervención de Mozilla AI es importante porque separa tres responsabilidades que los equipos a menudo combinan. Las instrucciones describen el comportamiento deseado. Los modelos interpretan esas instrucciones. La infraestructura decide qué acciones son técnicamente posibles.
La distinción parece simple, pero muchas implementaciones de agentes invierten esa jerarquía. Conceden acceso amplio primero y después piden al modelo que actúe con moderación mediante reglas en lenguaje natural. Ese diseño convierte al modelo tanto en trabajador como en su propio sistema de control principal.
Una instrucción de repositorio podría indicar que nunca se publique directamente desde una rama de funcionalidad. Podría exigir aprobación antes de cambiar código de autenticación. Podría prohibir la lectura de archivos fuera de un directorio específico.
Estas indicaciones mejoran el comportamiento cuando el agente las lee, interpreta y prioriza correctamente. No crean límites del sistema operativo, políticas de red ni puertas de aprobación. El modelo aún puede solicitar una acción que infrinja la regla escrita.
El ampliamente adoptado formato de instrucciones para agentes proporciona una convención útil para el contexto de los proyectos. Su sitio público describe AGENTS.md como un lugar predecible para comandos de compilación, instrucciones de pruebas, convenciones y consideraciones de seguridad. También informa de su adopción en más de 60.000 proyectos de código abierto.
Esa adopción demuestra por qué importan las instrucciones portables. Los equipos no deberían reescribir la misma guía de repositorio para cada producto de programación. Un formato compartido permite que las reglas viajen entre agentes y permanezcan visibles junto al código.
Sin embargo, la portabilidad no convierte la prosa en aplicación efectiva. Markdown no tiene autoridad sobre una shell, una cuenta en la nube, un registro de paquetes o una base de datos de producción. Influye en el modelo que lo lee, mientras el entorno de ejecución sigue controlando el mundo al que se puede llegar.
Por ello, Mozilla AI identifica una capa ausente. Las implementaciones de agentes necesitan controles fuera del bucle del modelo, donde una interpretación equivocada no pueda concederse silenciosamente una excepción.
Esto no hace que AGENTS.md sea menos valioso. Le da al archivo una función más clara. Las instrucciones deben comunicar la intención, mientras la infraestructura debe imponer el límite alrededor de esa intención.
La inversión práctica es significativa. Los equipos han tratado un mejor razonamiento como la vía hacia una autonomía más segura. Mozilla AI sostiene que una autonomía fiable comienza por asumir que el razonamiento a veces fallará.
Los agentes de programación convierten sugerencias en efectos secundarios
Cuanto más trabajo pueda completar un agente, menos aceptable resulta depender del buen juicio como límite final de seguridad.
Los asistentes de código tradicionales se limitaban principalmente a sugerir texto para que una persona lo revisara. El desarrollador decidía si insertar la sugerencia, ejecutar un comando o enviar un cambio aguas arriba. Esa acción humana constituía un punto de control natural.
Las herramientas agénticas condensan esos puntos de control. Una sola asignación puede activar el descubrimiento de archivos, la instalación de dependencias, la generación de código, la ejecución de pruebas y operaciones de repositorio. Cada paso crea un nuevo contexto que moldea la siguiente decisión del modelo.
Este bucle es útil porque el trabajo de software rara vez cabe en un único prompt y una única respuesta. Un agente debe observar resultados, revisar sus supuestos y probar otro enfoque. El mismo bucle también amplifica los errores tempranos.
Pensemos en un agente al que se le pide corregir una prueba de integración fallida. Puede inspeccionar archivos de entorno, iniciar servicios, actualizar dependencias y regenerar snapshots. Una instrucción imprecisa puede llevarlo mucho más allá de la prueba prevista.
El fallo no requiere un comportamiento malicioso. El agente podría inferir que un comando destructivo de limpieza es rutinario. Podría interpretar una credencial de prueba como desechable. Podría confiar en texto recuperado de una incidencia, dependencia o página web.
La inyección de prompts hace especialmente importante ese último escenario. Un agente puede encontrarse con instrucciones hostiles dentro del contenido que se le pidió procesar. Entonces, el modelo debe distinguir los datos de la tarea de los comandos mientras continúa trabajando.
La guía en lenguaje natural ayuda, pero el modelo sigue siendo el componente que decide si otro lenguaje natural es fiable. Es un lugar inestable para situar el límite final.
La infraestructura de ejecución puede limitar las consecuencias. La arquitectura de sandbox de OpenAI separa el arnés de confianza del entorno donde se ejecutan comandos dirigidos por el modelo. El arnés puede encargarse de aprobaciones, trazabilidad, recuperación y estado fuera del contenedor de ejecución.
Esa separación ilustra el mecanismo más amplio. El agente puede trabajar dentro de un entorno sin heredar automáticamente todas las credenciales o recursos disponibles para la organización. La infraestructura media lo que cruza el límite.
Un agente de programación encargado de actualizar documentación no debería necesitar credenciales para publicar paquetes. Un agente que repara un servicio no debería acceder automáticamente a repositorios no relacionados. Una tarea de redacción de pruebas no debería incluir permisos para una base de datos de producción.
Estas son decisiones de capacidades, no decisiones de redacción de prompts. Una capacidad es una acción que el entorno de ejecución permite, como escribir en un directorio o llamar a un endpoint aprobado. Una buena infraestructura concede capacidades según la tarea actual.
La presión recae primero sobre los equipos de plataforma y seguridad. Los desarrolladores quieren que los agentes actúen con menos supervisión porque la autonomía genera ganancias de productividad. Los equipos de seguridad deben garantizar que una menor supervisión no se convierta en autoridad ilimitada.
También recae sobre los proveedores. Una interfaz de agente pulida puede ocultar controles operativos débiles. Los compradores deben mirar más allá de los resultados de benchmarks y preguntar cómo gestiona el sistema la identidad, las credenciales, las aprobaciones, los registros, los reintentos y la recuperación.
La misma cuestión afecta a los desarrolladores individuales. Un agente local puede parecer contenido porque se ejecuta en un solo portátil. Sin embargo, esa máquina puede contener código fuente, sesiones de navegador, credenciales en la nube, documentos personales y claves de firma.
Un agente no necesita acceso administrativo para causar daños significativos. Solo necesita una credencial con más autoridad de la que exige la tarea. La infraestructura debe hacer más difícil crear ese desajuste.
Por eso la noticia no es simplemente otro llamamiento a una IA responsable. Mozilla AI está trasladando la responsabilidad del comportamiento del modelo al diseño del sistema. Eso coloca la carga sobre componentes que las organizaciones pueden inspeccionar y probar.
AGENTS.md explica las reglas, pero no puede imponerlas
El conflicto principal es ahora explícito: los archivos de instrucciones expresan la intención humana, mientras los controles del entorno de ejecución determinan lo que un agente puede hacer realmente.
AGENTS.md resuelve un problema real de coordinación. Un agente de programación necesita comandos, convenciones del repositorio, requisitos de validación y advertencias locales. Mantener ese contexto cerca del código lo hace visible, versionado y reutilizable.
El formato también permite a los equipos definir instrucciones más específicas dentro de repositorios grandes. Un servicio puede tener comandos de prueba o restricciones distintos de los de la raíz del repositorio. Esto se parece a la documentación por capas que ya utilizan las personas.
Sin embargo, todas las instrucciones siguen pasando por la interpretación del modelo. El agente debe encontrar el archivo pertinente, resolver reglas superpuestas, aplicarlas a la tarea actual y recordarlas durante una ejecución prolongada.
Cualquier fallo en esa cadena puede debilitar la regla. El archivo puede estar incompleto. El contexto puede truncarse. Una instrucción anidada puede entrar en conflicto con una instrucción raíz. El modelo puede generalizar una excepción de forma demasiado amplia.
Incluso el seguimiento perfecto de instrucciones no puede resolver todos los problemas. Una regla puede indicar que se obtenga aprobación antes de publicar un paquete. El agente aún necesita un mecanismo de aprobación fiable y una identidad autorizada para aprobar.
Si la aprobación existe solo como otro mensaje en el contexto, el contenido no confiable puede imitarla. Un sistema más sólido representa la aprobación como estado externo que el modelo no puede fabricar. El entorno de ejecución comprueba ese estado antes de liberar la acción.
El mismo principio se aplica a los límites de gasto. Decirle a un agente que ahorre tokens es una guía útil. Un presupuesto aplicado por el plano de control sigue siendo efectivo cuando un bucle se prolonga más de lo previsto.
La auditabilidad revela otra limitación. Una instrucción puede exigir que el agente explique sus decisiones. Esa explicación no es automáticamente un registro completo de las entradas de herramientas, el estado de permisos, los cambios de archivos, los reintentos o las acciones rechazadas.
Una pista de auditoría fiable debe capturar eventos fuera de la narración del agente. Debe mostrar qué identidad solicitó una acción, qué política se evaluó, qué entradas llegaron a la herramienta y qué resultado devolvió.
El registro también debería conservar los fallos. Un agente que intentó tres acciones prohibidas antes de encontrar una ruta permitida cuenta una historia distinta de uno que eligió la ruta permitida de inmediato. La salida final por sí sola oculta esa diferencia.
Esto importa durante los incidentes. Los equipos necesitan reconstruir qué vio el agente y qué autoridad tenía en ese momento. La documentación actual no basta si las políticas, los prompts o las credenciales cambiaron después.
Por tanto, la infraestructura debería vincular una acción a una ejecución específica, una versión de política, una versión de herramienta y un estado de aprobación. Eso hace que la revisión posterior dependa menos de la memoria o de transcripciones de chat reconstruidas.
Los registros también respaldan la mejora de ingeniería. Los equipos pueden identificar comandos que requieren intervención repetidamente, políticas que generan falsos positivos y tareas que exceden su alcance previsto. Esos patrones pueden orientar permisos más acotados y mejores flujos de trabajo.
Los desarrolladores siguen necesitando instrucciones bien redactadas. El objetivo no es sustituir la intención humana por políticas rígidas. Muchas decisiones de software requieren un contexto que no puede capturarse mediante una regla de sistema de archivos.
El mejor diseño asigna a cada capa una función adecuada. AGENTS.md le indica al agente cómo funciona el proyecto. Una capa de políticas decide si una acción propuesta encaja dentro del alcance permitido de la tarea.
Un sandbox limita los recursos expuestos a la ejecución. Un servicio de aprobación gestiona las excepciones con consecuencias. Un sistema de auditoría registra la decisión y su resultado.
En conjunto, esos componentes permiten que las reglas sobrevivan al reemplazo de un modelo. Un equipo puede cambiar de agentes sin tener que reconstruir sus límites más importantes dentro del formato de prompts de otro proveedor.
Esa durabilidad es fundamental para la tesis de Mozilla AI. Los modelos cambiarán con frecuencia. La propiedad de los repositorios, las obligaciones de cumplimiento y los riesgos de producción perduran mucho más.
El plano de control se convierte en el verdadero mecanismo de seguridad
Una infraestructura fiable para agentes sitúa políticas aplicables entre la solicitud de un modelo y cada acción de herramienta con consecuencias.
Un plano de control es la capa de confianza que gestiona el acceso, las políticas, el enrutamiento, los presupuestos y el estado operativo. El modelo puede proponer una acción, pero el plano de control decide si se ejecuta y cómo.
Esta arquitectura comienza con la identidad. Cada ejecución de un agente necesita una identidad distinta de la del operador humano y de la de otros procesos automatizados. Las credenciales compartidas dificultan la atribución y hacen que la revocación de permisos sea imprecisa.
El siguiente requisito es el principio de mínimo privilegio. Cada tarea recibe únicamente los archivos, comandos, servicios y destinos de red que necesita. Los permisos deberían expirar con la tarea, en lugar de mantenerse disponibles para futuras ejecuciones.
La guía de seguridad de sandbox de OpenAI recomienda cargas de trabajo aisladas, tráfico saliente restringido, credenciales separadas y acceso intermediado a servicios de terceros. Estos controles operan de forma independiente de la intención del modelo.
Las credenciales intermediadas son especialmente útiles. El entorno de ejecución puede enviar una solicitud aprobada sin ver un secreto reutilizable. Un proxy de confianza proporciona credenciales únicamente para el destino permitido.
Este diseño reduce el valor de una divulgación accidental. Si el código generado imprime su entorno, no es necesario que aparezcan claves de producción de larga duración. La revocación también se realiza en el intermediario, en vez de dentro de cada espacio de trabajo.
La mediación de herramientas proporciona otro punto de aplicación. La infraestructura puede validar argumentos, rechazar rutas peligrosas, limitar las tasas de solicitud y exigir aprobación para operaciones específicas.
Mozilla AI ha explorado ese patrón mediante plugins de políticas de mcpd. Mozilla describe la autenticación, la validación, la limitación de tasa y el registro como funciones que pueden situarse entre los agentes y los servidores de herramientas.
Esta ubicación importa porque los servidores de Model Context Protocol pueden exponer acciones sobre archivos, bases de datos y aplicaciones externas. Un intermediario central puede aplicar una política coherente sin confiar en que cada agente la reproduzca.
Un plano de control maduro también gestiona el estado. Los flujos de trabajo de los agentes pueden fallar después de completar algunas acciones, pero antes de registrar el éxito. Reintentar ciegamente todo el trabajo puede duplicar efectos externos.
La infraestructura debería saber qué pasos se completaron, cuáles siguen siendo seguros de reintentar y cuáles requieren conciliación. Una llamada para crear un pull request, una instrucción de pago o un mensaje a un cliente no siempre pueden repetirse como la lectura de un archivo local.
La aprobación humana debe situarse en límites seleccionados, no después de cada paso. Las solicitudes constantes de aprobación eliminan gran parte del valor de la delegación. La ausencia total de aprobación deja las decisiones con consecuencias por completo dentro del ciclo del modelo.
El punto medio útil es la escalada basada en el riesgo. La lectura de un repositorio puede avanzar automáticamente. La escritura dentro de una rama temporal también puede hacerlo. Publicar, desplegar, cambiar permisos o contactar a clientes puede requerir autorización explícita.
Las políticas deberían inspeccionar el contexto de cada acción. Un comando puede ser aceptable dentro de un entorno de pruebas aislado, pero estar prohibido contra producción. Una solicitud de red puede permitirse para documentación, pero bloquearse para endpoints desconocidos.
Los presupuestos necesitan una aplicación similar. Un agente que coordina varios subagentes puede generar costes más rápido que una persona supervisando un único chat. El plano de control puede establecer límites máximos por tarea, equipo, proveedor o resultado.
El plano de control abierto de Mozilla AI vincula este argumento de gobernanza al enrutamiento de modelos. Otari se presenta como una capa para el enrutamiento, los presupuestos, los controles de acceso, el despliegue y la conmutación por error entre proveedores.
El enrutamiento no es solo una optimización de costes. Distintas tareas pueden requerir diferentes límites de privacidad, objetivos de latencia o capacidades de modelo. La infraestructura puede aplicar esas decisiones de forma coherente, en vez de integrarlas por toda la base de código de la aplicación.
Este enfoque también mejora la portabilidad. Una organización puede reemplazar un modelo sin renunciar a su lógica de políticas, sus trazas históricas ni sus controles operativos. El agente pasa a ser un componente dentro de un sistema que la organización posee.
Para los equipos de ingeniería, esto puede preservar el conocimiento institucional. Una base de conocimiento técnico consultable puede conservar decisiones de arquitectura y documentación local. La política en tiempo de ejecución debe seguir controlando cómo los agentes usan ese conocimiento.
La clave es la separación. El conocimiento informa al modelo. La política restringe sus acciones. La auditoría registra lo sucedido. La recuperación gestiona el trabajo incompleto.
Ningún componente por sí solo hace que un agente sea fiable. El plano de control los coordina para que un juicio erróneo no determine todo el resultado.
La infraestructura abierta aporta control, no seguridad automática
Poseer la pila de agentes mejora la capacidad de inspección y la portabilidad, pero el código abierto no elimina por sí solo el riesgo operativo.
Mozilla AI vincula el control de la infraestructura con la apertura. Esa conexión es comprensible. Las organizaciones no pueden inspeccionar, modificar ni preservar por completo un sistema de control que solo existe detrás del límite de servicio de un proveedor.
La infraestructura abierta puede reducir la dependencia de un proveedor. Los equipos pueden conservar las políticas mientras cambian de proveedores de modelos. Pueden examinar el código de aplicación, añadir integraciones y desplegar componentes sensibles dentro de entornos que controlan.
También puede mantener la gobernanza cerca de la organización que asume el riesgo. Un hospital, un banco, una entidad pública o una empresa de software pueden necesitar reglas de aprobación y políticas de retención distintas. Un único valor predeterminado alojado no puede representar todas las obligaciones.
Sin embargo, la propiedad transfiere responsabilidad. Un plano de control autoalojado necesita actualizaciones de seguridad, revisiones de acceso, copias de seguridad, monitorización y recuperación probada. Un componente abierto desactualizado puede convertirse en una nueva debilidad.
La transparencia no garantiza una configuración correcta. Un equipo puede desplegar software inspeccionable con valores predeterminados permisivos, credenciales compartidas, registros incompletos o acceso de red sin restricciones. El código fuente puede ser abierto mientras el despliegue sigue siendo inseguro.
Los registros generan sus propias compensaciones. Las trazas detalladas ayudan en las investigaciones, pero pueden capturar código propietario, información personal, prompts y resultados de herramientas. Retenerlo todo indefinidamente puede entrar en conflicto con los objetivos de privacidad y minimización.
Los equipos necesitan límites explícitos de retención. Deberían registrar suficiente información para establecer responsabilidades sin convertir el sistema de auditoría en una copia permanente de cada entrada sensible.
La complejidad de las políticas es otro riesgo. Un amplio conjunto de reglas puede resultar difícil de razonar. Las excepciones superpuestas pueden crear lagunas, mientras que controles excesivamente estrictos pueden llevar a los desarrolladores hacia herramientas no autorizadas.
La respuesta no es simplemente más política. Los equipos necesitan controles pequeños y comprobables vinculados a riesgos específicos. Cada regla debería tener un responsable, una razón y un método de verificación.
El comportamiento del modelo también sigue siendo relevante. La infraestructura puede bloquear operaciones prohibidas, pero no puede garantizar código útil. Un agente puede mantenerse dentro de sus permisos y aun así producir una implementación incorrecta u omitir un requisito importante.
Por lo tanto, las pruebas y la revisión humana siguen formando parte del sistema. Los casos de evaluación privados o mantenidos de forma independiente pueden ayudar a detectar agentes que optimizan únicamente para las comprobaciones visibles. Las reglas de propiedad del código pueden dirigir los cambios sensibles a los revisores adecuados.
Este es el límite escéptico de la tesis de infraestructura para agentes de Mozilla AI. Una mejor infraestructura contiene fallos, conserva pruebas y hace posible la recuperación. No transforma un razonamiento incierto en ingeniería de software determinista.
Las organizaciones también deberían resistirse a tratar los registros de auditoría como prueba de seguridad. Un registro detallado puede mostrar exactamente cómo ocurrió un incidente. Prevenirlo requiere controles aplicables y políticas validadas antes de la acción.
También existe una cuestión de gobernanza sobre quién controla el plano de control. Una política central puede proteger a una organización, pero también puede crear una autoridad interna opaca. Los desarrolladores necesitan visibilidad sobre por qué se rechazaron acciones y cómo funcionan las excepciones.
Una implementación abierta ayuda a ese escrutinio, pero los procesos también importan. Los cambios de política deberían recibir revisión, pruebas y versionado. Las anulaciones de emergencia deberían expirar y permanecer visibles en el registro.
El enfoque más sólido trata la apertura como un modelo de propiedad, en lugar de como una etiqueta de seguridad. Las organizaciones obtienen la capacidad de inspeccionar y modificar el sistema. También aceptan la responsabilidad de operarlo bien.
Esa compensación es más creíble que prometer seguridad automática. Reconoce que la delegación fiable procede de la disciplina de ingeniería, no de una única función de producto.
Tres señales pondrán a prueba la tesis de infraestructura de Mozilla
La siguiente prueba consiste en determinar si las plataformas de agentes convierten los principios de infraestructura en valores predeterminados que los desarrolladores puedan verificar sin ralentizar el trabajo cotidiano.
La primera señal es la expansión de los permisos acotados a la tarea. Observe si los agentes de programación reciben acceso temporal a repositorios, directorios, comandos y destinos de red identificados. Una autoridad amplia a nivel de máquina debilitaría en la práctica el argumento de Mozilla AI, incluso si los proveedores promueven la seguridad en otros ámbitos.
La segunda señal es la calidad de las pruebas. Las plataformas deberían exponer registros duraderos de llamadas a herramientas, aprobaciones, decisiones de políticas, cambios de archivos y estado de reintento. Una transcripción por sí sola no responderá qué autoridad existía cuando se produjo una acción.
La tercera señal es la portabilidad. Los equipos deberían poder conservar políticas, trazas y estado de los flujos de trabajo cuando cambien de modelos o entornos de despliegue. Si la gobernanza sigue ligada a un proveedor, la elección del modelo seguirá controlando el sistema circundante.
Estas señales se refuerzan mutuamente. Los permisos acotados reducen el daño posible. Los registros de auditoría revelan si esos límites funcionaron. La portabilidad evita que los límites desaparezcan durante la próxima migración de modelo.
Los desarrolladores también deberían vigilar la fricción del flujo de trabajo diario. Una capa de control que interrumpe constantemente las acciones de bajo riesgo encontrará resistencia. Una que oculta las decisiones de política será difícil de confiar y depurar.
Los sistemas exitosos harán rutinarias las operaciones seguras y explícitas las operaciones excepcionales. Permitirán que los agentes lean, razonen, prueben y preparen cambios dentro de entornos delimitados. Se detendrán ante acciones con consecuencias externas o irreversibles.
El argumento de Mozilla AI sobre la infraestructura para agentes se reforzará cuando estas funciones se conviertan en expectativas estándar de producto. Se debilitará si los agentes siguen ganando autoridad mientras los controles permanecen como paneles opcionales o plantillas de prompts.
Para los equipos que adoptan ahora agentes de programación, la pregunta inmediata no es si el modelo más reciente obtiene una puntuación más alta. Pregunte a qué puede acceder el agente, qué acciones requieren aprobación y si cada decisión puede reconstruirse posteriormente. Después pregunte si esas protecciones pertenecen a su organización o desaparecen con el proveedor. Una IA mejor seguirá siendo útil, pero la infraestructura determina si esa inteligencia puede delegarse de forma responsable.
