AI Agent Identity Management — Designing Authentication, Authorization, and Auditing for Non-Human Identities (NHI)

AI agent identity management is the practice of treating AI agents as uniquely identifiable principals (non-human identities) — entities that can be clearly identified as "acting as whom" — and consistently designing and operating their authentication, authorization, and auditing. This article is aimed at engineers and security professionals running AI agents in production, and focuses on the layer that precedes "what the agent is allowed to do" (authorization and least privilege): specifically, "which identity it authenticates as, and how that identity is managed across its lifecycle." By the end, you will have a conceptual map — centered on the notion of Non-Human Identity (NHI) — that covers identity issuance, short-lived credentials, delegation, revocation, and audit logging as a unified design, and that gives you a starting point for implementation in your own environment.

To state the conclusion upfront: AI agents "behave like humans but do not satisfy the assumptions underlying human IAM," and traditional identity management breaks down across three dimensions — frequency, lifespan, and traceability. Human identities are designed around the assumption that "one person uses one account over a long period, logging in a few times a day." Agents, by contrast, issue large volumes of requests at high speed and can be created and destroyed in a matter of seconds. This section examines why directly reusing human IAM for agents leads to failure, organized around three perspectives: access characteristics, shared credentials, and the limits of authorization.

The frequency and lifespan of access differ by orders of magnitude between humans and AI agents. A human user logs in a few times a day, sessions last anywhere from a few hours to a few days, and behavior is relatively predictable. Agents, on the other hand, may issue a large number of consecutive API calls in a short period to complete a single task, with traffic density that is incomparable to that of humans.

The difference in lifespan is equally significant. Agents running in serverless environments or containers, for example, may start up per request and disappear once processing is complete — a short-lived pattern of operation. The model of "continuing to use the same credentials for months or years," as is typical with human identities, does not fit these nearly disposable workloads. Assigning long-lived, static credentials to short-lived agents means the credentials persist even after the agent itself is gone, making them easy to overlook during inventory reviews and leaving them abandoned.

Furthermore, the number of agents is not constrained by the number of human employees. It is not uncommon for a single developer to spin up multiple agents, each handling a different workload. As a result, the total number of identities to manage can far exceed the size of the organization, with non-human identities tending to outnumber human ones. Identity registries and review processes designed around headcount cannot keep pace with this rate of growth. The collapse of assumptions along three axes — frequency, lifespan, and count — is the fundamental reason why human IAM cannot simply be applied as-is.

Designing multiple agents to share the same API key or service account may seem convenient in the early stages of operation. It requires issuing only one credential and keeps configuration simple. But this convenience comes back to bite you later, in the form of untraceability and amplified blast radius in the event of a leak.

Consider, for example, a case where five agents all access a database using a single shared key. The audit log will record that "that key accessed" the resource, but it cannot distinguish "which agent" performed the operation. If a problematic operation is discovered, the agent responsible cannot be identified, and the investigation quickly hits a dead end. The inability to trace who did what after the fact directly leads to delays in incident response.

From a leakage-risk perspective, shared credentials also unnecessarily expand the blast radius. If a single key is ever exposed externally, the permissions of every agent using that key fall into the attacker's hands at once. With a one-agent-one-identity model, only the permissions of the leaked identity need to be revoked; with a shared design, determining the full scope of impact and containing it takes considerably more time.

Shared credentials also complicate revocation decisions. If you want to decommission a particular agent but other agents are using the same key, you cannot invalidate the key, and unnecessary permissions linger indefinitely. The fact that tracing, containment, and revocation all become harder with sharing is precisely why each agent should be issued its own unique identity.

When discussing access control for AI agents, attention tends to gravitate toward authorization — specifically, the design of least privilege to determine "what the agent is allowed to do." Restricting permissions is certainly important, but authorization alone cannot guarantee security. Authorization is a set of rules that determines "which operations are permitted for a given identity," and it is meaningless unless the prerequisite — authentication, confirming that "the request truly originates from that identity" — has been established.

For example, suppose you have carefully configured a least-privilege policy for a particular agent, allowing "read-only access." If that agent's credentials are shared with other agents, or if the setup allows for impersonation, then who is actually exercising those permissions becomes ambiguous. Even if the scope of permissions is correctly restricted, if the principal exercising those permissions cannot be uniquely identified, there is no way to guarantee that "the right permissions are assigned to the right party."

