The account stayed. The knowledge left.

Audits answer a specific question: are the documented controls operating as designed, for the applications in scope? For non-human identities, that usually means an owner field is populated, a rotation policy is in place, and privileged accounts are reviewed. Those are real controls. But they measure whether the account is documented, not whether it is understood. And they only apply to applications that were in scope to begin with.

An audit can confirm that a service account has an owner on record and a review on file. What it rarely confirms is whether that owner still knows what the account does. The controls can be operating perfectly while the knowledge behind them has quietly disappeared.

That gap used to be small enough to live with. It is not small anymore. Every integration, every automation, every pipeline, and now every AI agent brings its own service account, API key, or token. Nobody decided to create thousands of non-human identities. They accumulated one reasonable request at a time, each one approved for a good reason, most of them never looked at again.

You cannot see what you never connected

A large share of those identities live inside applications. When an application is connected to IAM and aggregated for the first time, they show up in the uncorrelated accounts: integration users, service accounts, local admins, API users, all with access and credentials, and none tied to a person. That list is often the first real NHI inventory an organization has ever seen, and nobody asked for it.

If the application was never connected, that list never appears. Its non-human identities stay exactly where they are, fully functional and completely invisible. Not every NHI lives inside an application's account store. Cloud workload identities and SaaS-to-SaaS grants often sit elsewhere. But the ones that do live inside applications can only be seen if the application is connected. Every application left out of IAM takes its non-human identities with it.

Orphans by default

An orphan account is an account whose owner is gone. A non-human identity starts in a similar place. It has no manager, no HR record, and no one to correlate it to. Until someone claims it, it is effectively an orphan.

The natural owner is the person who asked for it. Someone requested that service account or API key for a reason, and that person knows what it does and why it exists. The application owner approved it, because they decide what is allowed to exist inside their application. Those are two different responsibilities, and both matter. The requester owns the purpose. The app owner owns the permission.

Where it breaks

The model holds until the requester leaves.

When they do, the account does not leave with them. It stays in the application with the same access and the same credentials. What leaves is everything anyone knew about it: what it does, what depends on it, why it was created. The account stayed. The knowledge left.

Ownership then falls back to the app owner, and this is where the problem gets stuck. The app owner did not request the account, does not know what it does, and has no reason to track it. When it finally surfaces in a review or an audit, they face a choice with no good option. Turning it off might break a process nobody documented. Leaving it on means accepting access nobody can explain. Nobody wants to own it, and nobody dares to turn it off.

So it gets flagged as an exception. The exception gets approved. And the account goes back to exactly where it was, waiting for the next review to find it again. Each time around, the people who might have remembered are further away and the answer is harder to recover. An exception is not a decision. It is a deferral with paperwork.

Before the knowledge walks out the door

By the time an orphaned NHI is discovered, the easiest moment to answer the question has usually passed. That moment was before the requester left, when someone could still answer the only question that matters: what does this account do?

If the application is connected and the non-human identity is tied to the person who requested it, that person's mover or leaver event can do what it already does for their own access. It can trigger a handoff. Ownership gets reassigned, context gets captured, and the account moves to someone who understands it while the answer still exists. This isn't a new control. It's the joiner, mover, leaver discipline organizations already run for people, applied to the identities those people created.

None of that is possible unless IAM can see both the person and the account. That is what connecting the application actually delivers. It doesn't just add another app to a coverage number. It gives every non-human identity inside it a lifecycle that follows a human one.

The question worth asking

How many non-human identities in your environment have a requester on record? If that person left tomorrow, who would know what their service account does? And how many of those accounts sit in applications that have never been connected, where the question can't even be asked?

The non-human identities are already there. They were created for good reasons, by people who knew exactly why they needed them. The only question is whether that knowledge gets captured while those people are still around, or whether it becomes another exception waiting to be found.

Where Klyro fits

Everything above depends on one precondition: the application has to be connected. That is exactly where most identity programs stall. The big, well-documented applications get integrated first, and the long tail of legacy systems, custom tools, and niche SaaS waits in a backlog because every connector means research, schema modeling, and ongoing maintenance that the team doesn't have time for. That backlog is where the invisible non-human identities live. Klyro exists to close it. We onboard applications into your existing IGA platform, including the ones that were always too custom or too disconnected to justify the effort, and keep those integrations accurate as the applications change. Every application we connect brings its service accounts, API keys, and integration users into view, where they can be tied to a requester and given a lifecycle before the person who understands them walks out the door. Connecting the application isn't the whole answer, but it is the step that makes the rest of the answer possible.