IntroducciónLos agentes de codificación de IA ya no son simples herramientas de autocompletado. Leen repositorios, inspeccionan incidencias, editan archivos, ejecutan scripts, llaman herramientas, abren conexiones de red y, a veces, crean cambios listos para producción. Esto los hace útiles, pero también cambia el modelo de seguridad.La pregunta clave ya no es solo si un modelo puede rechazar una solicitud dañina. La cuestión más difícil es qué se le permite hacer al agente en tiempo de ejecución: qué archivos puede leer, qué scripts puede ejecutar, si puede acceder a internet, si los secretos están montados y si cada acción deja un rastro de auditoría útil.Este artículo reorganiza la discusión original sobre Fuego Amigo y Agente Rebelde en una guía práctica de seguridad para equipos que utilizan agentes de codificación de IA en flujos de trabajo reales de desarrollo.## Juicio FundamentalLa señal común detrás de Fuego Amigo y Agente Rebelde es simple: el contexto no confiable puede volverse peligroso cuando un agente lo trata como autoridad.Un README de repositorio, un script de dependencia, un archivo cargado por un cliente o un bloque de código de chatbot pueden parecer entradas ordinarias. Pero si un agente lee esa entrada y luego actúa sobre ella con acceso al sistema de archivos, shell, red o credenciales, la entrada ha cruzado efectivamente un límite de confianza.Para uso en producción, el agente no debería ser la autoridad final sobre si se permite o no una llamada a herramienta. Puede proponer una acción. La capa de permisos, el sandbox, el motor de políticas y el revisor humano deberían decidir si la acción está realmente permitida.## Por Qué Importa el Fuego AmigoFuego Amigo se centra en un flujo de trabajo de seguridad realista: pedirle a un agente de codificación de IA que revise un repositorio de terceros o de código abierto en busca de vulnerabilidades. Ese flujo de trabajo es atractivo porque parece defensivo. El equipo no le pide al agente que ataque nada. Le pide que inspeccione código y sugiera correcciones.El problema es que la revisión de seguridad requiere leer material no confiable. Un repositorio puede contener documentación, scripts, archivos de compilación, artefactos binarios y comentarios que no son solo datos. También pueden contener instrucciones dirigidas al agente.La lección importante no es entrar en pánico por las herramientas de seguridad de IA. Es separar la evidencia de la autorización.Un README puede explicar cómo se prueba normalmente un proyecto. No debería autorizar automáticamente al agente a ejecutar esa prueba. Un script de dependencia puede ser parte del repositorio. No debería volverse automáticamente confiable. Un paquete de terceros puede incluir un comando que parece una verificación de seguridad normal. El agente puede leerlo, pero la ejecución debería requerir un mayor nivel de confianza.Un patrón riesgoso se ve así:```Bash
./security.sh
2. **Aplicación de políticas**: una capa externa decide qué acciones están permitidas.
3. **Contención del tiempo de ejecución**: un entorno aislado limita el daño incluso si se aprueba la acción incorrecta.## Arquitectura Recomendada###
1. Aislar el Espacio de TrabajoLos repositorios de terceros, problemas desconocidos, auditorías de dependencias, archivos de clientes y paquetes descargados deben abrirse en entornos desechables. Un contenedor o una máquina virtual es un buen valor predeterminado.
El entorno aislado debe evitar montar el directorio de inicio del usuario, credenciales en la nube, tokens de gestores de paquetes, claves SSH, perfiles de navegador y configuración de producción. El código fuente puede comenzar como solo lectura. El acceso de escritura debe otorgarse solo cuando el agente haya producido un plan claro y el usuario haya aprobado el alcance.Los buenos valores predeterminados incluyen:- sin montaje del directorio de inicio personal
- sin credenciales en la nube de larga duración
- sin token predeterminado del gestor de paquetes
- sin acceso de red saliente sin restricciones
- cachés de paquetes temporales
- límites estrictos de tiempo y recursos
- registro completo de comandos###
- Dividir el Flujo de Trabajo del Agente en FasesNo permitas que la lectura, edición y ejecución colapsen en un solo flujo automático. Sepáralos.Fase de lectura: el agente puede inspeccionar archivos, identificar riesgos y producir un plan.Fase de parche: el agente puede generar un diff o parche, idealmente sin ejecutar scripts no confiables.Fase de ejecución: el agente puede ejecutar solo comandos aprobados dentro de una lista de permitidos estrecha, con tiempos de espera y límites de recursos.Si el comando propuesto provino de un README, un comentario de incidencia, un script de dependencia o un documento externo, la interfaz de aprobación debe mostrar esa fuente.Claramente. Un comando sugerido por el repositorio no es lo mismo que un comando solicitado explícitamente por el usuario.###
- Ejecutar escaneo determinista antes del juicio del modeloLos agentes de IA son útiles para explicar y clasificar, pero las herramientas deterministas deben ejecutarse primero siempre que sea posible.Por ejemplo:- Escaneo de secretos antes de cualquier ejecución de comandos
- Verificaciones de vulnerabilidades de dependencias antes de scripts de instalación
- Detección de binarios antes de ejecutar herramientas del repositorio
- Análisis estático antes de la interpretación del modelo
- Revisión de diff de lockfile antes de actualizaciones de paquetes
- Inspección del ciclo de vida de scripts antes de instalar dependenciasEl agente puede resumir y priorizar los hallazgos. No debe reemplazar los escáneres base.## Flujo de trabajo para código de tercerosPara repositorios no confiables, la opción más segura es inspeccionar primero, no ejecutar.1. Clonar el repositorio en un entorno limpio y desechable.
- Deshabilitar los ayudantes de credenciales y evitar montar secretos del host.
- Usar cachés de paquetes temporales.
- Restringir el acceso a directorios padres.
- Dejar que el agente lea archivos y produzca un plan de riesgos.
- Revisar los scripts del ciclo de vida antes de instalar dependencias.
- Pedir al agente que explique el origen y propósito de cada comando que quiera ejecutar.
- Ejecutar solo comandos aprobados con límites de tiempo, red y sistema de archivos.
- Traer solo artefactos revisados, como parches, informes y notas de reproducción.
- No traer cachés de paquetes, binarios generados, historial de shell ni estado de ejecución desde el sandbox.Una regla útil es simple: cuanto menos confíes en la entrada, menos autoridad debe recibir el agente.## Cómo los equipos de producto deben diseñar los permisos de los agentes de IAUn solo interruptor de "modo seguro" no es suficiente. Los productos reales necesitan permisos a nivel de capacidad.Un mejor modelo de permisos trata cada capacidad por separado:| Capacidad | Valor predeterminado recomendado | Por qué es importante |
|-|-|-|
| Leer archivos | Permitido en el espacio de trabajo delimitado | Los agentes necesitan contexto, pero no toda la máquina. |
| Escribir parches | Permitido después de la revisión del plan | Escribir código es más seguro que ejecutar código. |
| Ejecutar pruebas | Solo lista blanca | Los comandos de prueba pueden invocar scripts arbitrarios. |
| Instalar dependencias | Requiere aprobación | Los scripts del ciclo de vida de paquetes son una superficie de riesgo importante. |
| Acceso a red | Denegado por defecto para trabajo no confiable | Evita la exfiltración y la obtención remota de cargas útiles. |
| Acceder a secretos | Denegado por defecto | Los secretos no deben ser visibles para tareas no confiables. |
| Crear solicitudes de extracción | Requiere aprobación | Las PR pueden afectar repositorios confiables y sistemas de CI. |
| Desplegar | Requiere aprobación manual | El despliegue es una acción que impacta la producción. |Las pantallas de aprobación deben mostrar no solo el comando, sino también su origen. Un comando de la intención del usuario, inferencia del modelo, instrucciones del README, configuración de CI y comentarios de issues externos debe etiquetarse de manera diferente.## Lo que esto significa para los flujos de trabajo de NxCodeLos usuarios de NxCode a menudo quieren que los agentes manejen trabajo real de desarrollo: leer código, actualizar archivos, ejecutar verificaciones, generar artefactos de despliegue y producir documentación. Esas capacidades son valiosas, pero solo cuando los límites de permisos son claros.Un enfoque práctico es clasificar las tareas en tres grupos:1. Trabajo de bajo riesgo en entornos confiables****Repositorios
Ejemplos incluyen formato, actualizaciones de documentación, cambios pequeños en la interfaz de usuario y sugerencias de pruebas. Estos pueden usar mayor automatización cuando el repositorio y el entorno son confiables.
- Investigación sobre entradas no confiables
Ejemplos incluyen repositorios desconocidos, actualizaciones de dependencias, informes de problemas externos y archivos subidos por clientes. Estos deben ejecutarse en entornos desechables y restringidos.
- Operaciones que impactan en producción
Ejemplos incluyen despliegues, migraciones de bases de datos, rotación de secretos, cambios en la infraestructura y actualizaciones de permisos de CI/CD. Estos requieren aprobación humana y registros de evidencia sólidos.Este diseño no elimina la ventaja de velocidad de los agentes de codificación de IA. Mantiene al agente rápido cuando el riesgo es bajo, y exige más estructura cuando el radio de explosión es alto.¿Qué permisos deberían exponer los productos de codificación con IA?Los productos deberían exponer controles granulares para leer archivos, escribir parches, ejecutar pruebas, instalar dependencias, usar la red, acceder a secretos, crear solicitudes de extracción y desplegar. Cada capacidad debería tener su propio alcance, presupuesto, registros y reglas de aprobación.## Herramientas relacionadas- Claude Code: La herramienta de codificación agente de Anthropic para leer, editar y trabajar con bases de código.
- OpenAI Codex: La plataforma de agentes de codificación de OpenAI con conceptos de sandboxing y aprobación.
- Google Dialogflow CX: La plataforma de agentes conversacionales de Google Cloud, que incluye capacidades de playbooks y bloques de código.
- Docker: Una forma común de crear entornos de desarrollo y pruebas desechables.
- Semgrep: Una herramienta de análisis estático que puede escanear código fuente antes de la ejecución impulsada por agentes.
- GitHub CodeQL: Un motor de análisis semántico de código útil para flujos de trabajo de revisión de seguridad.## Enlaces relacionados- Investigación Friendly Fire de AI Now: Breve investigación sobre agentes de IA defensivos y riesgo de ejecución remota de código.
- Divulgación de Varonis sobre Rogue Agent: Informe técnico sobre la vulnerabilidad Rogue Agent en Dialogflow CX.
- Documentación de seguridad de Claude Code: Guía oficial de seguridad de Anthropic para Claude Code.
- Modo automático de Claude Code: Explicación de Anthropic sobre el modo automático y las decisiones de permisos en Claude Code.
- Documentación de sandbox de OpenAI Codex: Explicación oficial de cómo Codex utiliza límites de sandbox.
- Revisión automática de OpenAI Codex: Documentación oficial sobre el comportamiento de revisión automática de Codex.
- Bloques de código de Dialogflow CX: Documentación de Google Cloud para bloques de código Python en playbooks de Dialogflow CX.## ResumenFriendly Fire y Rogue Agent demuestran que la seguridad de los agentes de IA no es solo un problema de alineación de modelos. El límite práctico es el entorno de ejecución: archivos, comandos, acceso a la red, secretos, entornos de ejecución y auditabilidad.Los equipos que utilizan agentes de codificación con IA deberían tratar los repositorios no confiables y el contexto externo como entradas no confiables, incluso cuando la tarea es defensiva. El agente puede ayudar a inspeccionar y explicar, pero la ejecución debe ser controlada mediante sandboxing, políticas, escáneres y aprobaciones explícitas.El patrón más seguro es simple: permitir que los agentes razonen ampliamente, pero otorgar autoridad operativa de manera limitada.
