Coverage is a ratio. Applications governed, over applications that exist. Most identity programs spend all their time on the numerator: onboarding more applications, closing more of the backlog, reporting a higher percentage each quarter. The denominator gets set once, during an initial discovery exercise, and rarely revisited.

That was always a fragile assumption. Over the past year it became an untenable one.

The denominator is no longer static

Shadow AI changed the math. Employees are adopting AI tools at a rate no discovery exercise was designed to capture. Each tool authenticates to something. Each integration holds a credential. Each credential is an identity, whether or not the organization treats it as one.

None of those identities arrived through a request process. None of them appeared in a discovery exercise conducted before they existed. And none of them are in the denominator the program is reporting against.

The applications being governed did not change. The applications that exist did. The coverage number stayed the same. The actual governed proportion fell. And nothing in the reporting process was designed to notice.

A coverage metric that cannot fall is not measuring coverage.

Non-human identity is not a new concept. The volume is.

Service accounts have existed for as long as enterprise software. Mature identity programs have handled them for years: an owner, a defined purpose, a rotation schedule, a review cycle. The governance model for non-human identities is not the mystery.

What changed is volume, provenance, and rate of change. Provenance meaning where these identities come from and who is accountable for them.

A single AI integration can spawn credentials across a dozen systems. Those identities are created by developers and business users rather than arriving through a central request process. Agentic tooling adds and removes integrations continuously, not at the pace of a quarterly project.

The governance model most programs run was built for identities that arrive through a request, belong to a person, and change a few times a year. Non-human identities arrive through an API call and belong to a workflow rather than a person. New integrations get added, old ones get abandoned, and credentials accumulate in between with no lifecycle process attached to any of it.

Why these credentials are the most exposed

Non-human credentials are structurally attractive to attackers for reasons that have nothing to do with sophistication.

They are typically long-lived because rotating them risks breaking a production integration. They are frequently over-permissioned because the fastest way to make an integration work is to grant broad access and move on. They rarely have a human owner who would notice anomalous use. And they are often exempt from multi-factor authentication because there is no human present to complete a challenge.

Third-party access and non-human identity are largely the same population viewed from two angles: accounts that belong to no employee, sit outside the joiner-mover-leaver process, and reach into systems that matter. The credentials least likely to be rotated, scoped, or monitored are precisely the ones nobody has assigned to a person.

What has to change

The denominator needs to be treated as a live number, not a historical one. Discovery is not a phase. An estate count more than a year old is a historical document, not a measurement. A live denominator requires continuous discovery across multiple sources: SSO logs, expense data, cloud provider inventories, API gateway logs, and developer platforms. Each will miss what the others catch.

Non-human identities need to be counted in the same denominator as applications. Reporting them separately is what allows the primary coverage number to stay comfortable while the ungoverned population grows.

Every non-human identity needs a human owner. Not the team that created it. A named person accountable for whether it still needs to exist. Ownership is what makes every other control possible.

Coverage needs to be measured as a current condition, not a cumulative count. An identity governed eighteen months ago whose owner has left, whose permissions were widened for a migration and never narrowed, and whose credential has never rotated, is not governed. It is recorded.

The binding constraint is volume

An organization adding hundreds of machine identities a year cannot govern them through a process that takes weeks per integration and significant hours of an owner's time. As long as bringing something into governance is expensive, the ungoverned tail will keep growing faster than the program can close it. And the tail is where the exposure lives.

This is the problem Klyro was built to solve. Making the architectural work of onboarding (schema modelling, entitlement design, correlation logic) compound across applications rather than restart at each one, on the IGA platform the organization already owns. The governance model is not the hard part. Deploying it at the rate the estate is actually changing is.

The uncomfortable truth

Most identity programs are not failing to govern the identities they know about. They are governing those reasonably well and reporting a number that reflects it.

The problem is that the number's denominator was set before the estate looked like this, and nothing in the reporting process is designed to notice. Authentication matters. But for non-human identities, it is not the first problem to solve. Enumeration is. You cannot govern what you have not counted, and for the past year the counting has not kept pace with the creating.