AI and RBAC: Securely Managing Access in Generative AI Applications

The business problem in the intersection of AI and RBAC (Role-Based Access Control) pertains to controlling access to data used in generative AI applications. In essence, how do we maintain a balance between enhancing employees' collective knowledge and ensuring data security?

Understanding the Challenge

Generative AI applications require access to vast amounts of data. While this data is pivotal for the functioning of these applications, it's also essential to regulate who has access to this information.

A key question that arises is how to manage zero trust on data.

Applying RBAC in Generative AI

Implementing RBAC in generative AI involves creating a structured system where access to data is governed by the roles of individual users within an organization. Here's how we can apply RBAC to data used in generative AI:

1. Define User Roles:?Clearly define user roles within your organization. Each role should have specific permissions that determine the user's actions on the data.

2. Assign Roles and Permissions:?Assign roles to users based on their job functions. Permissions should be granular enough to control access at a detailed level.

3. Use RBAC Frameworks:?Leverage existing RBAC frameworks provided by platforms, which allow you to assign roles with designated privileges to users or groups.

4. Manage Access at Group and User Levels:?RBAC is additive, meaning a user's permissions are the sum of all permissions set at both the user and group levels.

5. Secure the AI Training Process:?Understand and secure the data flow within the AI training model.

6. Implement Access Control in Infrastructure:?Implement RBAC to assign specific roles to users at the infrastructure layer.

7. Continuous Monitoring and Adjustment:?Regularly review and adjust roles and permissions as necessary.

8. Ensure Explainability:?Work towards making AI models explainable.

9. Address Ethical and Privacy Concerns:?Consider ethical considerations like data privacy and algorithmic biases.

How to do Document RBAC

Document RBAC, sometimes referred to as row-level security, is a method for providing granular access control to sensitive documents. The process involves associating a sensitive document with a group identifier, which is then imported into a search index. When security filtering is enabled, users can only interact with data they can access in the knowledge base.

The steps involved in this process include:

- Assembling source documents with the required content

- Creating a field for the principal identifiers

- Pushing the documents to the search index for indexing

- Querying the index with the?search.in?filter function

Search Indexer

- In the search index, within the field collection, you need one field that contains the group or user identity, similar to the fictitious "security_id" field in the previous example.

- Custom Script uploading data to the index, including group ids that have the principal security IDs in string format

- Add a firewall rule to prevent any access other than API gateway. I recommend doing this on any indexer in the cloud

- How does this affect the application when permissions are removed? You have to custom-code the update to the search. There's also the risk of prompt injection protection in the search API that needs to be mitigated.

App API

- acquires users' authentication and authorization info, as part of that all the roles and their identifiers

- makes a request to the Search API while applying the security filter for the user in the index query,

??????????????? - example: group_ids/any(g:search.in(g, 'group_id1, group_id2,...')

- SECURITY CONCERN: if the app api doesn't provide the filter, it has full access to ALL data!!

API Management Gateway

- Use API management and policies to create a proxy API call that only allows connections to the Search API and prevents all connections to the search index directly.

- Add policies to reject any traffic without the security_id field info or if it is null

- allows for rate-limiting protections

I added the red line to represent the API management gateway and firewall to prevent access directly to the search API

I used the pictures and a huge amount of understanding from Matthew Gotteiner article.