Agentes de IA con herramientas: permisos, controles y límites
Cómo diseñar permisos para agentes de IA que usan correo, archivos, bases de datos o APIs: mínimo privilegio, aprobación humana, validación, logs y límites de ejecución.
Clasifica herramientas por consecuencia
No todas las acciones tienen el mismo riesgo. Consultar un calendario es distinto de crear una reunión; leer un registro es distinto de borrarlo. Diseña permisos por nivel de consecuencia y no solo por aplicación.
| Nivel | Ejemplo | Control |
|---|---|---|
| Lectura | Consultar documentación | Filtros de acceso y logs |
| Escritura reversible | Crear borrador o etiqueta | Validación y posibilidad de deshacer |
| Comunicación externa | Enviar correo | Aprobación o destinatarios permitidos |
| Irreversible / alto impacto | Borrar, pagar, publicar | Confirmación humana explícita |
Mínimo privilegio de verdad
Si el agente solo necesita leer dos carpetas, no le des acceso a toda la unidad. Si prepara borradores, no necesita permiso para enviar. Utiliza cuentas de servicio separadas cuando la plataforma lo permita y evita compartir credenciales de administrador.
Los permisos deben comprobarse en cada llamada a herramienta. No basta con decir al modelo “solo usa esto para X”.
Valida argumentos antes de ejecutar
Antes de llamar a una API, el backend puede comprobar destinatarios, importes, dominios, rutas y formatos. Este control es determinista y mucho más fiable que esperar que el modelo recuerde todas las reglas.
Ejemplo: un agente prepara correos internos. El sistema puede permitir solo direcciones del dominio de la empresa. Si el modelo propone un destinatario externo, la llamada se bloquea aunque el texto parezca convincente.
Aprobación humana que aporta algo
Una confirmación inútil muestra un botón “Aceptar” sin explicar consecuencias. Una buena aprobación enseña acción, destino, datos relevantes y posibilidad de corregir. Para pagos o borrados, muestra también la razón generada por el agente y la fuente de los datos.
Límites de ejecución para evitar bucles y costes
- Número máximo de pasos por tarea.
- Tiempo máximo de ejecución.
- Presupuesto máximo de llamadas o consumo.
- Número de reintentos por herramienta.
- Lista de herramientas permitidas por caso.
Un agente que no consigue resolver una tarea debe escalar o detenerse, no seguir probando indefinidamente.
Logs que permiten investigar
Registra qué herramienta se llamó, con qué identificador de tarea, qué resultado devolvió y si hubo aprobación. Evita guardar secretos innecesarios en logs. La trazabilidad sirve para mejorar el flujo y responder a incidentes.
La seguridad frente a prompt injection depende en gran medida de estas capas. Incluso si el modelo interpreta una instrucción maliciosa, los permisos deberían limitar las consecuencias.
Checklist para aplicarlo
- Cada herramienta tiene una razón de existir.
- Lectura y escritura están separadas cuando es posible.
- El backend valida argumentos antes de ejecutar.
- Las acciones de alto impacto requieren aprobación.
- Existen límites de pasos, tiempo y reintentos.
- Los logs permiten reconstruir la secuencia.
- Los secretos se guardan fuera de prompts y logs.
Preguntas frecuentes
¿Un agente puede usar mi cuenta personal?
Es posible en algunas integraciones, pero es más seguro usar permisos específicos, cuentas separadas o scopes mínimos cuando la plataforma lo permita.
¿La confirmación humana elimina el riesgo?
No, pero reduce impacto si la pantalla de aprobación muestra información suficiente. También hacen falta permisos y validación.
¿Qué herramienta debe recibir primero un agente?
Una herramienta de lectura y bajo riesgo suele ser un buen punto de partida antes de permitir escritura.
Fuentes y documentación para ampliar
Priorizamos documentación primaria y organismos especializados. Las funciones, límites y condiciones de servicios pueden cambiar; comprueba la versión vigente antes de tomar una decisión.