AI Pulse — Permissions Reference

·How to read this document

Three identities can hold permissions in an AI Pulse install. Each row below names the exact one, so your access reviews map cleanly to what's actually in your tenant.

Identity	What it is	What it's for
The managed identity	A system identity created by the ARM template, unique to your install.	Reads Azure resources, cost data, and Microsoft Graph to populate dashboards.
The sign-in app	An Entra app registration you create before install (`Connect-AIPulseTenant.ps1`).	Lets your people sign into the AI Pulse portal. Nothing else.
Your own admin account	The person running install/setup scripts.	Needs enough privilege to grant the two identities above their permissions — see each section.

auto-granted happens during ARM deployment, no extra step post-install step one script, run once after deploying optional only if you want the matching widget

1Azure roles — granted automatically

Assigned to the managed identity by the ARM template during deployment. Every one is a built-in Azure role, least-privilege, read-only.

Role	Role ID	Scope	Why
Reader	`acdd72a7-3385-48ef-bd42-f606fba81ae7`	Subscription	See resources and their configuration to build the AI inventory.	auto
Cost Management Reader	`72fafb9e-0641-4937-9268-a91bfd8191a3`	Subscription	Read spend figures for the cost dashboards.	auto
Key Vault Secrets User	`4633458b-17de-408a-b874-0445c86b69e6`	The install's own Key Vault only	Read its own deployment secrets (database password, gateway key, tracing key) at start-up.	auto

Never Contributor, Owner, or User Access Administrator. The install-time admin account needs one of those roles to grant the three above — but the managed identity itself never receives write access to anything.

2Microsoft Graph — granted in one post-install step

Granted to the managed identity by running Grant-AIPulseGraphAccess.ps1 once after deployment (the identity doesn't exist until the ARM deployment completes, so this can't happen automatically during install). Requires Privileged Role Administrator. Every permission is application, read-only.

Permission	Permission ID	Why
`Organization.Read.All`	`498476ce-e0fe-48b0-b801-37ba7e2685c6`	Detect licences (Copilot, Purview entitlement).	post-install
`User.Read.All`	`df021288-bdef-4463-88db-98f22de89214`	Let admins assign access by typing a person's email, not just an ID.	post-install
`Group.Read.All`	`5b567255-7703-4780-807c-7be8301ae99b`	Let admins assign access by typing a group's name.	post-install
`Directory.Read.All`	`7ab1d382-f21e-4acd-a863-ba3e13f7da61`	Directory reads underpinning the two rows above.	post-install
`AuditLog.Read.All`	`b0afded3-3588-46d8-8b3d-9842eff778da`	Admin audit trail and Microsoft 365 Copilot activity.	post-install
`Application.Read.All`	`9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30`	Discover unsanctioned ("shadow") AI apps registered in your tenant.	post-install
`DelegatedPermissionGrant.Read.All`	`7e05723c-0bb0-42da-be95-ae9f08a6e53c`	Read OAuth consent grants — the other half of shadow-AI discovery.	post-install

Grant a subset now and add the rest later with Grant-AIPulseGraphAccess.ps1 -Roles. Anything not yet granted shows an honest "permission pending" state in the portal — no widget fails, none are silently blank.

3Optional roles — you grant, per widget

Not requested by any script. Grant these only if you want the matching security-depth widgets — each is a standard built-in Azure role, assigned the same way as any other Reader role (Entra ID → IAM → Add role assignment, scoped to the managed identity).

Role	Scope	Powers
Monitoring Reader	Subscription	Deeper Azure Monitor metrics.
Security Reader	Subscription	Microsoft Defender for Cloud posture and alerts.
Log Analytics Reader	The workspace you connect	Per-agent trace queries.
Sentinel Reader	The workspace you connect	Microsoft Sentinel analytics signals.

Separately, connecting Microsoft 365 (Copilot usage, Purview labels) is done by your own M365 Global Admin running scripts/m365/run-all-m365-setup.ps1 under their own session — this isn't an app permission grant to AI Pulse at all; it's your admin creating the labels/policies directly.

The Entra app registration created by Connect-AIPulseTenant.ps1 is scoped to exactly one thing:

Permission	Permission ID	Type	Why
`User.Read`	`e1fe6dd8-ba31-4d61-89e7-88639da4683d`	Delegated	Standard OIDC sign-in — nothing else. It never reads your directory, licences, or audit logs; those all belong to the managed identity above.

5Auditing and revoking access

See what's granted: Entra admin center → Enterprise applications → search for your install's managed identity or the "AI Pulse" sign-in app → Permissions.
Revoke a Graph permission: remove the corresponding app role assignment from the managed identity's service principal. The matching widget returns to "permission pending" — nothing else changes.
Revoke an Azure role: remove the role assignment in Subscription → Access control (IAM). The dashboards relying on it go dark cleanly, with no partial or stale data shown.
Full audit trail: every grant/revoke against Entra ID is itself recorded in your own tenant's Entra audit log — AI Pulse doesn't need to be involved to review this history.

SYLVA Labs Pte Ltd · AI Pulse — Permissions Reference. Pre-release draft.

Companion to Azure services, data & security. Permission IDs reflect the current shipping install package (Grant-AIPulseGraphAccess.ps1, mainTemplate.json).

Permissions reference

Contents

On this page

·How to read this document

1Azure roles — granted automatically

2Microsoft Graph — granted in one post-install step

3Optional roles — you grant, per widget

5Auditing and revoking access

Contents

On this page

·How to read this document

1Azure roles — granted automatically

2Microsoft Graph — granted in one post-install step

3Optional roles — you grant, per widget

4The sign-in app's own permission

5Auditing and revoking access