NHI and Agentic Risk: How Compromise Happens

An agent incident does not have to begin with a strange model behavior. It can begin with an ordinary credential that no one removed.

A service account once belonged to a connector. The connector was replaced. The product surface changed. The owner moved teams. The documentation stopped mentioning it. But the account still authenticates, still reaches an API, and still carries the permission it had when the integration was alive. Then an agent arrives. It is given tools, context, and a task. Somewhere underneath that arrangement is the old identity, still able to answer.

This is the quiet shape of many agentic risks. The agent appears new, but the path it uses is old. It acts through tools, and tools inherit authority from non-human identities: service accounts, API keys, workload identities, OAuth applications, tokens, certificates, deploy keys, and CI credentials. These identities hold modern systems together. They also outlive the reasons they were created.

A non-human identity, or NHI, is an identity used by software rather than by a person. In an agentic system, that definition becomes more than inventory language. It describes the layer where possible actions become executable actions. A policy may say what the agent should do. A tool schema may describe how the agent should call a system. The backing identity decides whether the call is actually accepted.

That is why NHI governance belongs at the beginning of an agent security discussion, not in an appendix. Identity is not merely an access detail below the agent. It defines which tools, records, systems, and changes the agent can reach.

Two OWASP Lists, One System

The OWASP Non-Human Identities Top 10 for 2025 describes failures in the lifecycle of machine identities: improper offboarding, leaked secrets, weak authentication, overprivilege, unsafe reuse, poor isolation, and human use of machine credentials. The OWASP Top 10 for Agentic Applications 2026 describes failures in agent behavior: tool misuse, identity and privilege abuse, supply-chain compromise, memory poisoning, cascading failures, and human-agent trust exploitation.

These are not separate checklists. They describe different parts of the same failure path.

An NHI fault tells us which authority should not exist, should not persist, or should not be shared. An agentic fault tells us how that authority is selected, sequenced, amplified, or hidden inside a workflow. Put differently: NHI risk defines what can be reached; agentic risk describes how the system reaches for it.

OWASP makes this relationship explicit in Appendix C of the Agentic Applications Top 10, which maps NHI risks to Agentic Security Initiative risks. The first mapping is the one this opener focuses on: NHI1:2025 Improper Offboarding maps to ASI04: Agentic Supply Chain Vulnerabilities, with tool misuse as a contributing path.

That mapping is more than taxonomy. An unused identity that remains active is not only dead code with credentials. In an agent system, it can become a forgotten door into the tool supply chain.

NHI1: The Identity That Outlives Its Purpose

OWASP defines improper offboarding as the failure to deactivate or remove NHIs when they are no longer needed. The examples are ordinary: a deprecated service still has a service account, a departed owner leaves credentials behind, a test application keeps access into a sensitive environment. Their ordinariness is the point.

Security incidents often begin with something quiet. Not a spectacular model failure. Not a philosophical misalignment. A token remains valid. A service account has no current owner. A connector was removed from the product surface but not from the identity provider. A CI job was retired, yet its deploy key still opens a repository. A tool was disabled in the agent registry, but the credential behind it still authorizes the underlying API.

In a non-agentic system, this is dormant exposure. In an agentic system, dormancy is fragile. The moment a planner, tool router, model context, plugin registry, MCP server, retrieval connector, or automation path can rediscover the unused capability, the old identity becomes a usable execution path.

There is a small asymmetry here. Removing a user-facing feature is visible. Removing its identity path is harder to prove. The interface can vanish while the authority remains.

Why Offboarding Becomes Supply Chain Risk

Agentic supply-chain risk is usually discussed in terms of tools, packages, connectors, model dependencies, external services, and agent-to-agent interfaces. That is correct, but incomplete. Every one of those pieces may depend on one or more NHIs. The supply chain is not only made of code and configuration. It is made of authority.

A stale identity can keep a retired component alive in three ways.

First, it can preserve access after the component is removed from the approved architecture. A deprecated integration might no longer appear in the product diagram, but its OAuth client or service account may still reach production data.

