OWASP's Non-Human Identities Top 10 lists the ten most common risks with machine identities. Every one of them gets sharper when the identity belongs to an AI agent.
This page walks through all ten, then adds the web risk the list does not name, where an AI agent allow list helps.
Names follow the OWASP list. The agent angle below each item is our reading, meant for teams securing AI agents.
The list was written for all machine identities: service accounts, API keys, tokens and certificates. It was not written for agents specifically.
That makes it more useful, not less. Agents are machine identities that also make decisions, so every classic risk applies, with a twist.
Service accounts and keys stay active after the project, person or system is gone.
Pilot agents are spun up fast and forgotten fast. Their keys keep working.
Old agents may still run on a schedule nobody checks.
Secrets leak into code, tickets, chat, logs and public repositories.
Keys get pasted into prompts and agent configs. They then appear in model context and traces.
An agent can also paste a key into a web form.
Third-party integrations hold tokens into your systems. If the vendor is breached, so are you.
Third-party MCP servers and SaaS agents receive tokens to act for you.
Each one is a new outside identity with inside access.
Static passwords, basic auth and deprecated flows make machine identities easy to steal.
Agents are often built quickly on the easiest auth method available.
Browser agents may type passwords into login pages.
Machine identities get broad rights "to be safe", which attackers then inherit.
Agents are given wide access so they "can figure it out". Their choices then reach everything.
This is the identity form of excessive agency.
Pipelines and cloud resources store credentials in plain config or trust too broadly.
Agents deployed through pipelines inherit those weaknesses. Agents in the cloud can reach metadata endpoints.
Tokens and keys valid for months or years give attackers a long window.
Autonomous agents run for hours or days, so teams issue long-lived keys to avoid interruptions.
The same identity works in development and production, so a test leak becomes a production breach.
Agents are prototyped with production keys to "use real data". Evaluation setups reach real systems.
Several apps share one service account, so nothing can be traced or revoked cleanly.
A team runs five agents on one key. When one misbehaves, all must stop.
Staff use service credentials by hand, blurring who did what.
The reverse is common too: agents run under a person's own login, so the agent's actions look human.
Not every risk changes equally when the identity belongs to an agent.
Our assessment of how agents change each risk, to help you order the work.
"High" means agents make the risk both more likely and harder to spot. Start with those four rows.
| Risk | Growth with agents | Why | First control |
|---|---|---|---|
| NHI5 Overprivileged | High | Agents choose what to do with access | Task-scoped access |
| NHI2 Secret leakage | High | Keys in prompts, traces and forms | Vault plus deny upload and post pages |
| NHI3 Third-party NHI | High | MCP servers and SaaS agents multiply | Approved server list |
| NHI1 Offboarding | High | Pilots are created and forgotten | Review dates and one-step retirement |
| NHI7 Long-lived secrets | Medium | Long-running agents | Short-lived credentials |
| NHI4 Insecure auth | Medium | Browser agents on login pages | Deny third-party login pages |
| NHI8 Isolation | Medium | Evaluations with real access | Default-deny egress for tests |
| NHI9 Reuse | Medium | Many agents, one key | One identity per agent |
| NHI6 Cloud config | Medium | Agents reach metadata endpoints | Host list denies metadata |
| NHI10 Human use | Low to medium | Agents on personal logins | Separate identities |
The LLM list protects the model, the agentic list protects the actions, and the NHI list protects the keys. Use all three together. See the framework comparison for how they fit with NIST and AWS guidance.
The OWASP list covers identities you issue. Agents can also create identities on other people's websites.
Those accounts are real non-human identities tied to your company. They just live where your tools cannot see them.
Check the page type of every URL before the agent opens it. Deny the four credential page types.
Page types come from the page types database, verified for 40M+ domains.
| Signal | Where you see it | What to do |
|---|---|---|
| Denied signup page requests | Page-policy decision log | Ask the owner why the task needed an account |
| Welcome emails from unknown services | The agent's mailbox or shared inbox | Close the accounts, tighten web policy |
| Password reset emails nobody requested | Staff mailboxes | Check whether an agent reached a reset page |
| Invoices or trial reminders | Finance inbox | Trace the signup to the agent and cancel |
| Requests to many new domains in a day | Proxy logs | Review the agent's task and default-deny unclassified hosts |
Week 2 comes early on purpose. Web controls take effect in a day and stop new damage while slower identity work continues.
By the end of week 4, every agent should have one identity, one owner, one review date and one web policy.
The agent reads prospect websites and updates the CRM. Here is what an assessment found.
| Risk | Finding | Fix |
|---|---|---|
| NHI1 | Two older versions still ran on a schedule | Retired both, keys revoked |
| NHI2 | CRM key pasted in the system prompt | Moved to the vault |
| NHI3 | Uses a third-party enrichment MCP server | Reviewed and approved with read-only tools |
| NHI4 | Browser tool could reach any login page | Denied the login page type |
| NHI5 | CRM key could delete records | Replaced with update-only access |
| NHI6 | Runs in the cloud, metadata endpoint reachable | Denied by host list |
| NHI7 | Key valid for one year | Hourly credentials |
| NHI8 | Test runs used the production CRM | Separate sandbox identity |
| NHI9 | Shared key with the marketing agent | One identity each |
| NHI10 | Ran under the sales manager's login at first | Own service identity |
| Eleventh risk | Had created three trial accounts on vendor sites | Signup page type denied, accounts closed |
This is a composite example built from common patterns, not a single real customer.
Notice how many fixes were small. Most took less than a day once the finding was written down.
The eleventh-risk finding was the only one nobody expected. It was also the only one visible to outside companies.
Add an eleventh question: which login, signup and password reset pages can it reach on the web?
Record the answers in the agent register, next to the owner and review date.
The honest fine print — the same two assumptions we publish, plus two operational ones
Deny credential page types for every agent, on 40M+ domains.
