Non-Human Identity (NHI) for AI Agents: Security Guide

Every automated system needs an identity to act under a service account, an API key, or a workload credential. That's Non-Human Identity (NHI): the credentials and permissions machines use to authenticate, instead of a person logging in.

Classic NHI tooling assumes that identity executes one fixed function, the same way, every time - so you can scope tight permissions and flag anything unusual.

AI agents break that assumption. They reason through context and decide their next action on the fly. There's no fixed function left to govern, just a decision made fresh each run. This blog explores what non-human identity is and provides actionable insights into building an effective NHI security program for AI Agents.

What Non-Human Identity Traditionally Entails

Before their appearance in the business world, identities of this type were generally limited to a small number of in-role users. Some of the most common examples include:

• Service accounts: Restricted-use accounts used to access certain applications or networks, usually limited to a single server or database.

• Bots: Automated processes that perform a certain task on a regular interval, for example, data synchronization or night-time batch processing.

• SaaS-to-SaaS connections: Connections between third-party services, usually implemented through OAuth and allowing one system to access another while being online.

• API keys: They are used to access another application’s API and usually limit the scope of interaction to a particular set of endpoints.

The key feature of these early types of non-human identities was that their roles were fixed and usually quite limited. They performed one specific task and either interacted with only one other system or had a very limited set of allowed actions. This allowed traditional tools to manage such identities, for example, by automatically rotating their credentials or limiting their access to a predefined set of actions. Overall, such tools could rely on the fact that these types of entities would behave predictably and have a limited impact on the business if something went wrong.

Why AI Agents Are a Challenge to the Traditional NHI Model

The traditional NHI model rests on an assumption that identity and behavior are the same thing at provisioning time. AI agents are a challenge to this model, both in how they operate and in the problems they present.

Agents Make Decisions, Service Accounts Execute Known Logic

A service account's available behaviors are limited to the specific logic that implements calls to downstream systems: no judgment, no nuance, just execution of a specific request against a specific endpoint, in a specific order, as defined by the account code. The account's behavior is entirely tied to its identity; inspect the code, and you can determine exactly what this credential is capable of.

An AI agent inverts this relationship: given a particular objective and contextual information at decision time, it makes judgments about which tool to use, what arguments to provide, and whether to escalate to another agent, generating new behaviors every time. The credential is no longer directly linked to a specific behavior, but rather to a policy, which allows a range of behaviors to be taken under different circumstances. You cannot inspect the code to determine precisely what the identity is capable of, because there is no single behavior - only a decision surface that describes what the agent is permitted to do.

Different Impacts, Access Patterns, and Failure Modes

Once behaviors are no longer directly tied to an identity at provisioning time, the implications are challenging to incorporate into traditional security models. The impact of a credential being used for malicious purposes differs considerably depending on whether it is a service account or an agent.

A service account's blast radius is defined by the specific behaviors it is permitted to enact; compromise of the account results in those behaviors being misused for malicious purposes. An agent's blast radius is limited by the permissions it has been granted, but it has the capacity to perform any behavior permitted to any of the tools it can use. A compromised agent can combine the capabilities of all of the tools it can use, possibly escalating privileges or creating new behaviors that none of the tools specifically permit.

Similarly, the access patterns of a service account are entirely predictable, permitting anomaly detection to be effective at identifying potential compromises. The access patterns of an agent are designed to be contextualized to the specific decision surface it is operating on; detecting compromise becomes substantially more challenging, as malicious access patterns are much harder to distinguish from legitimate variations.

Finally, while a malfunctioning service account is likely to fail in a predictable way, exhibiting a specific pattern of behavior that differs substantially from expectations, a malfunctioning agent can execute behaviors that appear to be legitimate with no obvious impact. An agent that has been compromised can execute coherent behaviors that appear to be legitimate requests, with no immediately observable impact.

Blended Identity: Verifying the Agent and Its Delegated Authority

An AI agent is rarely an autonomous entity, acting on its own. In most cases, it is used either by the user or as a subroutine to another agent or a system. As such, verifying only the agent’s identity is only part of the equation, with the other, no less important, being the confirmation that the agent is indeed allowed to perform the action it is attempting to do.

Agent Identity vs. Delegated Authority

Those two concepts are often conflated, but in reality, they are distinct:

• Agent identity is the verifiable proof of the agent’s identity;

• Delegated authority is the permission granted by the user or another entity to perform certain tasks by an agent.

Each of these elements is frequently overlooked, which leads to vulnerabilities. While the first element (agent identity) proves that the action was done by a particular agent, the second (delegated authority) confirms that it had the right to do so. The two components are linked with the following logic: an agent that has a valid identity may perform actions that it was authorized to do, and the identity is necessary to prove that the agent was actually delegated authority.

Why Neither of Them Is Enough on Its Own

Having only agent identity leads to the problem where the agent can be held accountable for the action but without having the ability to stop it. In other words, the agent has a valid identity that proves that it did the action; however, it had no authority to do so, so the responsibility falls on the entity that delegated authority to it. On the flip side, having only delegated authority opens the door to rogue agents, where any entity that presents a valid delegation token can pretend to be the agent it was delegated to and perform any actions that the actual agent could do.

