Non-Human Identities: Govern Them Like Firewall Rules

Non-human identities are the new firewall rules: access that gets granted under deadline pressure, never gets reviewed, and quietly accumulates until an audit fails. A non-human identity (NHI) is any actor that is not a person, a service account, an API key, an OAuth app, a CI token, and now an AI agent. They already outnumber humans heavily. Veza's 2026 State of Identity & Access report found machine identities outnumber human users 17 to 1, and that just 0.01% of non-human identities control 80% of all cloud permissions. AI agents are about to pour fuel on a fire that was already burning.

The good news for anyone who has run a regulated firewall estate: you have seen this exact failure before, and you already own the cure. Ungoverned rules that nobody recertifies and nobody decommissions are why a rulebase rots. The same lifecycle discipline that keeps a firewall estate audit-ready, inventory, ownership, recertification, decommissioning, least privilege, change control, is what governs machine identities. The vocabulary is new. The control is not.

You already manage thousands of identities nobody reviews

Before a single AI agent arrives, the average estate is already drowning in machine identities, and most are unmanaged. The Cloud Security Alliance's 2026 survey on non-human identity and AI security found only 15% of organizations feel confident they can prevent an NHI-based attack, and more than 16% do not track the creation of AI-related identities at all. You cannot recertify what was never inventoried.

The drift looks identical to a neglected rulebase. Veza found dormant accounts already make up 38% of all accounts, and counted 824,000 orphaned identities, live entitlements with no human owner in the HR system. Each one is the machine-identity version of a firewall rule whose requester left the company three years ago: still permitting traffic, nobody willing to remove it, an open finding waiting for the auditor to notice.

This is firewall rule sprawl, exactly

Walk the lifecycle of a bad firewall rule and the parallel writes itself. A rule goes in fast to unblock a project. It is broader than it needs to be, because narrow takes longer and the change window is closing. The requester moves on. No one is sure if it is still needed, so no one removes it. Repeat for a decade and you have a rulebase no human understands, full of permit-any rules nobody will own. We have written the cure for that estate in the firewall rule recertification guide and the discipline of decommissioning rules.

Now read the same paragraph with "identity" swapped for "rule". An agent or service account gets a broad role fast to unblock a project. The credential is long-lived because rotating it takes effort. The engineer who created it moves teams. No one is sure what depends on it, so no one revokes it. That is how 0.01% of identities end up holding 80% of permissions, and it is why a rulebase audit and an identity audit surface the same three findings: over-broad grants, no owner, no review date.

AI agents make it worse, and faster

A firewall rule is static until a human changes it. An AI agent is not. It requests tools at runtime, spawns sub-agents, and chains actions across systems that were never designed to trust each other, which means the access graph now grows on its own between your review cycles. The credential exposure is already measurable: GitGuardian's State of Secrets Sprawl 2026 found AI-service secrets leaked to public GitHub reached 1.27 million, up 81% in a year, and that 24,008 secrets were exposed in Model Context Protocol config files alone, with 2,117 still valid. The plumbing that wires agents to tools is the new place keys go to leak and never get rotated.

An agent also fails open in a way a rule never does. A hijacked agent does not need a privilege-escalation exploit; it just uses the standing authority you already handed it, the confused-deputy pattern we covered in AI agent authorization, the control prompt injection cannot beat. Governing the identity is how you bound that blast radius before the injection ever lands. The full enumeration sits in the AI agent security threat model.

Apply the firewall-rule lifecycle to machine identities

Every stage you already run on rules maps onto identities one-for-one. Run them on your NHIs and the sprawl stops compounding.

The point is not to invent an AI-identity governance programme from scratch. It is to extend the one your firewall estate already runs, the same instinct behind optimizing a bloated rulebase and the zero-trust change controls regulated estates already operate.

What the auditor will ask

Under NIS2, DORA, and ISO 27001, access control is not satisfied by "the model was told what it may do", any more than "the operator was told to be careful" closes a finding on an out-of-scope firewall change. These frameworks ask access-control questions that apply to a non-human actor exactly as they apply to a person.

• NIS2 Article 21 requires access-control and asset-management measures. An untracked population of agent and service-account identities is an unmanaged asset class and an access-control gap, the same evidence terrain as NIS2 firewall evidence.
• DORA demands ICT risk management with identity and access controls over every component that can affect a financial entity's operations, autonomous agents included. The mapping mirrors DORA firewall compliance.
• ISO 27001 Annex A 5.16 and 8.2 cover identity lifecycle and privileged access rights, with no exemption for non-human identities. The recertification evidence looks like the ISO 27001 firewall audit checklist, applied to accounts and agents.

External guidance is converging on the same point. The Cloud Security Alliance's non-human identity work and CISA's Zero Trust Maturity Model both treat machine and workload identity as a first-class control plane, not an afterthought.

A governance checklist before your next agent ships

Every one of these should have a written answer on the same risk register as your firewall rules.

• Inventory. Can you list every non-human identity, including agents, and what each can reach? If not, that is finding one.
• Ownership. Does every identity have a named human owner recorded at creation, or are you already generating orphans?
• Recertification. Is there a review cycle that asks "still needed, still scoped right" for machine identities, the way you recertify rules?
• Decommissioning. When a project ends or an engineer leaves, is the identity revoked, or does it join the dormant 38%?
• Least privilege and credential life. Are grants scoped to the task with short-lived credentials, or broad roles with long-lived keys?
• Audit. Can you reconstruct which identity did what, under whose authority, on what input?

Why it matters

The agentic wave is being sold as a brand-new security category, and parts of it genuinely are. But the load-bearing control is one your discipline already encodes: access is granted to a named owner, scoped to a need, reviewed on a cycle, and removed when the need ends. Firewall estates that skipped that discipline ended up with rulebases no one could defend in an audit. Identity estates that skip it now will end up with 824,000 orphans that can act on their own. Treat every non-human identity, every agent included, as a privileged grant with a lifecycle, and the audit becomes evidence you already have rather than the finding on the front of the report.

Bringing agents or machine identities into a regulated estate? The free NIS2 Readiness Check covers exactly this: where your non-human access is inventoried, owned, and recertified, where it is not, and what an auditor will ask for.