The reason this article does not go deep into authorization and least privilege themselves is that they belong to a different layer. Least privilege is a design concern at the stage of "binding permissions to an identity," whereas this article addresses the layer before that — namely, "which identity to authenticate as, and how to issue and manage that identity." Keeping in mind the sequence of first establishing a principal unambiguously through authentication, and then layering authorization on top, helps clarify the responsibilities of each. The concrete design of least privilege is treated as an adjacent topic; here, the focus remains on the identity lifecycle.

Non-Human Identity (NHI) is a collective term for IDs assigned to non-human entities——such as AI agents, services, and workloads——that are subject to authentication, authorization, and auditing. It is a concept that reframes what were previously referred to individually as "service accounts" or "API keys" into a single category from a governance perspective. This chapter systematically covers what NHI specifically encompasses, how it differs from human identities and what management challenges it presents, and why it is attracting attention now.

NHI targets not the humans behind a login screen, but the entities that operate autonomously within systems. Notable examples include, first, AI agents——agent-type workloads that receive user instructions and call external APIs, retrieve data, and process it.

Next are service accounts: dedicated accounts not tied to any individual human, used by one application to access another system. They have been widely used for batch processing, scheduled execution, and system-to-system integration. In cloud environments, it has also become common to assign identities to workloads themselves——such as serverless functions and containers——and grant them access to other services via identity federation.

Beyond these, CI/CD pipelines, integration tokens for connecting with external SaaS platforms, and IoT devices are also subject to authentication and authorization as non-human entities. Until now, these have been managed separately in their respective contexts as API keys, OAuth clients, service accounts, certificates, and so on.

The key point of the NHI concept is not to treat these in isolation, but to group them together under the common category of "non-human entities that must be authenticated." With the proliferation of AI agents, the number of these non-human entities is growing rapidly, making it increasingly difficult to maintain an overall picture through individual management. That is precisely why there is a growing need for an approach that bundles these entities under a single concept and manages them in a unified manner.

The most significant difference between NHI and human identities lies in who triggers the identity lifecycle and how. Human identities are issued, modified, and deleted in conjunction with HR events such as onboarding, transfers, and departures. Review timing is relatively clear-cut, making it easy to incorporate them into periodic access reviews. NHI, on the other hand, is created by technical events such as code deployments or the launch of new agents, and has no fixed milestones like an HR process. Ownership of these identities tends to become ambiguous.

Management challenges stem from this ambiguity. First, identities with no clear owner are easy to create. It is common for a service account temporarily created by an engineer to continue running unattended after that person transfers, with no one taking over responsibility. An identity with no clear owner cannot be decommissioned and ends up being left in place.

Second, inventory reviews are difficult. With human identities, unnecessary ones can be identified by cross-referencing against a list of current employees, but NHI often has no corresponding "ground truth list." There is little basis for determining which identities are still needed and which are not.

Third, there is the diversity of authentication methods. Human identities are protected by relatively standardized methods such as passwords and multi-factor authentication, whereas NHI involves a mix of methods——API keys, certificates, tokens——resulting in inconsistent levels of protection. Applying human identity management practices without accounting for these differences will cause identities to fall through the cracks. NHI requires dedicated governance that explicitly defines ownership and lifespan, triggered by technical events.

Several structural changes underlie the growing attention to NHI as a governance concept. The most significant is the spread of cloud-native development practices. As microservice architectures have advanced and systems have been decomposed into numerous small components, each component must authenticate the others. Every service-to-service communication requires an identity, causing the number of non-human entities to explode.

This coincided with the proliferation of AI agents. Because agents operate by autonomously accessing external APIs and data sources, introducing even a single agent adds a new authentication entity. In configurations where multiple agents work in concert, that number grows further. This trend——where identities multiply independently of the number of human employees——is reaching a scale that traditional identity inventories and manual reviews can no longer keep up with.

In addition, credential leakage has become a recognized real-world threat. API keys accidentally committed to code repositories or logs, and service account keys left unrotated for extended periods, are easy footholds for attackers. The more non-human entities there are, the greater the total volume of unmanaged credentials, and the broader the attack surface.

