Protección de canalizaciones de agentes/RAG con autorización detallada

Durante los últimos 3 años, el panorama de la inteligencia artificial ha experimentado una transformación masiva. Hemos pasado de modelos de lenguaje básicos a sistemas completamente Agentes de IA que pueda actuar en nuestro nombre en tan solo unos pocos años. La IA es la nueva palabra de moda en todas partes. Todos bromeamos al respecto, pero en realidad, ha tenido un auge increíble y es sumamente poderosa. Y, como pueden ver, la IA no es nueva. Ha estado presente desde hace tiempo, pero desde la introducción de los LLMs y la IA generativa en 2023, ha habido un repunte en su uso.

Si bien el potencial de productividad con la IA es enorme, existen problemas de seguridad que deben abordarse al trabajar con sistemas autónomos como los Agentes de IA. Unas políticas de acceso mal configuradas a los datos podrían hacer que la IA recupere documentos internos sensibles o exponga información confidencial. Por lo tanto, en este blog exploramos cómo los enfoques tradicionales de control de acceso se quedan cortos cuando los sistemas de IA necesitan permisos contextuales a nivel de documento a gran escala y velocidad. Y cubrimos cómo la Autorización de Grano Fino (FGA) proporciona una seguridad sólida para la Generación Aumentada por Recuperación (RAG) y los sistemas de IA agéntica. Así, aprenda a implementar modelos de permisos que protejan la información confidencial al tiempo que permiten que la IA acceda únicamente a los datos autorizados.

El panorama cambiante de la IA y las brechas de seguridad

Los agentes de IA realizan tareas para los humanos llamando a API, aprendiendo de los errores y, a veces, trabajando sin supervisión humana. Pero, por supuesto, existen riesgos asociados con este rápido crecimiento y uno de esos grandes riesgos es la seguridad. Hemos visto varios tuits y escuchado a muchas personas de la industria hablar sobre la importancia de la seguridad y la autenticación al aprovechar la IA y los agentes de IA. Actualmente, no existe un modelo universal para integrar la seguridad de la IA en las aplicaciones.

OWASP comenzó a definir el  Los 10 mejores para aplicaciones de LLM en 2023 como un esfuerzo impulsado por la comunidad para destacar y abordar problemas de seguridad específicos de las aplicaciones de IA, y aquí están los 10 puntos principales para 2025. Uno de ellos es la divulgación de información confidencial. Los agentes de IA pueden ser autónomos, por lo que, sin el manejo adecuado, podrían revelar información sensible o datos confidenciales de la empresa, y esto puede ocurrir como resultado de un ataque deliberado o por accidente.

La IA debe considerar los permisos de los usuarios al acceder a los datos. ¿Cómo garantizamos que un Agente no pueda modificar registros existentes o acceder a documentos restringidos a otros empleados en tiempo de ejecución?

La respuesta es con autorización. Nosotros necesitamos asegurarnos de que nuestra IA los sistemas solo muestran la información correcta al usuario correcto.

Por qué la autorización tradicional se queda corta

Control de acceso basado en roles: RBAC es la forma más común en que las personas implementan la autorización en sus aplicaciones y sitios web. Cuando usamos RBAC, verificamos los roles. Si al usuario se le ha asignado un determinado rol o no antes de tomar decisiones de acceso. Si tiene el rol, obtiene acceso; si no, recibe un error 403 Prohibido (Forbidden). La principal desventaja de RBAC es principalmente la escalabilidad. No escala bien cuando hay múltiples roles.

Control de acceso basado en atributos (ABAC): ABAC es un avance respecto al RBAC para un control de acceso detallado, lo que nos permite otorgar a algunos usuarios acceso a documentos individuales y a otros acceso a diferentes documentos.

Sin embargo, todavía se queda corto cuando el documento está en carpetas anidadas; tendrías que recuperar todas las carpetas de forma recursiva hacia arriba en la cadena. Cuando el usuario está en grupos anidados, debes hacer lo mismo. Y necesitas hacer todo esto para autorizar la solicitud.

Así que veamos una forma aún mejor de hacer autorización. Aquí es donde entra ReBAC (Control de Acceso Basado en Relaciones). ReBAC permite expresar reglas de autorización basadas en las relaciones que los usuarios y los objetos de un sistema tienen entre sí. Los servicios ReBAC utilizan su conocimiento de las relaciones entre las diferentes entidades del sistema para tomar una decisión de autorización. Lo bueno de ReBAC es que puede hacer tanto RBAC como ABAC dependiendo de cómo definas esas relaciones.

Autorización detallada: la capa faltante

Autorización de grano fino aplica dinámicamente las reglas de acceso en el nivel de recurso. En lugar de otorgar permisos generales, FGA determina en el momento de la consulta exactamente qué documentos tiene permitido ver un usuario.

FGA se trata de controlar quién puede hacer qué con qué tipo de recursos, hasta un nivel individual. En un escenario típico que muestra un sistema basado en roles, uno podría decir: “Los administradores pueden ver todo, pero los usuarios regulares solo pueden ver un subconjunto”. Pero en una aplicación del mundo real, especialmente una que maneja muchos documentos, esto podría no ser lo suficientemente flexible. Aquí es donde entra OpenFGA.

OpenFGA es un proyecto de código abierto alojado en la CNCF y mantenido por Okta. Se inspiró en el sistema Zanzibar de Google, que describe cómo se creó la autorización para todos los servicios de Google. OpenFGA aborda lo anterior permitiéndole definir relaciones de autorización. Las relaciones definidas en el modelo de autorización pueden ser directas o indirectas. En pocas palabras, las relaciones directas se asignan directamente entre un usuario y un objeto y se almacenan en una base de datos. Las relaciones indirectas son las relaciones que podemos inferir según los datos y el modelo de autorización.

