Non-Human Identity Governance: a problem that didn't exist at scale before.

The shift, in one diagram

If you ran an Active Directory audit ten years ago, you were mostly counting people. Run that same audit today and the math has flipped. Service accounts, workload identities, API tokens, CI/CD runners, OAuth apps, RPA bots, and now AI agents — they outnumber humans by an order of magnitude, and almost none of them go through the joiner-mover-leaver process that governs human accounts.

The risk profile is also different. Human identities go through onboarding and offboarding. NHIs frequently get created during a project, granted broad permissions to make the application work, and then quietly persist after the project ends, the owner leaves, and the documentation rots. The result is overprivilege at industrial scale — a standing attack surface that grows every quarter and almost never shrinks on its own.

The failure loop you're trying to break

Almost every NHI breach we see in the field follows the same six-step pattern. The pattern is so predictable that the entire governance program can be designed around interrupting specific steps.

Step 1 — Discover what you actually have

Every mature NHI program starts with the same painful realization: nobody knows how many non-human identities the organization actually has. The first deliverable isn't a policy. It's a certifiable inventory — a continuously updated source of truth covering every machine identity across AD, Entra ID, your clouds, your secrets vault, your CI/CD platform, and your SaaS apps.

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} `
  -Properties PasswordNeverExpires, PasswordLastSet, LastLogonDate, ServicePrincipalName |
  Where-Object { $_.ServicePrincipalName -or $_.SamAccountName -like "svc_*" } |
  Select-Object SamAccountName, PasswordLastSet, LastLogonDate, `
    @{N="DaysSinceRotation";E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}} |
  Sort-Object DaysSinceRotation -Descending |
  Format-Table -AutoSize

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true} `
  -Properties LastLogonDate, ServicePrincipalName, Description |
  Where-Object { ($_.ServicePrincipalName -or $_.SamAccountName -like "svc_*") `
    -and ($_.LastLogonDate -lt $cutoff -or $null -eq $_.LastLogonDate) } |
  Select-Object SamAccountName, LastLogonDate, Description |
  Export-Csv -Path "dormant-nhis.csv" -NoTypeInformation

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

Get-MgServicePrincipal -All | ForEach-Object {
    $sp = $_
    $perms = Get-MgServicePrincipalAppRoleAssignment `
        -ServicePrincipalId $sp.Id -ErrorAction SilentlyContinue
    if ($perms) {
        [PSCustomObject]@{
            DisplayName = $sp.DisplayName
            AppId = $sp.AppId
            PermissionCount = $perms.Count
        }
    }
} | Where-Object { $_.PermissionCount -gt 0 } |
    Sort-Object PermissionCount -Descending

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
  Get-ADUser -Properties ServicePrincipalName, Description, LastLogonDate |
  Where-Object { $_.ServicePrincipalName -or $_.SamAccountName -like "svc_*" `
    -or $_.Description -match "service|app|automation|backup|sql" } |
  Select-Object SamAccountName, Description, LastLogonDate |
  Format-Table -AutoSize

Decision tree: is this NHI safe to disable?

The single most useful tool for the cleanup phase. Click through the questions for any candidate identity and the tree returns a concrete action.

Ownership: the organizational fix

Inventory alone doesn't solve governance. NHI ownership does. Every non-human identity needs a named human owner who is accountable for it. Not "IT." Not "the application team." A specific person.

Without explicit ownership, two things happen. First, access certifications become rubber-stamping, because nobody wants to be the person who disabled the account that broke production. Second, when something does go wrong, there's no one to call.

RBAC for machine identities

Once you know what you have and who owns it, the next question is what each identity is allowed to do. Role-Based Access Control is the structural mechanism that enforces least privilege at scale. Machine identities have far more predictable access requirements than humans, which is the structural advantage RBAC exploits — a backup service knows exactly which file shares it needs; a deployment runner knows exactly which environments it touches.

The four-step RBAC pattern

1. Define roles based on function, not identity. role-backup-reader, role-deployment-runner-prod.
2. Scope each role to the minimum permission set required, on the minimum resource set required.
3. Assign identities to roles. Never grant permissions directly to the identity.
4. Review role definitions quarterly and prune permissions unexercised in 90+ days.

