״Where״ Can They Go? Managing AI Permissions

GenAI has transformed how applications interact with data, blurring the lines of access control and requiring us to reassess our handling of AI permissions.

As AI identities can dynamically create workflows and traverse systems, they pose new challenges for permission management - making traditional methods such as whitelists, blacklists, or static access policies obsolete.

This article is the third installment in the series: “The Challenges of Generative AI in Identity and Access Management (IAM),” where we attempt to answer some major questions about AI identity security:

In my previous articles in the series, I’ve covered who is accessing our systems and what they’re attempting to do.

With these questions addressed, we turn to the next logical question: where are these identities allowed to go? Or, more specifically, which parts of our application are these identities trying to access?

In this article, we’ll explore modern approaches to controlling AI permissions, such as Retrieval-Augmented Generation (RAG) and dynamic authorization services. These solutions ensure AI systems remain secure while adapting to the flexibility and scale they demand.

The Free Reign of AI Identities

A few months ago, The Verge published an article highlighting how many prominent AI companies train models to ignore the robots.txt file on websites.

If you’re unfamiliar, robots.txt is a file placed in a website's root directory that tells search engines whether or not they are allowed to index the site. This file is useful for maintaining privacy, even for non-private applications. Many AI models training on the internet are directed to disregard this file - meaning they are accessing and consuming data from websites that explicitly block them.

This is just the tip of the access control iceberg—AI being trained on data its not supposed to have access to is a big enough problem already, but it doesn’t stop there.

While model training focuses on building AI capabilities by consuming data, AI agents apply these capabilities to perform tasks within systems. AI agents, especially those integrated into applications, can potentially access vast amounts of data. Due to their design, these agents might bypass traditional restrictions or inadvertently gain access to resources they shouldn’t.

Here are some steps we can take to avoid this:

Educating Ourselves on AI Access Control

Traditionally, when managing human and machine access, we’ve relied on blacklists or whitelists to regulate permissions. But with AI agents, reality has become far more flexible and complex. The first step in addressing this challenge is through education.

AI is not a black box or some form of sorcery—it’s a tool, albeit a powerful and complex one. Teams managing AI identities must understand how AI models operate, the potential risks of unrestricted access, and the importance of securing both the training and operational phases of AI models. With proper education, teams can take informed steps to control where AI agents are permitted to go, ensuring compliance with security and privacy policies.

Retrieval-Augmented Generation (RAG)

Another effective method that has gained popularity recently is Retrieval Augmented Generation (RAG). While RAG is not a tool, it’s a methodology that builds a pipeline to provide augmented, authorized data for large language models (LLM).

RAG enhances LLM outputs by combining two key steps: first, retrieving relevant information from a knowledge base and then using that information to augment the LLM's context for more accurate generation.

While RAG can work with traditional databases or document stores, vector databases are particularly powerful for this purpose because they can perform semantic similarity search, finding conceptually related information even when exact keywords don't match.

The "generation" part then involves the LLM synthesizing this retrieved-context with its pre-trained knowledge to produce relevant, factual responses grounded in your specific data.

Here’s a simplified explanation of how RAG works:

A user submits a query to an AI agent or application.
Instead of allowing the agent unrestricted access to all available data, the system first queries a database of authorized data.
The query is augmented with this filtered data before being passed to the AI for processing.
The AI’s response is validated to ensure it is based only on authorized sources.

Authorization checks in this context should happen at a crucial moment - after retrieving data from the vector database but before providing it to the LLM as context. This way, we maintain search efficiency by first finding all relevant information and later filtering out unauthorized data before it ever reaches the LLM. The LLM can only use and reveal information the user is authorized to see.

If, for instance, we have internal documents stored in a vector database, RAG can ensure the system retrieves only documents the user is authorized to access. This method prevents AI systems from inadvertently accessing or exposing unauthorized data.

Authorization Services

We can further extend this approach with authorization services:

A user submits a question via a LangChain application.
The application queries an authorization gateway connected to a vector database (e.g., storing internal documents).
An authorization service checks whether the user has access to the relevant documents. Relationship-based access control (ReBAC) is a particularly useful model in this case.
The system retrieves only the documents the user is authorized to access.
The model generates its response based solely on these authorized documents.

By combining semantic search with access controls, we ensure the LLM does not return answers based on unauthorized data. This approach separates concerns: the LLM engine can still function, but the underlying pipeline ensures it doesn’t access or return information it shouldn’t.

This also applies to model training. Most of us don’t train LLMs from scratch anymore, but we can inspect the data sources used for training. Ensuring the model is trained on authorized data and enforcing restrictions on the data it accesses or returns is critical for secure implementations.

These security checks and dynamic authorization models can be integrated by using Permit.io (A detailed step-by-step guide is available here), which provides the infrastructure needed to evaluate complex relationship chains in real-time. As your data scales and relationships grow more intricate, it can ensure each piece of information is accessible only to those with proper authorization.

You can try Permit.io’s free community tier to test how that works yourself.

Managing AI Permissions: Key Takeaways

It’s clear that the old methods of managing access—static whitelists and blacklists—are no longer sufficient. Instead, access must be dynamic, continuously monitored, and adaptable. Teams need to ensure that AI behavior is understood and secured during all phases of its lifecycle.

RAG can filter AI access to only authorized data sources, while dynamic authorization services with ReBAC support provide the necessary flexibility and control.

By addressing where AI agents are allowed to go, organizations can maintain secure operations while adapting to the challenges introduced by these advanced systems.

With this in mind, in my next article in the series, “The “When” - Dynamic AI Identity Security for a Changing Timeline,” we will turn to the final question: when should access be granted?

Until then, if you have questions or want to learn more about IAM, Join our Slack community, where hundreds of developers are building and implementing authorization.