Secure IAM for AI driven LLM applications

The role of identity and access management (IAM) in LLM-enhanced applications

As large language models (LLMs) and generative AI continue to make headlines, the critical role of robust identity and access management (IAM) has become increasingly important across various contexts for businesses of all sizes. They must ensure that sensitive or proprietary data are not inadvertently exposed to unauthorized parties by LLM-enhanced applications.

One approach that some organizations are taking is to develop custom LLMs by training them on curated data, allowing the models to autonomously determine and enforce access restrictions. This approach comes with significant challenges. 

• Prohibitive costs: Developing a custom LLM capable of managing access control requires intense computational resources and data management, leading to high costs for any organization. This approach is best pursued only when the benefits clearly outweigh the hefty resource commitment.
• Unpredictability of LLMs: The natural unpredictability of some LLM models adds another layer of complexity. Although there are techniques to promote consistent responses, ensuring absolute consistency and accuracy is challenging. False positives in the IAM space can lead to granting unauthorized access to users, which is an unacceptable risk for many organizations. 

Considering these challenges, how can organizations effectively leverage the advanced capabilities brought through AI and LLMs while securing sensitive data and assets with well-managed access control? The next section introduces a reference architecture that keeps IAM firmly in the orchestration layer while letting the LLM focus solely on language tasks.

Reference architecture: augmenting traditional applications with LLM-specific components

One way to address this question is by introducing a multilayered reference architecture (Figure 1) designed to integrate LLMs into web applications.

• Web interface/presentation layer serves as the user interface and enables interaction with the application.
• Database/data layer is responsible for data processing, storage, management and retrieval of data kept locally in this application through traditional databases (DB), thus avoiding retrieval through HTTP calls. Ensuring data security at this layer involves encrypting data at rest and in transit, enforcing strict access controls and leveraging secure storage services within the cloud.
• Orchestration/business logic layer remains pivotal. It implements the business logic and handles requests from start to finish, coordinating the other layers and components to fulfill them. Most importantly, it verifies identities (aka authentication) and enforces access control. 

Authentication works similarly to any typical web application where the identity of a user is verified and confirmed using a range of credentials, including passwords or biometric characteristics. As part of this process, relevant user data is often fetched and stored as part of the session. These data commonly include the authenticated user ID, among other details, facilitating the access control required for upcoming requests. Access control is the key to ensure that a user, identified by their user ID, has appropriate access to relevant data before proceeding with their requests.

The key distinction from traditional architecture is the inclusion of components that augment the application with LLM capabilities, highlighted in the orange dotted rectangle in Figure 1 above. 

• Vector DB component enables efficient, vector-based searches for data stored locally within this application. It provides semantic search capability, which is well-suited for LLMs and is not supported by traditional DBs. 
• Assistant/functions calling component serves a dual purpose: (1) it supports LLMs in processing requests by providing metadata for function calls (typically HTTP calls to web services) and their arguments to integrate external data. And (2), it aids the orchestration layer in executing these calls upon identification of the required HTTP calls and their parameters.

LLMs are tasked with two primary functions related to natural language. The first is to act as a language processor, understanding a user’s request by identifying the necessary information to retrieve or the actions to execute. Initially, LLMs fetch a list of available functions and their schemas from the assistant/functions calling component. Using this information along with the user’s request, they create structured data, usually in JSON format, containing instructions about what functions to call with what parameters. 

This data is then passed to the orchestration layer, which relies on the assistant/functions calling component to execute the necessary function calls, typically HTTP requests to web services. For instance, in answering a “How many paid time off (PTO) days does John have left?” inquiry, LLMs leverage relevant functions and their metadata provided by the assistant/functions calling component. It then crafts a response, showing that an HTTP call of “get PTO balance by user ID” to PTO service is required, and determines the appropriate user ID to pass in. 

The second is to formulate responses to requests in human-understandable languages. Responses are based on information provided by the orchestration layer as a result of making HTTP calls. For example, after a PTO balance is obtained, the orchestration layer supplies this data to the LLMs, together with the same inquiry as “How many PTO days does John have left?”, LLMs would generate a coherent response in natural language, such as “John has 5 days of paid time off remaining.” This capacity of LLMs is commonly referred to as “retrieval-augmented generation” (RAG). RAG allows LLMs to generate responses with the most contextually relevant results that match the user’s query by providing them with relevant data alongside the question posted. 

With each component and its role now explained, the remaining question is: How does the orchestration layer continue to play an important role in enforcing IAM, with the integration of these LLM-specific components? We will explore this further through a hypothetical case study, building upon the PTO balance inquiries example explored earlier. 

Hypothetical use case example: enforcing effective IAM for LLM-powered PTO balance inquiry

The sequence diagram below (Figure 2) illustrates the steps involved in retrieving and presenting a PTO balance using the LLM component. Proper access control occurs at Steps 5 and 8, as indicated by the orange highlights in the diagram and descriptions below.

The following are descriptions of each step illustrated in Figure 2. 

1. Users sign in and interact with the application through a web interface powered by LLMs, asking questions like “How many PTO days does John have left?”
2. The web interface relays the inquiry to the application’s orchestration layer, which coordinates user request processing.
3. This layer then involves the component, providing the inquiry along with authenticated user information, particularly their user ID.
4. The LLM component identifies the need for a specific call to retrieve PTO balance information, including an HTTP call “get PTO balance by user ID” and one of its parameters as John’s user ID. (Note: We assume that the list of functions and their corresponding schemas have been pre-fetched from the assistant/functions calling component and cached locally to the LLM component. For simplicity of illustration, we use only one HTTP call for this workflow, “get PTO by user ID,” instead of another call to “retrieve John’s user ID” first.)
5. The orchestration layer conducts an access control check to confirm that the authenticated user has the right to access John’s PTO balance. For example, a possible check would be whether the requestor is John himself or his manager.
6. If the user is authorized, the process moves to the next step; otherwise, it halts with an error message. With successful access control verification, the orchestration layer requests the PTO balance via the assistant/functions calling component, which facilitates communication with external services.
7. The assistant/functions calling component makes a RESTful API call to the PTO service to obtain the balance given the specified user ID.
8. The PTO service performs its own access control to double-check that the requesting user has rightful access to John’s PTO data, and returns the balance upon successful verification.
9. The PTO balance is sent to the assistant/functions calling component.
10. This component then conveys the balance to the orchestration layer.
11. The orchestration layer passes the balance, together with the inquiry “How many PTO days does John have left?” to the LLM.
12. The LLM generates a response, such as “John has 5 days of paid time off remaining.” and returns it to the orchestration layer.
13. This response is forwarded to the web client/presentation layer.
14. The web client/presentation layer displays the response, providing the user with the requested PTO balance in a clear and understandable manner.

As highlighted in the previously described workflow, despite integrating LLMs, the roles of IAM persist unchanged from traditional web applications. These functions continue to be managed by both the orchestration layer and the corresponding web services. These components work together to filter out unauthorized data, before feeding them into LLMs, which would generate human-friendly responses with RAG capability. 

The prudent approach to achieving IAM is to use LLMs only for their language capabilities

There’s a critical balance organizations must strike when integrating LLMs into their digital ecosystems while also maintaining the indispensable role of robust IAM. Despite the transformative potential of LLMs to enhance user interactions, their application does not extend to identity and access control. A reference architecture that marries LLM-specific components with traditional web application structures demonstrates a strategic approach to leveraging LLMs’ capabilities while ensuring data security and compliance through the orchestration layer and the corresponding web services. This architecture, which positions LLMs only as sophisticated language processors and generators, not only enriches the user experience but also upholds the stringent IAM measures that are essential.