Verifying Both Is a Blended Identity

A blended identity model requires both components to be present at the time of action and subject to verification. In other words, each time an agent acts, it must be possible to verify that the entity that performed the action is indeed who it is supposed to be, and its identity is valid. Furthermore, the same agent must have valid delegated authority that specifically allows it to perform the action at the time of the request.

This, in turn, requires that the permissions are scoped specifically to the tasks that need to be done by the agent; it cannot rely on the delegation being valid for the entire session or lifetime of the agent. Instead, it must be checked every time an action is taken and confirmed that the given delegated authority allows for it.

Implications for NHI Frameworks

The standard approach to service accounts in any system is typically for their authority to come from their identity: a logical entity that is programmed to perform certain actions on a predefined set of objects. However, an agent requires its authority to be dynamically verified against a potentially changing set of delegation rules provided by different entities in different cases. Therefore, any Non-Human Identity (NHI) framework that intends to work with AI agents must ensure that the identity of the agent and its delegated authority can always be verified.

What This Looks Like in Practice

The two principles mentioned above have direct implications for design but are, ultimately, policy decisions that have to be formalized in the access control mechanisms. In practice, this means that the implementation will use some combination of the following three measures to enforce the described guarantees: token segregation, expiration tracking, and rotation enforcement.

Token Segregation

The separation of duties is not a novel concept, but it applies here to segregating tokens based on their scope or functionality. By binding a particular set of credentials to narrower fields of operation, the attack surface that any one compromised token represents is greatly reduced. This is a critical security control, as it prevents an agent (human or programmatic) from gaining unconstrained access simply by possessing a valid token.

Expiration Tracking

A token that is valid for an indefinite period of time is, by definition, a perpetual authorization. It should be treated as such, both in terms of auditing and operational security. The very nature of the delegation model requires that permissions be reasserted at some point, and expiration tracking is the mechanism by which permissions can be narrowed, audited, and eventually terminated.

Rotation Enforcement

By virtue of being time-constrained, tokens require periodic replacement, and it is during this process that additional security controls can be enforced. The value of such measures is often overlooked, as the entire point of rotating credentials is to make sure that compromised tokens are only viable for a limited period of time. A rotation policy that is insecure or inconsistently enforced is, at best, a minor hindrance to an attacker.

Building an NHI Security Program for AI Agents

Translating these ideas into action requires more than just controls - it requires an entirely new program. Here's a suggested four-step process for building NHI security in the context of agentic systems.

Discovery: Understanding the Universe of Agents

An organization cannot secure what it does not understand, making discovery the starting point for NHI security. This entails building an inventory of all the agents that are present and active in the system, including what model they are running, where they are deployed, and the credentials associated with them. From this baseline, one can begin understanding what access each agent has to tools and data, as well as any downstream systems impacted by virtue of that access – because an agent’s risk is defined by its ability to act, not just its identity.

It is crucial to discover agents created by other agents, which are often not captured by more traditional provisioning mechanisms. Finally, the agents’ credentials must be carefully separated from other service accounts in the organization, as they often behave quite differently at the implementation level. In all cases, discovery typically finds many more NHI identities than one might initially assume

Policy: The Boundaries of Authorization

With a basic understanding of the universe of agents, the next step is to understand what each one is authorized to do – ideally, one is not going to spend much time securing identities that should not exist in the first place. This means articulating for each agent a clear view of what it is allowed to do – what actions it can take and what tools and data it can access. Wherever possible, this should be defined in terms of least privilege – that is, the agent should not be authorized to take actions that it does not strictly need to do its job. This is particularly important for agentic systems, since granting blanket access to an entire system under the assumption that the agent will only act on one’s behalf fails to recognize that it may pursue its own goals with potentially malevolent outcomes.

Delegation should always be time-bound to the extent possible, with clear expiration/renewal policies built in to avoid indefinite extension of authority. One must also think through escalation procedures for any action that falls outside the scope of delegation – ideally, there should be a clearly defined process for how such actions should be evaluated rather than simply assumed benign. This, too, should be developed in terms of actions, rather than just in terms of agents – a given entity may legitimately be able to perform different actions depending on context, and policy must reflect that nuance.

Evaluation: Checking Identity and Authority at Runtime

An agent’s actions are not fixed at the time of provisioning but rather emerge dynamically at runtime, making it critical to go beyond simple identity checks and constantly evaluate whether an agent is actually authorized to perform the actions it is attempting to carry out. This applies to every step taken by an agent – that is, its authorization must always be checked at runtime rather than simply assuming it has the right to do whatever it is doing based on some earlier assertion. Even more importantly, one must be able to detect when an agent is attempting to perform actions that fall outside what it is authorized to do. To the extent possible, one must be able to capture the decision-making context that caused the anomalous behavior to occur, so that the choice can be evaluated at a later point.

One must also tune detection logic to account for the fact that legitimate anomalous activity is likely to occur more frequently for agents than for standard service accounts, since the latter are typically designed to have highly consistent behaviors while agentic systems are expected to exhibit greater variability. This stage represents the core of any NHI security program, since it is where risks actually materialize – and risk is defined by the possibility that an agent will perform an unauthorized action rather than simply asserting that it has the right to do so at the time of provisioning.

