Non-Human Identities Are the New Shadow IT: A CISO's Guide to Machine Identity Governance

Every employee who leaves your company gets offboarded. Their badge stops working, their email is suspended, their access is revoked. There is a process, an owner, and an audit trail. Now ask the same question about the API key a contractor hardcoded into a CI pipeline two years ago, the OAuth app a developer authorized for a SaaS integration that got abandoned, or the MCP server a teammate spun up last week to give an AI coding agent access to your internal wiki. Who owns those? When do they expire? Would anyone notice if they were used at 3 a.m. from a residential proxy?

That gap is the entire problem. Non-human identities - the credentials software uses to authenticate to other software - now vastly outnumber the humans in your organization, and almost none of them have an HR record, a manager, or a natural end date. They are, in the most literal sense, the new shadow IT. And the fastest-growing, least-governed subset of them are AI agents and the MCP servers they connect to.

What is a non-human identity?

A non-human identity (NHI) is any digital identity used to authenticate and authorize a software entity rather than a person. The category is broad and growing:

• Static credential NHIs - API keys, long-lived secrets, SSH keys, and certificates
• Account-based NHIs - service accounts and machine accounts that act inside your systems
• Delegated-access NHIs - OAuth applications, access tokens, and refresh tokens that grant app-to-app access
• Workload identities - cloud workload credentials, Kubernetes service tokens, IAM roles, and OIDC federation
• Agentic identities - AI agents, sub-agents, and MCP clients that invoke tools autonomously

What unites them is what they lack. An NHI has no interactive login, no manager to deprovision it, no quarterly access review tied to a person, and no offboarding timeline driven by a resignation letter. It is created to solve an immediate engineering problem and then it persists - often with broad privileges - long after anyone remembers why it exists. That is precisely the behavior pattern of shadow IT, which is why we argue the agentic layer is just the latest and most dangerous chapter of the same story we told in our piece on why AI agents are the new shadow IT.

The scale: machine identities have quietly taken over

The ratio of machine to human identities is large, accelerating, and reported differently depending on who is counting and what environment they measure - so it is worth attributing precisely rather than quoting a single number.

Whichever figure fits your environment, the trend is unambiguous: machine identities now dominate the identity population, they are growing fastest where AI and cloud adoption are fastest, and a large share carry sensitive or privileged access. The supply-side numbers are just as stark. GitGuardian's State of Secrets Sprawl reported 23.8 million secrets leaked on public GitHub in 2024 (up 25% year over year), and 28.65 million new hardcoded secrets in public GitHub commits in 2025 - the largest annual jump on record - with leaks tied to AI services up 81%. Most of those leaked secrets stay valid; GitGuardian found a majority of secrets leaked years earlier remained active. An identity layer this large, this fast-growing, and this leaky is not a niche concern; it is a dominant attack surface.

The OWASP Non-Human Identities Top 10 (2025)

In 2025 OWASP published a dedicated Non-Human Identities Top 10, giving security teams a shared vocabulary for the risks. Notably, the list ranks Improper Offboarding at #1 - reflecting how often the dormant, forgotten identity becomes the exploited weakness.

The rest of this guide uses the five-stage NHI lifecycle as its spine, mapping each stage back to the OWASP items it mitigates and to a real breach that shows what failure looks like.

The non-human identity lifecycle

Governance is not a product you buy; it is a lifecycle you run. Corroborated across guidance from Netwrix, Okta, Token Security, and GitGuardian, the lifecycle has five stages.

1. Discovery and inventory

You cannot govern what you cannot see. The first stage is moving from zero visibility to a centralized inventory by scanning cloud accounts, SaaS apps, CI/CD systems, and directory services for every credential, service account, token, and key. Most organizations discover far more NHIs than they expected. This stage underpins everything else - an identity missing from the inventory is, by definition, ungoverned. For the agentic layer specifically, see our walkthrough on how to build an AI agent inventory and the companion piece on building an MCP server registry.

2. Secure provisioning

New NHIs should be created with least privilege by default, with credentials issued and stored through a secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than pasted into code or config. This stage is where you prevent OWASP NHI2 (Secret Leakage), NHI4 (Insecure Authentication), NHI5 (Overprivileged NHI), and NHI8 (Environment Isolation). The agentic equivalent - scoping tool permissions tightly so an agent can only touch what its task requires - is covered in our guides on least privilege for AI agents and secrets management for AI agents.