As these changes converge, the NHI concept——visualizing "non-human entities" not individually but as a single category, and systematically managing their ownership, lifespan, and permissions——has taken on a practical urgency. It represents, in essence, a shift in the scope of identity management from a human-centric model to one that encompasses both human and non-human entities.

Credentials for agents are handled through three design decisions: "issue a unique ID, operate with short-lived credentials, and control delegation and impersonation." The key is not to distribute long-lived static keys, but to adopt the principle of providing short-lived credentials scoped to what is needed, only when it is needed. This chapter explores how credentials should be provided to agents from the perspectives of the identity lifecycle from issuance to revocation, short-lived credentials and rotation, and countermeasures for delegation and impersonation.

Agent identity is easiest to understand when considered across three phases: issuance, delegation, and revocation. Starting with issuance: when launching a new agent, the starting point is binding a uniquely identifying ID to it. Because this ID serves as the reference point for later tracking "who did what," it is desirable that it be unique to each agent and that the owner (the responsible person or team) be explicitly identified. Recording the intended use, expected lifespan, and required scope of permissions as metadata at the time of issuance makes subsequent audits significantly easier.

Next is delegation. When an agent does not operate in isolation but acts on behalf of a user or another service, it is necessary to explicitly define "under whose authority, and to what extent, is the agent acting as a proxy." By keeping the scope of delegation narrow, the system can be designed so that even if the agent is compromised, the damage remains confined to the delegated scope. While delegation is convenient, leaving its scope ambiguous risks permissions expanding in a chain reaction, which is why explicitness is critical.

Finally, there is revocation. When an agent has fulfilled its role or is decommissioned, the corresponding ID and credentials must be reliably invalidated. If revocation is overlooked, an ID that should no longer be active can persist while retaining its permissions, remaining as an attack surface. Deciding on a lifespan at the time of issuance and building in a mechanism for automatic expiration once that deadline passes reduces the risk of revocation being forgotten through manual oversight. Designing issuance, delegation, and revocation as a unified lifecycle is essential for preventing abandoned IDs.

Operating with a fixed, long-lived key assigned to an agent carries prolonged risk in the event of a leak. Even if a key is exposed, an attacker can continue using it for as long as it remains valid. The fundamental approach to avoiding this is the use of short-lived credentials. By issuing a token with a short expiration each time access is needed and ensuring it automatically becomes unusable once that expiration is reached, the window of opportunity for misuse—even if a token is leaked—can be kept small.

Short-lived credentials are often implemented in a pattern similar to OAuth 2.0 access tokens: a time-limited token is obtained and used each time, and once it expires, a new token is retrieved. There are also mechanisms such as workload identity federation, which uses the environment in which the agent is deployed as the root of trust, allowing short-lived credentials to be obtained without storing long-term keys. In all cases, the common direction is "avoid storing secrets for long periods."

There are still situations where long-term secrets are unavoidable. In such cases, what matters is secret rotation—the practice of periodically replacing credentials with new ones. For example, using a secret management tool (generally a mechanism like Vault), configuring agents to retrieve secrets on demand and have them automatically renewed at regular intervals reduces the risk of relying on the same secret over an extended period.

Short-lived credentials and rotation share the same underlying idea: intentionally shortening the period during which a secret is valid. By moving toward a design where keys are retrieved at runtime and used only briefly—rather than hardcoded into source code or configuration files—the impact of a leak becomes easier to contain.

Delegation and impersonation refer to situations where an agent operates "under the authority of a principal other than itself"—for example, an agent calling an API on behalf of a user, or behaving as another service. This is a legitimate capability in its own right, but if designed incorrectly, it can become a loophole through which an agent exercises permissions it was never meant to have.

The danger lies in patterns where broad permissions are handed over with an ambiguous scope of delegation. For instance, if an agent acting on behalf of a user is placed in a state where it "can do anything the user can do," then if the agent is compromised, the attacker gains access to the user's full set of permissions. By restricting the operations that can be proxied to only what is necessary, and by explicitly encoding what is being proxied within the token itself, it becomes easier to limit the cascading impact of a breach.

