14.2 Access Controls, Role-Based Security & Permissions on Grounding Data

Access Controls, Role-Based Security & Permissions on Grounding Data

Quick Answer: Large Language Models (LLMs) and vector databases are fundamentally identity-blind. If an agent retrieves confidential documents during retrieval-augmented generation (RAG), the model will incorporate that restricted information into its response regardless of who is asking. Enterprise architects must enforce pre-retrieval security trimming at the data layer. In Microsoft Dataverse, this is achieved through business unit hierarchies, row-level security (RLS), and column-level Field-Level Security (FLS). In Microsoft Graph, security trimming is enforced natively by user-delegated ACLs. In Azure AI Search, architects must index Entra ID security group ACLs into an allowed_groups collection and inject an OData $filter containing the caller's transitive group memberships at query time.

When deploying generative AI across an enterprise, data access governance shifts from static file permissions to dynamic prompt context boundaries. If a sales representative asks an internal Copilot, "What is the pricing strategy for Project Titan?" the system must guarantee that the retrieved grounding context contains only documents that the specific sales representative is legally and operationally permitted to view.

Relying on the LLM to filter sensitive data via system prompts (e.g., "Do not show this document to users who are not managers") is an acute security anti-pattern. System prompt instructions can be bypassed with trivial jailbreaks or semantic evasion. Access controls must be cryptographically and deterministically enforced at the data store before text chunks are injected into the prompt context window.

---

1. The Dataverse Security Model for Copilot Studio Agents

Microsoft Dataverse serves as the primary data fabric for Microsoft Power Platform and Copilot Studio. When an agent queries Dataverse tables (such as Accounts, Knowledge Articles, or Custom Entities), it operates under the sophisticated, role-based Dataverse security engine.

+-----------------------------------------------------------------------------+
|                     DATAVERSE MULTI-TIER SECURITY ENGINE                    |
+-----------------------------------------------------------------------------+
                                      |
         +----------------------------+----------------------------+
         |                                                         |
         v                                                         v
+---------------------------------+       +---------------------------------+
|        ROW-LEVEL SECURITY       |       |      COLUMN-LEVEL SECURITY      |
|     (Record Visibility)         |       |      (Attribute Masking)        |
+---------------------------------+       +---------------------------------+
| - Business Unit (BU) Hierarchy  |       | - Field Security Profiles       |
| - Security Roles & Privileges   |       | - Read / Update / Create ACLs   |
| - Ownership (User vs Team)      |       | - Sensitive fields (SSN, Salary)|
| - Sharing & Access Teams        |       | - Returns NULL / MASKED to agent|
+---------------------------------+       +---------------------------------+

1.1 Business Units, Security Roles, and Record Ownership

Dataverse models enterprise structure through a hierarchical tree of Business Units (BUs):

• Root Business Unit: The top-level container representing the entire organization.
• Child Business Units: Subordinate branches representing regional offices, business divisions, or legal entities.
• Modern Business Units (Matrix Ownership): Allows users from one BU to own or access records owned by another BU without changing their primary organizational assignment.

Security roles define what actions a user can perform across eight core privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share). Each privilege operates at a specific Privilege Depth:

• Basic (User): Access is restricted to records owned by the individual user or shared with them directly.
• Local (Business Unit): Access extends to all records owned by any user or team within the user's immediate business unit.
• Deep (Parent-Child): Access includes the user's business unit and all subordinate child business units beneath it.
• Global (Organization): Complete access to all records across the entire tenant.

When a Copilot Studio agent queries Dataverse using a User-Delegated connection, Dataverse intercepts the query and dynamically injects filtering predicates based on the caller's effective security roles. A sales agent in the London BU querying the opportunity table will only retrieve London opportunities; Tokyo opportunities are excluded at the SQL/OData layer.

1.2 Column-Level / Field-Level Security (FLS) in Agent Responses

