Mínimo privilegio en agentes IA: cómo limitar tokens de API

En julio de 2025, el agente de IA de Replit borró la base de datos de producción de una empresa durante una sesión de código autónomo, pese a instrucciones explícitas de no tocarla, y su propio fabricante tuvo que salir a reconocer el fallo públicamente. El motivo técnico de fondo no fue que la IA "decidiera" borrar nada: fue que el agente operaba con un token que tenía permisos de escritura total sobre el entorno. Mínimo privilegio significa exactamente lo contrario: dar a cada agente solo el permiso necesario para su tarea concreta -acceso de lectura, o escritura acotada a un repositorio o recurso concreto-, de modo que un error, una alucinación o una inyección de prompt solo pueda dañar lo que ese token alcanza, nunca el resto de la infraestructura de la empresa.

En la práctica de la mayoría de equipos que integran IA en su pipeline de CI/CD o en su gestor de código, existe un único token o clave de servicio creado tiempo atrás para el bot de despliegue, y cuando llega el momento de conectar un agente de IA a esa misma API, se reutiliza esa credencial porque ya funciona y evita configurar nada nuevo. Ese token suele tener alcance de organización completo: puede leer y escribir en todos los repositorios, borrar ramas, modificar workflows de CI y en muchos casos gestionar webhooks o secretos. El agente de IA hereda ese alcance completo aunque su tarea real sea, por ejemplo, abrir un pull request en un único repositorio o consultar el estado de una API. Nadie decide conscientemente dar tanto poder al agente: es una herencia de una decisión de infraestructura tomada antes de que el propio agente existiera. Ese es el patrón que explica la mayoría de incidentes de "la IA borró algo que no debía": no fue el agente quien decidió tener ese poder, fue el equipo humano el que nunca lo restringió.

Blast radius: lo que el agente puede tocar, no lo que necesita tocar

El concepto clave que casi nadie explica bien es que el riesgo de un agente autónomo no depende de lo inteligente o torpe que sea el modelo: depende del blast radius de sus credenciales, el conjunto total de recursos que ese token puede modificar o borrar, sin importar si la tarea concreta iba a tocar solo uno de ellos. Un agente con un token de solo lectura sobre un repositorio y de escritura acotada a una rama concreta tiene un blast radius minúsculo: en el peor de los casos, rompe esa rama. Un agente con un token de organización con permisos de administrador tiene un blast radius que incluye cada repositorio, cada secreto de CI y cada configuración de despliegue de la empresa. Un desarrollador con ese mismo token también podría borrar algo por error, pero un humano que va a ejecutar un force-push sobre main normalmente duda o relee el comando dos veces; un agente que genera y ejecuta comandos en cadena dentro de un bucle no tiene ese momento de duda salvo que se lo hayas construido explícitamente, y puede encadenar decenas de llamadas a la API en segundos antes de que nadie note el error.

El incidente de Replit de julio de 2025 se hizo público porque el fundador de la empresa afectada lo relató directamente y el propio consejero delegado de Replit reconoció el fallo, anunciando cambios en los controles de seguridad del producto, incluyendo una separación más estricta entre entornos de desarrollo y producción. Lo relevante para cualquier equipo que integre agentes de IA en su propio pipeline no es el nombre del proveedor, sino el patrón de fondo: el agente tenía capacidad técnica de alcanzar un recurso que su tarea no necesitaba tocar en absoluto. Ninguna instrucción en lenguaje natural, por explícita que sea, sustituye una restricción real a nivel de credencial: si el token puede borrar la base de datos, tarde o temprano alguien -humano o agente- acabará borrándola.

Usa tokens de grano fino, no claves de organización

La mayoría de proveedores de API relevantes para automatización -GitHub, GitLab, plataformas cloud, gestores de proyecto- ofrecen desde hace años tokens de grano fino que permiten limitar el acceso a un repositorio concreto, a una acción concreta y con fecha de caducidad. GitHub, por ejemplo, recomienda activamente sus fine-grained personal access tokens frente a los tokens clásicos de acceso total, precisamente porque permiten auditar y revocar por repositorio sin afectar al resto de integraciones. Configurar esto para un agente de IA no añade complejidad de desarrollo: es una pantalla de configuración distinta al crear el token, no una integración nueva que programar. El coste real está en el hábito: hay que crear un token específico para el agente, con scope explícito, en lugar de copiar el que ya existe.

• Crea un token o API key exclusivo para el agente, nunca compartido con CI/CD, bots de Slack u otras integraciones
• Limita el scope a los repositorios o recursos concretos que la tarea del agente necesita, no a toda la organización
• Otorga permisos de lectura por defecto; añade escritura solo en la acción específica que el agente debe ejecutar
• Excluye siempre permisos de administración, borrado de repositorios, gestión de secretos y force-push sobre ramas protegidas
• Configura caducidad corta en el token (30-90 días) en vez de crear tokens sin expiración
• Registra qué agente usa qué token en un inventario simple, para poder revocar uno sin apagar el resto del pipeline

Separa credenciales por función, no por comodidad

El error más habitual no es técnico, es organizativo: se crea un token por comodidad operativa -uno para todo- en lugar de uno por función. La solución táctica más simple, que no requiere ingeniería adicional, es separar como mínimo tres credenciales distintas: una de solo lectura para tareas de análisis o auditoría del agente, otra de escritura acotada para la acción concreta que debe automatizar, y una tercera, completamente separada y fuera del alcance de cualquier agente, para despliegues a producción. Esta separación limita el blast radius sin construir un sistema de permisos propio ni adoptar herramientas nuevas: se hace con las opciones de scope que ya ofrece la propia plataforma.

Sería cómodo cerrar el artículo diciendo que basta con tokens de grano fino para que un agente de IA sea seguro, pero no es del todo cierto. Mínimo privilegio no impide que un agente sea víctima de una inyección de prompt, no impide que interprete mal una instrucción ambigua, y no sustituye la necesidad de revisar lo que propone antes de que se ejecute en entornos sensibles. Lo que hace es acotar el daño posible cuando algo de eso falla, que es distinto a evitar que falle. Tampoco es gratis: mantener tokens de grano fino por agente y por función implica más credenciales que rotar y más superficie que documentar, y en equipos muy pequeños con dos o tres integraciones puede sentirse como burocracia frente al beneficio real. Nuestra recomendación en Blurtek no es construir un sistema de gestión de credenciales sofisticado para una pyme con un agente y un pipeline sencillo: para la mayoría de casos basta con separar en dos o tres tokens con scope acotado y revisar sus permisos cada trimestre, sin contratar herramientas adicionales de gestión de secretos.

El principio de mínimo privilegio no hace que un agente de IA sea infalible, hace que su primer error no sea también el último que puedas permitirte.