The key to preventing impersonation is the ability to verify "who is acting as whom" at the authentication stage. The receiving party must be able to confirm whether the token presented by an agent was truly issued for that agent itself, or on behalf of which principal it was issued. Standards such as OAuth 2.0 and OpenID Connect provide a framework that supports this kind of verification by embedding the intended recipient and purpose within the token.

As implementation guidance: first, keep delegation chains as shallow as possible. When an agent further delegates authority to yet another agent, it eventually becomes impossible to trace who ultimately authorized what. Second, apply short expiration times to delegated tokens as well. And third, audit logs should record both "the agent as the acting entity" and "the principal being represented," so that accountability can be traced after the fact.

Identity only becomes meaningful when it functions as the target of least-privilege grants and as the subject of audit logs. Even if a unique ID is issued, its value as an identifier is wasted if it is not connected to units of permission or units of log recording. This section addresses how to bridge the ID established through authentication to least privilege (a concern belonging to a separate layer), and how to design audit logs that preserve "who did what, and when." Rather than delving into the specifics of authorization itself, the focus here is on the connection points.

Least privilege is the principle of granting each ID only the minimum permissions necessary for its operational purpose, and it is a design concern at a separate layer from authentication—the primary subject of this article. What is important here is that least privilege can only be achieved if "the entity to which permissions are assigned" is uniquely established. When each agent is issued a distinct ID, permissions can be scoped to that ID as the unit of control. Conversely, if multiple agents share a single ID, permissions required by one agent are automatically granted to the other as well, making it impossible to uphold least privilege.

In other words, establishing identity through authentication is a prerequisite for realizing least privilege. Consider, for example, an agent that only reads data and another that also writes data. If separate IDs are assigned to each, the former can be granted read-only access while the latter is granted both read and write access. It is precisely because the IDs are distinct that permissions can be appropriately separated.

The reason this article does not go into the specifics of least-privilege design—such as role definitions or methods for writing policies—is that these belong to the independent domain of the authorization layer. What should be understood here is not that "issuing an ID is the end goal," but rather the bridging concept of connecting that ID to the authorization mechanism as the unit of permission assignment. Only with a unique ID as the foundation can least privilege, as the structure built upon it, stand stably. Authentication and authorization have distinct responsibilities, but by using identity as a shared axis, the two can be made to work in concert.

Audit logs are records that enable the reconstruction of "who did what, and when," and they also serve as a means of verifying that an NHI design is actually functioning as intended. One of the greatest practical benefits of issuing unique IDs per agent is that the subject of audit log entries can be identified at the individual agent level. With shared IDs, the most you can determine is "that ID performed the operation," but with unique IDs, you can record "which agent performed the operation."

To organize the elements that should be included in an audit log: first, the principal—that is, which agent's ID performed the operation. When delegation is involved, recording both the acting agent and the original principal being represented makes it easier to trace accountability. Next is the timestamp—the date and time the operation was performed. Then the target and the operation itself—which resource was acted upon and what kind of operation was performed (read, write, delete, etc.). Additionally, whether the operation succeeded or failed serves as a clue for anomaly detection.

One important consideration when recording these elements is protecting the logs themselves. If audit logs can be easily tampered with, they cannot serve as reliable evidence in the event of an incident. Logs should be stored in an append-only format that resists modification, and it is advisable to separate permissions so that agents themselves cannot delete or alter those logs.

Audit logs only deliver their full value when combined with ID lifecycle design, not in isolation. It is precisely because mechanisms such as unique ID issuance, short-lived credentials, and revocation are in place that the records preserved in logs can be tied to a consistent principal, making it possible to reliably answer "what happened, and under whose responsibility."

NHI implementation can proceed incrementally in three steps: unique ID issuance → privilege minimization via short-lived tokens → automation of revocation and rotation. There is no need to aim for a perfect system from the outset. The practical approach is to build steadily in sequence: first separate IDs, then shorten the lifespan of secrets, and finally automate operations. This chapter concretely describes what to do at each step and the rationale behind it.

The first step is to issue a unique ID for each agent. This forms the foundation of NHI design. If you are currently operating with shared keys, the initial goal is to transition to a state of "one agent, one ID." Assign each agent a name or ID that uniquely identifies it, and record as metadata what purpose it serves and who is responsible for it.

