Non-Human Identity Security for AI Agents
Non-human identity security stopped being a niche IAM concern the moment machine identities became the dominant identity class in many enterprises. A 2026 identity-security survey reported an average of 109 machine identities for every human identity, up from 82:1 the year before, and the same report said 9 out of 10 organizations experienced a successful identity-related breach in the last 12 months, while 96% said human identities operate with access far beyond what their roles require (Palo Alto Networks identity security landscape). That's the backdrop for AI agents now, because the core issue isn't just how many identities exist, it's that agents need to create, verify, and maintain accounts on systems you don't control.
The old model of identity governance assumes you own the infrastructure, the identity provider, and the revocation path. AI agents break that assumption. A production agent may need durable access to third-party sites, email inboxes, browser sessions, TOTP challenges, and long-lived credentials at the same time, which turns identity into a workspace problem rather than a simple login problem.
Table of Contents
- Why Non-Human Identity Security Is Now a First-Class Problem
- The Threat Model for AI Agent Identities
- Where Traditional IAM Falls Short for Agents
- Credential Management and Origin-Scoped Authentication
- Persistent Sessions and the Agent Account Lifecycle
- Auditability and Human Oversight for Agent Actions
- Building Versus Adopting Agent Identity Infrastructure
Why Non-Human Identity Security Is Now a First-Class Problem
The scale shift is already visible in the enterprise data. One industry report says modern environments now manage machine-to-human identity ratios of at least 25:1 in 89% of organizations, and nearly half exceed 100:1 (ManageEngine survey report). Independent coverage of the same general problem also describes machine identities as outnumbering humans by 109:1 on average in recent reporting (BERI on machine identities). Those numbers matter because machine identities aren't a corner case anymore, they're the default substrate for cloud, CI/CD, APIs, and agent systems.
The part service accounts never had to do
A service account usually authenticates to one internal API, maybe a database, maybe a queue. An AI agent has a much uglier job. It may need to sign up on a website, confirm an email address, enroll in MFA, survive browser-session expiry, and keep using the account later from a fresh process.
That changes the risk profile in a way traditional IAM doesn't cover well. A service token is scoped and predictable. An agent identity can accumulate credentials for dozens of SaaS products, inboxes, and web apps, all while operating on infrastructure the security team doesn't own.
Practical rule: if an identity has to survive across runs, the security boundary can't be the prompt or the process. It has to be the workspace.
Human vs. Non-Human Identity Scale in Modern Enterprises
| Identity Type | Typical Count per Enterprise | Credential Lifespan | Scope of Access | Governance Maturity |
|---|---|---|---|---|
| Human identity | Lower and centrally managed | Tied to employment lifecycle | Mostly bounded by role | Mature |
| Non-human identity | Often far larger than human population | Often long-lived or persistent | Frequently spans multiple systems | Uneven |
| Agent identity | Growing fast in production agent stacks | Must persist across runs | External websites, inboxes, sessions, MFA | Emerging |
That gap is why non-human identity security has become a control-plane issue, not an IAM footnote. The problem isn't just inventory. It's that existing controls were built for users who log in, work, and log out. Agents don't fit that pattern, and the breach surface shows it.
The Threat Model for AI Agent Identities
The attack surface expands as soon as secrets touch model context. If an LLM sees a plaintext password, API key, or session token in a prompt or tool result, that secret is no longer just a secret. It's now part of the agent's working context, which means prompt injection, logging, retries, and debugging paths all become leakage vectors.
Credential exposure to the model context
The worst mistake is letting the model handle raw credentials end to end. That's convenient during prototyping, and it's exactly how teams end up with passwords embedded in traces, chat transcripts, or tool output. A support agent reading a malicious customer email is a good example, because the email can instruct the model to echo back a stored admin password or reveal an API token in a reply.
Origin mismatches and lookalike pages
The next failure mode is origin confusion. An agent that autofills credentials into a browser form can be tricked by a lookalike domain, a malicious redirect, or a manipulated DOM into submitting secrets to the wrong place. The security mistake here is treating “a login page” as enough evidence, when the only thing that matters is the live origin.
Session hijacking and stale secrets
Persistent browser sessions are valuable because they keep the agent authenticated across runs. They're also valuable to attackers for the same reason. Once a session cookie is stolen, it often bypasses the friction of a fresh login, which makes cookie theft and local-state theft much more dangerous than a single password exposure.
Stale and over-privileged credentials
The last problem is accumulation. Agents tend to pick up credentials over time, and teams rarely clean them up with the same discipline they use for human accounts. Without automated rotation and tight scoping, one compromised workspace can expose a very wide blast radius.
A useful mental model is simple. If the agent can reuse it, an attacker will try to reuse it too.
The browser is where all four threats converge. That's why the auth layer has to be deterministic, origin-aware, and isolated from the model itself. The model can choose intent. It should not see the keys.
Where Traditional IAM Falls Short for Agents
Traditional IAM works because it assumes central control. You own the identity provider, you enforce SSO or federation, and you can revoke access in one place. That model breaks when the identity lives on third-party infrastructure like Gmail, Outlook, Shopify, Slack, or some vendor portal that only accepts username, password, and TOTP.
Secrets managers are necessary, but they're not enough
Vaults, CyberArk, and AWS IAM solve storage and distribution problems. They don't solve usage problems. A secrets manager can hand a credential to an environment, but it can't understand whether the browser is on the right origin, whether the agent is typing into the correct field, or whether the flow just turned into an attacker-controlled page.
That's the missing layer. Traditional IAM controls who gets the credential. Agent identity infrastructure has to control what happens when the credential is used.
Sessions are not tokens
Browser state makes life messy. Human IAM systems track token lifecycles and federated sessions. Agents depend on cookies, local storage, and other browser artifacts that don't fit cleanly into those controls. A valid browser session can survive long after the password that created it is rotated, which means the revocation story gets much harder once the agent is living in a third-party browser session.
The OAuth model helps explain the boundary. The spec distinguishes confidential clients from public clients based on whether they can keep credentials secret, and the security guidance treats secure client authentication as a requirement for anything that stores reusable credentials (OAuth 2.0 design decisions, OAuth 2.0 security cheat sheet). For agents, that means any credentialed flow needs a trusted server boundary, not a browser-exposed secret.
Credential Management and Origin-Scoped Authentication
The first rule is blunt. The LLM should never see a raw password, API key, or TOTP seed. If it does, you've already widened the attack surface to include prompt injection, trace logging, and model-context leakage.
Keep secret use out of prompt context
The right shape is a vault between orchestration and browser automation. The model expresses intent, then a deterministic auth layer retrieves the secret, checks the origin, and types it directly into the browser without returning the value to the model. That keeps the secret out of tool output and out of any place an attacker can try to coerce it back out.
A proper credential flow also needs scoping. Stored secrets should be bound to specific domains, because a prompt injection on one site shouldn't let the agent exfiltrate credentials to another. If the live origin doesn't match the expected origin, the fill should fail closed.
Handle TOTP as a server-side capability
TOTP needs the same treatment. The seed should live encrypted in an isolated component, and code generation should happen there too. The agent can request the action, but it shouldn't receive the seed or the generated code as reusable text. That limits what leaks if a model response, browser log, or debug trace gets exposed.
Scoping beats convenience
Teams often want the model to “just do auth.” That's the wrong instinct in production. Let the model own high-level intent, but keep the credential entry path deterministic and bounded. Rotation and least privilege still matter for service account keys and API tokens, and they matter more once those identities can be reused across third-party websites.
This guide to AI agent authentication covers the surrounding auth patterns, but the core operating rule stays the same. The model shouldn't handle secrets. It should trigger secret use under a strict origin policy.
The video below is a useful companion if you're designing the boundary between orchestration and auth handling.
A simple credential-control checklist
- Bind secrets to origin: make the browser prove where it is before any credential is injected.
- Keep secrets server-side: never return passwords, seeds, or tokens through read APIs.
- Log the access path: record which identity used which credential on which origin.
- Prefer short-lived scope: use the narrowest token or key that gets the job done.
The security value here is boring, and that's good. If the credential layer is deterministic, the model can't improvise its way into leaking secrets.
Persistent Sessions and the Agent Account Lifecycle
An agent account has a lifecycle, not a single login event. It starts with signup, moves through verification and MFA enrollment, then spends most of its life surviving session expiry, password resets, and site changes without losing state.
Signup and verification
A sane production flow starts with a dedicated email alias for the workspace. The agent uses that inbox to complete email verification, and the resulting account state lands in an encrypted, per-identity session store. That store needs to survive process restarts, because a long-running agent can't depend on one container or one browser instance staying alive forever.
The browser profile matters just as much as the mailbox. Cookies, local storage, and session artifacts need to persist together, or the agent ends up redoing work every time a job restarts.
MFA enrollment and re-authentication
If the site supports TOTP, enroll it once, store the seed safely, and make the future login path deterministic. That way the agent can re-authenticate later without a human reaching in for every session refresh. A good workflow also detects when a site starts requiring step-up auth or a CAPTCHA, then pauses long enough for the right approval path instead of blindly retrying.
Keep browser identity stable
Fingerprint consistency is part of the lifecycle too. User-agent strings, timezone settings, and related browser traits should stay stable enough that the site doesn't flag the agent as a completely new visitor every time. If those details drift, fraud systems get noisy, and the agent gets stuck in endless re-login loops.
Browser session management for agents is usually where teams discover how much state they were accidentally depending on.
Operational reality: session durability is less about “keeping a browser open” and more about preserving identity state across restarts, upgrades, and login flow changes.
When a site changes its login form or introduces a new bot-detection step, the break shouldn't show up as silent failure. Monitoring has to catch the regression early, because a broken auth flow often looks like a harmless retry storm until it burns through the account or the session is gone.
Auditability and Human Oversight for Agent Actions
Every action under a non-human identity needs a trail. Not just the final result, but the credential used, the origin it was used against, the action taken, and the response received. Without that, incident response becomes guesswork.
What a useful log actually contains
A flat access log isn't enough for agent systems. You need the action sequence, because the model's tool calls and decision path are part of the evidence. That's how you reconstruct whether the agent made a legitimate decision, got steered by bad data, or wandered into a privilege boundary it shouldn't have crossed.
| Field | Description | Example |
|---|---|---|
| Workspace ID | The persistent agent identity | workspace_42 |
| Origin | The live site where the action happened | ` |
| Credential reference | Which stored secret was used | admin-password-v3 |
| Action | What the agent did | submitted_login_form |
| Result | Outcome of the action | success |
| Approval state | Whether a human approved it first | approved |
| Event time | When it happened | 2026-08-26T10:14:00Z |
Where humans should still step in
Not every action needs a gate, but the high-risk ones do. Financial transactions, account deletions, permission changes, and anything that changes ownership should require explicit approval before the agent proceeds. Lower-risk operations can stay autonomous if the audit trail is clean and the workspace policy is tight.
Alerts should watch for behavior, not just failures
Anomalous origin use, weird action sequences, and sudden frequency spikes matter because they often show compromise before a full breakage event. If an agent starts using credentials from the wrong site, or starts churning through an unusual set of actions, that's a signal to stop and inspect.
Compliance monitoring for agent systems is basically the operating layer that makes this reviewable after the fact. If you can't explain what happened, you can't safely let the agent keep going.
Building Versus Adopting Agent Identity Infrastructure
Building this stack in-house sounds straightforward until you try to own the edge cases. You need credential vaulting, origin-scoped fills, TOTP handling, browser profile persistence, session recovery, and the ugly behavior around changing login flows. Then you still have to maintain fingerprint consistency, rotate secrets, and handle third-party sites that break authentication without warning.
What building actually costs
The hard part isn't the first implementation. It's the maintenance. Every external site has its own auth quirks, every browser update can shift behavior, and every new agent flow adds another place where a secret could leak or a session could die. If your team isn't ready to own that operational burden, the system will accumulate security debt.
What adopting changes
A managed identity layer can abstract a lot of the repetitive plumbing. That doesn't remove browser infrastructure, secrets management, or IAM. It just centralizes the workspace, the persistent inbox, the credential handling, the approval gates, and the activity history in one place instead of forcing every agent team to rebuild it.
Agentstead is one option in that category. It gives agents durable workspaces with persistent browser identity, email, credentials, TOTP authenticators, approvals, and activity history, so they can create, authenticate to, and maintain accounts on third-party websites without exposing the secret values back through read APIs.
How to decide
- Build it if the workflow is core to your product and the auth surface is narrow enough to own.
- Adopt it if your agents need to touch many third-party services, and the identity plumbing isn't your differentiator.
- Be conservative if you have a small platform team, because account lifecycle bugs are expensive to unwind later.
The wrong choice compounds. A brittle in-house identity layer becomes its own security system to babysit. A managed layer isn't magic, but it can keep you focused on the agent product instead of the authentication plumbing.
If your agents need durable accounts, persistent browser sessions, TOTP handling, and audit trails on third-party sites, Agentstead is built for that layer. It gives each agent a workspace with an inbox, credentials, browser state, approvals, and activity history, so you can keep secrets out of model context and keep auth state tied to the right origin. Visit Agentstead if you want to see how that workspace model fits into a production agent stack.