La autenticación comprueba quién eres; la autorización decide qué puedes hacer. Un número creciente de aplicaciones impulsadas por IA verifica la identidad de un usuario una sola vez al iniciar sesión y luego permite que el agente subyacente actúe sobre cualquier recurso durante el resto de la sesión, entregándole efectivamente un «cheque en blanco». Ese diseño abre la puerta a filtraciones accidentales de datos, correos electrónicos no deseados o incluso actualizaciones destructivas de bases de datos, y el riesgo aumenta cada vez que un asistente de IA puede invocar múltiples herramientas con una latencia de milisegundos.

Por qué se sigue cometiendo este error

La mayoría de los desarrolladores de IA tratan la pantalla de inicio de sesión como la única puerta de seguridad. El código solicita una contraseña o un token, marca la sesión como «autenticada» y luego asume que cualquier solicitud posterior es segura. En una aplicación web tradicional, los clics lentos de un usuario humano proporcionan un punto de control natural; un humano hará una pausa antes de pulsar «eliminar». Sin embargo, un agente de IA puede ejecutar docenas de llamadas a herramientas en segundos. Si la plataforma solo pregunta «¿Está el usuario conectado?», cada llamada hereda el mismo privilegio sin restricciones.

La causa raíz es la conveniencia. Los equipos suelen aprovisionar una única cuenta de servicio de larga duración para toda la aplicación, de modo que el código no tenga que gestionar múltiples tokens o alcances (scopes). Esa cuenta suele tener permisos amplios —lectura, escritura, eliminación— en todos los proyectos. Cuando un asistente de IA se ejecuta dentro de esa sesión, hereda automáticamente esos derechos, independientemente de si la tarea actual realmente los requiere.

Lo que está en juego

  • Exposición de datos – Un agente que puede leer cualquier archivo después de que un usuario inicie sesión puede extraer inadvertidamente documentos confidenciales en una respuesta que luego se comparte fuera de la organización.
  • Acciones no deseadas – El asistente de IA de un ingeniero de soporte podría ejecutar una consulta SQL directa contra bases de datos de producción simplemente porque la sesión del ingeniero sigue activa, incluso si la consulta no tiene relación con el ticket que se está gestionando.
  • Cumplimiento normativo – Muchas reglas de protección de datos exigen que el acceso se limite al mínimo necesario. Un modelo de permisos generalizado puede violar esos principios y provocar auditorías o multas.
  • Coste operativo – Los errores que eliminan o modifican registros obligan a los equipos a revertir cambios, investigar las causas raíz y reconstruir la confianza con los usuarios, lo que supone una pérdida de tiempo y dinero.

El paso que falta: autorización por acción

La autorización debe evaluarse en cada «puerta» dentro del sistema, no solo en la entrada principal. La pregunta cambia de «¿Quién es este?» a «¿Puede realizarse esta acción específica en este recurso específico ahora mismo?». Implementar esa comprobación no requiere un rediseño completo; solo necesita pasar de un único indicador de sesión a tokens de alcance limitado y de corta duración.

Cómo funciona en la práctica

  1. Solicitar un token con un alcance definido – Cuando el agente de IA necesita llamar a una herramienta, primero obtiene un token que enumera los permisos exactos requeridos (p. ej., read:ticket, execute:sql_query).
  2. Validar el token para cada llamada – Antes de que la herramienta se ejecute, el servicio comprueba que el token incluya el alcance necesario y que el token no haya expirado.
  3. Relacionar el recurso con el alcance – Si la solicitud se dirige a un proyecto o base de datos en particular, el token debe otorgar explícitamente acceso a ese identificador.
  4. Rechazar o permitir – Si alguna comprobación falla, la llamada es denegada y el agente recibe un error que puede mostrar al usuario.

La diferencia en el código es sencilla. Un enfoque «malo» podría verse así:

if session.is_authenticated():
    tool.run(params)

Un enfoque «bueno» amplía la comprobación:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

El segundo patrón añade unas pocas líneas, pero obliga al sistema a hacer la pregunta correcta para cada operación.

Estándares que lo facilitan

Los alcances (scopes) de OAuth 2.0 ya proporcionan una forma ampliamente adoptada de limitar lo que un token puede hacer. Al emitir tokens de acceso de corta duración que codifican alcances como project:1234:write o email:send, los desarrolladores pueden confiar en las librerías existentes para realizar el paso de verificación.

Las más recientes Rich Authorization Requests (RFC 9396) amplían esta idea, permitiendo que un cliente solicite permisos granulares en tiempo de ejecución en lugar de predefinir una lista estática. Esa flexibilidad es útil cuando un flujo de trabajo de IA puede necesitar añadir o eliminar capacidades sobre la marcha basándose en la intención del usuario.

Contraargumento: simplicidad frente a seguridad

Algunos equipos argumentan que las comprobaciones por acción añaden latencia y complejidad al código, especialmente cuando el asistente de IA debe llamar a muchas herramientas en rápida sucesión. Señalan que un único token de sesión evita la sobrecarga de obtener y validar un nuevo token para cada llamada. Sin embargo, la contrapartida es una exposición drásticamente mayor al uso indebido. Los servicios modernos de validación de tokens están diseñados para operar en microsegundos, y el viaje de ida y vuelta adicional de la red puede agruparse o almacenarse en caché sin sacrificar el principio de mínimo privilegio. En entornos donde la integridad de los datos y el cumplimiento normativo no son negociables, el modesto coste de rendimiento se ve compensado por la reducción del riesgo.

Qué observar a continuación

  • Adopción de tokens con alcance (scoped tokens) en los SDK de IA – Esté atento a las actualizaciones de los principales kits de herramientas de plataformas de IA; muchos están empezando a exponer funciones auxiliares para alcances basados en OAuth.
  • Marcos de trabajo de política como código (Policy-as-code) – Las soluciones emergentes permiten a los equipos declarar reglas de autorización en un archivo declarativo, aplicándolas automáticamente en tiempo de ejecución.
  • Registros de auditoría que muestran decisiones por acción – A medida que más plataformas registren cada comprobación de autorización, las organizaciones ganarán visibilidad sobre qué acciones de IA se están permitiendo o bloqueando, lo que informará futuros ajustes de políticas.

Conclusión

Tratar una sesión iniciada como un permiso para hacer cualquier cosa es una receta para consecuencias imprevistas. Al trasladar la decisión de autorización desde el momento del inicio de sesión a cada llamada individual a una herramienta —y aprovechando tokens de corta duración y con alcance limitado— las aplicaciones de IA pueden mantener la conveniencia de los agentes autónomos mientras protegen los datos, cumplen con las regulaciones y evitan percances costosos. Las líneas de código adicionales son un precio pequeño para un sistema que hace la pregunta correcta cada vez que se intenta una acción.