Certain table attributes are too sensitive to expose even if a user has access to the parent record (e.g., a customer's Social Security Number, credit card token, or executive compensation figures in an employee table). Dataverse manages this through Column Security Profiles:

• Attributes are flagged as IsSecured = true in the Dataverse table schema.
• Security administrators create Field Security Profiles granting Read, Update, or Create permissions to specific Entra ID users or Dataverse Teams.
• Agent Behavior under FLS: When an agent queries a record where Field-Level Security applies, Dataverse suppresses the secured column value for unauthorized users, returning null or a masked string (*****).

[!CAUTION] Critical Architecture Rule: Prompts and topic formulas in Copilot Studio must be designed defensively to handle null or masked values returned by Field-Level Security. If an agent's reasoning loop expects an integer salary value and receives null, unhandled exceptions or hallucinations may occur. The prompt should explicitly instruct: "If the salary attribute is null or masked, inform the user that their security role does not authorize access to financial attributes."

---

2. Microsoft Graph Permissions Trimming (M365 Copilot & Copilot Studio)

Microsoft 365 Copilot and Copilot Studio agents grounded on Microsoft Graph access unstructured enterprise content across SharePoint Online, OneDrive for Business, Microsoft Teams, and Exchange Online.

[ User Prompt ]
      |
      v
[ Microsoft 365 Copilot Orchestrator ]
      |
      | 1. Query with User Delegated Token
      v
[ Microsoft Graph Semantic Index ]
      |
      | 2. Evaluates Native SharePoint / OneDrive ACLs (Pre-Retrieval Trimming)
      |    * Checks Direct User Rights, Security Groups, M365 Groups
      v
[ Only Authorized Document Chunks Returned ]
      |
      v
[ LLM Reasoning Context Window ]
      |
      v
[ Grounded, Safe Response to User ]

2.1 Pre-Retrieval Security Trimming Mechanics

Microsoft Graph does not rely on post-hoc redaction. The Microsoft Graph Semantic Index maintains a continuous mapping of document content and the underlying security Access Control Lists (ACLs) of the source repository:

1. When an author modifies permissions on a SharePoint document library or file, SharePoint synchronizes the updated ACLs to Microsoft Graph in near real-time.
2. When an employee issues a prompt, the Semantic Index searches only within the partition of documents where the employee's Entra ID User Object ID or group memberships match the document's read ACLs.
3. Documents that the user cannot view in SharePoint Online will never appear in search results, will never be summarized by Copilot, and will never be cited in footnotes.

2.2 The "Over-Sharing" Risk and Remediation Architecture

A critical finding in enterprise agent implementations is that Copilot does not cause security breaches; rather, it amplifies existing over-sharing. If a human resources site was inadvertently shared with Everyone except external users five years ago, employees rarely noticed because the link was obscure. However, when an employee asks Copilot, "Show me recent executive severance discussions," Copilot will faithfully retrieve and summarize the poorly secured document.

Architectural Remediation Strategy:

• Microsoft Purview Information Protection (MPIP): Apply sensitivity labels (e.g., Highly Confidential - Executive Only) with automated encryption. Even if a document is shared broadly, only users with cryptographic rights can decrypt and view the text.
• Restricted SharePoint Search (RestrictedSearchMode): Administrators can temporarily enable Restricted SharePoint Search in the Microsoft 365 Admin Center, limiting enterprise-wide Copilot search to a curated list of up to 100 approved SharePoint sites while security teams audit permissions across the estate.
• Data Access Governance (DAG) Reports: Utilize SharePoint Advanced Management (SAM) to generate over-sharing reports identifying sites with broad sharing links or public group access, allowing targeted permission remediation before deploying agents.

---

3. Azure AI Search Security Filters & Document-Level Security

When building custom Agentic RAG architectures in Azure AI Foundry or Copilot Studio with external knowledge repositories (such as Azure Blob Storage, AWS S3, Confluence, or custom SQL databases), architects must implement document-level security manually using Azure AI Search.

+-----------------------------------------------------------------------------------+
|              AZURE AI SEARCH DOCUMENT-LEVEL SECURITY ARCHITECTURE                 |
+-----------------------------------------------------------------------------------+

  INGESTION PHASE (Delta Pipeline):
  [ Document Source ] ---> Read Document & Source ACLs
                                    |
                                    v
                     Extract Entra Group Object IDs
                     ['sg-hr-team', 'sg-executives']
                                    |
                                    v
  [ Azure AI Search Index ]
  {
    "chunk_id": "chunk-001",
    "content_vector": [0.012, -0.043, ...],
    "text": "2027 Executive Bonus Pool Formula...",
    "allowed_groups": ["c1234567-aaaa-bbbb-cccc-111122223333", "d9876543-xxxx"]
  }

-------------------------------------------------------------------------------------
  RETRIEVAL PHASE (Agent Runtime Query):
  [ Authenticated User ] ---> Issues Prompt: "Show me executive bonus calculations"
                                    |
                                    v
                     Extract User OID & Transitive Groups
                     User OID: 'u-user-001'
                     Member Groups: ['sg-sales', 'sg-all-staff']
                                    |
                                    v
  [ Search Request with Injected OData Filter ]
  POST /indexes/corporate-kb/docs/search
  {
    "search": "executive bonus calculations",
    "vectorQueries": [...],
    "filter": "allowed_groups/any(g: search.in(g, 'u-user-001,sg-sales,sg-all-staff'))"
  }
                                    |
                                    v
  RESULT: Chunk-001 is MATHEMATICALLY EXCLUDED before vector ranking!

3.1 Ingestion Phase: ACL Schema Definition

In Azure AI Search, the index schema must be defined with a dedicated, filterable collection field to hold the security identifiers:

{
  "name": "allowed_groups",
  "type": "Collection(Edm.String)",
  "filterable": true,
  "searchable": false,
  "retrievable": false,
  "sortable": false,
  "facetable": false
}

Note that searchable and retrievable are set to false. Users must never be able to search for group IDs or view the ACL array in response payloads; the field exists purely for server-side evaluation during filtering.

During ingestion, the pipeline (e.g., Azure Functions or Azure Data Factory) queries the source repository's security API, resolves user and group names to Entra ID Object IDs (GUIDs), and populates the allowed_groups array for every chunk derived from that document.

3.2 Retrieval Phase: Runtime Token Extraction & OData Filtering

When an agent processes a user request at runtime:

1. The agent orchestrator inspects the user's incoming Entra ID access token.
2. The orchestrator extracts the user's Object ID (oid) and their security group memberships from the groups token claim. (If the user belongs to more than 200 groups, Entra ID includes an overage indicator, requiring the orchestrator to call Microsoft Graph /v1.0/users/{id}/transitiveMemberOf to resolve the full group list).
3. The orchestrator constructs a hybrid/vector search request injecting a strict OData $filter:

   allowed_groups/any(g: search.in(g, 'user-oid,group-oid-1,group-oid-2,group-oid-3'))
   

4. Azure AI Search evaluates the filter prior to ranking and similarity scoring. Any vector whose allowed_groups does not intersect with the user's identity claims is discarded immediately. Unauthorized text chunks never enter the LLM prompt context.

---

4. Architectural Comparison: Grounding Store Security Models

---

5. Designing Zero-Trust Data Access for Agentic Architectures

Applying the three core principles of Zero Trust to Agentic RAG architectures guarantees robust defense-in-depth across the entire AI data pipeline:

+-----------------------------------------------------------------------------+
|                   ZERO TRUST PILLARS FOR AGENTIC RAG                        |
+-----------------------------------------------------------------------------+
|                                                                             |
|  1. VERIFY EXPLICITLY                                                       |
|  - Authenticate every agent tool call and API invocation.                   |
|  - Re-evaluate user permissions, group memberships, and token validity.     |
|  - Never trust cached authorization states across reasoning loops.          |
|                                                                             |
|  2. USE LEAST PRIVILEGE ACCESS                                              |
|  - Scope agent connectors to specific SharePoint sites (Sites.Selected).    |
|  - Utilize Just-In-Time (JIT) access via Microsoft Entra PIM.               |
|  - Restrict autonomous agents with Exchange Application Access Policies.    |
|                                                                             |
|  3. ASSUME BREACH                                                           |
|  - Encrypt all grounding data in transit (TLS 1.3) and at rest (CMK).       |
|  - Enforce pre-retrieval filtering to prevent unauthorized context loading. |
|  - Maintain unified diagnostic audit logs in Microsoft Purview & Azure      |
|    Monitor capturing user OID, document URI, and retrieved chunk hashes.   |
+-----------------------------------------------------------------------------+

Practical Implementation Checklist for Solution Architects

1. Never rely on LLM post-processing for security. Filter at the retrieval source.
2. Resolve group memberships transitively. Ensure nested Entra ID security groups are fully resolved during ACL matching in Azure AI Search.
3. Isolate dev/test indexes. Non-production vector indexes must be populated with synthetic test fixtures, never synchronized directly from production SharePoint libraries containing sensitive PII.
4. Monitor retrieval anomalies. Ingest search query logs into Microsoft Sentinel to detect users or compromised agent loops attempting broad vector searches across restricted domains.