Second, it can obscure ownership. Agents and tools often compose actions across systems. When a credential has no living owner, no one can confidently answer whether a tool call is legitimate, obsolete, or malicious.

Third, it can convert a low-risk foothold into a tool path. An attacker who finds an unused key, a stale workload identity, or an abandoned connector does not need the model to fail in some unusual way. The attacker needs the agent environment to contain a valid path from instruction to tool.

This is why NHI1 maps naturally to ASI04. A tool supply chain is only as clean as the identities that still make its tools callable.

The Control Plane View

It helps to separate three layers that are often blended together.

The NHI control plane is the lowest of these three, but not the least important. It is closer to enforcement than intention. A policy may say the agent should not access payroll. A tool descriptor may say it only reads customer tickets. But if the credential attached to the runtime can query payroll, then payroll remains reachable.

Agent policy can reduce choice. Tool design can reduce ambiguity. NHI governance removes authority that should not exist: which permissions remain, which credentials are valid, which workloads can assume which roles, which connectors still have tokens, which owners can attest that an identity should live.

When NHI governance is weak, higher-level controls must compensate for authority that should not be there. That bargain does not hold for long.

What to Measure Before Adding More Agent Controls

Before adding another layer of agent policy, a team should be able to answer a smaller set of identity questions.

• Which NHIs back each agent tool, connector, retrieval source, scheduler, and automation path?
• Which owner is responsible for each NHI today?
• Which NHIs have had no successful use in the last 30, 60, or 90 days?
• Which identities can still be assumed by retired services, archived repositories, disabled agents, old CI jobs, or deprecated MCP servers?
• Which tool calls would still succeed if the agent registry entry disappeared but the backing credential remained valid?
• Which credentials have appeared in logs, prompts, traces, notebooks, tickets, chat systems, memory stores, or evaluation corpora?
• Which high-impact permissions are denied by default even when an NHI is compromised?

These questions are not glamorous. They are more like calibration than invention. But calibration matters when a system can execute faster than a human reviewer can reconstruct what happened.

What Has To Be True

For NHI1 in an agentic system, offboarding has to cover more than the identity provider. The system has to prove that old authority no longer answers.

A tool catalog needs identity lineage. It should show not only what an agent is allowed to call, but which NHI answers when the call arrives. Without that join, the catalog describes the interface and hides the authority.

Each NHI needs a current owner, a documented purpose, an expected caller, and an expiration or review interval. If the owner leaves, the identity should not drift into shared memory as something everyone assumes someone else understands.

Removal also has to be tested. It is not enough to mark an identity as removed. Old tool paths should fail closed: old tokens rejected, old roles unavailable, old connectors unable to refresh, old CI contexts unable to deploy, old MCP servers unable to invoke protected APIs.

Agent traces should join the agent, goal, tool, backing NHI, resource, and policy decision. Without that join, incident response sees fragments: a tool call here, an API credential there, a model transcript somewhere else.

The sharper the consequence, the less acceptable it is for an agent to act through inherited ambient access. Some actions should require fresh, scoped, short-lived authority. A credential whose original purpose has become folklore should not be able to move money, change infrastructure, delete records, or send messages as if nothing has changed.

Agent security is not only a question of prompts, policies, and model behavior. It is also a question of stale authority.

An agent can only call what its credentials permit it to call. Non-human identities decide which APIs answer, which data opens, which infrastructure changes, which messages send, which records move. When an NHI outlives its purpose, the past remains executable.

The first discipline of agentic security is therefore not novel. It is the old work of identity, made urgent by systems that can turn dormant permission into action. Offboard the identity, or the agent may inherit authority from a system that no longer exists.

This series follows the same pattern across the NHI risks that most sharply intersect with agentic systems. The next piece moves from improper offboarding to overprivileged NHIs: least privilege meets least agency, and an excessive credential turns tool misuse from an agent failure into a routine consequence of bad authority design.