As a concrete approach, organize the following information for each ID:

• ID name (a label that uniquely identifies the agent)
• Owner (the person or team responsible for it)
• Purpose (what the agent is designed to do)
• Expected lifespan (permanent or temporary)

Maintaining this as a registry provides a basis for future audits and revocation decisions. With unique IDs, records can be kept in audit logs at the individual agent level, making it possible to track "who did what." Conversely, skipping this step and moving forward with shared IDs will yield no traceability.

The key mindset for this step is not simply the act of issuing IDs, but rather cultivating the operational habit of "always associating an ID with a responsible owner and a defined purpose." Preventing the creation of IDs with unknown owners is the first safeguard against future NHI sprawl—the uncontrolled proliferation of NHIs that become unmanageable. For example, embedding "ID registration and owner designation" into the procedure for launching a new agent makes it much harder for IDs to be issued without a recorded owner or purpose.

The second step is to switch the credentials provided to agents to short-lived tokens, thereby minimizing privileges from a temporal perspective as well. Once unique IDs have been established in Step 1, rather than directly binding long-term keys to those IDs, the approach shifts toward issuing tokens with short expiration windows on demand.

The general approach is as follows: first, identify the long-term keys and hardcoded credentials that agents are currently using. Then, evaluate whether those can be replaced with token-based authentication. For example, using an approach similar to OAuth 2.0 access tokens—obtaining a time-limited token each time it is needed and refreshing it upon expiration. In cloud environments, configurations such as workload identity federation, which uses the agent's execution environment as the root of trust to obtain short-lived credentials, are also an option.

This step has two objectives. The first is to reduce the window of damage in the event of a leak. If a token's validity period is short, even if it is exposed, the window for misuse is limited. The second is to shift toward a culture of not hardcoding secrets directly into code or configuration files. Designing the system to obtain tokens at runtime reduces the risk of keys ending up in repositories or logs in the first place.

It should be noted that what is addressed here is strictly the temporal minimization on the authentication side—"how long and with which credentials can the agent operate"—which is a separate layer from the principle of least privilege on the authorization side, i.e., "which operations are permitted." The two are complementary, but starting by shortening the lifespan of credentials raises the overall security baseline of the identity infrastructure.

The final step is to automate revocation and rotation, shifting to operations that do not depend on manual intervention. Even if the foundations of unique IDs and short-lived tokens are established in Steps 1 and 2, if revocation and key rotation remain manual processes, missed actions translate directly into lingering risk. The purpose of automation is to eliminate this human factor—forgetting or deferring—through design.

The operations to automate can be broadly summarized as follows:

• Automatic expiration-based revocation (automatically invalidating IDs and tokens that have exceeded the lifespan set at issuance)
• Periodic secret rotation (automatically renewing long-lived secrets at regular intervals when they are necessary)
• ID revocation for decommissioned agents (invalidating the IDs of agents that have fulfilled their purpose, in conjunction with the decommissioning process)

To build these as systematic mechanisms, options include using the automatic renewal features of secret management tools (such as Vault-like systems), or setting an expiration date at the time of ID issuance so that it is automatically revoked upon expiry. What matters is that revocation and rotation become standard operations performed autonomously by the system, rather than tasks that someone has to remember to carry out.

When automation is working effectively, it becomes much easier to prevent unnecessary IDs from retaining permissions indefinitely, even as the number of agents grows. Conversely, an asymmetric state—where issuance is automated but revocation remains manual—is a classic pitfall that leads to NHI sprawl. Making issuance and revocation symmetrically automated is the key to keeping operations sustainable.

There are two pitfalls that commonly trip up NHI design: "reusing human accounts" and "unauditable NHI sprawl." Both follow a pattern where the path of least resistance is taken early on, making the situation difficult to recover from later. This chapter takes a concrete look at why these common design mistakes occur, what damage they can lead to, and how to avoid them.

The most common pitfall is allowing agents to use accounts originally created for humans. For example, a developer might configure an agent with their own account credentials and have it call external APIs using those permissions. Since it can be up and running immediately with an existing account, this approach feels convenient during the testing phase—but it introduces multiple problems when carried into production.

