El CTO de KloudStax plantea que los agentes de codificación necesitan identidad propia, no credenciales prestadas — y que las primeras diez líneas de una política de comandos pueden frenar filtraciones por instalación de paquetes.
Los agentes de inteligencia artificial que escriben, revisan o despliegan código están dejando de ser experimentos de laboratorio para convertirse en componentes activos de pipelines de desarrollo en producción. Vinay Thakker, CTO de KloudStax, acaba de publicar un marco de control de acceso que aborda una tensión estructural: estos agentes operan con autonomía técnica — ejecutan comandos, instalan dependencias, acceden a repositorios — pero lo hacen en nombre de personas que tienen permisos, responsabilidades y límites de red distintos. La pregunta que Thakker pone sobre la mesa no es si los agentes necesitan controles, sino cómo diseñar esos controles sin replicar los errores que ya se vieron con cuentas de servicio mal configuradas y proxies de credenciales que terminaron siendo puertas traseras permanentes.
Por qué los agentes no pueden heredar credenciales humanas sin más
El enfoque más común hasta ahora ha sido que el agente de IA opere bajo las credenciales del desarrollador que lo invoca — una extensión del modelo de «actuar en nombre de». Thakker argumenta que ese diseño genera dos problemas inmediatos. Primero, diluye la trazabilidad: si un agente instala un paquete malicioso o modifica código sensible usando las credenciales de un ingeniero senior, los logs muestran la acción del humano, no la del agente — lo que complica auditorías y respuesta a incidentes. Segundo, amplifica el radio de impacto de una credencial comprometida: si un atacante toma control del agente, hereda automáticamente todos los permisos del usuario asociado, sin necesidad de escalar privilegios.
La alternativa que propone es que cada agente tenga su propia identidad técnica — una cuenta de servicio dedicada, con permisos explícitos y limitados — y que la identidad del humano se adjunte como metadato de contexto cuando el agente actúa en su nombre. Esto permite que los sistemas de logging registren dos capas: quién autorizó la acción (el desarrollador) y qué entidad la ejecutó (el agente). En términos de control de acceso, significa que el agente solo puede hacer lo que su política permite, independientemente de los permisos del usuario que lo invocó.
Dónde fallan los proxies de credenciales en entornos de CI/CD
Thakker dedica parte del análisis a los proxies de credenciales — sistemas intermediarios que almacenan secretos y los inyectan en tiempo de ejecución para que los agentes no manejen claves directamente. El problema, según su lectura, no es el concepto sino la implementación: muchos proxies terminan configurados con permisos excesivos (acceso de lectura a todos los secretos del proyecto) y sin rotación automática, lo que los convierte en un punto de fallo único. Si el proxy se compromete, el atacante obtiene acceso a todas las credenciales que gestiona, no solo a las que el agente necesitaba para una tarea específica.
La recomendación es que los proxies operen bajo el principio de mínimo privilegio por sesión: cada vez que un agente solicita una credencial, el proxy valida que la tarea en curso justifica ese acceso, entrega un token de corta duración y registra la transacción con contexto completo (qué agente, para qué tarea, en nombre de quién). Esto requiere integración con sistemas de gestión de identidad que soporten políticas dinámicas — no listas estáticas de permisos.
Las primeras diez líneas de una política de comandos para agentes de codificación
Thakker propone que las políticas de control de comandos para agentes de IA se escriban como listas de negación explícitas antes que listas de permisos abiertos. Las primeras diez líneas, según su marco, deberían prohibir: ejecución de shells interactivos, instalación de paquetes desde repositorios no aprobados, modificación de archivos de configuración de red, acceso a directorios fuera del workspace del proyecto, uso de comandos de transferencia de archivos sin logging, creación de cuentas de usuario o claves SSH, modificación de políticas de firewall o seguridad, ejecución de binarios compilados localmente sin firma, acceso a servicios de metadatos de nube (como el endpoint 169.254.169.254 en AWS), y descarga de contenido desde URLs no validadas.
Estas restricciones apuntan a cerrar vectores de exfiltración y movimiento lateral que son triviales de explotar si el agente tiene acceso sin restricciones a un shell. La lógica es que un agente de codificación legítimo no necesita abrir un socket de red arbitrario ni modificar iptables — si lo intenta, es señal de compromiso o de una tarea mal definida.
Cómo frenar filtraciones de datos a través de instalaciones de paquetes
Uno de los vectores que Thakker señala como subvalorado es la instalación de dependencias. Un agente que puede ejecutar `npm install`, `pip install` o `go get` sin restricciones puede, intencionalmente o no, traer paquetes que exfiltran datos durante su instalación — scripts de post-install que envían variables de entorno, contenido de archivos o metadatos del proyecto a servidores externos. Este patrón ya se documentó en ataques de supply chain contra desarrolladores humanos; con agentes autónomos, el riesgo se amplifica porque el agente puede instalar decenas de paquetes en minutos sin revisión humana.
La contramedida propuesta es que los agentes solo puedan instalar paquetes desde mirrors internos o registros aprobados, y que cada instalación pase por un análisis estático previo que detecte scripts de red en hooks de instalación. Esto no elimina el riesgo — un paquete malicioso puede esconder su comportamiento — pero reduce la superficie de ataque al limitar qué repositorios son alcanzables y al forzar que cada nueva dependencia deje un registro auditable antes de ejecutarse.
Exposición en América Latina por adopción de agentes sin políticas de acceso
Aunque el análisis de Thakker no menciona geografías específicas, la adopción de agentes de IA en pipelines de desarrollo está creciendo en equipos de tecnología de Brasil, México y Argentina — especialmente en fintechs y startups que compiten por velocidad de entrega. La ausencia de políticas de control de acceso formales en estos entornos es un patrón observable: muchos equipos implementan agentes de codificación como extensiones de IDE o bots de CI/CD sin revisar qué permisos heredan ni qué comandos pueden ejecutar. En contextos donde la infraestructura de seguridad todavía está madurando — equipos sin SIEM, sin gestión centralizada de secretos, sin políticas de red segmentadas — un agente comprometido puede moverse lateralmente sin fricción.
El riesgo no es hipotético: si un agente con acceso a un repositorio de código puede instalar paquetes arbitrarios y ejecutar comandos de red, un atacante que comprometa ese agente (vía prompt injection, por ejemplo) obtiene un punto de entrada persistente con capacidad de exfiltración. Para equipos en la región que están adoptando estas herramientas, la recomendación de Thakker de empezar con políticas de negación explícitas — antes de habilitar permisos amplios — es directamente aplicable.
Nuestro análisis
El marco de Thakker no es una solución técnica empaquetada — es un conjunto de principios de diseño que asume que los agentes de IA van a operar con autonomía creciente y que los controles tienen que anticipar eso, no reaccionar después del primer incidente. Lo que distingue este enfoque de las guías genéricas de seguridad para IA es que se enfoca en el plano de ejecución — qué comandos puede correr el agente, qué red puede alcanzar, qué secretos puede tocar — en lugar de quedarse en el plano de datos (qué información ve el modelo). Esa distinción importa porque un agente de codificación comprometido no necesita exfiltrar datos del modelo; le alcanza con ejecutar `curl` o instalar un paquete malicioso.
El patrón que emerge es similar al que ya se vio con contenedores: al principio, muchos equipos los corrían como root sin políticas de red porque «era más fácil»; después vinieron los exploits y las políticas de seguridad se volvieron obligatorias. Con agentes de IA, estamos en la fase de «es más fácil darles acceso amplio» — pero los vectores de abuso ya están documentados. La pregunta es si los equipos van a implementar controles antes del primer incidente de exfiltración vía agente, o si vamos a esperar a que pase para recién entonces escribir las políticas que Thakker está proponiendo ahora.