Microsoft 365 Copilot and Copilot Studio
The Microsoft 365 connector discovers your tenant's Copilot deployment, its published agents and every Copilot Studio agent in your Power Platform environments, imports directory audit activity as MITRITY audit events, reads tenant security posture, and assesses each published Copilot Studio agent against a set of posture checks — through a read-only Entra (Azure AD) app using application permissions. It never writes to your tenant.
Read SaaS-Embedded Agent Governance first for the connector model; this page covers Microsoft 365 specifics. Graph reads use the generally-available Microsoft Graph v1.0 API; Copilot Studio reads use the Power Platform admin API and each environment's Dataverse Web API.
Where Microsoft AI services fit
Azure OpenAI / AI Foundry traffic is protected inline at the LLM Gateway; Copilot Studio and Microsoft 365 Copilot agents are discovered, inventoried and posture-assessed through this connector. The two are different by design: an Azure OpenAI call leaves your workload for an endpoint you chose, so the gateway can sit on that hop and govern every prompt; a Copilot Studio agent runs inside Microsoft, with no customer-controlled hop, so the connector governs it out-of-band — by reading how it is configured and telling you what is risky.
What it discovers
- The tenant's Microsoft 365 Copilot deployment as a governed agent.
- Org-published app-catalog entries — the declarative agents and Copilot Studio agents an administrator approved for the organization (
AppCatalog.Read.All). - Copilot Studio agents — every agent in every Power Platform environment, read from the environment's Dataverse database: published or not, approved or not. Each is discovered with its environment, authentication mode, access-control policy, published state and date, generative-orchestration setting, knowledge-source and connector counts, and Teams app id. An agent that is both in the app catalog and in Copilot Studio appears as two entries, cross-referenced to each other.
Requirements
| Requirement | Detail |
|---|---|
| Licensing | A Microsoft 365 Copilot-licensed tenant for Copilot discovery; Copilot Studio agents are read from Power Platform regardless. |
| Role | A Global Administrator (or Privileged Role Admin) to grant admin consent, and a Power Platform administrator to register the app for Power Platform reads and add it to environments. |
| MITRITY plan | Pro or Enterprise; Owner role, or Manager role with access scope all. |
Step 1 — Register an Entra app
- In the Microsoft Entra admin center → App registrations → New registration, name it (e.g.
mitrity-governance) and register. No redirect URI is needed — the connector uses the client-credentials (app-only) flow, not interactive sign-in. - Note the Application (client) ID and the Directory (tenant) ID on the Overview page.
- Under Certificates & secrets → New client secret, create a secret and copy its value immediately (it is shown only once). This is the secret MITRITY stores, encrypted.
One app registration and one secret serve every read below; the connector mints a separate short-lived token per audience (Microsoft Graph, the Power Platform admin API, each Dataverse environment) at sync time.
Step 2 — Grant read-only Graph permissions
Under API permissions → Add a permission → Microsoft Graph → Application permissions, add the read-only permissions the connector uses, then click Grant admin consent:
| Permission | Used for |
|---|---|
AuditLog.Read.All | Directory audit activity (Observe) |
Policy.Read.All | Authorization policy & security defaults (Posture) |
SecurityEvents.Read.All | Secure Score (Posture) |
AppCatalog.Read.All | Published agents / app catalog (Discover; the admin-approval check) |
Directory.Read.All | Tenant + Copilot deployment metadata (Discover) |
Application permissions require admin consent — until an administrator grants it, the connector cannot read anything. Add only the read permissions above; the connector never needs write scope.
Step 3 — Allow the app to read Power Platform
Copilot Studio agents and data policies are not in Microsoft Graph. Two Power Platform steps give the same app read access to them:
-
Register the app as a Power Platform admin management application, so it can list environments and data policies. In PowerShell with the
Microsoft.PowerApps.Administration.PowerShellmodule:Add-PowerAppsAccount New-PowerAppManagementApp -ApplicationId <application-client-id>This registration is how Microsoft grants app-only access to the Power Platform admin lists; it is not scoped to read-only by Microsoft, so the connector's read-only behavior is a property of the connector — it only ever issues read calls (environments and data policies) — and every call is visible in your tenant's admin activity logs.
-
Add the app as an application user of each environment whose Copilot Studio agents you want inventoried and assessed. In the Power Platform admin center → Environments → (environment) → Settings → Users + permissions → Application users → New app user, pick the app registration, and assign it a security role with Read access (organization scope) to the Agent (
bot), Agent component (botcomponent) and Connection Reference tables. A custom role with only those read privileges is the least-privilege choice; an environment where the app is not an application user is inventoried as Unknown rather than skipped silently.
The connector reads agent configuration only: which authentication mode and audience an agent has, what knowledge sources and connectors it binds, whether it is published and set up for Teams. It never reads conversation transcripts, topic contents, or authentication configuration values.
Sovereign clouds
US Government and China tenants use different endpoints and token audiences. The Connect form covers the public cloud; for a sovereign cloud, create the connection through the API (POST /api/v1/platforms) and set the optional overrides in auth_metadata next to tenant_id and client_id:
| Key | Default | Purpose |
|---|---|---|
login_base_url | https://login.microsoftonline.com | Entra token endpoint host |
graph_base_url | https://graph.microsoft.com | Microsoft Graph host |
power_platform_base_url | https://api.bap.microsoft.com | Power Platform admin API host |
power_platform_scope | https://service.powerapps.com/.default | Token audience for the Power Platform admin API |
Dataverse environments need no override: their instance URLs come from the admin API, and the connector follows them only on recognized Dataverse hosts (*.dynamics.com, *.microsoftdynamics.us, *.appsplatform.us, *.dynamics.cn, https only).
Step 4 — Connect in MITRITY
In Settings → Platforms → Connect a platform, choose Microsoft 365 and provide:
| Field | Value |
|---|---|
| Account / Organization | Your tenant domain, e.g. acme.onmicrosoft.com |
| Client secret | The secret value from Step 1 |
| Directory (tenant) ID | From the app Overview page |
| Client ID | The Application (client) ID from Step 1 |
Save, then click Sync now. The connector exchanges the client secret for short-lived tokens at sync time and runs Discover → Observe → Posture.
Observe
The connector imports directory audit activity from auditLogs/directoryAudits, advancing a timestamp high-water-mark cursor each sync so it never re-imports the same event. Imported events carry source = m365, are marked observed (recorded, not gated), and flow to the audit log, Insights, and any configured SIEM destination.
Posture
Findings appear on the connection card in Settings → Platforms. As with every connector, a control that cannot be read is recorded as Unknown rather than OK — see Posture & Security.
Tenant checks
Read from Microsoft Graph on every sync: agent_registration_restricted (non-admin users cannot register applications), security_defaults_enabled, and secure_score.
Power Platform checks
Read from the Power Platform admin API and each environment's Dataverse database on every sync.
| Check | What it looks at | Severity | How to fix |
|---|---|---|---|
power_platform_read | Whether the Power Platform admin API could be read at all. | — (OK / Unknown) | Complete the management-application registration in Step 3. |
power_platform_environment_dlp (per environment) | Whether at least one Power Platform data policy applies to the environment, and whether it blocks unauthenticated chat and public-website knowledge. | High when no policy applies | Create a data policy in the Power Platform admin center (Security → Data and privacy → Data policy) that includes the environment. |
copilot_studio_inventory (per environment) | Whether the environment's Copilot Studio agents could be read, and how many are published. | — (OK / Unknown) | Add the app as an application user of the environment (Step 3). |
Copilot Studio agent checks
Each published Copilot Studio agent is assessed on every sync. These findings are reported only while the condition holds — a check that passes produces nothing, and a finding disappears on the next sync after you fix it. Unpublished agents are inventoried but not assessed, because nobody can reach them.
| Check | What it looks at | Severity | How to fix |
|---|---|---|---|
copilot_studio_authentication | The agent is published with No authentication: anyone with the link, including people outside your organization, can chat with it. | High | In Copilot Studio, set Settings → Security → Authentication to Authenticate with Microsoft (or Authenticate manually) and republish. To prevent it tenant-wide, block the Chat without Microsoft Entra ID authentication in Copilot Studio connector in a data policy. |
copilot_studio_audience | The agent's access-control policy is Any (every user in your tenant) or Any (multi-tenant) (users from other Microsoft 365 tenants). | Medium (Any) / High (multi-tenant) | Share the agent with specific users or security groups, or set its access control to group membership. |
copilot_studio_org_publication | The agent is set up for Teams and Microsoft 365 Copilot with access for everyone in the organization, but it is not in the admin-approved organization app catalog. | Medium | Submit the agent for admin approval (Show to everyone in my org) so it is reviewed before it reaches the whole organization, or narrow its audience. |
copilot_studio_knowledge_scope | A knowledge source is broader than a business location: the whole SharePoint tenant (the tenant root, /sites, /teams or the OneDrive root) or public web content. | Medium | Scope SharePoint knowledge to specific sites, libraries or folders; keep only public websites you own; block the Knowledge source with public websites and data in Copilot Studio connector if public websites are never needed. |
copilot_studio_ungrounded_answers | The agent may answer from the model's general knowledge (Allow ungrounded responses) or from web search rather than only from governed knowledge sources. | Medium | Turn off Allow ungrounded responses and web search in the agent's Generative AI settings. |
copilot_studio_connector_dlp | The agent binds connectors that no applicable data policy classifies explicitly, so they fall into the policy's default group. | Medium | Add the connectors to the Business or Blocked group of the data policy covering the environment, or set the policy's default group for unlisted connectors to Blocked. |
copilot_studio_environment_dlp | The agent runs in an environment with no data policy at all; its connectors, knowledge sources and channels are ungoverned. | High | Create a data policy that includes the environment. |
Every finding carries its evidence (the setting values it was derived from, never a secret) and the remediation above. An environment without a data policy is reported twice on purpose: once for the environment (power_platform_environment_dlp, for whoever owns the platform) and once per published agent in it (copilot_studio_environment_dlp), so the exposure is visible on each agent it affects. When your governance lifecycle is on, a warning on an agent opens a review for that agent at the finding's severity (subject to your review-severity threshold in governance settings), so the fix is tracked to a named owner rather than left on a card.
Graceful degradation
If the tenant is not Copilot-licensed, or a Graph permission was not consented, the connector records Unknown findings and imports whatever it can rather than failing the sync. If the app is not a Power Platform management application, power_platform_read is Unknown and no Copilot Studio agents are discovered; if it is not an application user of an environment, that environment's copilot_studio_inventory is Unknown while the others are still read. Grant the missing access and re-sync to fill the gaps.
Governing a discovered agent
Assign a policy to a discovered agent to move it to governed (governance mode Constrained), or suppress it. Microsoft 365 and Copilot Studio agents are observed and posture-assessed, not enforced in-band, in this release — see read-only by design.
Related documentation
- SaaS-Embedded Agent Governance
- Posture & Security
- LLM Gateway — Azure OpenAI and AI Foundry — inline protection for the Microsoft AI traffic that does leave your workload
- Writing Policies
- SIEM Integration