04 Blast Radius Dependency Rollup

Query

// Phase 3, query 4 of 4: Blast-radius dependency rollup.
//
// *** DRAFT, UNTESTED *** -- see the repository README "Project status" warning.
//
// Purpose: a KQL-native approximation of the Phase 2 evaluator's blast-radius
// simulation (access-graph/scripts/evaluate-access.mjs), for ad hoc exploration
// directly inside the workbook's "Blast Radius" page without waiting for a full
// evaluator run. It answers: "if I remove {TargetResourceApp}/{TargetPermission}
// tenant-wide, how many agent identities, blueprints, and business processes
// are touched, split into confirmed (actively used in the lookback window) vs.
// potential (granted but not observed in use)?"
//
// This query CANNOT discover "business processes" or "blueprint family" on its
// own -- neither concept exists as a native column in Microsoft Graph activity
// logs or Entra sign-in logs. You must maintain your own reference table (a
// Log Analytics custom table, e.g. AgentBusinessDependencies_CL, or an
// externaldata() CSV/JSON) with at least these columns, one row per
// (agent, business process) dependency:
//   AgentServicePrincipalId : string  -- matches ServicePrincipalId in Graph activity/sign-in logs
//   AgentBlueprintId        : string  -- your blueprint/agent-family label
//   BusinessProcessId       : string
//   BusinessProcessName     : string
// Without this table, the query still returns the agent- and blueprint-level
// counts (which ARE derivable from native tables), but affectedBusinessProcess
// columns will be empty and must be sourced from the Phase 2 evaluator's JSON
// output instead, which reads businessProcesses[] from the canonical model.
//
// Populates (access-model-evaluation-schema.json): blastRadiusResults[]
// confirmedAffectedAgentCount / potentiallyAffectedAgentCount /
// affectedBlueprintIds / affectedBusinessProcessIds, computed directly from
// telemetry as a cross-check against the evaluator's file-based computation.
//
// Required tables: MicrosoftGraphActivityLogs, plus your own
// AgentBusinessDependencies_CL reference table (optional, see above).
let TargetResourceApp = "Microsoft Graph"; // PLACEHOLDER
let TargetPermission = "Sites.ReadWrite.All"; // PLACEHOLDER

About this query

Explanation

This query is designed to estimate the impact of removing a specific permission from a resource across an entire tenant. It aims to determine how many agent identities, blueprints, and business processes would be affected by such a change. The query distinguishes between those that are actively used (confirmed) and those that are granted but not observed in use (potential).

Here's a simplified breakdown of the query:

Purpose: The query simulates the impact of removing a specific permission (e.g., "Sites.ReadWrite.All" for "Microsoft Graph") across all users in a tenant. It helps identify which agents, blueprints, and business processes would be affected.
Data Sources:
- MicrosoftGraphActivityLogs: Used to identify which service principals (agents) have been granted the specified permission and whether they have actively used it.
- AgentBusinessDependencies_CL (optional): A custom table that links agents to business processes and blueprints. This table is necessary to identify affected business processes and blueprints, as these concepts are not natively available in Microsoft logs.
Process:
- The query looks at activity logs within a specified time window (90 days by default) to find service principals with the target permission.
- It checks if these permissions have been actively used (e.g., through write operations like PATCH, POST, PUT, DELETE).
- It categorizes each service principal as "confirmed" (actively used) or "potential" (granted but not used).
- It attempts to join this data with the optional custom table to identify affected business processes and blueprints.
Output:
- Counts of confirmed and potentially affected agents.
- Lists of affected blueprint IDs and business process IDs.

This query provides a quick, ad-hoc way to explore the potential impact of permission changes without running a full evaluation. However, it requires additional data (custom tables) to fully assess business processes and blueprints.