What does zero trust mean for identity?
By Identra · Updated
Zero trust identity is the application of the never trust, always verify principle to every identity in an environment: human, machine, and AI agent. Instead of granting durable access after a single login, zero trust treats each request as untrusted and evaluates identity, posture, and context continuously, at every access decision.
Key numbers
- Machine identities outnumber human identities 82 to 1 in organizations (CyberArk Identity Security Landscape, 2025)
- 22% of breaches involved stolen credentials as the initial access vector (Verizon Data Breach Investigations Report, 2025)
- 88% of basic web application attacks used stolen credentials (Verizon Data Breach Investigations Report, 2025)
- 79% of IT and security professionals feel ill-equipped to prevent attacks that use non-human identities (Cloud Security Alliance and Oasis Security survey, 2026)
From network perimeter to identity perimeter
Zero trust began as a network architecture idea. Forrester analyst John Kindervag introduced the term in 2010, and NIST formalized it in Special Publication 800-207 in 2020. The core principle is simple: grant no implicit trust based on network location, asset ownership, or past behavior. Every request for access is evaluated on its own merits, every time.
As perimeters dissolved into cloud services, remote work, and API-to-API traffic, identity became the natural enforcement point. If you cannot trust the network a request comes from, the only thing left to evaluate is who or what is making the request, with which credential, from what context, and for what purpose. That shift makes identity the control plane of zero trust. It also means a zero-trust program is only as strong as its weakest identity, and most organizations have far more identities than they think.
Why is continuous evaluation different from login-time verification?
Traditional access control front-loads all the scrutiny. A user authenticates once, often with MFA, receives a session or token, and is then trusted for hours or days. Zero trust rejects that model because trust decays: a session can be hijacked, a token can be stolen, a device can be compromised, and a legitimate identity can start behaving illegitimately, all after the login check has passed. The Verizon Data Breach Investigations Report (2025) found stolen credentials were the initial access vector in 22% of breaches, and 88% of basic web application attacks used stolen credentials. A credential that passed verification at login is exactly what attackers replay.
Continuous evaluation moves the trust decision from the front door to every door. Each request is scored against current signals, and access can be narrowed or revoked mid-session when the picture changes.
| Dimension | Login-time verification | Continuous zero-trust evaluation |
|---|---|---|
| When trust is decided | Once, at authentication | At every access request |
| What is evaluated | Credential validity | Identity, device, context, behavior, and requested action |
| Stolen credential impact | Full session access until expiry | Anomalous use flagged or blocked mid-session |
| Revocation | Wait for token or session expiry | Immediate, per-request denial |
| Privilege model | Standing entitlements | Just-in-time, least-privilege grants |
Where do non-human identities break zero-trust assumptions?
Most zero-trust reference architectures quietly assume a human on a managed device. Non-human identities, which are service accounts, API keys, OAuth app tokens, workload identities, and pipelines, violate those assumptions at scale. CyberArk's Identity Security Landscape (2025) found machine identities outnumber human identities 82 to 1, so the population zero trust was designed around is now a rounding error in the identity inventory.
The gaps are structural, not incidental:
- No second factor: an API key or client secret is a single static credential, so possession equals identity.
- No device posture: a workload has no managed laptop to attest, removing a core zero-trust signal.
- No session to re-evaluate: many NHI credentials are long-lived bearer tokens that stay valid for months or years.
- No clear owner: orphaned service accounts persist after the team or project that created them is gone.
- No behavioral baseline: few organizations know what normal looks like for each machine identity, so anomalous use goes unflagged.
What does zero trust mean for AI agents?
AI agents stress zero trust harder than traditional NHIs because they combine machine speed with human-like discretion. An agent authenticates legitimately, often with OAuth tokens delegated from a human user or with credentials granted to a tool integration such as an MCP server, and then decides for itself which actions to take. The credential check passes; the question is whether each individual action the agent takes should be trusted.
That breaks the last comfortable assumption of login-time security: that a verified identity implies verified intent. An agent with a valid token can chain permissions across systems, be steered by prompt injection, or drift far outside the task it was delegated, all without a single failed authentication. A Cloud Security Alliance and Oasis Security survey (2026) found 79% of IT and security professionals feel ill-equipped to prevent attacks that use non-human identities, and agents widen that gap. For agents, zero trust has to mean per-action authorization: evaluating each tool call and data access against the agent's identity, its delegation chain, and the task it is supposed to be doing.
How do you apply zero trust to identity in practice?
Applying zero trust to the full identity population, not just the human slice, comes down to a few disciplines:
- Inventory every identity: humans, service accounts, workloads, and agents, along with the keys and tokens each one presents, with a named owner for each.
- Replace long-lived secrets with short-lived, automatically rotated credentials wherever the platform allows.
- Grant least privilege per task, and prefer just-in-time elevation over standing entitlements.
- Evaluate context on every request: source, time, target resource, and whether the action fits the identity's history.
- Monitor identity behavior at runtime and wire detection to fast revocation, so a flagged credential can be cut off in minutes, not at the next rotation.
- Extend the same controls to AI agents, including delegation tracking and per-action policy, before agent adoption outpaces governance.
How Identra thinks about it
Most zero-trust programs, as we see them deployed, stall at the login screen: they verify humans thoroughly at authentication and then trust everything downstream, even though the overwhelming majority of identities are non-human and never see a login screen at all. If machines and agents are the majority, the trust decision has to live where they operate, at runtime. That means treating every action by every identity, human, workload, or AI agent, as its own verification event, scored against who is acting, what they are entitled to, and whether the behavior fits the task. Zero trust that stops at authentication is a perimeter by another name.
Go deeper: The Non-Human Majority
Frequently asked questions
What are the core principles of zero trust for identity?
Grant no implicit trust based on network location, asset ownership, or past behavior. Every access request is evaluated on its own merits, every time, against identity, device, context, and the requested action. Privileges are granted just in time at least-privilege scope, and trust is continuously re-evaluated during the session rather than decided once at login.
Is zero trust a product you can buy?
No. NIST SP 800-207 defines zero trust as an architecture and a set of guiding principles, not a product category. Vendors sell components, such as identity providers, policy engines, and segmentation tools, but the model is a program: inventorying every identity, removing standing privilege, evaluating context per request, and wiring detection to fast revocation.
How does zero trust apply to machine identities?
Awkwardly, unless designed for them. Machine identities outnumber humans 82 to 1, yet most zero-trust architectures assume a person on a managed device. Service accounts have no second factor, no device posture to attest, and often no owner, and many hold long-lived bearer tokens. Applying zero trust means short-lived credentials, per-request evaluation, and behavioral baselines for every workload.
What is the difference between zero trust and least privilege?
Least privilege is one ingredient of zero trust: each identity should hold only the permissions its current task requires. Zero trust is the broader model, adding continuous verification of every request, context and device evaluation, the assumption that the network is hostile, and mid-session revocation when behavior changes. You can enforce least privilege and still trust logins forever.