Study guide
14.2 Access Controls, Role-Based Security & Permissions on Grounding Data
Microsoft Certified: Agentic AI Business Solutions Architect Expert AB-100
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Requirements Analysis & Grounding Data
1.1 Assessing Agents for Task Automation, Analytics & Decision-Making 1.2 Grounding Data Evaluation: Accuracy, Relevance, Timeliness, Cleanliness & Availability 1.3 Structuring Enterprise Business Data for AI System Interoperability
2 Chapter 2: AI Strategy, Cloud Adoption Framework & CoE
2.1 Cloud Adoption Framework (CAF) for Azure AI Strategy & Roadmap 2.2 Multi-Agent Architecture: Microsoft 365 Copilot, Copilot Studio & Foundry 2.3 Microsoft AI Center of Excellence (CoE) & Solution Governance 2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog 2.5 Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools
3 Chapter 3: Model Selection, Prompt Engineering & Dynamics AI
3.1 Model Selection Strategy, Custom Models & Small Language Models (SLMs) 3.2 Enterprise Prompt Engineering Guidelines & Prompt Libraries 3.3 Cross-App AI Strategy for Multi-App Dynamics 365 Solutions
4 Chapter 4: ROI, TCO, Build vs Buy & Model Routing
4.1 ROI Criteria & Total Cost of Ownership (TCO) for AI Solutions 4.2 Comprehensive Financial ROI Analysis for Business Processes 4.3 Build vs Buy vs Extend Architectural Decision Framework 4.4 Dynamic Model Router Architecture & Cost-Performance Optimization
5 Chapter 5: Dynamics 365 AI & Contact Center Design
5.1 Business Terms & Copilot Customization in Customer Experience and Service 5.2 Connectors & Data Flow Design for Copilot in Dynamics 365 Sales 5.3 Agent Integration with Dynamics 365 Contact Center Channels
6 Chapter 6: Agent Archetypes & Copilot Studio Core
6.1 Designing Task Agents, Autonomous Agents & Prompt-and-Response Agents 6.2 Copilot Studio Topic Design, Trigger Phrases & Graceful Fallbacks 6.3 Orchestration Selection: Standard NLP vs CLU vs Generative AI Orchestration
7 Chapter 7: Copilot Studio Advanced Actions & Power Platform
7.1 Designing Agent Flows & Prompt Actions in Copilot Studio 7.2 Power Apps Canvas App Integration, Generative Pages & Agent Feeds 7.3 Power Platform Well-Architected Framework for AI Workloads 7.4 Proposing Microsoft Power Platform AI Features & the AI Hub
8 Chapter 8: Agent Extensibility, MCP & Computer Use
8.1 Microsoft Foundry Custom Models & Foundry Tools Selection 8.2 Agent Extensibility via Model Context Protocol (MCP) in Copilot Studio 8.3 Computer Use Automation & Web UI Interactions in Copilot Studio
9 Chapter 9: Advanced Behaviors & Prebuilt App Orchestration
9.1 Agent Behaviors: Multi-Step Reasoning, Voice Mode & M365 Agent Optimization 9.2 Orchestrating Prebuilt AI in Dynamics 365 F&O and M365 Copilot for Sales/Service 9.3 Orchestrating Prebuilt Copilot AI Features in Dynamics 365 Customer Experience & Service 9.4 Proposing Microsoft 365 Agents for Business Scenarios 9.5 Adding Knowledge Sources to In-App Help & Guidance in Dynamics 365 Finance & Supply Chain
10 Chapter 10: Telemetry, Monitoring & Agent Tuning
10.1 Monitoring Architectures: Azure Monitor, Application Insights & Studio Analytics 10.2 Telemetry Data Interpretation, Performance Metrics & Latency Tuning 10.3 User Feedback Analysis, Backlog Prioritization & Continuous Improvement
11 Chapter 11: Testing Strategy & Model Validation
11.1 Agent Testing Frameworks, Quality Metrics & Groundedness Benchmarks 11.2 Custom AI Model Validation, Safety Criteria & Regression Testing 11.3 Copilot-Assisted Test Case Generation & Cross-Dynamics End-to-End Testing 11.4 Validating Effective Copilot Prompt Practices
12 Chapter 12: ALM for Grounding Data & Copilot Studio Agents
12.1 ALM for Grounding Data, Vector Indexes & Knowledge Synchronization 12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging 12.3 Environment Strategy & Automated Deployment Pipelines for Studio Agents
13 Chapter 13: ALM for Foundry Agents & Dynamics 365 AI
13.1 ALM for Microsoft Foundry Agents Service & Model Registries 13.2 ALM for Custom AI Models, Fine-Tuning Artifacts & Deployment Slots 13.3 ALM for Dynamics 365 AI in Finance, Supply Chain & Customer Engagement
14 Chapter 14: Agent Identity, Security & Access Controls
14.1 Agent Identity Architecture, Microsoft Entra ID & Authentication Flows 14.2 Access Controls, Role-Based Security & Permissions on Grounding Data 14.3 Secure Data Processing & Grounding Data Isolation
15 Chapter 15: Model Security & Threat Mitigation
15.1 Model Security Architecture & Defense Against Vulnerabilities 15.2 Mitigating Prompt Manipulation, Jailbreaks & Indirect Prompt Injections 15.3 Azure AI Content Safety, Prompt Shields & Guardrails
16 Chapter 16: Responsible AI, Governance, Residency & Audit
16.1 Microsoft Responsible AI Standard: Principles, Assessment & Implementation 16.2 Data Residency, Sovereign Boundaries & Cross-Border Compliance 16.3 Comprehensive Audit Trails, Model Decision Logging & Microsoft Purview 16.4 Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory
14.2 Access Controls, Role-Based Security & Permissions on Grounding Data
Key Takeaways Explain This Topic AI
Vector search indexes and large language models do not enforce native data security; enterprise agentic RAG architectures must enforce security trimming pre-retrieval to guarantee that unauthorized document chunks never enter the model's context window.
Microsoft Dataverse provides a multi-layered security model where business unit hierarchies, security roles, record ownership, row-level security (RLS), and column-level Field-Level Security (FLS) dynamically mask sensitive attributes before agent response generation.
Microsoft Graph grounding in Microsoft 365 Copilot and Copilot Studio natively enforces user-delegated ACL trimming across SharePoint, OneDrive, and Exchange, requiring organizations to remediate tenant over-sharing prior to agent rollout.
In Azure AI Search, document-level security is implemented by indexing Entra ID User and Group Object IDs into an allowed_groups collection field and executing an OData $filter matching the caller's transitive group memberships at query time.
Zero-Trust agent architectures adhere to Verify Explicitly, Use Least Privilege, and Assume Breach, requiring just-in-time (JIT) access, end-to-end token validation, and comprehensive audit telemetry across all data planes.
Last updated: September 2026
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:
When an author modifies permissions on a SharePoint document library or file, SharePoint synchronizes the updated ACLs to Microsoft Graph in near real-time.
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.
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:
The agent orchestrator inspects the user's incoming Entra ID access token.
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).
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'))
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
Grounding Store Security Primitives Enforcement Mechanism Token Requirements Common Architectural Pitfall
Microsoft Dataverse Business Units, Security Roles, User/Team Ownership, Field Security Profiles Native SQL/OData query filtering and column masking User-Delegated Entra ID Token Overriding delegated context with an administrative connection reference, bypassing row/column security.
Microsoft Graph (M365) SharePoint ACLs, OneDrive Permissions, Exchange Mailbox Rights Semantic Index pre-retrieval trimming against source repository ACLs User-Delegated Token with Graph Scopes Tenant over-sharing where sensitive folders are open to "Everyone except external users."
Azure AI Search Custom Collection(Edm.String) holding Entra OIDs / Group GUIDs OData $filter execution ( search.in ) combined with vector/hybrid search User Token for claims extraction; Search Service Key or Managed Identity for search execution Post-filtering in code after retrieval, which wastes top-k vector slots and risks context leakage.
Azure SQL / Fabric Row-Level Security (RLS) security predicates, Column Encryption, Dynamic Data Masking Native database engine security predicate functions Entra ID Integrated Token / Managed Identity Running queries under a single shared db_datareader account rather than passing caller identity.
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
Never rely on LLM post-processing for security. Filter at the retrieval source.
Resolve group memberships transitively. Ensure nested Entra ID security groups are fully resolved during ACL matching in Azure AI Search.
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.
Monitor retrieval anomalies. Ingest search query logs into Microsoft Sentinel to detect users or compromised agent loops attempting broad vector searches across restricted domains.