Herramientas con Mínimo Privilegio
Dale al agente el conjunto de herramientas más estrecho, y a cada herramienta el alcance más estrecho, que la tarea realmente necesita. El patrón asume que la inyección de prompts a veces tendrá éxito y acota lo que un agente secuestrado puede hacer: no puedes parchear el modelo, pero sí decidir a qué es capaz de llegar.
Definición
Las herramientas con mínimo privilegio son la práctica de acotar el catálogo de herramientas de un agente, y la credencial que hay bajo cada una, al mínimo que la tarea requiere, de modo que las consecuencias de un ataque con éxito o de un error del modelo queden acotadas por diseño y no por la obediencia del modelo.
Problema
Un agente con herramientas amplias y credenciales amplias convierte cualquier inyección, jailbreak o alucinación con éxito en una acción real con todo el alcance de la cuenta que hay detrás.
Cuándo usarlo
Úsalo allí donde un agente pueda actuar: llamar APIs, escribir ficheros, enviar mensajes, mover dinero. Cuanta más autonomía y menos revisión humana, más hay que fijar el radio de impacto en la capa de permisos y no en el prompt.
Solución
Parte de la tarea, no de la plataforma. Lista las operaciones que el agente debe realizar y expón exactamente esas. Un catálogo montado a partir de «lo que ofrece la API» es una concesión de permisos que nadie revisó.
Separa lectura de escritura: herramientas distintas, credenciales distintas y ninguna ruta de escritura alcanzable por un argumento de una herramienta de lectura. Los endpoints de «consulta» que además mutan son la escalada silenciosa más común.
Acota la credencial, no solo la herramienta. Una herramienta de solo lectura respaldada por un token de administrador está a un bug de ser una herramienta de escritura; emite credenciales por herramienta con el alcance más estrecho que soporte el sistema de arriba.
Acota los parámetros. Pon en lista de permitidos las rutas, repositorios, tablas, cuentas o destinatarios a los que una herramienta puede dirigirse, para que un agente secuestrado no pueda reapuntar una herramienta legítima a un objetivo ilegítimo.
Haz que las concesiones caduquen y se revisen. Las herramientas se acumulan; retira lo que nadie invoca y trata añadir una herramienta como el cambio de permisos que es.
Registra la concesión y la llamada por separado. Lo que el agente podía hacer y lo que hizo son dos auditorías distintas, y un incidente necesita las dos.
Componentes
Beneficios
- Acota el daño de una inyección con éxito sin depender de que el modelo se porte bien.
- Convierte «¿es seguro este agente?» en un artefacto revisable: una lista de herramientas, alcances y responsables.
- Mejora de rebote la precisión al elegir herramienta: menos herramientas y más nítidas son más fáciles de distinguir para un modelo.
- Hace investigables los incidentes, porque el conjunto alcanzable se conocía antes del incidente.
Riesgos
- Ampliación por comodidad: un token amplio pegado durante una depuración y nunca estrechado después.
- Fragmentación: decenas de herramientas finísimas que el modelo no sabe distinguir, cambiando una victoria de seguridad por una pérdida de fiabilidad.
- Falsa tranquilidad. El mínimo privilegio acota consecuencias; no evita el ataque, y no dice nada sobre la exfiltración a través de una herramienta de lectura legítimamente concedida.
- Fricción de proceso: si emitir una credencial acotada cuesta más que reutilizar una amplia, el proceso se convierte en la vulnerabilidad.
Cuándo no usarlo
- Prototipos sobre datos sintéticos sin alcance a producción, donde la ceremonia cuesta más que el riesgo que elimina.
- Cuando la plataforma de arriba no sabe expresar alcances: entonces el control se mueve a un proxy delante, en lugar de darse por satisfecho.
- Cuando estrechar al agente empujaría el trabajo a una vía humana que está peor acotada y peor auditada.
Tecnologías
Ejemplos
- Un agente de programación con un token de repositorio acotado a un repositorio y un prefijo de rama, sin lectura a nivel de organización. Una inyección por el README de una dependencia todavía puede abrir una rama; no puede llegar a los otros cuarenta repositorios.
- Un agente de soporte con las herramientas de CRM separadas: read_customer con una clave de solo lectura y update_ticket restringida a los tickets ya presentes en la conversación. Una sesión secuestrada puede molestar a un ticket, no exportar la base de clientes.
- Un servidor MCP público cuyo catálogo entero son getters sobre contenido ya publicado, respaldado por ninguna credencial: no hay nada que revocar porque no hay nada que filtrar.
Evidencia de producción
- Contexto
- El endpoint MCP público de esta base de conocimiento, accesible para cualquier agente de internet.
- Escenario
- El corpus es público y de solo lectura, así que el catálogo son íntegramente getters. No hay herramienta que escriba, ninguna que llegue a datos que el sitio no publique ya y ninguna credencial alcanzable desde una herramienta.
- Tecnología
- JSON-RPC sin estado sobre HTTP en un route handler de Next.js, lista de orígenes permitidos comprobada antes de ejecutar ningún handler, límite de tasa por llamante en Redis y log de auditoría estructurado por llamada.
- Carga
- Tráfico continuo y desatendido de agentes desde el lanzamiento, más rastreadores de registros y comprobaciones de salud de directorios.
- Resultados
- Un cliente de este servidor secuestrado por inyección de prompts no puede obtener nada que no pudiera haber descargado del sitio público, porque el conjunto alcanzable es exactamente el corpus publicado. No hay credencial que revocar ni ruta de escritura que abusar.
KPIs
- Herramientas por agente
- El tamaño del catálogo. Crecer sin retirar es la señal de que las concesiones se acumulan sin revisión.
- Porcentaje de herramientas con escritura
- Cuánto del catálogo puede cambiar estado. El número que conviene llevar al mínimo que la tarea permita.
- Antigüedad de la herramienta sin uso más vieja
- Días desde la última invocación de una herramienta concedida. Una concesión vieja sin uso es alcance que nadie necesita y que un atacante hereda.
- Cobertura de alcance documentado
- Porcentaje de herramientas con alcance escrito y responsable con nombre. Una herramienta sin documentar es una herramienta sin acotar.
Modos de fallo observados
- El token de administrador detrás de la herramienta de solo lectura: alcance declarado en la capa de herramienta, sin acotar en la capa de credencial.
- Reapuntado de parámetros: la herramienta es legítima y el objetivo no, porque nada restringió el argumento.
- Diputado confundido: estrechar las herramientas sin estrechar bajo qué autoridad corren no cambia nada, porque quien llama sigue heredando el alcance del agente.
- Deriva del catálogo: las herramientas añadidas para un experimento se quedan, y el conjunto de permisos que se revisó ya no es el desplegado.
Lecciones aprendidas
- Escribe el radio de impacto antes de conceder la herramienta, no después del incidente.
- El nombre de una herramienta no es su alcance. Solo lo es la credencial del lado servidor.
- Retirar una herramienta que nadie invoca es el trabajo de seguridad más barato que existe.
- El mínimo privilegio paga dos veces: acota ataques y hace que el agente elija mejor sus herramientas.
FAQs
- ¿El mínimo privilegio detiene la inyección de prompts?
- No, ni pretende hacerlo. Asume que a veces tendrá éxito y decide de antemano qué puede conseguir un ataque exitoso. Prevenir y contener son trabajos distintos, y solo contener está bajo tu control.
- ¿Cuánto es demasiado estrecho?
- Cuando el modelo ya no distingue dos herramientas, o cuando una tarea rutinaria necesita cuatro llamadas que podrían haber sido una con seguridad. Dividir mejora hasta que empieza a producir elecciones erróneas, y una llamada equivocada es un fallo por derecho propio.
- Usamos una sola cuenta de servicio para todo, ¿tan malo es?
- Significa que cada agente, y cada atacante que llegue a uno, tiene el alcance de la tarea más amplia que realice cualquiera de ellos. Una sola cuenta es la versión de este patrón en la que el radio de impacto es «todo».