Autorización en aplicaciones con LLM

• Los modelos de lenguaje grandes (LLM) son sistemas impredecibles que procesan entradas inciertas de usuarios humanos, por lo que es indispensable aplicar el principio de mínimo privilegio (least privilege)
• A medida que los LLM se usan en la práctica para búsqueda interna, automatización y muchas otras tareas, deben operar solo con "permisos efectivos (effective permissions)" otorgados al mínimo necesario para evitar incidentes de seguridad y usos indebidos
• En una arquitectura RAG (Retrieval-Augmented Generation), los embeddings de datos y las verificaciones de permisos están separados de la fuente de datos, por lo que se necesita un control de acceso preciso a nivel de recurso
• Cuanto más aumentan los usos complejos como datos externos de terceros/RAG, agentes y MCP, más se vuelve un tema central de seguridad dónde y cómo se aplican realmente los permisos
• La autenticación basada en tokens, como OAuth, tiene límites para el control fino de permisos por recurso, por lo que la lógica real de autorización debe implementarse directamente en la capa de aplicación

---

Términos y conceptos básicos

• Prompt: solicitud del usuario enviada al LLM (instrucciones, preguntas, etc.)
• RAG (Retrieval-Augmented Generation): flujo de trabajo que adjunta datos adicionales al prompt para mejorar la precisión de la respuesta del LLM (por ejemplo, adjuntar automáticamente la lista de vacaciones de la empresa)
• Context: datos auxiliares adjuntos al prompt (como materiales relacionados recuperados)
• Embedding: representación vectorial numérica de un texto, usada para búsqueda y coincidencia de datos
• Agent: motor de ejecución basado en LLM que realiza acciones según el prompt (como invocación automática de herramientas)
• Tool: funcionalidad externa, como una API o aplicación, que el LLM puede invocar directamente
• Model Context Protocol (MCP): protocolo estándar propuesto por Anthropic para el acceso de herramientas por parte de LLM

Principios clave del modelo de autorización para LLM

• Golden Rule:

  El LLM debe operar solo con los permisos mínimos estrictamente necesarios para procesar la solicitud del usuario

• A los usuarios humanos se les puede tolerar cierto "exceso de privilegios por costumbre", pero los LLM son impredecibles, rápidos y pueden causar daños a gran escala cuando cometen errores.
  → Los "permisos efectivos (effective permissions)" del LLM deben limitarse a la intersección entre los permisos del usuario, del LLM y de la tarea

Cálculo de permisos efectivos (effective permissions)

• Permisos efectivos de una aplicación con LLM =
  1. permisos que tiene el LLM
  2. permisos que tiene el usuario
  3. permisos necesarios para la tarea solicitada
     La intersección de estos tres elementos
• El usuario "delega" su rol al LLM (chatbot, etc.) mediante impersonation,
  pero no se debe exceder el rango de permisos que tienen tanto el LLM como el usuario
• Se explica de forma intuitiva con un diagrama de Venn de permisos
  • La ejecución solo se permite cuando los permisos de la tarea están completamente contenidos en la intersección

RAG (Retrieval-Augmented Generation) y manejo de permisos

1. RAG con datos propios (1st Party)

• Ejemplo: un chatbot interno que encuentra en el código fuente de la empresa "archivos que contienen claves secretas"
• Embedding: todos los archivos se convierten en vectores y se guardan en una base de datos; el prompt también se convierte en vector para hacer matching por similitud
• Dónde aplicar los permisos:
  • Verificar de inmediato la organización propietaria real, el tipo, el repositorio y los permisos del usuario sobre el "archivo" devuelto como resultado de búsqueda
  • Confirmar si el usuario puede acceder a ese archivo (permiso a nivel de recurso)
  • Realizar la verificación de permisos en la capa de aplicación durante el proceso de vincular el embedding con los datos fuente
• Incluir la lógica de permisos dentro del propio LLM es inestable (por su naturaleza probabilística no se puede garantizar)
• Resumen:
  • La clave de RAG es aplicar de forma estricta los permisos por usuario y por recurso después de conectar el embedding con los datos originales

2. RAG con datos de terceros (3rd Party)

• Uso de embeddings de datos de APIs o sistemas externos (por ejemplo, wiki, sistema de tickets, etc.)
• Problema: el embedding y los datos originales existen en sistemas distintos → el lugar donde aplicar permisos se vuelve ambiguo
• Tres formas de manejar permisos
  1. Delegar los permisos al sistema externo (verificar los permisos reales en cada solicitud API individual; problemas de lentitud y rate limits)
  2. Sincronizar el ACL (lista de control de acceso) en la aplicación (alta exactitud y confiabilidad, pero aumenta el costo de gestión y sincronización del ACL)
  3. Reimplementar dentro del sistema la propia lógica de permisos externa (más carga de gestión y sincronización, y mayor complejidad lógica)
• Conclusión: según la situación real, es importante el trade-off entre el "lugar donde se aplican los permisos" y el método usado
  (hay que elegir entre rendimiento y simplicidad, costo operativo y precisión, etc.)

LLM basados en agentes (AI Agent) y permisos

• Ejemplo: un chatbot que realiza tareas automáticas de mantenimiento, como eliminar ramas de un repositorio o cerrar issues
• Con MCP (Model Context Protocol), se exponen herramientas (funciones/API) al LLM de forma estandarizada
• En cada solicitud de MCP se debe aplicar el modelo de permisos efectivos
  (intersección entre permisos del usuario, del agente y de la tarea)
• Límites de la autenticación basada en tokens, como OAuth
  • Aunque la información de permisos está incluida en el token, no cubre permisos en tiempo real a nivel de activo o recurso
  • En la práctica, solo parte de la información va en el token, y el resto requiere implementar lógica de autorización aparte en la capa de aplicación

Conclusión y resumen práctico

• En entornos de LLM/RAG/Agent, la clave de la gestión de permisos es elegir dónde y cómo aplicarlos

• A través del modelo de permisos efectivos, se restringe al LLM para que opere solo dentro de la intersección de "usuario + LLM + tarea"

• Los tokens de autenticación como OAuth deben usarse solo para identificar "quién hizo la solicitud",
  y la verificación real de permisos por recurso debe hacerse obligatoriamente en la aplicación

• Al integrarse con sistemas externos,
  1) delegar permisos (baja de rendimiento), 2) sincronizar ACL (complejidad operativa), 3) reimplementar la lógica de permisos (alto mantenimiento)
  requieren un diseño que considere distintos trade-offs

• Resumen final:

  El LLM debe operar solo dentro de los permisos mínimos estrictamente necesarios para procesar la solicitud del usuario,
  y los permisos efectivos (effective permissions) se definen como la intersección entre los permisos del LLM, del usuario y de la tarea
  La verificación real de permisos debe realizarse obligatoriamente por recurso, en la capa de aplicación