---
Title: "Non-human identity: the enterprise guide to agent identity"
Url: "https://devrev.ai/blog/non-human-identity"
Published: "2026-09-18"
Last Updated: "2026-09-18"
Author: "Akhil Kintali"
Category: "Blog, Computer"
Excerpt: "AI agents are a new class of non-human identity, and most enterprises can't yet account for what they can do. Start with an inventory and four questions."
Reading Time: 16
---

# Non-human identity: the enterprise guide to agent identity

## TL;DR

- An accurate non-human identity inventory connects each software principal to its owner, purpose, credentials, and permissions. Counting keys alone won’t tell you what can act.
- AI agents belong in that inventory alongside service accounts, workloads, and bots. Their context-dependent tool choices make the link between identity and each request especially important.
- Evaluate agents through four questions: how they authenticate, what they’re authorized to do, how delegation stays accountable, and where controls prevent disallowed execution.
- Identity and access management (IAM) can support agents. The gap appears when shared, overbroad credentials replace explicit identities, acting-person context, lifecycle ownership, and enforceable limits.

## What is a non-human identity?

A non-human identity (NHI) is a digital identity assigned to a software application, service, workload, device, or AI agent rather than a person. Systems use it to recognize the entity and apply access rules. API keys, certificates, and tokens are credentials associated with identities, not the underlying entities themselves.

## The non-human identity landscape starts with an inventory discrepancy

Your secrets vault and application register can both be correct while telling different stories. Imagine a vault listing several credentials for a support integration. The application register lists one connector. Neither one shows which requests came from a support engineer, a scheduled task, or an agent choosing its next action.

That discrepancy matters before an upcoming October 2026 agent rollout. You need to know which software can act, for whom, and under whose oversight. A credential count can’t answer those questions.

The starting point is a **principal**: an entity a system recognizes when making access decisions. A non-human identity inventory should connect principals to credentials, rather than treating every credential as another independent actor.

### Service accounts, workloads, and bots

Service accounts represent software rather than employees. They can support a backup job, a deployment pipeline, or an application integration. Their permissions can change. Credentials needn’t be long-lived secrets, either.