Find permission drift in your existing roles

az role assignment list --all `
  --query "[?principalType=='ServicePrincipal']" -o json |
jq -r ".[] | [.principalName, .roleDefinitionName, .scope] | @tsv" |
sort | uniq -c | sort -rn | head -50

Secrets management

Non-human identities authenticate with secrets — passwords, API keys, certificates, OAuth tokens. The 18.1 million tokens SpyCloud recaptured didn't escape from vaults. They escaped from source code, config files, shared spreadsheets, and Slack messages. A real secrets program has four pillars:

Detect committed secrets in your repos right now

# Scan current repo for committed secrets, full history
gitleaks detect --source . `
  --report-format json `
  --report-path leak-report.json `
  --verbose

Lifecycle management

The operational backbone. Every NHI moves through four stages, and weakness in any one of them undermines the others.

A mature lifecycle program directly prevents the accumulation of orphaned and stale identities — they exist precisely because deprovisioning gets skipped. It also embeds credential rotation as a recurring lifecycle event rather than a special project, which is the only way rotation actually happens at scale.

Continuous monitoring & behavioral analytics

Governance controls established at provisioning time aren't enough on their own. RBAC, secrets management, and lifecycle workflows define what should happen. They don't tell you what is happening right now.

For each NHI, establish a behavioral baseline (expected source IPs, auth times, target resources, privilege use, data volumes), then alert on meaningful deviations. The matrix below maps the four observed patterns to concrete responses.

Find authentication from unusual source IPs (Sentinel/KQL)

SigninLogs
| where TimeGenerated > ago(7d)
| where ServicePrincipalName != "" or AppDisplayName != ""
| summarize SourceIPs = make_set(IPAddress),
            AuthCount = count() by ServicePrincipalName, AppDisplayName
| extend IPCount = array_length(SourceIPs)
| where IPCount > 3
| sort by IPCount desc

The hardest case: governing AI agents

AI agents break assumptions that even modern NHI programs rely on. A traditional service account does one thing. An AI agent, by design, decides what to do next, calls APIs, queries databases, writes to systems, and chains tools together based on a prompt. The traditional notion of "expected behavior" gets fuzzy.

When something goes wrong with an AI agent, you need to be able to answer: which agent did this, on whose behalf, under what policy? A shared identity makes all three questions unanswerable. Tool-level scoping is what prevents the prompt-injection pattern where an attacker convinces the agent to use a capability it technically has but shouldn't be using in this context.

Mapping NHI controls to regulatory frameworks

Most regulatory frameworks don't say "non-human identity" by name. The requirements absolutely apply — they're just phrased generically. A practical mapping:

The pattern: every framework asks for access control, audit evidence, periodic review, and incident response. A mature NHI program built on lifecycle management, RBAC, secrets management, and continuous monitoring produces this evidence automatically and continuously, instead of as a fire drill before the audit.

The 9-month roadmap

Most organizations cannot do all of this at once, and they shouldn't try. Here's the sequence that works.

The 15-minute weekly NHI hygiene checklist

Once the program is running, this is what keeps it healthy. Block 15 minutes on a calendar every Friday afternoon and run through it.

The bottom line

The directory is no longer a roster of people. It's a control plane for an automated enterprise. Govern it accordingly.

Non-human identity governance is the most significant structural shift in identity security right now, and it didn't exist at this scale even three years ago. AI agents are accelerating the curve, not creating it — service accounts and workload identities were already outpacing humans before LLMs showed up. Agents are just making the gap impossible to ignore.

For sysadmins: the mental model has to shift. Service accounts are not plumbing. They are identities, and they need ownership, least privilege, lifecycle control, credential protection, and behavioral monitoring — the same controls human identities have had for two decades.

For CTOs and COOs: this is a control-plane investment, not a tool purchase. The organizations that build a real NHI governance discipline in 2026 will have cleaner directories, faster audits, fewer breaches, and the ability to deploy AI agents in production without wondering what they're actually doing in there. The ones that don't will keep finding out the hard way, one infostealer report at a time.