Non-Human Identity Security: How to Apply Zero Trust to Service Accounts, Workloads, and AI Agents

Zero trust programs usually start with people: single sign-on, MFA, device checks, and conditional access. Then the audit comes back, non-human identity security becomes the urgent gap, and the largest group of identities with standing access turns out to be software. Service accounts created for a migration years ago, API keys pasted into scripts, OAuth apps connected by a single employee, CI/CD tokens, and, since 2025, AI agents that call tools on their own.

The discipline is about bringing those identities under the same rules as people: verify every request, grant least privilege, and assume breach. This guide works through the lifecycle of a non-human identity, from discovery to retirement, and maps each stage to the risks OWASP has catalogued. It focuses on identity. For permissions, logging, and kill switches that are specific to agents, see our guide to AI agent governance.

Definition: A non-human identity (NHI) is a digital identity used by software rather than a person: a service account, API key, OAuth client, certificate, cloud workload identity, or AI agent. It authenticates to systems and holds access to data or actions, often with no MFA and no named owner.

Why non-human identity security needs its own program

Human identities have a natural lifecycle tied to HR: a joiner gets an account, a leaver loses it. Non-human identities have no such trigger. They are created by developers, platforms, and integrations, and nothing removes them automatically when a project ends. Three traits make them risky:

• They often authenticate with static secrets, such as keys and passwords, that do not expire.
• They are frequently granted broad permissions because nobody knows exactly what they need.
• They lack an owner, so nobody notices when one starts behaving oddly.

AI agents add a fourth trait. An agent decides at run time which tools to call, so its access pattern is harder to predict than a script’s. That makes least privilege more important, not less.

The OWASP NHI Top 10 in brief

The OWASP Non-Human Identities Top 10, released in 2025, gives security teams a shared list of risks. Each one maps to a control you can assign to an owner:

Stage 1: Discover every non-human identity

Every non-human identity security program begins with a count, and the count is almost always higher than anyone expects.

Start with an inventory, because most teams undercount. Pull from:

• Your identity provider: service principals, app registrations, and OAuth grants
• Each cloud account: IAM users, roles, access keys, and managed identities
• Secrets managers and CI/CD systems
• SaaS admin consoles: connected apps, API tokens, and bots
• Code repositories, using secret scanning on current code and history
• AI platforms: agents, their connectors, and the credentials they hold

Record for each identity: what it is, which system it lives in, what it can access, how it authenticates, when it last authenticated, and who created it.

Stage 2: Assign an owner to every identity

An identity without an owner is the root of most NHI risks. Give each one a named human owner and a team, both recorded in a field the security team can query. Set a rule: identities with no owner after 30 days are disabled, then deleted after a further review period. This step alone closes much of the offboarding risk.

Stage 3: Issue identities in the zero trust way.

The NIST zero trust architecture, SP 800-207, treats every access request as untrusted until verified by whoever or whatever makes it. For non-human identities, that means moving away from static secrets wherever the platform allows:

• Use cloud workload identities, such as AWS IAM roles, Azure managed identities, and Google Cloud service account impersonation, instead of stored access keys.
• Use workload identity federation so CI/CD pipelines receive short-lived tokens rather than stored credentials.
• Use OAuth 2.0 client credentials with short token lifetimes for service-to-service calls.
• Consider SPIFFE-based workload identity for services running across clusters and clouds.
• Give each AI agent its own identity rather than letting it act with a user’s full session.

Where a static secret cannot be avoided, store it in a secrets manager, never in code or configuration files, and set an expiry date.

Stage 4: Scope access to the task

Least privilege is harder for software because developers often grant broad roles to make something work quickly. A practical routine:

1. Compare granted permissions with permissions actually used over the last 90 days, using your cloud provider’s access analysis tools.
2. Remove unused permissions and replace wildcard roles with specific ones.
3. Limit where each identity can be used from, such as specific networks or workloads.
4. For AI agents, grant access per tool and per data set, and require human approval for actions that change records, move money, or send external messages.
5. Keep separate identities for test, staging, and production.

Stage 5: Rotate secrets and shorten lifetimes

Long-lived secrets are the easiest target for attackers because a leaked key keeps working. Set rotation by risk: automatic rotation for anything that touches production data, and a maximum lifetime for every secret. Rotation must be tested, because a rotation that breaks an integration teaches teams to stop rotating. Keep a runbook for emergency revocation so a leaked key can be killed in minutes.

Stage 6: Monitor behavior

Non-human identities are predictable, which makes anomalies easier to spot than with people. Alert on:

• Authentication from a new location, network, or workload
• Use of permissions the identity has never used before
• Interactive logins to accounts meant only for machines
• Sudden spikes in API calls or data volume
• For AI agents, calls to tools outside the agent’s approved list

Send these events to the same security monitoring platform that handles human identity alerts, with the owner attached so the right person is contacted.

Stage 7: Retire identities on purpose

Retirement is the stage most non-human identity security programs skip. Build it into change processes. When an application is decommissioned, an integration replaced or an agent switched off, the identities and secrets go with it. Run a quarterly review of identities that have not authenticated in 90 days, and disable them after owner confirmation.

Who owns non-human identity security

Ownership is usually split, and that is fine as long as it is written down. The identity or IAM team owns the standards, the inventory, and the review process. Platform and cloud teams own workload identities and pipeline federation. Application teams own the identities their services use and respond when an alert fires.

The security operations team owns detection and emergency revocation. For AI agents, add the business owner of the agent, who decides what the agent is allowed to do and approves changes to its tools. Report progress with a few simple measures: the share of identities with a named owner, the number of static secrets older than 90 days, the number of identities unused for 90 days, and the time taken to revoke a leaked secret.

Where to start in the next 30 days

1. Run secret scanning across your main code repositories and revoke anything live that it finds.
2. Export all cloud access keys older than 90 days and plan to replace them with workload identities.
3. List every OAuth app connected to your main SaaS platforms and remove those with no business owner.
4. Give every AI agent in production its own identity, scoped to its tools.

These steps fit inside a wider identity program. For agents built on enterprise platforms, our comparison of enterprise AI agent platforms notes how each handles agent credentials. If you are choosing an identity platform, our upcoming comparisons of IAM tools will cover how each handles workload and agent identities.

FAQs: