Service accounts, API keys and tokens now outnumber people in most companies. AI agents are the fastest-growing kind.
This page groups the NHI vendors by approach and shows what identity can and cannot control. Identity answers "who is this agent". An AI agent allow list answers "where may it go".
A non-human identity is anything that logs in or holds access without being a person.
Most companies already manage some of these. Agents are different from other NHIs in one way. A service account does the same thing every time. An agent chooses what to do next.
Every new agent brings keys, tokens and service accounts, often created by the agent's builder in minutes.
One agent may touch a CRM, a file store, email and the public web in a single task.
Nobody reviews each step, so access mistakes show up only in logs.
Agents can create accounts on outside sites, which no internal directory will list.
Vendors are listed as examples, based on how they describe their products. Many cover more than one approach.
Find every machine identity across SaaS and cloud, then score and clean up.
Replace static secrets with short-lived, policy-based access.
Large identity providers adding agent identities to their directories.
Vaults and privileged access tools that store and rotate secrets.
Access reviews and entitlement analysis across people and machines.
Find leaked keys in code, tickets and chat before attackers do.
Most large companies end up with two or three of these approaches working together, not one.
The market is consolidating. Palo Alto Networks announced a deal to acquire CyberArk in 2025, and more identity deals are likely.
Answered by NHI and identity platforms.
Answered by page-type data, checked before each request.
An agent with a perfectly scoped identity can still open a stranger's signup page and create an account. Identity never saw that request, because it was not using the agent's credentials.
A research agent starts with a scoped, short-lived identity. The NHI platform shows it as healthy.
A vendor page says "Sign up to see full pricing". The agent follows the link.
It fills the signup form with a company email. A new third-party account now exists.
That account is a non-human identity in all but name. No inventory will ever find it.
At 09:14 the URL is checked. Page type: signup. Request denied and logged. No account is created.
This is why the signup, password_reset and login page types matter to identity teams. They are where new identities are born.
The same pattern applies to password reset pages. An agent that can reach them can lock people out of accounts or take them over.
Login pages carry a third risk: an agent handed a leaked credential can use it, even if nobody meant it to.
| Need | NHI discovery | Workload access | Identity platform | Secrets and PAM | Page policy data |
|---|---|---|---|---|---|
| Find all agent credentials | Yes | Partly | Own directory | Vaulted ones | No |
| Short-lived agent access | No | Yes | Yes | Rotation | No |
| Owner and offboarding | Yes | Partly | Yes | Partly | No |
| Stop agents signing up elsewhere | No | No | No | No | Yes |
| Stop agents on login pages of other sites | No | No | No | No | Yes |
| Stop purchases and uploads | No | No | No | No | Yes |
| Evidence per action | Credential use | Access grants | Sign-ins | Secret use | Every URL decision |
The table describes typical products by approach. The pattern is clear: identity tools and page policy data cover different rows.
Discovery, so you know how many agent identities exist and who owns them.
Page policy data at the egress point, so agents stop creating identities elsewhere while you clean up.
Short-lived access for agents, replacing static keys one team at a time.
Identity governance reviews that include agents alongside people.
All four are among the 28 page types for 40M+ domains. Each URL is verified on the site, not guessed from a pattern like /login.
See login page detection and the credential surface taxonomy.
Agents need different lifetimes and reviews than service accounts.
Low-code and vendor agents often hide inside SaaS tenants.
Minutes are better than days for autonomous agents.
Ownership is the first thing auditors check.
Agents reach tools through servers that hold their own secrets.
The same agent may need different rights for different jobs.
All keys, tokens and sessions should end together.
Sign-in logs miss what the agent did afterwards.
Page types and host lists can inform access decisions.
Delegated access needs consent, limits and a clear trail.
The identity platform issues the agent a short-lived credential for the task.
The agent calls internal systems. Identity policy decides what it may reach.
The agent wants a public web page. The proxy checks the URL's page type.
Read pages pass. Login, signup and password reset pages are denied for this agent.
Both decision logs are joined by agent ID for audit and incident review.
Joining the logs by agent ID is the key design choice. It lets one review answer both "what could it access" and "where did it try to go".
Use the same agent ID in the identity platform, the gateway, the proxy and the governance register. Mismatched names are the most common reason audits stall.
If the identity is revoked, the proxy should also deny that agent everything. One kill switch, two enforcement points.
Step 4 is usually missing from NHI programmes. It is also the step that prevents new, untracked identities from appearing on other sites.
Add it to the same change process as steps 3 and 6, so the web policy is reviewed whenever access changes.
| Question | Delegated agent (acts for a user) | Autonomous agent (acts for itself) |
|---|---|---|
| Whose rights does it use? | A subset of the user's rights | Its own service identity |
| Main identity risk | Doing more than the user intended | Holding more access than the task needs |
| Key identity control | Consent and scoped delegation | Short-lived, task-scoped credentials |
| Main web risk | Signing up or buying in the user's name | Creating accounts in the company's name |
| Key web control | Deny action pages, ask the user | Deny action pages, ask the owner |
| Audit question | Did the user approve this? | Was this inside the agent's purpose? |
Both kinds need the same web control. Only the person who approves an exception changes.
Delegated agents are growing fastest, because they arrive inside tools staff already use. Record them in the same register as your own agents.
Every action looks like the person did it. Audit trails become useless.
Nobody can tell which agent did what, or revoke just one.
A leaked agent key keeps working long after the project ends.
Keys pasted into instructions end up in logs and model context.
Agents log in to or sign up for third-party sites without anyone knowing.
Old agents keep tokens and keep calling services.
Agents with their own identity, as a share of all agents found.
Median lifetime of agent credentials, trending down.
Agents without a named owner. The target is zero.
Denied attempts on login, signup and password reset pages, per agent.
Days from retirement decision to all credentials revoked.
The fourth metric comes from page-policy decision logs. It is the early sign of an agent trying to create identities of its own.
Report all five monthly, broken down by agent owner, so each owner sees their own agents.
The honest fine print — the same two assumptions we publish, plus two operational ones
Page types for login, signup and password reset pages on 40M+ domains.
