Who’s Really Calling? Decoding Identity Context to Catch Service Principal and Managed Identity Abuse

Machine identities now vastly outnumber humans in most Azure tenants, and they are routinely over-permissioned, long-lived, and sparsely monitored. When a service principal deletes diagnostic settings or a managed identity writes to a storage account, the analyst staring at the Activity Log has to answer a deceptively hard question: which identity actually did this, and on whose behalf? The same operation can come from a human in the Portal, a human running az CLI commands, a custom OAuth app acting on a user's behalf, a service principal with a leaked secret, or a system- or user-assigned managed identity — and in the raw JSON these scenarios look far more alike than they should. Misreading that context is exactly how OAuth consent abuse, leaked SP credentials, and over-privileged managed identities slip past detections written for a human-centric world. This session presents hands-on research mapping six concrete Azure identity scenarios — user via CLI, user via Portal, service principal with application permissions, service principal with delegated permissions, system-assigned managed identity, and user-assigned managed identity — to the exact claims each emits. The result is a three-layer identity-context model that separates human from non-human actors, distinguishes credentialed service principals from Azure-managed identities (flagging impossible combinations as anomalies), and pinpoints the parent resource behind a managed identity so legitimate automation can be whitelisted with precision. Attendees leave with an annotated identity claims matrix, a SIEM-agnostic decision tree, and a tiered starter ruleset they can deploy against their own tenants the week they get home.