3.5 Agent Permissions and Grounding

Key Takeaways

  • Grounding enriches LLM prompts with relevant organizational data retrieved from Microsoft Graph and configured knowledge sources.
  • Built-in Copilot grounds broadly on the user's accessible M365 content via Graph; custom agents scope to maker-defined knowledge sources.
  • Copilot does not bypass SharePoint, OneDrive, or Exchange permissions — oversharing in source locations increases Copilot and agent exposure.
  • Teams app permission policies control which Copilot Studio agents published to Teams are allowed or blocked for users or groups.
  • Administrators control agent access by combining approval workflows, Entra group membership, Teams policies, and Power Platform environment permissions.
Last updated: July 2026

Quick Answer: Grounding injects relevant organizational data into the LLM prompt context. Built-in Copilot uses Microsoft Graph across the user's permitted M365 content; custom agents use maker-configured knowledge sources. Copilot never bypasses permissions — fix oversharing at the source. Control agent availability with Teams app permission policies, approval workflows, and Entra group scoping.

Why Grounding and Permissions Dominate AB-900

The largest AB-900 domain is Data Protection and Governance (35–40%), and Domain 3 agent questions repeatedly connect back to who can see what through AI. Grounding is the mechanism; permissions are the guardrail. Exam scenarios describe data leaks, overshared SharePoint sites, or agents reaching too-broad audiences — the fix is almost always permission remediation, not disabling Copilot entirely.

What Grounding Means

Grounding is the process by which Copilot or an agent retrieves relevant organizational content — emails, documents, meetings, chats, structured records — and injects it into the prompt context sent to the large language model (LLM). This ensures responses are accurate and specific to the user's organizational situation rather than generic web knowledge.

Grounding is not:

  • Connecting a physical on-premises server (that is hybrid/Graph connector territory)
  • DLP filtering (compliance step that may block content separately)
  • Assigning sensitivity labels (classification, applied before or during generation)

Built-in Copilot Grounding Architecture

Microsoft 365 Copilot grounds through:

  1. Semantic index — pre-built tenant index of organizational content respecting existing permissions
  2. Microsoft Graph — real-time retrieval of content the signed-in user can already access
  3. Optional web grounding — Bing/public web enrichment when the admin toggle is enabled

The critical rule: Copilot can only retrieve data the user already has permission to read. If a user cannot open a SharePoint file in the browser, Copilot cannot surface it in a response. The semantic index does not expand access — it indexes within permission boundaries.

Custom Agent Grounding

Custom agents differ in scope:

AspectBuilt-in CopilotCustom Agent
Data scopeUser's accessible M365 content via GraphMaker-configured knowledge sources
IndexTenant semantic indexAgent-specific sources (SharePoint, files, Dataverse, web)
Use caseGeneral productivityTargeted domain (HR, IT, sales playbook)

A custom agent can be intentionally narrow — grounded only on an HR policy SharePoint library rather than the user's entire mailbox. Makers and admins must verify connected sources do not contain overshared or mislabeled content.

Permission Inheritance and Oversharing Risk

SharePoint oversharing — "Anyone" links, excessive guest access, inherited permissions on sensitive libraries — is the primary Copilot exposure risk. Because Copilot respects but does not fix permissions, overshared content may appear in responses to users who should not see it.

Administrative remediation tools (covered in Domain 2 but applied here):

  • Data Access Governance reports — highlight overshared sites and files
  • SharePoint Advanced Management — access governance policies
  • Sensitivity labels and DLP — prevent inappropriate sharing at creation

On the Exam: If a scenario describes unintended data appearing in Copilot responses, the first answer is review and remediate SharePoint/file permissions — not delete Copilot licenses or disable Graph.

Controlling Agent Access

Multiple layers restrict which users interact with which agents:

Agent Approval Process

Only approved agents appear in the organization catalog. Unapproved submissions remain unavailable.

Entra Security Groups

Administrators assign agent access to specific Entra groups — e.g., only the HR team sees the HR policy agent.

Teams App Permission Policies

The Teams admin center app permission policies control which apps — including Copilot Studio agents published as Teams apps — are allowed, blocked, or limited to specific user groups:

Policy SettingEffect
Allow specific appsOnly listed apps available to the policy's users
Block specific appsListed apps hidden from users
Org-wide defaultBaseline allow/block for all apps

This is not a blanket default block on all Copilot Studio agents — policies are configurable.

Power Platform Environment Permissions

Makers and users need appropriate roles in the Power Platform environment hosting the agent. Environment security groups gate who can author vs who can consume.

Integrated Apps (M365 Admin Center)

The Integrated apps section manages third-party plugins and connectors that extend Copilot and agent capabilities — controlling which external data sources and actions are approved.

Actions and Connector DLP

When agents use actions (API calls, Power Automate flows, connectors), Power Platform DLP policies restrict which connector combinations can access business vs non-business data. An agent action calling an unapproved connector may be blocked even if the agent itself is approved.

Declarative vs Autonomous Agent Permissions

Declarative agents operate within defined topic boundaries — easier to audit. Autonomous agents plan multi-step tasks independently, increasing the need for strict action permissions and connector DLP because the agent may chain operations the maker did not explicitly script step-by-step.

Worked Scenario: Agent Reaching Wrong Audience

A Copilot Studio agent published to Teams is visible to all 10,000 employees, but it contains internal-only compensation guidance. The administrator should:

  1. Revoke broad publication until access is scoped
  2. Update Teams app permission policy to allow the agent only for HR Entra group
  3. Verify knowledge source SharePoint library permissions match intended audience
  4. Re-submit through approval process if org policy requires re-review after scope change
  5. Run Data Access Governance report on connected SharePoint sources

Web Grounding and External Data

The web grounding toggle (org settings) controls whether Copilot supplements internal data with Bing and public web content. Regulated industries often disable web grounding to keep responses within governed tenant data. This setting affects built-in Copilot; custom agent public website knowledge sources are configured separately in Copilot Studio.

Common Exam Traps

TrapReality
Copilot bypasses SharePoint permissionsCopilot respects existing permissions
Built-in Copilot cannot use GraphGraph is the primary retrieval path
Teams policies only apply to first-party appsPolicies include Copilot Studio agents
Grounding = DLP filteringGrounding is data retrieval; DLP is separate enforcement
Custom agents cannot use knowledge sourcesKnowledge sources are a core agent feature
Test Your Knowledge

What does 'grounding' mean in the context of Microsoft 365 Copilot?

A
B
C
D
Test Your Knowledge

Which best describes how built-in Copilot capabilities compare to custom agents in terms of data grounding?

A
B
C
D
Test Your Knowledge

How do Teams admin center app permission policies govern Copilot Studio agents published to Microsoft Teams?

A
B
C
D
Test Your Knowledge

What is an 'action' in a Microsoft Copilot Studio agent?

A
B
C
D