A **workload identity** identifies running software, such as a containerized service or background process. Workload identities already support dynamic, non-AI systems. The [SPIFFE specification overview](https://spiffe.io/docs/latest/spiffe-about/overview/) describes identities for software across changing environments, including short-lived, verifiable identity documents. SPIRE is an implementation of those specifications.

Bot accounts represent automated activity inside an application. A notification bot might post deployment updates; a maintenance bot might change records. Non-agent software can make decisions and perform consequential actions, too.

These labels overlap. An agent may run as a workload and use a service principal in another system. Map the relationships. A single category label can hide which principal actually reaches the destination system.

### AI agents add a changing action path

An AI agent can select tools and sequence actions using model-generated decisions. A support task might begin with retrieving an account record, then branch into checking an incident or preparing a change.

The identity challenge is connecting that changing path to a stable, governed actor. Which agent made the request? Was it acting for a particular employee? Did it hand the task to another agent?

Agent identity and acting-person identity remain distinct. The agent is the software actor; the employee is the person on whose behalf it may operate. A background agent might have no acting person at all. It still needs an accountable owner and an explicitly authorized purpose.

### An identity inventory example

The following non-human identity examples illustrate one support workflow, not a customer deployment. Each row identifies an actor rather than a secret.

| Principal | Purpose and accountable owner | Acting context | Credential relationship | Access and lifecycle evidence |
| --- | --- | --- | --- | --- |
| Ticket-sync service | Copy ticket updates; integration engineering | Scheduled service activity | Credential references tied to this service | Approved ticket fields; disable access when integration retires |
| Support-resolution agent | Investigate an assigned case; support operations | Authenticated support engineer for each request | Execution credentials linked to agent and request | Agent scope plus engineer’s rights; review when tools change |
| Overnight triage agent | Classify unassigned cases; support operations | Governed background service context | Credentials tied to the scheduled workload | Classification scope only; revoke when schedule retires |

In short: inventory the actor, its authority, and its retirement path; record credentials as linked evidence.

Keep secret values out of the inventory. Store references to the credential system, plus the issuing authority and responsible team. Include downstream principals when a connector changes identity between systems. That transition can explain why the application log and destination log disagree.

Record last use separately from approved purpose. An active credential might belong to an obsolete integration; an unused principal might support a disaster-recovery workflow. Neither activity nor inactivity settles whether access is appropriate. Ask the named owner to explain the dependency before removing it.

### Why credential management doesn’t finish the job

Vaulting and rotation protect credentials. But non-human identity management also covers ownership, provisioning, permission review, monitoring, and retirement. NHI security tools may address different parts of that work, so assess coverage against the inventory rather than a category label.

IAM means identity and access management, and it can govern both people and software. The failure isn’t IAM itself. It’s losing request context behind an account with broader access than the task requires.

For instance, a shared connector could retrieve restricted ticket fields for an employee who can’t view them directly. Rotating its secret wouldn’t correct that permission mismatch. The identity record establishes the actor; [AI access control](https://devrev.ai/blog/ai-access-control) governs what that actor can access.

## The four questions every agent identity must answer

A useful identity review follows one request across systems. Each question exposes a different gap. One answer isn’t enough.

| Question | Evidence to inspect | A revealing test | Deeper explanation |
| --- | --- | --- | --- |
| Authentication: which agent is calling? | Principal identifier, credential issuer, intended recipient, and validity checks | Present a credential to the wrong service; confirm rejection | [how AI agents authenticate](02-ai-agent-authentication.md) |
| Authorization: what may it do here? | Agent permissions, acting context, requested resource, and policy decision | Ask for a record the requester cannot access | [how AI agent authorization works](03-ai-agent-authorization.md) |
| Delegation: who handed off which authority? | Delegator, delegate, task scope, and linked action records | Reconstruct a downstream change back to its authorized task | [AI agent delegation and accountability](04-agent-delegation.md) |
| Enforcement: where can execution stop? | Checks at retrieval and tool boundaries, approval state, and denial evidence | Attempt a prohibited action; inspect the destination for side effects | [AI agent guardrails](05-ai-agent-guardrails.md) |

In short: authenticate the actor, determine its authority, preserve the handoff, and enforce the decision where access or action occurs.

### Authentication: how does the agent prove its identity?

Authentication verifies the identity presented by a caller. A receiving service has to validate the credential, including its issuer, intended use, and validity. Recognizing a token-shaped string isn’t enough.

Consider the support agent calling a ticket service. The receiver needs evidence of the calling principal, not merely proof that someone possesses a shared integration secret. An API key can be scoped, but sharing it can obscure which workload actually used it.

Short-lived credentials reduce the lifetime of a stolen credential. They don’t establish ownership, prove business intent, or guarantee protection against replay. Workload identity and request context complement credential controls rather than replace them. The review should establish exactly what a successful authentication proves before moving to permissions.

### Authorization: what is the agent allowed to do?

Authorization determines whether an identified actor may perform a specific operation on a specific resource. Being authenticated doesn’t imply permission to retrieve every record or call every tool.

For an agent acting on behalf of an employee, a useful default is permission intersection. Access must fall within both the agent’s configured privileges and that employee’s current rights. Task constraints can narrow it further.

A support engineer’s access to a ticket shouldn’t automatically authorize an agent to delete it. Conversely, an agent’s broad search capability shouldn’t expose records the engineer cannot read. Background work needs its own explicitly governed service scope. Don’t invent an employee session to make an unattended process fit an interactive permission model.

### Delegation: who is accountable after a handoff?

Delegation passes a task and permitted authority to another actor. Accountability depends on preserving that relationship through execution, not merely recording that agents exchanged messages.

Suppose the support agent asks a diagnostic agent to inspect an incident. The receiving agent needs a bounded task and usable authorization context. An investigator should be able to connect its tool calls to that handoff and the initiating request.

Record both software actors, the permitted task, and the resulting actions. Include the acting person when there is one; otherwise record the authorized service context. A parent–child arrangement isn’t automatically unsafe, and peer-to-peer messaging isn’t automatically secure. The test is whether the handoff preserves scope and attribution without silently expanding authority.

### Enforcement: where are the limits applied?

Enforcement makes a policy decision effective at an access or action boundary. A denied retrieval must keep unauthorized data out of model context. A denied write must stop the destination change.

An agent might draft an account update that requires approval. The execution path should hold that update until the required approval exists, then recheck authorization before writing. Approval confirms intent; it doesn’t create access rights.

Logs help reconstruct what happened, but recording a forbidden action after completion doesn’t prevent it. Likewise, instructions in a prompt aren’t a substitute for controls outside the model. Identity checks, authorization, approval gates, and runtime guardrails serve complementary purposes. Inspect where each applies, especially when a request crosses a connector into another system.

## Where non-human identity governance leaves gaps

A governance gap can exist even when every credential is stored securely. An abandoned principal, an unexplained permission grant, or a missing retirement owner each leaves a different opening. Lifecycle evidence makes those gaps visible without relying on a market-wide identity ratio.

### What the published risk guidance establishes

The [OWASP NHI Top 10 for 2025](https://owasp.org/www-project-non-human-identities-top-10/) names improper offboarding, secret leakage, overprivileged identities, and long-lived secrets among its risks. It also identifies identity reuse and failures to isolate environments. These are separate failure modes, not synonyms for poor secret storage.

OWASP’s [2025 guidance on excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) adds an agent-specific connection. It describes excessive functionality, permissions, and autonomy, including tools that access systems through a generic, highly privileged identity.

That guidance supports a practical distinction. Machine identity management protects the software identity and its credentials. Agent governance must also examine the actions available to the model and the authority applied when it selects them. The responsibilities overlap; neither disappears because the other has an owner.

### Review changes, not just creation

Provisioning approval is only the start of a non-human identity lifecycle. Adding a tool can change what an agent can attempt without changing its principal identifier. Moving its owner to another team can leave responsibility unclear while scheduled work continues.

For the overnight triage agent, a permission review should distinguish classifying cases from editing customer records. If a new connector enables edits, that’s a scope change even if nobody creates another account. Record who approved it and which policy now limits it.

Retirement requires its own evidence. Disabling the schedule doesn’t necessarily disable the identity or invalidate existing credentials. Confirm the destination rejects further access, and account for delegated work already in progress. Retain enough event history to explain earlier activity without retaining unnecessary sensitive payloads.

An [AI governance framework](https://devrev.ai/blog/ai-governance) establishes broader oversight. The identity-specific contribution is concrete: who owns each principal, what changes trigger review, and how retirement becomes enforceable.

### Standards cover different parts of the lifecycle

Standards help divide this work accurately. SPIFFE addresses workload identification; it doesn’t decide whether a support engineer may see a particular ticket. The [SCIM protocol, RFC 7644](https://www.rfc-editor.org/rfc/rfc7644.txt), supports provisioning and managing identity resources across systems. Its extension model allows custom resources, but agent support depends on the implementation.

[NIST SP 800-207, Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), rejects implicit trust based solely on network location or asset ownership. That principle remains useful when a trusted internal agent reaches for a sensitive resource. Its location doesn’t settle whether this request is allowed.

These foundational standards define responsibilities; they aren’t agent-security certifications. In an [AI agent security review](https://devrev.ai/blog/ai-agent-security-review), ask which component implements each responsibility and what evidence demonstrates the result. A list of supported standards won’t reveal a missing check between two otherwise well-configured systems.

## What should you look for in an agent-identity model?

Look for an identity model that preserves the actor, acting context, and applicable limits through the full request path. A named agent in a dashboard isn’t sufficient if every downstream action becomes an indistinguishable call from an administrator account.

### Evaluate the request path, not the label

An identity-aware design connects the agent’s stable identity to request-specific authority. Existing IAM, workload identity infrastructure, and application controls can provide those pieces. Whether the design is built in or integrated matters less than whether the context survives each boundary.

Ask for evidence from the destination system, not just the agent interface. Can its logs distinguish the agent from the requesting employee? Can you suspend one agent without disabling unrelated workflows? Does removing a permission change the next access decision?

These questions belong in a [build vs buy AI agents](https://devrev.ai/blog/build-vs-buy-ai-agents) decision because they expose ongoing operational work. Someone must maintain identity mappings, review scope changes, and repair connectors that discard context. A successful demonstration should make that responsibility visible.

### Run the intersection test

Choose a delegated workflow and ask: “Can the agent retrieve a record that the requesting employee cannot access?” Then reverse the test: can the employee make it perform an operation outside the agent’s approved scope?

Both attempts should fail in an intersection-based design. Inspect the retrieval and destination evidence, not only the final answer. Hiding a restricted field from the response doesn’t undo exposure if the model already received it.

Keep explicitly authorized background workflows separate from this test. Their authority derives from the governed service purpose, not a fictional acting employee. Review them against that service scope and its owner’s approval.

DevRev gives agents distinct identities within the same IAM mechanisms used for people in Computer, by DevRev. Agent Studio provides configuration for agent identity and permissions. For requests made on someone’s behalf, DevRev intersects agent privileges with that person’s privileges before data reaches the model. This preserves the distinction between the agent and the person rather than treating them as one identity.

## Start with one workflow you can account for

Choose one workflow to inventory before expanding your agent rollout. Start with a task your team understands, such as investigating a support case, and follow it into every connected system.

Write down each principal, its owner, the credentials it uses, and the authority behind the request. Find the point where one identity becomes another. Then test a denied action and retire the workflow in a non-production environment. Those checks reveal whether the inventory describes actual behavior or only intended configuration.

For product evaluation, [DevRev’s trust center](https://security.devrev.ai) provides security documentation, including SOC 2 Type 2 and ISO/IEC 27001:2022 materials. Use those documents alongside workflow evidence; organizational assurance doesn’t independently prove an individual permission decision.

Your first useful milestone isn’t an enterprise-wide count. It’s one workflow whose owner can explain every actor, every handoff, and exactly how access ends. Expand from there with an inventory you can defend.

## Frequently asked questions

These questions address common points of confusion when you begin inventorying software identities and evaluating agents.

### What is a non-human identity?

A non-human identity represents software or a device rather than a person. Examples include application service principals, workload identities, bot accounts, and AI agent identities. Credentials such as API keys and tokens help systems recognize those principals or verify access claims. Managing the identity also requires ownership, permissions, and lifecycle controls.

### Why are AI agents different from other non-human identities?

AI agents can use model-generated decisions to select tools and sequence tasks, so their action path can change with context. Other software can also act dynamically. The agent-specific concern is preserving identity, permitted scope, and accountability across model-selected actions, including delegated tasks and requests made on an employee’s behalf.

### How many non-human identities are in a typical enterprise?

There isn’t a useful universal count without a shared counting method. An inventory might count principals, credentials, workloads, or application instances, producing different totals. Start by defining the unit, then map credentials and deployments to their principals. Track ownership and active permissions alongside totals so the count supports decisions.

### What is the OWASP NHI Top 10?

The OWASP NHI Top 10 is a risk taxonomy focused on non-human identities. Its 2025 edition covers issues including improper offboarding, secret leakage, excessive privileges, and long-lived secrets. It is separate from OWASP’s LLM Top 10. Use it to organize security reviews, not as a certification of an agent’s safety.

### What should enterprises look for in an agent identity model?

Look for verifiable agent identities, explicit ownership, request-specific authorization, traceable delegation, and enforcement before disallowed access or action. For delegated employee requests, test that agent permissions and the employee’s rights both constrain access. Background agents need separately governed service scopes. Also verify how permission changes and retirement affect active workflows.