Non-Human Identities and AI Agents: The Access Nobody Reviews

Treat every service account, API key, token, and AI agent as an identity with an owner, a purpose, a minimum set of permissions, and an expiration date. The OWASP Non-Human Identities Top 10 ranks improper offboarding, secret leakage, and vulnerable third-party integrations as the top three risks (OWASP). Start with an inventory, because most organizations cannot say how many non-human identities they have.

Identity programs were built around people: joiners, movers, leavers, quarterly access reviews. Non-human identities (NHIs) skip almost all of that. They are created by developers or vendors, granted broad permissions to make something work, and rarely revisited. AI agents make the problem bigger, because an agent that can read email, query a database, and call APIs is a non-human identity with a lot of reach.

What counts as a non-human identity

OWASP describes NHIs as identities used by applications, typically backed by secrets such as API keys, tokens, certificates, or encryption keys that authenticate to other systems or SaaS applications. Long-lived secrets behave much like human passwords (OWASP). In practice that includes:

• Service accounts in Active Directory and Entra ID
• Cloud IAM roles, access keys, and workload identities
• OAuth applications and SaaS-to-SaaS integrations
• CI/CD pipeline credentials
• AI agents and copilots acting with delegated or application permissions

The OWASP NHI Top 10

1. Improper offboarding. NHIs left active after their purpose ends.
2. Secret leakage. Keys and tokens in source code, config files, or chat.
3. Vulnerable third-party NHI. A compromised extension or integration used to steal credentials.
4. Insecure authentication. Deprecated or weak methods.
5. Overprivileged NHI. More permissions than the function needs.
6. Insecure cloud deployment configurations. CI/CD credentials exposed, or OIDC trust without strict claim conditions.
7. Long-lived secrets. Credentials that never expire.
8. Environment isolation. The same NHI used across test and production.
9. NHI reuse. One identity shared across multiple services.
10. Human use of NHI. People using service accounts for manual work, which destroys accountability.

List and definitions from OWASP's 2025 ranking. GitGuardian's analysis of the list adds practical examples of how each risk shows up in real environments (GitGuardian).

Why AI agents raise the stakes

AI agents combine several of these risks at once. They usually run on an OAuth grant or API key (secret leakage, long-lived secrets), they are often granted broad scopes so they can be helpful (overprivileged), and they act on instructions that may come from untrusted content, such as an email or document carrying a prompt injection. An agent with permission to read a mailbox and send messages can be steered into doing both on an attacker's behalf. We covered the governance side in our post on AI security for regulated industries.

A 30-day starting plan

1. Inventory. Export service accounts, app registrations, OAuth grants, and cloud access keys. Count them. Most teams are surprised.
2. Assign owners. Every NHI gets a named human owner. Anything nobody claims within two weeks gets disabled, with a documented rollback.
3. Kill the oldest secrets. Rotate keys older than a year, and move CI/CD to short-lived, federated credentials where your platform supports it.
4. Scope AI agents tightly. Grant agents the narrowest permissions that work, require human approval for actions like sending email or changing records, and log every action they take.
5. Scan for leaked secrets in repositories and collaboration tools, and make it continuous.
6. Monitor behavior. Alert when an NHI authenticates from a new location, at a new time, or calls APIs it has never used. A SOC that baselines service-account behavior catches abuse that MFA cannot, because NHIs do not use MFA.

Compliance is catching up

Frameworks already cover this in principle. NIST SP 800-171, HIPAA, and PCI DSS all require least privilege and account management, and none exempt service accounts. Assessors increasingly ask to see the NHI inventory. If yours does not exist yet, the inventory step above is also audit preparation, and it fits naturally into a broader zero trust identity program.

If you want help building the first inventory, get in touch.

Frequently asked questions

What is a non-human identity?

A non-human identity is an identity used by software rather than a person, such as a service account, cloud role, API key, OAuth application, CI/CD credential, or AI agent, usually authenticated with a secret like a key, token, or certificate.

What is the OWASP Non-Human Identities Top 10?

A 2025 OWASP ranking of the top risks for non-human identities, led by improper offboarding, secret leakage, and vulnerable third-party NHIs, and including overprivileged NHIs, long-lived secrets, and human use of NHIs.

Why are AI agents a non-human identity risk?

AI agents typically run on API keys or OAuth grants with broad permissions and act on content that may contain malicious instructions, so a compromised or manipulated agent can misuse all of its access.

How do I start securing non-human identities?

Inventory service accounts, app registrations, OAuth grants, and keys; assign a human owner to each; disable unowned identities; rotate old secrets; move to short-lived credentials; and monitor NHI behavior for anomalies.

Do compliance frameworks cover service accounts?

Yes. Least privilege and account management requirements in NIST SP 800-171, HIPAA, and PCI DSS apply to service accounts and other non-human identities as well as people.