Latest / 1 More Paper / Permission-Aware RAG: Identity and Access Management (IAM)-Based Access Filtering in Multi-Resource Environments — Jeong & Lee (2025)
Transcript
- You’re listening to “Permission-Aware RAG: Identity and Access Management (IAM)-Based Access Filtering in Multi-Resource Environments,” by J. Jeong and S.-G. Lee. Published in 2025. Abstract. Retrieval-Augmented Generation (RAG) enhances large language models (LLMs) by integrating external knowledge sources, which significantly improves response accuracy and contextual relevance. However, most existing RAG research implicitly assumes that all retrieved content is equally accessible to any user. This approach fails to address the complex, fine-grained access control required in enterprise environments in which data originates from multiple, independently governed sources. Attempting to merge heterogeneous authorization models, such as RBAC and ABAC, often leads to significant compliance burdens and unintended data exposure. To address this issue, we propose a permission-aware RAG framework that enforces resource-level access control by directly interfacing with provider-controlled Identity and Access Management (IAM) systems. By performing real-time permission validation against native IAM endpoints without requiring policy merging, this design preserves governance boundaries and ensures compliance. We implemented a prototype and conducted a comprehensive evaluation using a multi-hop QA benchmark. The evaluation included scenario-based qualitative analysis to verify policy enforcement, large-scale quantitative validation that confirms its scalable policy enforcement and quantifies the impact of access levels on answer quality. Results demonstrate that our framework provides secure, scalable information retrieval while maintaining strict adherence to diverse access policies across multi-resource environments. Introduction. Large Language Models (LLMs) have demonstrated remark-able capabilities in a wide range of natural language tasks, leading to significant advances in AI applications. How-ever, when deployed in domain-specific or high-stakes envi-ronments, LLMs face notable limitations, including in fields such as healthcare,, law, and finance. In partic-ular, LLMs lack access to up-to-date or institution-specific knowledge at inference time, undermining their reliabil-ity and effectiveness for critical decision-making. To The associate editor coordinating the review of this manuscript and approving it for publication was Sedat Akleylek. mitigate this gap, Retrieval-Augmented Generation (RAG) has emerged as a promising approach that enhances LLMs by injecting relevant external documents retrieved from structured or unstructured knowledge sources directly into the generation pipeline. Most existing RAG research implicitly assumes a uniform access model, where all retrieved content is equally accessible to any user of the system. This implicit-trust approach is fundamentally incompatible with the modern principles of a Zero Trust Architecture (ZTA), which mandate fine-grained, per-resource authorization based on the principle of least privilege. This assumption fails to address the access control challenges that arise in multi-organizational or multi-service environments, where data originates from sources governed by distinct identity and policy frameworks. As a result, these systems fall short in addressing real-world scenarios where fine-grained, user-specific authorization is required to ensure privacy, security, and regulatory compliance. As illustrated in Fig. 1, the same query can produce different responses depending on the user’s access level. For example, public users may be limited to viewing basic prod-uct specifications and publicly available reviews, whereas authorized employees might retrieve confidential internal reports or proprietary analyses. This scenario highlights the necessity for enforcing user-specific access control in RAG systems, especially in multi-source environments where the sensitivity and ownership of data vary across sources. Current RAG architectures lack mechanisms necessary for fine-grained, context-aware access control. When a centralized vector database aggregates documents from multiple data providers, applying a unified access policy across all content becomes both operationally complex and legally impractical. Centralized attempts to merge policies often result in permission escalation, ambiguous policy interpretation, and significant compliance overhead. Fur-thermore, integrating heterogeneous access control models, such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), into a single enforcement layer can introduce semantic inconsistencies and lead to unintended data leakage. To address these challenges, we propose a Permission-Aware RAG framework that enables fine-grained access control across multi-resource environments. Our approach preserves centralized retrieval efficiency while delegating access control to Identity and Access Management (IAM) systems operated by each provider. Instead of attempting to merge or reinterpret access policies, the framework dynamically verifies document-level permissions at query time by interfacing with native IAM endpoints such as Google Cloud Platform (GCP) IAM, Amazon Web Services (AWS) IAM, or open-source Keycloak. By leveraging existing IAM infrastructures that are already trusted and maintained by each organization, our approach ensures policy consistency and practical deployability. This decen-tralized control model reduces legal risks, respects policy autonomy, and ensures compatibility with diverse security architectures. The key contributions of this paper are as follows: • We propose a novel RAG framework that supports permission-aware retrieval across multi-resource envi-ronments by enabling fine-grained access control across heterogeneous policy domains. • We implemented a prototype integrated with GCP, AWS, and Keycloak IAM, validating the feasibility of our approach in real-world environments. • We validate the framework through three evaluations on the HotpotQA dataset: (i) scenario-based qualitative evaluation, (ii) large-scale quantitative evaluation, and (iii) latency impact evaluation. II. RELATED WORK. A. ACCESS CONTROL NEEDS IN RAG SYSTEMS RAG systems are increasingly used in multi-resource envi-ronments where knowledge is distributed across diverse data sources. For example, in many enterprises, data resources are distributed across multiple departments, services, and infras-tructure environments. In healthcare organizations, patient records may be stored separately within hospitals, clinics, and research labs due to privacy policies, organizational boundaries, and system silos. In finance, investment reports, client data, and regulatory documents are often managed using different cloud providers, on-premise servers, or SaaS platforms depending on departmental budgets, policies, and compliance requirements. Such fragmented environments make centralized data integration challenging and result in complex multi-resource settings that RAG systems must operate within. Each data source is governed by its own access con-trol policies and regulatory requirements. Healthcare data must comply with HIPAA, GDPR, and local privacy laws. Financial data is subject to strict industry-specific regulations, and government documents often require strict security clearances. Furthermore, these policies are implemented using heterogeneous models such as RBAC or ABAC, making unified enforcement complex. Without aligning retrieval processes with these diverse policies, RAG systems risk unauthorized disclosure, policy conflicts, and regulatory violations. Therefore, RAG systems require fine-grained (resource-specific), user-specific, and real-time access validation mech-anisms. However, existing RAG frameworks lack built-in capabilities to perform such dynamic authorization at query time. The need for such mechanisms has been formally recognized in recent security analyses of RAG systems. For instance, a systematic review by Ammann et al. identifies Retrieval Data Leakage as a primary threat and proposes Access Limitation as a critical mitigation strategy. This underscores the academic and practical importance of developing robust access control frameworks specifically for RAG. Therefore, a central challenge in RAG security research is to determine how to effectively implement this Access Limitation in complex, real-world enterprise environments. B. REPRESENTATIVE APPROACHES TO INTEGRATED ACCESS CONTROL Prior research has proposed multiple strategies for integrating access control into RAG systems. As illustrated in Fig. 2, these approaches can be broadly categorized into centralized and distributed architectures, depending on how documents are stored and policies enforced. Centralized frameworks consolidate documents from various sources into a single vector database and apply internal filtering mechanisms. For example, Chen et al. proposed a proof-of-concept implementation that maintains a centralized vector database alongside an internal permission store. A more structured centralized approach is seen in VAULT, which models access control rules directly within a Knowledge Graph. However, this model necessitates a complex and continuous synchronization of its internal node-level access attributes with the original IAM systems, creating a significant challenge for maintaining real-time pol-icy consistency, especially in heterogeneous environments. While these different architectures enable streamlined management within a single policy domain, they share a critical limitation: they require merging diverse access control models, such as RBAC and ABAC, into a unified enforcement layer. This process is not only operationally burdensome but also introduces semantic mismatches and risks of unintended data leakage or privilege escalation due to flawed policy mapping. Distributed frameworks, by contrast, maintain policy autonomy by enforcing access control within each data provider’s environment. For instance, MediRAG imple-ments a federated retrieval system across hospitals, using policy-based access control (PBAC) at each node to ensure that organizations can independently define and enforce policies. This architecture preserves data sovereignty and aligns well with compliance requirements in sensi-tive domains like healthcare. However, MediRAG assumes that all nodes adopt a uniform PBAC model, which is often unrealistic. Real-world enterprises frequently employ heterogeneous IAM systems such as GCP IAM, AWS IAM, or Keycloak, each with its own authentication workflows, policy languages, and role hierarchies. Requiring standard-ization across such diverse systems introduces substantial adoption barriers. Furthermore, MediRAG lacks integration with these native IAM systems, making centralized governance and cross-domain identity management difficult to scale. We address this gap by delegating authorization to each provider’s native IAM at retrieval time, rather than consolidating policy management. In environments where heterogeneous access control models such as RBAC, ABAC, and custom policies coexist across administrative domains, requiring centralized policy consolidation becomes highly impractical. Centralized RAG architectures struggle with the complexity and risk of merging diverse policies, while distributed frameworks often rely on a unified access control model that does not reflect real-world diversity. These limitations underscore the need for an alternative approach that can respect policy autonomy while still enabling efficient retrieval. To this end, we propose Permission-Aware RAG, a framework that supports fine-grained access control through real-time permission validation by directly interfacing with native IAM systems. This design enables secure and scalable retrieval across heterogeneous multi-resource environments without requiring structural reconfiguration. C. FEDERATED IDENTITY AND ZERO TRUST ARCHITECTURES While Federated Identity Management (Federated IAM) provides the foundational layer for authentication in multi-service environments, recent surveys highlight persistent challenges such as privacy risks, attribute aggregation, and revocation. Privacy-preserving extensions like PRIMA enable selective disclosure and unlinkability between identity providers (IdPs) and service providers (SPs). Reference models such as the Reference Service Model Framework for Identity Management attempt to standardize identity management architectures across centralized, feder-ated, and user-centric models. However, none of these approaches address the subsequent, more granular challenge of real-time, per-document authorization within retrieval-augmented systems. Our Permission-Aware RAG framework is designed to solve precisely this challenge. It operates on the principles of a Zero Trust Architecture (ZTA), which mandates continuous verification for every access request. While Federated IAM establishes who the user is, our framework determines what that authenticated user is allowed to see at the moment of retrieval. By delegating this check to native IAM systems, we enforce ZTA’s least privilege principle for every retrieved resource, bridging a critical gap between fed-erated authentication and practical, secure, access-controlled retrieval in modern enterprise environments. This approach is also compatible with existing enterprise Single Sign-On (SSO) mechanisms, as it leverages the same IAM endpoints used for federated authentication. III. METHODOLOGY. A. MOTIVATION FOR IAM-BASED INTEGRATION Modern enterprises use IAM systems such as AWS IAM, GCP IAM, Azure Active Directory (Azure AD), and Keycloak to manage fine-grained access control across their resources. These systems provide authentication, autho-rization, RBAC/ABAC policy support, audit logging, and version-controlled policy management to ensure security and regulatory compliance. For example, depending on service requirements, resources may be deployed across GCP, AWS, or on-premise environments. Organizational policies may mandate that certain data be processed exclusively on-premise for compliance reasons, while other services leverage cloud-based solutions. Although consolidating diverse access control policies into a single, unified policy across all services and organizations may be considered ideal, achieving such integration in practice requires extensive legal reviews, cross-institutional policy reconciliations, and thorough conflict analysis across heterogeneous access models. These processes, such as policy mapping and role harmonization, are time-consuming and operationally burdensome, often delaying the deploy-ment of Retrieval-Augmented Generation (RAG) systems that require timely integration with external knowledge sources. To address this challenge, our framework integrates RAG systems with existing IAM infrastructures, enabling real-time access validation without requiring full policy unification. This design maintains the independent policy governance of each organization while ensuring compliance, operational feasibility, and immediate deployability. By leveraging the trusted IAM endpoints operated by each provider, the system maintains consistency with institutional policy structures (e.g., RBAC, ABAC, resource policies) and prevents seman-tic mismatches. It also integrates seamlessly with native IAM functionalities such as audit logging, policy evaluation, and token validation, thereby minimizing legal and compliance risks in multi-resource environments. B. THREAT MODEL Our framework’s security model is grounded in the Zero Trust Architecture (ZTA) principle of never trust, always verify, treating every document access request as a distinct transaction that requires explicit authorization. Based on this, we use the STRIDE model to define our scope. • Information Disclosure (In Scope): This is the primary threat our framework prevents. Conventional RAG systems implicitly trust any retrieved document, creating a significant risk of leaking sensitive information. Our framework mitigates this by enforcing real-time, per-document authorization against native IAMs. • Elevation of Privilege (In Scope): We address unin-tentional privilege escalation at the data access layer. By delegating authorization checks to the authoritative source (the native IAM), our framework prevents flawed logic, such as faulty policy merging, from granting users access to data beyond their intended scope. • Spoofing, Tampering, Repudiation, and Denial of Service (Out of Scope): Our framework focuses specifically on authorization and assumes other foun-dational security layers are in place. We assume user identity verification (spoofing) is handled by upstream authentication systems (e.g., SSO). Threats to data integrity (tampering), auditability (repudiation), and service availability (denial of service) are considered out of scope, to be addressed by underlying infrastructure security. C. SYSTEM ARCHITECTURE The Permission-Aware RAG framework is designed to enable access control across multi-resource environments without requiring central policy merging. As illustrated in Fig. 3, the architecture’s modular pipeline is centered around the Permission Retriever, which utilizes a Credential Manager and an IAM Adapter to filter documents retrieved from the Vector Store, using details from the Metadata Store. This design ensures both maintainability and scalability. Each module addresses specific operational needs. For example, by separating the Credential Manager from the IAM Adapter, security credentials can be managed and updated independently of permission validation logic, ensuring flexi-bility and security. To enforce user-specific access rights, document permis-sions are delegated to the IAM systems operated by each service provider. This design preserves the independent policy governance of each organization while enabling real-time authorization checks without requiring unified policy consolidation. By avoiding the need to merge policies, the framework mitigates risks of semantic conflicts and ensures compatibility with heterogeneous access control models deployed by different institutions. The system operates in two primary stages: the Indexing Stage and the Query Stage, described below. 1) INDEXING STAGE. • (a) Data are collected from each service or organization and sent to the Data Ingestion Manager. • (b) The Data Ingestion Manager assigns a globally unique resourceID to each resource, serving as a persistent identifier linking document chunks to their provider and IAM information, while also enabling efficient metadata updates and deletions when resource information changes over time. • (c) Document chunks, their corresponding embeddings, and the associated resourceID are stored in the vec-tor store as vectormeta, referring to embedding records coupled with resource metadata for downstream retrieval and filtering. This indexing stage normalizes and stores all metadata and embedding information required for retrieval and access control. Its successful execution determines real-time search speed and validation efficiency in the subsequent query stage, enabling fast and accurate Permission-Aware RAG responses even in large-scale environments containing millions of documents. 2) QUERY STAGE. • The user submits a query, which is encoded via an embedding model. • The vector store is searched to identify semantically relevant documents. • The top-k relevant documents are passed to the Permission Retriever module. • For each document, the resourceID stored in vectormeta is used to retrieve its IAM metadata from the Metadata Store. • The Credential Manager retrieves necessary creden-tials required for authorization checks. • The IAM Adapter receives permission requests for relevant documents and concurrently verifies them with IAM services. It then returns the validation results, enabling the system to filter out unauthorized documents. • Filtered authorized documents and the user query are passed to the LLM to generate the final answer. The architecture is designed to support horizontal scaling of the Permission Retriever and IAM Adapter modules, which is expected to handle high query volumes with minimal performance degradation. By delegating access validation to native IAM systems rather than consolidating policy management, the framework mitigates risks such as per-mission misconfiguration (incorrect access settings granting unintended permissions), policy drift (gradual divergence between intended and actual policies over time), and privilege escalation (users gaining higher privileges than originally authorized). This decentralized validation model ensures that each data provider retains full control over resource access decisions, aligning with security and compliance requirements. D. CORE MODULES 1) DATA INGESTION. To provide a scalable and reliable entry point for all external resources, the Data Ingestion module is responsible for collecting and ingesting resources from diverse data sources into the Permission-Aware RAG framework. Each ingested resource is assigned a globally unique identifier called resourceID, generated as a UUID, ensuring persistent and collision-free identification across the system. Simultane-ously, the module stores the original data source identifier as localresourceid, which references the resource’s native identifier within its originating platform or repository. This dual-identifier design significantly enhances trace-ability by maintaining both a system-wide unique ref-erence (resourceID) and the source-specific identifier (localresourceid). Such structure enables reliable CRUD operations, ensuring that modifications or deletions can be efficiently propagated back to the original data source while preserving consistent mappings within the RAG system. The detailed metadata schema for each resource, including provider-specific parameters required for permission valida-tion, is provided in Appendix A. A key design principle is the decoupling of static vector embeddings from dynamic metadata. The vector store holds embeddings linked by resourceID for rapid retrieval, while the metadata store contains information prone to operational changes, such as file names and storage locations. This separation is crucial for maintainability and efficiency, as it allows metadata to be updated independently without the costly re-indexing of vector embeddings. In summary, the Data Ingestion module combines a dual-identifier mechanism for robust traceability with a decoupled storage architecture for operational efficiency. This approach provides a scalable and maintainable founda-tion, ensuring that permission-aware retrieval can function effectively in complex, dynamic enterprise environments. 2) CREDENTIAL MANAGER. The Credential Manager module serves as an orches-tration gateway for obtaining, managing, and providing service-specific credentials required for authorization checks across heterogeneous platforms such as GCP, AWS, and Keycloak. Its primary purpose in production environments is to integrate with external Identity Providers (IdPs) such as Active Directory, Okta, or enterprise Single Sign-On (SSO) solutions, leveraging authentication and authoriza-tion protocols including Security Assertion Markup Lan-guage (SAML), OAuth2, and OpenID Connect (OIDC). Through these integrations, it dynamically retrieves and refreshes tokens to enable seamless, compliant, and auditable access to resources. In this experimental implementation, however, the Cre-dential Manager replaces dynamic token retrieval with direct storage and lookup of static credentials, such as pre-generated service account keys or access keys, to simplify deployment and facilitate reproducible evaluation of permission-aware retrieval workflows. For example, GCP uses pre-generated service account keys, AWS uses access key ID and secret access key pairs, and Keycloak-based local services store client credentials in a static form. While this approach does not reflect production-scale orchestration, it simplifies the credential retrieval logic for evaluating the core permission validation functionality of the framework. To optimize performance and reduce redundant authoriza-tion requests, the framework employs an internal caching mechanism for credentials with a time-to-live (TTL) config-uration. This TTL-based caching ensures that credentials are reused within their validity window, while expired tokens are automatically refreshed to enforce security policies such as key rotation requirements. In summary, while the experimental Credential Manager uses static credentials for simplicity, its modular design anticipates integration with dynamic, secure, and compliant credential orchestration mechanisms in production environ-ments. To further clarify this production-grade integration, we detail the complete dynamic credential orchestration workflow, which integrates with enterprise SSO systems, in Appendix B. 3) IAM ADAPTER. The IAM Adapter module is responsible for validating user access permissions for each retrieved document. It lever-ages platform-specific SDKs to communicate with the native IAM service of the document’s provider (e.g., GCP, AWS, or Keycloak). To prevent access validation from becoming a performance bottleneck, the adapter employs a multithreading-based architecture to execute these I/O-bound permission checks in parallel. The adapter’s modular design and specific implementation details are further described in Appendix C. Overall, the IAM Adapter provides a robust and extensible solution for validating user access permissions across heterogeneous services. IV. EXPERIMENTAL SETUP. A. EXPERIMENTAL OVERVIEW The primary objective of this experimental evaluation is to assess whether the proposed Permission-Aware RAG frame-work can accurately and effectively enforce document-level access control in realistic, heterogeneous multi-resource environments without requiring centralized policy merging. To achieve this, three distinct experiments were designed: a scenario-based qualitative evaluation to analyze the correct application of access control rules in realistic user-policy-resource combinations across GCP, AWS, and Keycloak; a large-scale quantitative evaluation to measure permission filtering scalability and its resulting impact on answer quality; and a latency evaluation to measure the performance overhead of real-time permission validation by varying retrieval volume and concurrency. All experiments were conducted on a server equipped with an Intel Xeon Gold 6230 CPU, 754GB of RAM, and three NVIDIA Tesla V100 GPUs. The experiments were conducted using the HotpotQA dataset, selected for its multi-hop questions that require retrieving information from multiple documents, simulating complex enterprise environments. Document contexts were encoded using the all-MiniLM-L6-v2 Sentence Transformer model into 384-dimensional embeddings and stored in a centralized FAISS-based vector store. For final answer generation, the gpt-4o-mini model served as the LLM backend. To simulate a multi-cloud environment and ensure consistent network conditions, cloud resources were hosted in GCP’s asia-northeast3 and AWS’s ap-northeast-2 regions. B. DATASET PREPARATION For this study, we used the HotpotQA dataset as the primary data source, given its wide adoption for evaluating multi-hop question answering systems. Specifically, we uti-lized the development set (distractor setting), which contains 13,783 unique supporting fact documents corresponding to 7,405 multi-hop questions, as the core corpus for our experiments. HotpotQA consists of Wikipedia-based articles containing multi-hop questions that require retrieving and reasoning over multiple documents, making it suitable for evaluating document-level retrieval and permission filtering in the proposed framework. In particular, since each question requires integrating information distributed across different documents, it effectively simulates realistic enterprise envi-ronments where resources are distributed across multiple services, the central RAG retrieves them, and each service’s IAM system is used for real-time permission validation before integration. This characteristic provides a strong basis for evaluating the framework’s ability to handle document-level retrieval and access filtering in complex multi-service settings. 1) DATA SELECTION AND FILTERING. We selected a subset of HotpotQA focusing on three main domains: films, music, and people. Questions and their associated supporting facts were filtered to ensure coverage across these domains. Here, supporting facts refer to the core evidence sentences within the original documents that are essential for inferring the answer to each question. The selection also aimed to simulate realistic multi-service enterprise scenarios, where different document types are managed by distinct services with separate IAM systems (e.g., film data in GCP, music data in AWS, and people data in Keycloak). 2) PREPROCESSING AND EMBEDDING UNIT. CONFIGURATION The original contexts in the HotpotQA dataset are structured as a list of self-contained sentences or short paragraphs for each document title. Recognizing that these are already mean-ingful units of information, this study utilized them directly as individual embedding units. Therefore, instead of applying an additional, arbitrary chunking process, we leveraged the dataset’s inherent structure. This approach avoids the risk of semantic loss from artificial splitting and preserves the original context of each sentence. C. QUALITATIVE EVALUATION: SCENARIO-BASED SETUP A scenario-based qualitative evaluation verifies the frame-work’s fine-grained, document-level enforcement under realistic, enterprise-like multi-service conditions and con-trasts its behavior across heterogeneous services with a centralized-policy control group, thereby highlighting the robustness and advantages of the delegated IAM approach. Fig. 4 illustrates the scenario-based qualitative evaluation setup. 1) ENVIRONMENT CONFIGURATION. Three distinct services were configured to simulate a heterogeneous organizational environment: • Film Service (GCP IAM / RBAC): Film documents governed by RBAC roles (e.g., Film Producer / full, Film Intern / partial) • Music Service (AWS IAM / ABAC): Music documents controlled by ABAC using user attributes such as region and tier. • People Service (Keycloak IAM / RBAC): People documents managed on an on-premise Keycloak server with RBAC roles (e.g., Talent Agent, NoAccess). For the qualitative evaluation, a scenario-based subset of 20 multi-hop questions was sampled from HotpotQA. Each question requires at least two supporting documents, and the set spans all three domains (Film, Music, People). To reflect realistic enterprise boundaries, Film documents were stored in GCP, Music documents in AWS, and People documents in an on-premise service managed by Keycloak. The complete list of questions is provided in Appendix D. Policy-filtering correctness across heterogeneous IAM settings was evaluated using this scenario configuration. 2) USER PROFILES. Table 1 summarizes thirteen user configurations. The Admin user has unrestricted access to all services and serves as the upper bound for permission coverage and filtering correctness. Single-service users (F1, F2 for Film, M1, M2, M3 for Music, P1, P2 for People) represent typical enterprise roles or attributes confined to a single domain. Multi-service users (FM, FP, MP) combine heterogeneous IAM models across two domains, allowing us to verify that cross-service policy enforcement remains consistent. Control Group (CG) models a policy-merging scenario that would arise in the absence of our framework. An administra-tor consolidates heterogeneous rules into a single RBAC role named Media Reviewer, intending to replicate the FM user’s privileges. Those privileges combine the Film service’s Film Producer role with the Music service’s ABAC conditions country=US and tier=premium. During the manual process of consolidating heterogeneous policies into a single RBAC role, the country=US attribute is inadvertently omitted, leaving only tier=premium. As a result, the Media Reviewer role grants access to all premium-tier Music documents regardless of country, expanding its scope beyond the intended FM policy and creating a cross-region data-leakage risk. CG therefore exposes the vulnerability of manual policy merging and serves as the control group for comparison with our distributed verification framework. 3) EVALUATION PROCEDURE. To qualitatively assess the accuracy of document-level access filtering, each of the 13 user profiles was given a set of 20 multi-hop questions. For each query, the framework retrieved the top-5 relevant documents from the centralized vector store, then validated each document against the provider’s IAM (GCP, AWS, Keycloak). Using the expected allow/deny decision from the user’s assigned policy as the ground truth, we compared it with the actual filtering result to verify whether unauthorized documents were consistently excluded and authorized ones correctly passed. We refer to this agreement as Match, which is formally defined in. D. QUANTITATIVE EVALUATION: LARGE-SCALE SETUP This large-scale quantitative evaluation was designed to verify two key objectives for the proposed Permission-Aware RAG framework. First, it confirms that the framework oper-ates stably and accurately enforces document-level access control according to heterogeneous IAM policies in a large-scale, multi-cloud environment that simulates real-world operating conditions. This is essential for demonstrating the system’s security robustness and operational reliability. Second, it quantitatively analyzes the impact of strict access control on final answer quality. To this end, we measure the correlation between a user’s permission scope (Permission Coverage) and answer accuracy (EM and F1 Score) to clearly define the inherent trade-off between security and answer quality. An overview of the experimental environment is shown in Fig. 5. 1) USER ENVIRONMENT AND DOCUMENT DISTRIBUTION. For our experiments, we used the 13,783 unique supporting fact documents, corresponding to 7,405 questions, from the HotpotQA development set (distractor setting). These documents were evenly distributed across Google Cloud Platform (GCP), which enforced Role-Based Access Control (RBAC) policies, and Amazon Web Services (AWS), which enforced Attribute-Based Access Control (ABAC) policies. Within each environment, we configured five distinct buckets and randomly assigned the documents to them. In the GCP environment, each bucket was bound to a unique IAM role (Role 1–5), while in the AWS environment, each bucket was associated with specific combinations of predefined attributes (e.g., Attribute A, B, C). We also defined eight user profiles with varying levels of access to simulate diverse permission scopes, including a baseline admin user with full access. The remaining users were configured with scoped roles and attribute combi-nations to reflect restricted access patterns. The detailed configurations for both the resource access requirements and the user profiles are provided in Appendix E. 2) EVALUATION PROCEDURE AND METRICS. With the GCP (RBAC) and AWS (ABAC) environments fully configured, we evaluated the system using 1,000 randomly sampled questions from the HotpotQA development set of 7,405 questions. For each query, the vector retriever selected semantically relevant documents using a fixed top-k retrieval with k = 5. These documents were filtered through real-time IAM validation. Only the authorized subset was passed to the LLM for answer generation. Permission Coverage (PermCov) quantifies the proportion of all retrieved documents that a user is actually authorized to access, as formally defined in: This metric indicates how restrictive a user’s effective permission scope is: lower values mean the user can view only a small portion of the retrieved set (i.e., most retrieved documents are inaccessible). In other words, PermCov measures how many unauthorized documents are mixed into retrieval results and thus highlights the necessity of permission-aware document access in RAG systems. Match indicates whether the system’s IAM enforcement exactly agrees with the user’s true permissions for all retrieved documents, which is formally defined in. This was verified programmatically using the following procedure: • Ground-Truth Generation: For each user profile, we established a ground-truth by pre-generating a definitive list of all documents they were permitted to access. • Verification: The set of documents the framework deemed accessible for a given query was compared against the ground-truth list. Any document incorrectly included in the results was a False Positive (FP), and any document from the ground-truth list that was incorrectly excluded was a False Negative (FN). (PASS, if (FP + FN) = 0 Match = FAIL, otherwise where FP and FN denote false positives and false negatives in permission checks, respectively. Following standard QA evaluation practice, we use Exact Match (EM) and F1 Score to evaluate the final answer quality. EM checks if the model’s predicted answer exactly matches the ground-truth, while F1 computes the token-level overlap. In addition, we introduce a supplemental metric, EM@Admin, which measures the Exact Match score only over the subset of questions that the admin user answered correctly. This metric captures the performance degradation attributable solely to permission filtering, isolating the impact of restricted access from cases where the question is inherently unanswerable even with full access. By comparing EM and EM@Admin, we can assess how much access control affects the ability to answer questions that are, in principle, answerable. This evaluation verifies the system’s ability to precisely enforce document-level access control while maintaining answer quality. By comparing EM and F1 scores across users with different permission scopes, we analyze the trade-offs between secure filtering and QA accuracy. E. LATENCY EVALUATION: IMPACT OF PERMISSION RETRIEVAL AND CONCURRENCY This experiment was designed to evaluate the latency overhead introduced by real-time permission retrieval in the Permission-Aware RAG framework. In multi-cloud environ-ments where each retrieved document requires validation against its native IAM system, permission checks can become a performance bottleneck. This evaluation aims to measure how such latency scales with increased number of retrieved documents and concurrency. To accurately measure the raw overhead of each real-time API call, this evaluation bypassed any caching of the permission check results (i.e., the allow/deny decisions). Such a mechanism, which would typically be managed with a Time-to-Live (TTL), was disabled to ensure every check was validated externally. 1) OBJECTIVE AND METRICS. The primary objective is to assess how the permission validation process affects system responsiveness. We focus on three latency dimensions: • IAM Latency: Time taken to complete permission checks for all top-k retrieved documents via IAM APIs. Measured from the start of validation until all responses are returned. • End-to-End (E2E) Latency: Total processing time from query submission to final LLM response. • GCP Latency: Average API response time for permis-sion checks from GCP IAM. • AWS Latency: Average API response time for permis-sion checks from AWS IAM. 2) EXPERIMENTAL DESIGN. To measure the system’s latency under varying permission retrieval loads, we conducted two sets of experiments using an admin-level user with full access to all documents. Both experiments were conducted under the same setup as the quantitative evaluation and were run on 50 queries sampled from the HotpotQA dev set. Top-k Variation. We fixed the number of concurrent permission threads to 20 and varied the number of retrieved documents per query (top-k) from 1 to 20. This setup evaluates the cost of permission checking as more documents are validated. Worker Concurrency Variation. We fixed top-k at 10 and varied the number of permission-checking threads (max-workers) from 1 to 20. This experiment measures the scalability of parallel permission validation and its impact on latency. V. EVALUATION. This section presents a comprehensive evaluation of the Permission-Aware RAG framework through three distinct experiments: a qualitative analysis, a large-scale quantitative analysis, and a latency evaluation. Table 2 provides a high-level summary of each evaluation’s objective and key findings. A. QUALITATIVE EVALUATION: A SCENARIO-BASED ANALYSIS The qualitative evaluation began by validating the frame-work’s baseline accuracy and core design principles in a single-service RBAC scenario. The results in Table 3 demonstrated both inter-service segregation, as the F1 user (Film Producer) was correctly blocked from non-Film documents, and intra-service granularity, as the F2 user (Film Intern) was granted access to only a specific subset of Film documents. The consistent PASS scores confirmed the reliability of the document-level enforcement mechanism, providing a solid foundation for more complex evaluations. The evaluation next compared our delegated approach against a manual policy merging baseline in a cross-service scenario, revealing a critical security vulnerability. As detailed in Table 4, the CG (Control Group) user, operating under a flawed merged policy, was granted access to the ‘‘Make Mine Music’’ document where the FM user was correctly denied. This failure, caused by an omitted attribute during the manual policy translation, is visualized in Fig. 6. The figure clearly illustrates the security risks introduced by manual policy merging compared to the precise, policy-compliant enforcement of our framework. This outcome highlights that manual policy consolida-tion is not only error-prone but also faces fundamental architectural limitations. Attempting to translate complex ABAC policies into RBAC, for instance, can lead to a ‘‘role explosion’’ that renders the system difficult to manage. In contrast, our framework’s delegated approach circumvents these challenges entirely by enforcing the original policies through their native IAM systems. The qualitative evaluation thus confirms our method as a more practical and robust solution for maintaining security and policy integrity in complex, multi-resource environments. B. QUANTITATIVE EVALUATION: LARGE-SCALE ANALYSIS To assess the scalability and policy enforcement accu-racy of the proposed Permission-Aware RAG framework under realistic enterprise conditions, we conducted a large-scale evaluation using 1,000 multi-hop questions and approximately 13,783 documents distributed across GCP and AWS. Eight user profiles with varying access levels were designed to simulate fine-grained permission settings. Table 5 presents the results across all users. All profiles achieved a perfect Match score, indicating that the frame-work successfully enforced real-time, document-level access control for every retrieved document in accordance with each user’s IAM policy, even at scale. Moreover, we observe a clear positive correlation between Permission Coverage (PermCov) and QA performance. As users gain access to a greater portion of the document corpus, their EM and F1 scores improve accord-ingly. For instance, user-2 (PermCov 9.48%) achieved an F1 of 0.30, while user-7 (69.84%) scored 0.50. Furthermore, the standard deviations for both EM and F1 scores are relatively consistent across all user profiles, indicating that the framework’s QA performance is stable regardless of the user’s access level. This trade-off quantifies the cost of limited access in terms of answer quality, offering practical insight for balancing security and utility. To isolate the impact of access restrictions from question difficulty, we introduce EM@Admin, a metric that computes EM only over the subset of questions correctly answered by the admin. As shown in Table 5, the EM@Admin score consistently exceeds the standard EM score for all non-admin users. This clearly indicates that restricted document access directly reduces the availability of crucial supporting documents necessary for correctly answering the questions. The EM@Admin metric thus isolates the impact of access restrictions from inherent question difficulty, highlighting the tangible trade-off between fine-grained permission control and achievable answer accuracy. Users with broader access consistently achieve higher EM@Admin scores. For example, user-3 reached 0.52, while user-7 achieved 0.75. This confirms that performance differences are attributable to access constraints rather than inherent question complexity. Interestingly, user-1, who had no access to any documents (PermCov 0.00%), still achieved a non-trivial F1 score of 0.31. This suggests that the LLM may have relied on its internal knowledge or correctly guessed answers to binary (e.g., Yes/No) questions. In cases where no documents are retrieved, applying adaptive prompting, as demonstrated in FIT-RAG, can help the model better utilize its self-knowledge and improve response quality. Overall, these results validate that the Permission-Aware RAG framework robustly enforces heterogeneous access policies while preserving predictable QA performance. It enables secure, explainable, and operationally reli-able deployment in enterprise environments requiring fine-grained access control. C. LATENCY EVALUATION: IMPACT OF PERMISSION RETRIEVAL AND CONCURRENCY This section analyzes the latency evaluation results, focusing not just on performance metrics but on their practical implications for real-world deployment. The experiments confirm that the framework’s architecture effectively bal-ances real-time security with high performance. To accurately measure the raw overhead of each real-time API call, the caching of permission check results was intentionally disabled for this evaluation. 1) LATENCY BY NUMBER OF RETRIEVED DOCUMENTS. As shown in the top block of Table 6, when the number of retrieved documents (top-k) was increased from 1 to 20, the corresponding IAM Latency for permission checks increased modestly by about 140 ms. In sharp contrast, the total End-to-End (E2E) Latency was substantially higher. Furthermore, the standard deviation data reveals a key insight into performance stability: while the IAM Latency shows a relatively low and stable standard deviation, the E2E Latency exhibits significantly higher volatility. These results confirm that the latency introduced by permission validation is negligible compared to the inference time of the LLM, indicating that access control does not impose a performance bottleneck. The primary factor influencing user-perceived latency is the LLM, not the security check. This alleviates the major concern of performance degradation for enterprise adoption and confirms the framework’s ability to scale efficiently with increasing data loads. 2) LATENCY BY WORKER CONCURRENCY. The bottom block of Table 6 illustrates the effect of parallelism. Increasing the worker count from 1 to 15 reduces the mean IAM Latency by approximately 70% in total (from 420.71 ms to 127.33 ms), with the most substantial reduction occurring between 1 and 4 workers. However, beyond 4 workers, the performance gains diminish, indicating that the system is approaching a state of saturation. Although some conditions show high standard deviation due to external network factors, the standard deviation of IAM Latency remains consistently and substantially smaller than that of the total E2E Latency. This confirms that even when accounting for real-world network volatility, the parallel permission validation step is not the primary driver of unpredictability in the system. This provides a data-driven guideline for tuning an optimal number of workers to balance speed and stability in a real-world deployment. The findings empirically demonstrate that integrating IAM-based, fine-grained access control into high-throughput RAG systems does not lead to critical performance degrada-tion, thereby supporting the feasibility of secure deployment in enterprise environments. VI. CONCLUSION AND FUTURE WORK. This paper introduced the Permission-Aware RAG frame-work, a novel architecture for enforcing real-time, document-level access control in retrieval-augmented generation sys-tems operating across heterogeneous, multi-resource envi-ronments. By delegating access validation to native IAM systems, the framework preserves policy autonomy and eliminates the need for centralized policy merging, which is often error-prone and operationally burdensome. The experimental evaluations collectively demonstrate that the framework reliably enforces fine-grained permissions, scales effectively across diverse services, and maintains stable and predictable low-latency performance suitable for real-time applications. These findings confirm the frame-work’s ability to support secure, policy-compliant retrieval without compromising responsiveness or answer quality. Its plug-and-play design allows seamless integration with existing IAM infrastructures such as RBAC and ABAC, enabling flexible RAG deployment across independently governed services. In contextualizing the advantages of our design, we com-pare it against alternative approaches. First, manual policy merging, as demonstrated by our qualitative evaluation baseline (the CG user), is error-prone and can introduce critical security risks like data leakage. This approach is not only operationally burdensome but often leads to a loss of policy granularity during translation. Second, static filtering, which involves pre-building separate indexes for each user role or group, is fast but highly inflexible. It requires index regeneration upon permission changes, causes unnecessary data duplication when the same document is shared across multiple groups, and inevitably suffers from stale permission issues in dynamic environments. In contrast, index-level controls filter based on metadata within a single index, which can emulate RBAC and simple ABAC. However, this approach requires continuous metadata synchronization for complex or dynamic policies and struggles to reflect time-based conditions or hierarchical resource policies in real-time. Moreover, query costs can increase with the num-ber of filter conditions, leading to performance degradation in large-scale environments. Our framework’s approach of delegating validation to native IAMs in real-time directly overcomes these limitations. It eliminates the risks of manual policy mapping, ensures that the most current permissions are always enforced, and leverages the full expressiveness of IAM, thereby providing superior security, dynamism, and compliance in complex enterprise environments. Despite these strengths, several practical challenges and limitations remain. The framework’s reliability is influenced by the availability and responsiveness of external IAM services, making it vulnerable to issues like IAM outages. Furthermore, while the dataset utilized in this study was well-suited for evaluating the core mechanisms of multi-hop question answering and permission-aware retrieval, it does not fully capture the scale, heterogeneity, and policy com-plexity of proprietary enterprise environments. Consequently, the results should be interpreted with this limitation in mind, and future work should extend the evaluation to more diverse datasets and realistic IAM configurations. To address these limitations, future work will focus on enhancing the framework’s robustness for production environments. We have identified several edge cases, such as those mentioned above, and a detailed breakdown of these cases with candidate mitigation strategies is outlined in Appendix F as preliminary considerations. Key areas of future research will include implementing robust TTL-based caching to handle API rate limits and reduce latency, and introducing health checks with fallback mechanisms to improve fault tolerance. Additionally, we plan to explore new retrieval strategies to enhance answer quality in low permission coverage scenarios. Finally, to further enhance security, we aim to encrypt both document embeddings and metadata within the vector store. In summary, the Permission-Aware RAG framework establishes a secure, scalable, and adaptable foundation for building trustworthy, access-controlled AI systems in real-world, multi-tenant environments. The implementation of the proposed framework is publicly available as open-source code on GitHub. APPENDIX A RESOURCE METADATA SCHEMA Table 7 details the metadata schema managed by the Data Ingestion module. APPENDIX B PRODUCTION-GRADE CREDENTIAL ORCHESTRATION WORKFLOW This appendix details the practical workflow for the Cre-dential Manager in a production environment. It illustrates how the framework implements Identity Federation by integrating enterprise Single Sign-On (SSO) systems with cloud Security Token Services (STS). The process, illustrated in Fig. 7, adheres to the principle of least privilege by avoiding the use of static, long-lived keys. The workflow consists of the following key stages: • User Authentication via SSO (Steps 1-5) When a user first accesses the RAG application, the RAG framework redirects them to a corporate Identity Provider (IdP) like Okta or Azure AD for authentication. Upon successful authentication, the IdP issues a primary identity token (e.g., an OIDC ID Token or a SAML Assertion), which is returned to the RAG framework. The framework validates this token to establish a secure, authenticated session for the user. This initial step handles user authentication securely without the RAG system ever handling user passwords. • Dynamic & Temporary Credential Issuance (Steps 6-8) Once authenticated, the user submits a query to the RAG framework (Step 6). The Credential Manager then uses the user’s identity information from the established session to request a temporary, short-lived credential from the cloud provider’s Security Token Service (STS) (Step 7). The STS, in turn, issues the temporary credential back to the framework (Step 8). This ‘‘token exchange’’ process is central to the framework’s security, as it ensures that permissions are granted dynamically and expire automatically. • Permission-Aware Resource Access (Steps 9-11) The IAM Adapter uses the newly issued temporary credential to make an authorized API call to the native cloud service. The cloud provider’s IAM service validates the credential and the requested permission, returning a success or failure response (Step 10). Based on these real-time checks, the RAG framework processes only the authorized documents to generate and return the final, filtered response to the user (Step 11). This end-to-end workflow demonstrates how the Permission-Aware RAG framework can be securely deployed in complex enterprise environments by integrating with exist-ing identity management systems and enforcing dynamic, just-in-time access control. APPENDIX C IAM ADAPTER IMPLEMENTATION DETAILS The IAM Adapter is designed with a modular and extensible architecture to validate user access permissions across heterogeneous platforms. Each implementation class extends a shared interface defined in the abstract base class AccessControlBase, which declares the common checkpermission method. Service-specific classes, including GCPAccessControl, AWSAccessControl, and KeycloakAccessControl, inherit from this base class and implement the method using their respective native IAM APIs and SDKs. Specifically, the boto3 library is used for AWS, the google-cloud-storage SDK for GCP, and REST API endpoints for Keycloak-based services. To enhance system scalability and response performance, the IAM Adapter employs a multithreading-based architec-ture. Permission checks are predominantly I/O-bound due to network API calls, and executing them in parallel prevents access validation from becoming a bottleneck in the retrieval pipeline. The current implementation leverages Python’s ThreadPoolExecutor class from the concurrent library to manage thread pools and schedule tasks concur-rently, ensuring efficient resource utilization. Furthermore, the adapter’s modular design is intentionally extensible to support more advanced parallel processing schemes. For instance, in large-scale production environ-ments, the adapter can be readily integrated with multipro-cessing architectures that leverage distributed task queues such as Celery or RabbitMQ. These systems enable the distribution of permission-checking tasks across multiple worker nodes, thereby further increasing throughput and reliability. Overall, the IAM Adapter provides a robust and extensible solution for validating user access permissions across het-erogeneous services. By leveraging platform-specific SDKs, parallel execution, and support for advanced distributed processing, it ensures both secure and efficient operation within the Permission-Aware RAG framework. APPENDIX D SCENARIO-BASED EVALUATION QUESTIONS This appendix provides the full list of scenario-based evaluation questions used in qualitative evaluation. See Table 8. APPENDIX E USER AND RESOURCE CONFIGURATION FOR QUANTITATIVE EVALUATION This appendix details the user profiles and resource config-urations created for the large-scale quantitative evaluation (Section IV-D). This setup was designed to create a trans-parent and reproducible testbed with heterogeneous IAM policies. First, to establish a clear and reproducible benchmark, we defined specific access control requirements for the resources used in our evaluation. These resources are distributed across two distinct policy environments. The first is Google Cloud Platform (GCP), which utilizes a Role-Based Access Control (RBAC) model, and the second is Amazon Web Services (AWS), which employs an Attribute-Based Access Control (ABAC) model. Table 9 provides a detailed breakdown of these requirements, specifying the exact IAM role needed to access each GCP bucket and the particular combination of user attributes required for each AWS bucket. Next, Table 10 shows the eight user profiles configured for the evaluation. These profiles were intentionally designed to test the framework’s performance under varying levels of data accessibility, from a user with no permissions (‘user-1‘) to one with complete access (‘baseline-admin‘). Each profile is assigned a unique combination of GCP’s role-based permissions (RBAC) and AWS’s attribute-based permissions (ABAC), allowing us to evaluate the system’s ability to handle heterogeneous policies concurrently. The ‘baseline-admin‘ user, who has unrestricted access, serves as the upper bound for measuring maximum permission coverage and achievable answer quality. The detailed settings for each profile are also available in the publicly accessible source code for reproducibility. APPENDIX F EDGE CASES AND MITIGATION STRATEGIES Deploying the proposed framework in a production setting requires careful consideration of potential edge cases that could impact its stability and security. To outline preliminary directions, we have identified several scenarios, ranging from external service failures to specific permission-handling situations. Table 11 provides a summary of these edge cases and possible mitigation strategies.