Security Model

Security & permissions model

A consolidated view of how the solution authenticates, what it can access, and how data is protected. The detailed, step-by-step grants live on Prerequisites and Deployment Guidance; this page explains the model.

Identities

The solution uses two Entra ID app registrations (service principals):

• Installer — used only during install/upgrade to create & configure the Azure resources. Needs Owner of the resource group + Reader on the subscription.
• Runtime — used by the running importers to read Microsoft 365 data and access the Azure resources.

See Prerequisites → Solution service principals.

What the runtime account can access

Two distinct kinds of access, both held by the runtime service principal:

1. Microsoft Graph & Microsoft 365 API permissions (application permissions, admin-consented) — read-only access to the workloads you enable. Full list and per-permission reasons: Prerequisites → Permissions.
2. Azure RBAC roles — data-plane access to the solution's own Azure resources (Storage, Redis, Service Bus, Cognitive). Assigned automatically by the installer on the resource group. Full list: Prerequisites → Azure RBAC roles.

All Microsoft 365 access is read-only — the solution never writes back to your tenant's workloads.

Secrets & Key Vault

• The runtime account's client secret is stored in Key Vault and read by the importer at run time; it is also present as the ClientSecret app setting created by the installer.
• Prefer certificate authentication for the runtime account where possible — the certificate's private key lives in Key Vault and no client secret is needed. See Certificate authentication.
• The runtime account is granted Get/List secrets on the vault via a Key Vault access policy (not an Azure RBAC role).

Authenticating to Azure services (RBAC-first)

The solution prefers Entra ID (RBAC) authentication over keys wherever the service supports it:

Service	How the runtime authenticates
Service Bus	Entra ID RBAC (Azure Service Bus Data Owner). No SAS keys — works with namespaces that have local/SAS auth disabled.
Redis	Entra ID (AAD) token auth when access keys are disabled (Data Owner access-policy assignment).
Storage	Entra ID RBAC (Storage Blob Data Contributor).
Cognitive Services	Key, with automatic fallback to Entra ID RBAC (Cognitive Services User) when key auth is disabled.
Key Vault	Entra ID token + a vault access policy (Get/List secrets).
SQL Database	SQL authentication via the SPOInsightsEntities connection string.

Network security

• Private endpoints can lock every PaaS resource to a VNet with public access disabled — see Private endpoints.
• The installer can enable the Key Vault firewall and the SQL Server firewall, allow-listing the installer's IP and the App Service outbound IPs.
• See the Network & firewall rules the installer machine needs.

Data privacy

• All collected data is stored in your own tenant and Azure subscription — in the analytics SQL database. The one exception is Azure AI Language (Cognitive Services), which is optional and off unless you configure it: see Copilot prompt content below and the bullet on content & sentiment.
• De-identified (anonymised) usage reports must be turned off in the Microsoft 365 admin center, otherwise activity can't be matched to real users. See Prerequisites → Tenant & subscription configuration.
• Content & sentiment: when Azure AI Language (Cognitive Services) is enabled, Teams chat, page comments, (optional) sent-email bodies and (optional) Copilot prompts are scored for sentiment/keywords. This is optional and off unless configured.
• Anonymous usage telemetry is opt-in and contains no tenant data — only build version and which imports are enabled. Source is public and the receiver is documented: Telemetry Service.
• What is (and isn't) collected per workload: What data is collected.

Copilot prompt content

Applies to the CopilotInteractionHistory import, added in Stable build 1791. Off by default.

Worth stating plainly, because it is the one place where user-authored content can leave the tenant.

With CopilotInteractionHistory on and Cognitive Services not configured: prompt and response text are never stored and never sent anywhere. Only derived statistics are kept — word and character counts, attachment / link / mention counts, response latency, and similar.

With CopilotInteractionHistory on and Cognitive Services also configured: prompt text is sent to Azure AI Language so that a language, a sentiment score and keywords can be extracted. The prompt text itself is still not stored — but the extracted keywords are, and a keyword can amount to a whole short prompt. So:

• Prompt content leaves the tenant boundary for analysis.
• A recognisable fragment of it is persisted in copilot_interaction_keywords → keywords.
• Anyone with access to the Reports page can see the resulting keyword word cloud.

Three controls are worth knowing about:

Control	Effect
Leave Cognitive Services unconfigured	No prompt text leaves the tenant. Statistics still collected. The three prompt-insight charts are hidden and the Reports page says why.
UserGroupsFilter	Scopes the import to named groups. Without it the import is tenant-wide, so set it if you intend a pilot.
Clean Data By User StoredProc.sql	Per-user erasure. It deletes that user's interactions, sessions, watermarks, extracted keywords and usage-report rows. Re-run the CREATE OR ALTER after upgrading — an older deployed copy predates these tables and will leave the data behind.