First, traceability is lost. Audit logs record operations under that developer's ID, making it impossible to distinguish between actions taken by the human themselves and actions taken by the agent. When something goes wrong, isolating the root cause becomes difficult.

Second, permissions tend to be excessive. A human account bundles together all the various permissions that person needs for their work. An agent typically requires only a small subset of those, but reusing the account hands over all the unnecessary permissions along with them. If the agent is ever compromised, the attacker gains access to everything the human account can do.

Third, the lifecycles fall out of sync. Human accounts are deactivated when someone leaves or changes roles, so if an agent is running under a person's account, it can suddenly stop working the moment that person's account is disabled—an entirely avoidable incident.

The remedy is straightforward: issue agents a dedicated ID separate from any human account. It may seem like extra effort at first, but a dedicated ID establishes traceability, least privilege, and an independent lifecycle all at once. Building the habit of using dedicated IDs from the testing phase onward prevents costly rework when moving to production.

The other archetypal pitfall is NHI sprawl—a state in which NHIs proliferate beyond the ability to manage them, making a full inventory impossible. Unlike human employees who go through a formal hiring process, agents and service accounts can be created casually with each code deployment or quick proof-of-concept. Each individual decision seems minor, but the cumulative result is a mountain of identities that no one has a complete picture of.

What makes this dangerous is that unnecessary IDs linger invisibly. A service account created for a temporary test, for instance, may retain its permissions long after the test is over simply because no one deleted it. When the person responsible moves to another role and ownership becomes unclear, the passive logic of "I can't tell if it's safe to delete, so I'll leave it" compounds over time. IDs with unknown owners and unknown purposes become ideal footholds for attackers.

The response to NHI sprawl is not to stop IDs from being created, but to maintain a manageable state even as they accumulate. Concretely, this means enforcing a practice of recording the owner, purpose, and expected lifespan at the time of issuance, and maintaining a centralized ledger for a unified view. On top of that, the ledger should be reviewed on a regular basis to identify and retire IDs whose owners are unknown or that have not been used for an extended period. Metadata recording at issuance and periodic audits must work together before proliferation can be kept under control.

Particularly effective is combining this with the automated expiration discussed in the previous chapter. If a lifespan is defined at issuance and a mechanism exists to automatically expire IDs once that deadline passes, the total volume of abandoned IDs can be kept in check. Sprawl arises from an asymmetry where "issuance is easy, expiration is manual," so designing both sides to be symmetrical is the fundamental countermeasure.

Q: What is the difference between Non-Human Identities (NHIs) and traditional service accounts? A: The two concepts overlap in what they cover, but differ in how they frame the subject. A service account is the name for a specific mechanism, whereas NHI is a higher-level concept that groups together all principals that are not human and subject to authentication, authorization, and auditing—including service accounts, API keys, workload identities, and more. The core idea behind NHI is to govern these non-human principals, which have historically been managed in silos, under a common set of axes: owner, lifespan, and permissions.

Q: Do I need NHI practices even at a small scale, with only one or two agents? A: When the scale is small, a minimal approach is often sufficient, but adopting the mindset early makes things easier down the road. At a minimum, even with just a few agents, it is worth issuing dedicated IDs rather than reusing human accounts and avoiding hardcoded long-lived keys. Because agents tend to multiply, starting with dedicated IDs from the outset prevents the rework of having to retrofit the practice once numbers grow.

Q: Between authentication (who is acting) and authorization (what is permitted), which should be designed first? A: The natural order is to establish the principal unambiguously through authentication first, and then layer authorization on top of that. If it has not been determined who is making a request, there is no well-defined subject to which least-privilege permissions can be assigned. This article focuses on authentication and identity lifecycle; the concrete design of authorization concerns such as least privilege is treated as a separate layer and topic.

Q: Won't introducing short-lived tokens complicate processing due to the need to re-acquire tokens? A: In most cases, existing standards and mechanisms such as OAuth 2.0 and workload identity federation handle token acquisition and renewal, so there is little need to implement complex logic yourself on the application side. In fact, the practice of hardcoding long-lived keys into code or configuration tends to generate greater costs later in the form of breach response and rotation overhead. Short-lived tokens are a design choice where the security benefit—reducing the window of exposure in the event of a leak—tends to outweigh the effort of adoption.