How Permafrost works

The common CIEM-category mistake is to treat Azure as one permission surface. It is not. Microsoft Cloud has two. They run on different consent flows, surface in different log streams, and live behind different APIs.

The first surface is Azure RBAC: the control plane where role assignments at management group, subscription, resource group, and resource scope decide who can do what to the customer’s Azure resources. Azure RBAC assignments are visible in the Azure Resource Manager APIs and audited in the ARM activity log.

The second surface is Microsoft Graph consent: the directory plane where application permissions are granted to enterprise apps and service principals. Graph consents are visible in the Microsoft Graph APIs and audited in the Entra directory audit log.

Permafrost treats them as distinct first-class surfaces. The semantics, the blast radius, and the remediation pattern on each side are different enough that collapsing them produces worse answers, not simpler ones.

The permission-gap analysis for Azure RBAC is driven by the ARM activity log. Every finding on an RBAC assignment points to a specific activity-log row that proves the assignment is unused, or to the absence of such a row across the measurement window, which is itself the evidence.

That signal is defensible: here is the role assignment, here is the log range we measured against, here is what we did and did not see. The Azure RBAC permission gap is the load-bearing signal in Permafrost and the foundation for the Unused Permission Risk Score (UPRS). UPRS scores Azure RBAC only. Directory-side findings for Microsoft Graph application permissions and Entra directory roles live on a separate first-class surface so the signals stay legible.

Mixing RBAC and Graph activity into one composite score collapses two different kinds of evidence into one number. The customer cannot tell which signal triggered an alert. The tool cannot explain itself. Permafrost keeps them apart on purpose so every finding stays auditable.

Three steps. Read-only throughout. Each step is one-way: Permafrost reaches into the customer’s data plane through Reader-class scopes and nothing more. The customer’s tenant is never modified by the ingest or analyze passes.

1. Ingest. Permafrost pulls identity, permission, and activity data from Microsoft Graph and Azure Resource Manager. The pull cadence depends on the data type and the customer’s tier; identity inventory refreshes more often than slow-changing role-policy data.
2. Analyze. The ingested data is partitioned by customer (more on this below) and fed into three analysis families: permission-gap analysis (the engine behind UPRS), deterministic finding detection (privilege paths, toxic combinations, dormant high-privilege accounts), and pattern matching that powers the incident timeline.
3. Surface. The analysis output is presented through dashboards (Identities, Findings, Roles, PIM, Activity), exportable artifacts (custom Azure roles as ARM / Bicep / Terraform), and the remediation surface that runs in one of three customer-chosen modes.

The analysis runs on three data families.

• Identity inventory. Users (members and guests), security groups, service principals (application identities), managed identities (system-assigned and user-assigned), and AI agent identities (the copilot-class principals that have appeared in modern Azure tenants).
• Permission inventory. Azure RBAC role assignments at every scope, Microsoft Graph application permissions, Privileged Identity Management eligible assignments and their activation policies, and Conditional Access policy context that affects the access picture.
• Activity inventory. ARM activity-log entries for control-plane operations on Azure resources, and the Entra directory audit log for directory-side changes. We pull enough to evidence permission-gap findings and the incident-timeline patterns; we are not a log retention destination.

Permafrost supports customers connecting more than one Azure tenant. Each customer organization owns a workspace. Inside that workspace, the customer connects one or more Azure tenants through read-only consent. The dashboard rolls up across those connected tenants; each tenant is analyzed independently underneath.

The isolation rule has two parts.

Within a customer’s workspace, Permafrost can correlate findings across the tenants that customer has connected. A privileged identity that appears in two of the customer’s connected tenants surfaces in both. The dashboard view rolls up across the tenants that customer has authorized.

Across separate customer organizations, Permafrost does not aggregate. There is no cross-workspace comparison, no benchmark feature that exposes one customer’s data to another, no shared join key that can span workspaces. Every dataset is partitioned by customer at the storage layer; the partition is structural, not just a query-time filter.

When this documentation says “your connected tenants” it means the set of tenants this customer has connected to this customer’s workspace. It never means anything broader than that.