You check your Okta dashboard. You see 1,200 active users. You check your AWS IAM dashboard. You see 45,000 active roles.
Something is wrong. You don’t have 45,000 engineers. You have 45,000 ghosts.
Welcome to the Non-Human Identity (NHI) Crisis. In 2026, the primary consumer of your infrastructure is no longer a human with a badge. It is an Autonomous Agent with an API key.
And unlike humans, these agents don’t attend security training. They don’t use 2FA. And they definitely don’t resign. They just accumulate.
The “God Mode” Problem
How did we get here? When a developer builds a “Customer Support Agent,” they need it to check order status. So they ask for database access. The IAM team asks: “Which tables?” The developer says: “I don’t know yet. The agent might need to check Orders, or Returns, or Inventory. It depends on what the customer asks.”
So the IAM team sighs and grants ReadOnlyAccess to *.
The agent works. Everyone is happy.
Until six months later, when that same agent is tricked by a prompt injection into downloading the entire customer database. You gave a probabilistic actor deterministic “God Mode” privileges.
Why Static IAM Fails for Dynamic Agents
Traditional Identity Governance Administration (IGA) was built for people.
- People are stable: Bob is in Accounting. He needs access to Netsuite.
- Agents are fluid: Agent V2 might need access to Slack today, and access to Jira tomorrow.
When you try to apply human rules to bots, you get two outcomes:
- Broken Agents: You lock them down too tight, and they crash when they try to do something new.
- Breached Data: You leave them too open, and they become the path of least resistance for attackers.
You cannot solve this by reviewing spreadsheets once a quarter. You are fighting a wildfire with a clipboard.
The Solution: Identity Sandboxes
The only way to secure a non-deterministic agent is to observe it in a controlled environment. You need to move from Static Policy Definition to Dynamic Policy Generation.
This is why top security teams are using PrevHQ as an “Identity Sandbox”.
1. The “Zero Trust” Start
When a developer opens a PR for a new agent, PrevHQ spins up an ephemeral environment. Crucially, the agent starts with Zero Privileges.
2. The Learning Mode
We run the agent through a gauntlet of 1,000 simulated user requests.
- User: “Where is my order?” -> Agent tries to read
Orderstable. -> Access Denied. - User: “I want a refund.” -> Agent tries to write to
Refundstable. -> Access Denied.
3. The Auto-Generated Policy
PrevHQ records every “Access Denied” event. It then generates a precise IAM policy that allows only those specific actions on only those specific resources.
“Allow
db:Selectontable:Orders” “Allowdb:Insertontable:Refundswhereamount < $50”
You copy-paste this policy into Terraform. You have achieved Least Privilege without guessing.
Stop Managing Secrets, Start Managing Behavior
The era of “Long-Lived Service Accounts” is ending.
If you have a static API key sitting in a .env file for 3 years, you are already hacked.
The future is Ephemeral Identity. Agents should only have access while they are working, in environments that are verified.
Don’t let your “Ghosts” haunt you. Turn on the lights. Sandbox the identity. And secure the bot.
FAQ: Managing Non-Human Identity for AI Agents
Q: What is Non-Human Identity (NHI)?
A: Identities for machines. It refers to the credentials (API keys, certificates, service accounts) used by software to authenticate to other software. In the AI era, NHI volume is exploding because every agent needs its own identity.
Q: How do I manage non-human identity for AI agents?
A: Use scoped, short-lived credentials. Never share keys between agents. Use “Workload Identity Federation” (like AWS OIDC) to let agents authenticate without stored secrets. And most importantly, use Identity Sandboxes to test and scope permissions before deployment.
Q: Why is “Least Privilege” hard for AI?
A: Unpredictability. Unlike a traditional script that always does Steps A, B, and C, an AI agent chooses its own path. It is hard to predict exactly what permissions it will need, leading to “Over-Privilege” by default.
Q: How often should I rotate agent keys?
A: Ideally, never (because they shouldn’t exist). You should aim for keyless authentication (OIDC). If you must use keys, rotate them automatically every few hours. A key that exists for months is a liability.