3. Ongoing monitoring

Provisioning is a point in time; behavior is continuous. This stage means logging every NHI's authentication and activity, baselining normal behavior, and alerting on deviations - a service account that suddenly enumerates repositories, a token used from a new region, an agent that starts calling tools it never touched before. Monitoring catches NHI5 (overprivileged use that goes active), NHI9 (reuse), and NHI10 (human use of a machine identity). For agents this is the realm of runtime monitoring and anomaly detection and a complete AI agent audit trail.

4. Credential risk management

This is the rotation and hygiene stage: enforcing expiry, rotating secrets on a schedule and after exposure, and eliminating long-lived static credentials wherever short-lived, workload-issued tokens can replace them. It directly addresses NHI7 (Long-Lived Secrets) and reduces the blast radius of NHI2 (Secret Leakage). The sobering context: most leaked secrets in GitGuardian's research stayed valid long after exposure, because no one rotated them.

5. Decommissioning and offboarding

The most-failed stage, and the reason OWASP ranks Improper Offboarding (NHI1) first. When a service is retired, a project ends, or a vendor relationship closes, every associated NHI must be deactivated - not assumed dead. "Believed unused" is not the same as "disabled," as the next two incidents make painfully clear.

What failure looks like: two breaches built on forgotten NHIs

Cloudflare (November 2023): the credentials they thought were unused

Downstream of the October 2023 Okta compromise, Cloudflare rotated credentials - but missed one access token and three service account credentials believed to be unused. Over the Thanksgiving weekend, an attacker used those four non-human identities to reach Cloudflare's self-hosted Atlassian stack. According to Cloudflare's own disclosure, the attacker viewed 202 of roughly 194,100 Confluence wiki pages and accessed 36 of about two million Jira tickets, and gained access to its Bitbucket source-code management system before being cut off; Cloudflare reported no customer data or systems were affected. This is a textbook failure of offboarding and rotation (OWASP NHI1 and NHI7): the human response was fast, but four dormant machine identities slipped through and provided the foothold.

Microsoft Midnight Blizzard (January 2024): the dormant OAuth app

In January 2024 Microsoft disclosed that the Russian state actor it tracks as Midnight Blizzard (NOBELIUM / APT29) used a password-spray attack to compromise a legacy, non-production test tenant account that lacked MFA. From there, the attacker identified and abused a legacy test OAuth application that had elevated access to Microsoft's corporate environment, using it to grant broader access and exfiltrate email from a small number of senior leadership, security, and legal accounts. The entry point was a forgotten account; the escalation ran through a forgotten OAuth application - both classic NHI failures.

The unifying lesson: in both cases the human identity story was relatively well managed. It was the non-human identities - dormant service accounts, an unrotated token, a legacy OAuth app - that were never inventoried, monitored, or offboarded. The 2025 equivalent of those forgotten credentials is the unvetted MCP server and the over-permissioned coding agent, a pattern we have documented in our coverage of the Cline GitHub Actions npm token theft incident.

Why agentic identities break the legacy model

It is tempting to treat an AI agent as just another service account. It is not. Legacy IAM - OAuth 2.0, OIDC, SAML - assumes a single authenticated principal with static, coarse-grained scopes. Agentic identities violate every one of those assumptions, a tension the Cloud Security Alliance's work on agentic identity and ISACA's writing on the agent authorization gap both describe in depth. Agents are:

• Autonomous and goal-directed - they decide which tools to call to accomplish a task, rather than executing a fixed, pre-authorized code path
• Dynamic in their access - they request just-in-time tool access that varies run to run, so a static scope cannot capture what they will actually touch
• Ephemeral - sub-agent identities can live for seconds to minutes, far below the granularity of traditional provisioning and review cycles
• Nested in delegation - an agent acts on behalf of a human, and a sub-agent acts on behalf of that agent, forming a chain of delegated authority that OAuth's flat principal model cannot express

The result is a semantic gap. Traditional logging can tell you that a token was issued and an API was called. It cannot tell you why a tool was invoked, for which task, or under whose delegated authority - exactly the questions an investigator needs after an incident. That gap is the core reason a service-account inventory alone does not constitute agent governance.

How standards are catching up: MCP authorization

The Model Context Protocol's June 18, 2025 authorization specification is the most concrete attempt so far to bring rigor to the agentic NHI layer. Its key moves:

