TL;DR: Zero trust breaks down for service accounts, API keys, OAuth tokens, IAM roles, secrets, and AI agents when the underlying identity is invisible, unowned, or over-permissioned, according to Oasis Security. The governance gap is no longer theoretical: policy enforcement without identity ownership and lifecycle control cannot secure machine-to-machine traffic.
At a glance
What this is: This analysis argues that zero trust cannot fully govern modern enterprise traffic unless non-human and agentic identities are discoverable, owned, and lifecycle-managed.
Why it matters: It matters because IAM, IGA, and PAM teams need policy enforcement and identity governance to work together or machine-to-machine access remains outside control.
Context
Zero trust assumes every connection can be tied to a known, accountable identity and evaluated in context. That model fits human users more naturally than service accounts, API keys, OAuth tokens, IAM roles, secrets, and AI agents, where ownership and lifecycle are often incomplete or missing.
In this article, Oasis Security argues that the real governance gap is not just enforcement at the network edge. The missing piece is identity context for non-human and agentic access, including ownership, visibility, and revocation across cloud, SaaS, on-premises systems, and emerging agentic brokers.
Key questions
Q: What breaks when Zero Trust is implemented without identity governance?
A: Zero Trust breaks when the policy engine is enforcing stale or incomplete identity data. If access approvals, ownership, and revocation are not governed, the organisation keeps validating entitlements that no longer match business intent. The result is technically strong enforcement built on weak identity records, which still leaves over-privileged accounts and hidden exceptions in place.
Q: Why do service accounts and tokens create a different zero trust problem than human users?
A: Because their identity state is often opaque, unowned, or long lived. Human access models assume a person can be challenged, reviewed, and offboarded through established governance processes. Machine identities can persist quietly, reuse credentials, and keep operating after the original business need has changed.
A: Security teams should pair continuous machine identity with threat detection so every machine connection is verified before it is trusted. In OT, that means authenticating devices, limiting which systems can initiate or maintain sessions, and enriching detections with identity context. This reduces blind trust in east-west traffic and gives responders clearer evidence for containment and recovery.
Q: What is the difference between enforcing policy inline and governing the identity behind it?
A: Inline enforcement decides whether a live request should pass. Identity governance decides what that identity is allowed to exist with over time, who owns it, and when its access should be rotated or removed. Both are required for zero trust in non-human environments, but they solve different control problems.
Technical breakdown
Why zero trust assumptions fail for non-human identities
Zero trust is designed around an authenticated, accountable identity behind every request. That assumption breaks when the subject is a service account, token, secret, or AI agent that may have no clear human owner, no visible inventory entry, or no reliable expiry discipline. In those cases, policy can still inspect traffic, but it cannot confidently tell whether the underlying identity should exist, who should manage it, or whether its access remains justified. The result is a control gap between connection-level enforcement and identity-level governance.
Practical implication: teams need to inventory and own NHI before zero trust policy can be trusted to make meaningful decisions.
How inline enforcement and identity governance complement each other
Inline enforcement and identity governance solve different parts of the same problem. Enforcement brokers or inspects the live connection, deciding whether a request is allowed in the moment. Governance answers what the underlying identity is, who owns it, what it may access, and whether its credentials should be rotated or revoked. Without governance, enforcement sees only traffic. Without enforcement, governance has no control over the live session or tool call. The article's central point is that zero trust for machines becomes practical only when both layers are connected.
Practical implication: align policy enforcement with identity ownership, lifecycle state, and access scope so decisions are based on current identity context.
What changes when AI agents and MCP servers enter the control plane
AI agents change the pace and shape of identity risk. They can spawn sub-agents, reach systems rapidly, and operate through MCP servers or other brokered paths without the visibility assumptions that were acceptable for humans. If an agent's reach is defined by a broad standing credential or a hardcoded secret on a managed endpoint, the control problem becomes one of identity governance, not just traffic filtering. The issue is not merely that the agent connects to more systems. It is that the identity behind those connections may outlive the task, exceed the intent, or remain unknown to the security team.
Practical implication: treat agentic access as governed identity, not as ordinary automation, and tie every agent to an owner and expiry.
NHI Mgmt Group analysis
Zero trust for non-human identity fails when identity is not governable. The article is right to frame the problem as an assumption collapse, not a tuning issue. Zero trust presupposes that the subject of policy is known, accountable, and lifecycle-managed, but service accounts, API keys, OAuth tokens, IAM roles, and AI agents often are not. Practitioners should treat this as a boundary problem in identity architecture, not a network-policy gap.
Identity blast radius is now the better lens than perimeter enforcement. Once machine traffic dominates enterprise flows, the decisive question becomes how far a compromised or stale non-human identity can reach before it is detected or revoked. That makes ownership, expiry, and access scoping core governance variables, not administrative hygiene. Security teams should map where machine identities can accumulate standing access and where policy enforcement has no identity context to rely on.
Agentic traffic exposes the weakness of static privilege assumptions. AI agents can generate more requests, branch into sub-agents, and move faster than human review cycles. The result is that least privilege defined once at provisioning time is no longer enough when access paths evolve during runtime. Teams need to re-evaluate whether their current governance model can explain who is acting, under what authority, and for how long.
Inline control without lifecycle governance creates an incomplete zero-trust model. Enforcement can deny, inspect, and broker traffic, but it cannot on its own answer who owns the identity, whether the credential should still exist, or whether the access path has outlived its purpose. That is why the strongest reading of this article is structural: identity governance and zero trust are complementary control planes, not interchangeable ones. Practitioners should design them as a single operating model.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust for AI Agents
What this signals
Identity ownership is becoming the control boundary for zero trust. When machine identities can appear in cloud, SaaS, on-premises, and agentic environments, the limiting factor is no longer only whether traffic is inspected. The programme question becomes whether every non-human identity can be mapped to a steward, an expiry, and a revocation path before access is allowed to persist.
Agentic systems push governance upstream into issuance time. Security teams cannot rely on periodic access review alone when identities can spawn, branch, and act faster than review cycles. The practical shift is to move governance closer to creation, assignment, and policy binding so that broad standing access never becomes the default.
Zero trust now depends on visible machine identity at scale. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That gap explains why enforcement tools alone struggle to produce reliable decisions for non-human traffic.
For practitioners
- Map every non-human identity to an owner Build an inventory that ties service accounts, API keys, OAuth tokens, IAM roles, secrets, and agents to a named operational owner and a revocation path.
- Rotate and revoke on lifecycle events Trigger secret rotation, credential revocation, and access review when an identity becomes stale, orphaned, over-privileged, or no longer tied to a valid use case.
- Bind enforcement decisions to identity context Feed ownership, risk score, and access scope into inline policy so the control plane can evaluate more than source, destination, and protocol.
- Constrain agentic access to task scope Treat AI agents as governed identities with explicit expiry, bounded tool reach, and clear account ownership instead of persistent broad access.
Key takeaways
- Zero trust fails as a complete governance model when non-human identities are unowned, invisible, or carry standing access that outlives the business need.
- The control problem is no longer only inspection at the wire. It is the combination of identity ownership, lifecycle state, and scoped authority for every machine and agent.
- Teams that want meaningful zero trust outcomes need to connect enforcement with identity governance so that machine access can be attributed, bounded, and revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on non-human identities whose access cannot be reliably tied to accountable identity state. |
| NHI-05 — Overprivileged NHI | Standing access and broad permissions are a core risk in the article's machine identity model. | |
| NHI-07 — Long-Lived Secrets | The article explicitly calls out secrets and credentials that persist beyond their intended use. | |
| Recommendation — Apply NHI-04 to ensure every machine and agent identity is attributable, owned, and governed before access is allowed. Reduce overprivileged NHI access so enforcement decisions can operate on bounded identity scope. Rotate and revoke long-lived secrets so machine identities do not retain access after their purpose ends. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about governing entitlements behind inline policy decisions. |
| Recommendation — Map machine identities to PR.AA-05 so authorization reflects ownership, scope, and lifecycle state. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central to the governance gap described in the article. |
| Recommendation — Use IA-5 to enforce rotation, revocation, and lifecycle control for non-human authenticators. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | The article explicitly relies on inline enforcement as one side of the control plane. |
| Recommendation — Place policy enforcement in line with machine identity governance so requests are evaluated in context. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud and SaaS machine identities in the article fall directly under cloud IAM governance. |
| Recommendation — Apply CSA IAM controls to inventory, own, and retire cloud identities used by machines and agents. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Identity Ownership: Identity ownership is the assignment of a responsible human for each identity's purpose, access, review, and retirement. For non-human identities, ownership must be explicit because the creator is not always the right person to approve ongoing access. Without ownership, review and revocation become inconsistent and slow.
- Inline Enforcement: Inline enforcement is the technical act of applying access policy in the live session path, not just at approval time. It matters because identity governance without runtime enforcement can authorize access that the session layer never actually constrains, especially in distributed and third-party environments.
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 20, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org