Configurar OpenFGA ReBAC

Hay 4 conceptos principales sobre OpenFGA y cómo funciona:

1. Tienda Una tienda es una entidad de OpenFGA que se utiliza para organizar modelos de autorización y tuplas. Literalmente, donde almacenas tus datos
2. Modelo de autorización: Un modelo de autorización es donde defines quién puede hacer qué y bajo qué condiciones. Estas van a ser tus políticas de autorización expresadas en un modelo. En el modelo, tenemos que definir las entidades que van a ser relevantes al tomar decisiones de autorización.
3. Tuplas de relaciónUna tupla de relación es una tupla base o triplete que consiste en un usuario, una relación y un objeto. Puede pensar en las tuplas como los “hechos” de su sistema de autorización. Tenemos una forma de relación de usuario a objeto. Los datos presentes en las tuplas de relación definen esencialmente el estado de su sistema, y usted modifica las tuplas a medida que el estado de su sistema evoluciona.
4. Consultas: Por último, para usar esto para verificar la autorización, tenemos que ser capaces de consultar el sistema. Y lo que hace el sistema OpenFGA para responder a esta pregunta es recorrer el grafo. Así que el sistema FGA comienza en el recurso (el informe de gastos) y, de arriba a abajo, pregunta

En resumen, los datos en las tuplas de relación definen el grafo. El modelo de autorización define las reglas para recorrer el grafo. Y cuando consultas al sistema, la consulta recorre el grafo según las reglas y devuelve “Sí, estás autorizado” o “No, no lo estás” dependiendo del resultado.

Control de acceso basado en relaciones OpenFGA

SignificadoKate puede ver forecast.pdf porque es miembro del equipo de Finanzas, el cual tiene permisos de visualización sobre ese documento.

Implementación de FGA en una canalización de IA RAG

RAG es un marco de trabajo diseñado para superar las limitaciones de los LLM y proporcionar respuestas más precisas y detalladas. Aunque los LLM se entrenan con vastos conjuntos de datos, a menudo tienen dificultades con el conocimiento especializado, la información actualizada y la generación de resultados incorrectos de hecho, también conocidos como “alucinaciones”. RAG mitiga estos problemas mediante la recuperación dinámica de datos relevantes de fuentes externas en tiempo real.

En lugar de depender exclusivamente de conocimientos preentrenados, un sistema RAG recupera datos específicos de un dominio. Esto es excelente cuando los datos son públicos o se pueden compartir libremente. Pero, ¿qué hacer si algunos de esos datos son restringidos o confidenciales? Esto plantea un desafío importante: garantizar que cada usuario solo acceda a la información que está autorizado a ver. Un sistema RAG seguro necesita aplicar un control de acceso detallado sin sacrificar la velocidad o la escalabilidad. Los roles pueden cambiar, los proyectos pueden ser reasignados y los permisos pueden evolucionar con el tiempo. Manejar todo esto de manera eficiente es clave para construir una aplicación RAG verdaderamente segura y robusta.

Y aquí es exactamente donde entra OpenFGA. Al integrar OpenFGA con una canalización de RAG, podemos desacoplar la lógica de control de acceso de la aplicación RAG principal. Podemos aplicar modelos de autorización en tiempo real y garantizar que el contexto recuperado siempre se filtre según los permisos del usuario antes de ser enviado al LLM para generar una respuesta.

Al integrarse con una base de datos vectorial como Couchbase, existen dos estrategias principales para implementar OpenFGA para RAG:

1. Postfiltrado

• Recuperar documentos de Couchbase Vector Search
• Enviar resultados a OpenFGA para eliminar los documentos no autorizados
• Enviar resultados filtrados al modelo de IA

2. Pre-filtering

• Call OpenFGA to remove the unauthorized docs
• Add a pre filter for the vector search query to limit the search scope
• Only retrieve embeddings for documents the user can access

---

Example of FGA with RAG

Let’s say you as a developer want to use an AI-assistant to get the forecast of the company. The system must ensure you only see the public forecast data and not any private financial reports that are restricted to the Finance team. Without the right safeguards, this becomes a Sensitive Information Disclosure risk, exactly the kind of issue highlighted by the OWASP Top 10 for LLM applications.

Here’s how Fine-Grained Authorization (FGA) solves it:

Step 1 – Permissions Check: OpenFGA checks the access rights. If the access doesn’t belong to the Finance team, private financial documents are excluded.

Step 2 – Filtering: OpenFGA (via its SDK) filters out any results the user shouldn’t see.

Step 3 – Document Retrieval: Perform vector search with the applied filter to only retrieve documents permissible to be seen by the user.

Step 4 – Answer Generation: LLM generates a response only from the authorized subset of documents.

Real world applications

There are a lot of benefits to applying Fine-Grained Authorization in AI applications. Let’s explore some of the popular use cases:

• Multi-Tenant SaaS: One tenant’s AI queries never retrieve another tenant’s data
• Salud: Patient record retrieval that is restricted to only authorized practitioners
• Finanzas: Sensitive forecasts and regulatory data accessible only to relevant teams
• Legal: Case documents restricted based on client-attorney assignments

Final thoughts: security without sacrificing speed

Without the right security, you risk adding a whole new attack surface to your application with agentic AI. AI applications now handle sensitive user data and are not just processing the information; they are interacting with APIs, automating decisions, and acting on users’ behalf

The agents need to have least privileged access to user data, non-static access credentials, and fine grained access control. OpenFGA provides a way to secure AI in apps while also enabling the applications to scale hundreds of millions active users seamlessly as the agent ecosystem grows.

Thus, Fine-Grained Authorization, powered by OpenFGA and integrated with Couchbase Vector Search, ensures AI systems are both powerful and safe, thus delivering AI innovation without compromising security.