• MCP servers are OAuth 2.1 resource servers - they validate tokens but do not issue them, cleanly separating the authorization server from the protected resource
• PKCE (RFC 7636) is mandatory using the S256 method - hardening the authorization-code exchange against interception; plain PKCE is disallowed
• RFC 9728 Protected Resource Metadata lets clients dynamically discover a server's authorization requirements via a well-known protected-resource endpoint, instead of hardcoding them
• RFC 8707 Resource Indicators are required, so tokens are audience-scoped to a single server - the defense against confused-deputy and token-passthrough attacks

This is real progress, and any MCP server you adopt should enforce it. But there is a load-bearing caveat: authorization is downstream of identity. PKCE protects the code exchange; it does not authenticate the client workload itself. A stolen client or a malicious agent that completes the flow is still authorized. That is why workload identity - IAM roles, Kubernetes service tokens, OIDC federation - remains essential underneath the MCP layer. For the broader picture, see our explainers on OAuth for MCP servers and the complete MCP server security guide.

Agentic-specific threats your NHI program must account for

Beyond authorization mechanics, agentic identities introduce failure modes that have no analogue in classic NHI thinking:

• The lethal trifecta - coined by Simon Willison on June 16, 2025: an agent that simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally can be tricked into exfiltrating data. Mitigation means breaking the trifecta through taint tracking and policy-gating any exfil-capable action. We go deep on this in our piece on the lethal trifecta and AI agent data exfiltration.
• Memory poisoning (MINJA) - academic work on the Memory INJection Attack (arXiv 2503.03704, accepted as a NeurIPS 2025 poster) demonstrates query-only poisoning of an LLM agent's memory: a user can inject malicious records through ordinary queries that later mislead the agent on unrelated tasks. See our explainer on AI agent memory poisoning.
• Indirect prompt injection - untrusted content carrying hidden instructions is the delivery mechanism for both of the above; our primer is indirect prompt injection explained.

Concrete controls: what a security team does this quarter

1. Discover everything. Run automated discovery across cloud, SaaS, CI/CD, and your directory - then extend it to the agentic layer: every AI agent, MCP client, and MCP server in use. Treat the inventory as a living asset, not a one-time audit.
2. Kill the dormant ones. Build a recurring process to find and decommission NHIs with no recent activity. This is your direct mitigation for OWASP NHI1 and the exact failure behind Cloudflare and Midnight Blizzard.
3. Rotate and shorten. Enforce rotation schedules, replace long-lived static secrets with short-lived workload-issued tokens, and wire secret scanning into pre-commit and CI to stop NHI2/NHI7 at the source.
4. Right-size privilege. Review NHI permissions against actual usage and strip unused scopes. For agents, scope tools to the task and gate exfil-capable actions.
5. Monitor behavior continuously. Baseline normal NHI activity and alert on anomalies - new regions, new tools, unusual volumes, machine identities used interactively (NHI10).
6. Validate MCP authorization. Confirm MCP servers act as OAuth 2.1 resource servers with PKCE (S256), RFC 8707 audience scoping, and RFC 9728 metadata before you trust them with data.
7. Keep an audit trail. Maintain a continuous, queryable record of NHI activity - the evidence layer for incident response and for compliance obligations under GDPR accountability and security-of-processing (Art. 5(2) and Art. 32), SOC 2 access-control criteria, and ISO 27001 access management.

For mapping this work to formal frameworks, our guides on ISO 42001 AI agent governance and the NIST AI RMF for AI agents connect NHI controls to recognized management systems.

Where continuous agent and MCP visibility fits

Most of the controls above already have mature tooling for classic NHIs - secrets managers, CSPM, IGA. The gap is the agentic layer, because the tools that inventory service accounts and cloud roles were not built to see an AI agent's tool calls, an MCP server spun up on a developer laptop, or a nested delegation chain. That blind spot is the category Anomity addresses: continuous discovery and inventory of every AI agent and MCP server across the fleet (the anonymity problem - software operating invisibly), behavioral and permission anomaly detection on that layer (the anomaly half), and a continuous audit trail that answers the offboarding and accountability questions OWASP NHI1 and the breaches above expose.

None of that replaces your NHI program; it extends it to the fastest-growing identities you currently cannot see. If you want the deeper mechanics of how discovery works at the agent layer, read our walkthrough on inside Anomity discovery. The governing principle is the same one that has held for service accounts for two decades, now applied to the agents quietly running across your organization: you can't govern what you can't see.