Seguridad de los agentes de IA: el riesgo ya no es solo que escriban código, sino que lo ejecuten
Durante meses hemos hablado de la IA como copiloto: una herramienta que sugiere funciones, resume documentación o genera pruebas. Ese marco ya se queda corto. Los nuevos agentes de programación pueden leer un repositorio, modificar archivos, ejecutar comandos, abrir una pull request e incluso coordinarse con otras herramientas del ciclo DevOps. La frontera relevante ya no está en si el código generado es elegante, sino en qué permisos tiene el agente y qué puede hacer sin supervisión. Ahí aparece un problema nuevo: estamos metiendo identidades operativas dentro del proceso de desarrollo.
De asistente de código a actor dentro del repositorio
Un asistente clásico propone texto. Un agente actúa. La diferencia parece pequeña, pero en seguridad cambia casi todo. GitHub describe su Copilot coding agent como un sistema capaz de trabajar de forma autónoma en un entorno basado en GitHub Actions para completar tareas asignadas desde issues o Copilot Chat. En la práctica, eso significa que el agente no solo “sabe programar”: puede clonar código, ejecutar pruebas, aplicar cambios y preparar una revisión.
Microsoft ha reforzado esta idea en Build 2026, al hablar de seguridad para código, agentes y modelos durante todo el ciclo de desarrollo. Su mensaje es claro: la IA ya no vive al margen del pipeline, sino dentro de él. Esto obliga a tratarla como un componente de ingeniería, no como una extensión simpática del editor.
La pregunta técnica deja de ser “¿me ayuda a programar más rápido?” y pasa a ser otra: “¿qué superficie de ataque estoy abriendo?”.
El fallo peligroso no siempre está en el código generado
El riesgo más visible es que el agente escriba una consulta SQL insegura, un control de acceso débil o una dependencia vulnerable. Eso ya era preocupante con los copilotos de primera generación. Pero los agentes añaden un plano adicional: pueden equivocarse ejecutando acciones.
Un prompt malicioso en un README, una issue manipulada o una respuesta externa aparentemente inocua pueden intentar condicionar el comportamiento del agente. En el mundo de la seguridad de LLM esto se aproxima a la inyección de instrucciones, pero aplicada a herramientas con capacidad real de operar sobre ficheros, credenciales, APIs o entornos de prueba.
OWASP ya ha publicado el Top 10 for Agentic Applications 2026, centrado precisamente en sistemas autónomos o semiautónomos que planifican, deciden y actúan. Es una evolución natural de marcos como el OWASP Top 10 tradicional, del que ya hablamos en Tecnoic al explicar la seguridad web: cuando cambia la arquitectura, cambia también el mapa de amenazas.
Permisos mínimos también para identidades no humanas
El primer error sería dar al agente el mismo acceso que a un desarrollador senior. Es cómodo, pero técnicamente peligroso. Un agente de IA debe tener identidad propia, permisos limitados y trazabilidad completa. No debería reutilizar tokens personales, credenciales compartidas ni claves con más alcance del necesario.
La regla de mínimos privilegios se vuelve mucho más importante porque el agente puede actuar a gran velocidad y con una interpretación imperfecta del contexto. Si solo necesita crear una rama, ejecutar tests y abrir una pull request, no debería poder desplegar en producción, borrar artefactos, modificar secretos o alterar reglas de protección del repositorio.
También conviene separar entornos. Una cosa es permitir que el agente trabaje sobre una copia aislada del repositorio y otra muy distinta darle acceso directo a bases de datos reales, servicios internos o sistemas de integración continua con credenciales amplias. El sandbox no es un extra: es el cortafuegos operativo entre una ayuda útil y un incidente serio.
La seguridad debe moverse al flujo de trabajo, no al final
Con agentes de código, revisar solo el resultado final es insuficiente. Hay que observar el proceso: qué instrucciones recibió, qué archivos tocó, qué comandos ejecutó, qué dependencias añadió y qué pruebas pasaron. La revisión humana sigue siendo necesaria, pero debe apoyarse en controles automáticos.
En un pipeline razonable, el código propuesto por un agente debería pasar por análisis estático, análisis de dependencias, detección de secretos, pruebas de seguridad y revisión de cambios sensibles. También encaja aquí el uso de SBOM para saber qué componentes han entrado en la aplicación y mantener la trazabilidad de la cadena de suministro.
El marco del NIST AI Risk Management Framework ayuda a ordenar esta conversación porque insiste en gobernar, mapear, medir y gestionar riesgos de IA. Traducido al desarrollo software: inventario de agentes, políticas de uso, controles técnicos, auditoría y métricas. No basta con comprar licencias de una herramienta popular; hay que integrarla en un modelo de gobierno.
El nuevo DevSecOps tendrá que auditar decisiones de máquinas
La adopción de agentes de IA no se va a frenar porque la productividad que prometen es demasiado atractiva. Pueden acelerar tareas repetitivas, generar pruebas, explorar deuda técnica y reducir el coste de cambios pequeños. El problema es introducirlos como si fueran simples plugins.
En los próximos meses veremos más organizaciones definiendo políticas específicas para agentes: qué repositorios pueden tocar, qué ramas pueden crear, cuándo necesitan aprobación, qué herramientas pueden invocar y qué logs deben conservarse. En entornos regulados, esta trazabilidad será especialmente relevante. Si un agente cambia código que afecta a datos personales, servicios críticos o integraciones con terceros, alguien tendrá que poder explicar qué ocurrió.
La parte incómoda es que muchas prácticas actuales de desarrollo ya eran frágiles antes de la IA. Tokens demasiado amplios, secretos mal gestionados, pipelines con permisos excesivos y revisiones superficiales no nacen con los agentes, pero los agentes los amplifican.
Conclusión
Los agentes de IA para programar no son solo una nueva interfaz para escribir código. Son actores dentro del ciclo de vida del software. Por eso su seguridad debe diseñarse como se diseña cualquier componente con capacidad operativa: identidad, permisos mínimos, aislamiento, monitorización y revisión. La oportunidad es evidente, pero el atajo puede salir caro. ¿Estamos preparados para auditar no solo el código, sino también las decisiones de quien lo ha generado?