Violation Triage: Managing Unauthorized Agent Actions

Any system that permits agents to take actions must also have processes for dealing with actions that the agents should not have been able to take – which is why unauthorized actions inevitably lead to triage. This begins with defining severity levels for different types of anomalous actions based on the sensitivity of the action itself, as well as the potential impact it might have had if it had occurred in production. One must also define response procedures, ideally delegating responsibility for triaging violations back to the same entity that was responsible for delegating authority to the agent in the first place. This ensures that whoever granted permissions to an agent is held accountable for ensuring those permissions are only exercised when they should be.

As with any security incident, one must ensure that triage considers both the symptoms (what the agent did) and the root causes (why it was able to get away with it). This is particularly true for agentic systems, since it is essential to distinguish between an agent that legitimately wanted to do something the system was not authorized to do versus one that made an unintended choice based on insufficient context. The ability to make this distinction represents a security advantage over traditional service accounts, which typically lack this level of introspection – but it is only available if one has the proper auditing context, which is why the preceding steps are so critical.

Akto AI Agent Security with Visibility and Control Over NHI’s

As organizations begin to adopt AI agents, these new workloads require access to enterprise systems and data, typically through a "Non-Human Identity" (NHI): an API key, bearer token, or OAuth grant. The new "Identity for AI agents" product by Akto is designed to discover, govern, and secure this category of identity, which differs from both standard human users and service account NHIs.

What are the core problems that are addressed by Akto

Akto frames the gap in most IAM programs around three failure modes specific to agents:

• Ungoverned and persistent access: agents are often granted permanent access via NHI without any form of authorization at the point of use;

• Overprivileged by default: agents are frequently issued with overly permissive, non-specific access to enterprise data and systems;

• No owner, no audit trail: agents typically operate without direct human ownership, specific authorization, or audit trails.

Three-step implementation model

1. Discover every NHI associated with an AI agent

Akto recommends inventorying every bearer token, API key, or OAuth grant used by an agent. The implementation captures all relevant information about the discovered credential, including the owner, access scope, and rotation policy. This process also includes agent-to-owner binding and mapping to determine which NHI is used by which agent and for what purpose. The outcome is an enterprise-wide picture of all AI agents, their owners, and the NHIs that provide them with access to corporate systems.

2. Enforce agent-specific IAM policies

The tool then applies least-privilege IAM policies based on the discovered and documented scope of access for each agent. The implementation also covers credential rotation and approval life-cycle management, which can be set individually for every agent or a group of agents. The policies are applied as constraints and enforced at run-time, with the ability to manage access based on the agent's owner.

3. Detect and remediate violations

Every policy violation can be detected at runtime, with information about the affected agent, the blast-radius of the impact, and the necessary remediation. All violations are documented, and the responsible owner can review and approve the changes.

Interested in exploring Akto’s AI Agent Security? Book your demo today!

Final Thoughts on Non-Human Identity (NHI) for AI Agents

Identity, as a term, has evolved from describing what a system is to encompassing what a system could be. Service accounts got special governance attention because their behaviors were largely predictable; agents render that particular brand of control ineffective, and so it has to be replaced

Blended identity, the continuous validation of an agent plus the permissions it is using, is the way ahead.

The challenge of agents is not hypothetical or distant; they are already interacting with production systems under credentials not designed to support such interactions. The organizations that will benefit the most from the coming changes will be those that treat blended identity as a strategic priority, rather than something to be considered after the fact.

FAQs: Non-Human Identity (NHI) for AI Agents

1. What is non-human identity (NHI), and how do AI agents differ?

NHI stands for any digitized identity that represents the machine, not people, and encompasses service accounts, API keys, OAuth tokens, and workload credentials that grant access to systems on behalf of someone else. AI agents are not different in that they use these mechanisms to act in their own name; however, unlike traditional automation, they perform actions that they themselves decide how to execute.

2. Why is conventional NHI security inappropriate for AI agents?

NHI governance tools assume that a service account is executing predictable sets of actions, which allows limiting access based on a known baseline of functions. This does not work for AI agents because their operation depends on dynamic reasoning, so what they do cannot be reliably predicted.

3. What is "blended identity," and why is it relevant to NHI?

Blended identity refers to the situation where two aspects of the agent’s identity must be validated at all times in unison: the agent itself and the delegated authority it uses, which is granted by another entity (human or machine). In practice, neither one of these credentials is used standalone, including at the moment of authentication.

4. What is token segregation, and why is it relevant to agent identity?

The concept of token segregation is that to gain auditability and accountability benefits, each agent (or the agent’s task) should possess its own credential rather than share it with other entities. This goes beyond the convenience of having a single API key for all agents; instead, sharing would make auditing impossible because multiple actors would be using the same token.

5. Why is expiration tracking and rotation relevant to agent identity?

If credentials are rotated regularly, a compromised token will provide less operational leverage to an attacker since its lifespan is now limited. By contrast, if agent identity never expires, such a credential might as well be a permanent root account on the infrastructure.