What Is NHI (Non-Human Identity)? Understanding Agent Identity Risk in SaaS

NHI (Non-Human Identity) is any identity used by software, rather than a person, to authenticate and access systems or data: applications, workloads, APIs, bots, service accounts, roles, and API or access keys. This is the industry-standard framing, and it’s the space OWASP’s Non-Human Identities Top 10 project addresses. OWASP’s own page focuses on cataloging the risks (see the Top 10 below) rather than a single formal definition. It’s a good starting point for what counts, but the short version undersells what’s actually changed in the last two years: AI agents have introduced a new, higher-stakes subclass of NHI, agent identity, and turned NHI from a secrets-management footnote into one of the most consequential identity problems in SaaS security.

NHI meets agent identity: why AI agents changed the equation

Traditional NHIs (a CI/CD pipeline’s API key, a monitoring tool’s service account) do one narrow thing with one set of credentials. An AI agent doesn’t. It can behave like a digital employee: read your Google Drive, query a database, update Salesforce records, post in Slack, modify a Jira ticket, and call other agents, all under a single agent identity that often has broader reach than any one human’s login.

That expanded capability set is significant enough that Microsoft now treats agent identity as its own category, distinct from both human identity and traditional NHI. Entra Agent ID, Microsoft’s dedicated platform for agent identity authentication, authorization, governance, and lifecycle controls, reached general availability in April 2026, with support for Dataverse agent users following in public preview as of August 2026. That’s a strong signal this isn’t a hypothetical risk category; major platform vendors are already building dedicated infrastructure around agent identity specifically, and actively expanding it.

Human identity vs. NHI vs. agent identity: three risk profiles

The agent identity row is the one to sit with. An autonomous agent can act entirely on its own agent identity, while an interactive agent may act on a human’s behalf using delegated permissions, and agents increasingly talk to other agents, creating trust relationships that need their own authentication and audit trail. Each of those patterns needs to be governed differently.

The API key isn’t the issue, itself. It’s the whole chain.

Most NHI conversations start and end at “protect the secret.” That’s necessary but not sufficient. The credential is one link in a longer chain that has to be understood end to end:

Identity → credential → permissions → resources → activity → owner

Skip any link — say, you rotate the credential but never map which human or team owns the identity — and you still have an ungoverned NHI, just with a fresher token.

The OWASP Non-Human Identities Top 10 (2025)

OWASP’s NHI Top 10 project catalogs the recurring failure modes across that chain:

1. Improper Offboarding: NHIs that are never deactivated when the service, integration, or employee that created them goes away.
2. Secret Leakage: API keys, tokens, and certificates ending up in unsanctioned stores (repos, chat logs, config files).
3. Vulnerable Third-Party NHI: compromised third-party apps or SaaS integrations that steal or misuse credentials.
4. Insecure Authentication: deprecated or weak auth methods protecting the identity itself.
5. Overprivileged NHI: identities with far more access than their function requires.
6. Insecure Cloud Deployment Configurations: exposed credentials or tokens in CI/CD pipelines.
7. Long-Lived Secrets: credentials with distant or nonexistent expiration dates.
8. Environment Isolation failures: the same NHI reused across dev, staging, and production.
9. NHI Reuse: one identity shared across multiple applications or services.
10. Human Use of NHI: people using service credentials for manual tasks instead of their own identity.

None of these are AI-specific. All of them get worse once the identity behind them is an agent making autonomous decisions across several systems at once.

Agent Identity Risk Inside SaaS

Most NHI writing, including OWASP’s own framing, is pitched at the infrastructure layer: secrets managers, CI/CD, cloud IAM. That’s necessary, but it misses where a lot of agent identity risk actually surfaces first: inside the SaaS applications the business runs on.

Every SaaS tenant has its own version of this graph, and the identity sits at the front of it, not the credential:

Agent identity (NHI) → connected app → scopes granted → SaaS objects and data → actions taken → risk

Play it out with an illustrative scenario: an AI sales agent’s identity is connected to Salesforce, scoped to read and write Accounts and Contacts: object types covering 600,000 records. Nothing about that grant looks unusual on approval day. Then at 2 a.m., that same agent identity downloads 80,000 contacts in a single session. Was that a legitimate bulk-enrichment job, or exfiltration through a compromised or over-permissioned agent identity? Without visibility into the identity itself, including which agent, which scopes, which objects, which actions, at what volume and time, there’s no way to answer that question quickly enough to matter.

This is the version of NHI risk that emerges first for most companies, because shadow AI adoption inside SaaS tools is already happening faster than most security teams can inventory it. 1 in 5 organizations has already experienced a breach linked to unsanctioned AI (IBM, 2025). It’s a close cousin of the Shadow AI vs. Shadow IT problem, but viewed through agent identity rather than tool inventory: the question isn’t just “is this AI tool sanctioned,” it’s “what agent identity is operating here, and what can that identity actually touch.”

Agent identity also isn’t a wholesale replacement for the app-level access controls teams already have. Unauthorized third-party SaaS integrations were already a known problem before agents entered the picture, and our OAuth App Risk in 2026 report covers that layer in depth. What’s new is the identity layer sitting on top of it: once the thing holding that access is an autonomous agent identity rather than a static integration, the access grant is only half the risk picture. The other half is what the identity actually decided to do with it.

Essential Controls for Agent Identity Governance

Applied to agent identity specifically, the standard NHI controls need a few additions:

• Discover every agent identity, both sanctioned and shadow, connected to your SaaS estate, not just the ones IT provisioned.
• Give each agent its own unique identity rather than sharing a generic service account across multiple bots or automations.
• Map every agent identity to a human or business owner, so “who’s responsible for this” has an answer before an incident, not during one.
• Enforce least privilege and short-lived credentials on every agent identity rather than standing, broad grants.
• Monitor what data each agent identity actually reads and modifies; the scopes it was granted are the ceiling, not the reality.
• Detect anomalous agent identity behavior; volume, timing, and object-type patterns that don’t match the agent’s normal function (like a 2 a.m. bulk download).
• Revoke the agent identity immediately when the agent is retired. This is Improper Offboarding (OWASP NHI1), and it’s the single most common gap in practice.

This is effectively where preventing data loss from AI agents and stopping AI-agent data leaks inside SaaS platforms like Salesforce is less of an “AI governance” conversation and more of a specific agent identity governance problem: mapping every agent identity to its scopes, its object-level activity, and its owner, tenant by tenant. That’s the graph SSPM from Spin.AI is built to make visible.

FAQ

Was this helpful?

Yes No