For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/es/articles/friendly-fire-rogue-agent-ai-coding-security.md.
Fuego Amigo y Agente Rebelde demuestran que la seguridad de los agentes de IA no es solo un problema de alineación de modelos. El límite prá...
Los 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.
La 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.
Fuego 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í:
./security.sh
El comando en sí puede parecer inofensivo, pero la pregunta importante es de dónde vino. ¿Fue solicitado explícitamente por el usuario? ¿Fue sugerido por el modelo? ¿Fue copiado de un README de terceros? ¿Estaba incrustado dentro de un comentario de incidencia o script de dependencia? Esas fuentes no deberían tener el mismo nivel de confianza.
Agente Rebelde muestra un tipo diferente de riesgo. En lugar de un agente de codificación local revisando un repositorio, el problema es una IA en la nube
plataforma donde los agentes conversacionales pueden ejecutar bloques de código dentro de un entorno de ejecución gestionado.
La lección útil para los equipos de producto y seguridad es que los chatbots no son solo indicaciones y respuestas. También pueden incluir entornos de ejecución, cuentas de servicio, salida de red, variables de sesión, registros, infraestructura compartida y permisos de despliegue.
Cuando un agente conversacional puede ejecutar código o acceder a datos de clientes, debe gobernarse como una aplicación de producción. Eso significa privilegios mínimos, separación de entornos, registro de auditoría, revisión de cambios y propiedad clara. Tratarlo solo como una "configuración de conversación" es demasiado débil para el riesgo real.
Friendly Fire y Rogue Agent son incidentes diferentes, pero apuntan al mismo modo de falla: un contexto no confiable recibe poder operativo.
En el escenario de Friendly Fire, el contenido de un repositorio no confiable puede influir en un agente para que ejecute comandos. En el escenario de Rogue Agent, la ejecución de código dentro de una plataforma de agente puede afectar el comportamiento del tiempo de ejecución compartido y los datos sensibles de conversación. La investigación relacionada con MCP también ha planteado una preocupación similar: la vista de aprobación orientada al usuario y los metadatos que el modelo recibe realmente pueden no representar siempre la misma imagen de confianza.
Por eso, el diseño de seguridad no puede depender solo de un modelo cuidadoso. Un modelo puede ayudar a razonar sobre el riesgo, pero no debería aprobar sus propias llamadas riesgosas a herramientas inmediatamente después de leer instrucciones no confiables.
Una arquitectura más segura separa tres capas:
Los 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:
No permitas que la lectura, edición y ejecución colapsen en un solo flujo automático. Sepáralos.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
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.
Los agentes de IA son útiles para explicar y clasificar, pero las herramientas deterministas deben ejecutarse primero siempre que sea posible.
Por ejemplo:
El agente puede resumir y priorizar los hallazgos. No debe reemplazar los escáneres base.
Para repositorios no confiables, la opción más segura es inspeccionar primero, no ejecutar.
Una regla útil es simple: cuanto menos confíes en la entrada, menos autoridad debe recibir el agente.
Un 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.
Los 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:
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.
2. 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.
3. 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.
Friendly 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.
Empieza con una sola frase y obtén un sitio completo en minutos.
