Non-Human & Agentic Identity Governance

For the first time, the identities an enterprise cannot see outnumber the ones it can. Across the estates analysed in Orchid Security’s Identity Gap: 2026 Snapshot, 57% of identity sits outside the systems meant to govern it — and the fastest-growing part of that invisible majority is non-human: service accounts, API keys, and now AI agents.

What counts as a non-human identity

A non-human identity (NHI) is any credential that authenticates and acts without a person directly behind it in the moment — service accounts, API keys, OAuth tokens, webhooks, and now AI agents and the MCP servers that connect them to the rest of the estate. Industry surveys — CyberArk’s Identity Security Landscape among them — put the ratio of non-human to human identities at roughly 45 to 1 in a typical enterprise. Most governance programmes were built for the 1, not the 45.

Why non-human identity is harder to govern

Human accounts go through a joiner-mover-leaver process anchored to HR events: someone starts, moves teams, or leaves, and an identity process reacts. Non-human identities have no equivalent trigger. A service account or an AI agent’s credential is typically created by a developer in minutes — no procurement gate, no ticket, no expiry. Orchid Security’s Identity Gap: 2026 Snapshot found that 67% of non-human accounts are created directly inside applications, unseen and unmanaged by the organisation’s IAM programme, and that 40% of accounts overall are orphaned — still active after the people who owned them have gone.

Agentic identity: the fastest-growing category

Agentic identity is non-human identity’s newest and fastest-growing subset — the credentials held by local AI assistants, agent frameworks, and the MCP servers that connect them to email, code repositories, databases and internal APIs. An MCP server is typically wired up with standing credentials so an assistant can act without asking each time, and it is usually set up by one developer, in one config file, with no identity process anywhere in the path. There is no joiner-mover-leaver process that covers an MCP server: when the developer who wired it up moves on, the credential stays behind and keeps working.

Server-side discovery tools struggle here specifically because the delivery mechanism is so mundane: API keys pasted into dotfiles, database passwords in .env files, tokens sitting in shell histories. An application-layer scan can see the account inside an application; it cannot see the copy of that account’s credential sitting in a config file on a developer’s laptop. That surface only becomes visible with discovery at the endpoint itself.

How NDGM finds what other tools miss

NDGM’s Reeve edge agent runs on endpoints and finds sprawled secrets and local AI/MCP identities — the credentials living in dotfiles, .env files and tool configuration files that server-side scans never reach. Reeve is a Go single binary: read-only, metadata-only, and outbound-only. It records that a credential exists, what kind it is, and where it sits — never the secret’s value or the surrounding file contents. That is a privacy-preserving design choice, not a policy promise.

Finding an ungoverned identity is a diagnosis, not a cure. NDGM closes the loop: every non-human and agentic identity gets a named owner, a governed lifecycle, and — where a finding demands it — approval-gated credential rotation and secret vaulting. Govern-only tools stop at the report.

Frequently asked questions