TL;DR: Many enterprises already own MFA, ZTNA, posture and segmentation controls, but those tools still lack a shared policy model, leaving humans and workloads governed by separate engines with inconsistent decisions, according to NetFoundry's commissioned KuppingerCole Analysts Buyer’s Compass. The deeper issue is not missing features but fragmented identity policy that cannot coordinate access across human, NHI and AI agent use cases.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on NetFoundry's research: Zero trust programmes often have the individual controls they need, but they fail when those controls do not share a common policy model across human, workload and agent access.
Why it matters: IAM and security teams need a single governance view because fragmented decision engines create inconsistent access outcomes, weak revocation paths and mismatched controls across humans, workloads and AI agents.
Context
Zero trust fails operationally when access controls are deployed as isolated products instead of a coherent policy layer. In that state, MFA, ZTNA, endpoint posture, microsegmentation and workload controls may all exist, but they do not evaluate risk together or share enforcement context.
That fragmentation matters most where identity boundaries overlap, especially between people, services and agents. Zero Trust Identity Guide is the right starting point because the governance problem here is not the absence of controls, but the absence of one decision model that can coordinate them.
Key questions
Q: How should teams unify zero trust policy across humans and workloads?
A: Teams should unify zero trust policy by using a single policy model for both human access and workload access, while separating the identity signals, controls and enforcement points. Humans are governed through authentication strength, device trust, session controls and step-up checks. Workloads are governed through service account identity, certificates, tokens, SPIFFE or OIDC-based attestations, and per-workload authorisation.
Q: Why do workload connections need different zero trust controls than human sessions?
A: Workload connections need different zero trust controls because they are usually non-interactive, machine-to-machine sessions that cannot use human factors such as passwords, MFA prompts or browser-based step-up. They should be mutually authenticated with certificates, signed tokens or workload identity standards, and bound to the service account, process or runtime scope that actually initiates the connection.
Q: What frameworks help govern AI agent access to tools and data?
A: Teams should combine agentic AI risk guidance with zero trust and NHI controls. OWASP Agentic Applications Top 10 helps structure tool and privilege risks, while zero trust and NHI governance define how access should be brokered, scoped, and audited. The key is separating approved task access from secret exposure.
Q: How do bearer tokens fail as proof of machine identity?
A: Bearer tokens fail as proof of machine identity because possession alone is enough to use them, so any stolen or replayed token can impersonate the workload. They do not cryptographically prove that the sender is the intended workload unless they are bound to a client certificate, signed key, device attestation or other sender-constraining control.
Technical breakdown
Shared policy models in zero trust platforms
A zero trust platform is only coherent when its policy layer can express the same access intent across multiple enforcement points. Without that, MFA, ZTNA, posture checks and segmentation each answer a different question, often with different owners and different trust assumptions. The result is not a missing control but policy drift: one system allows the session, another constrains the path, and a third has no visibility into the decision. For humans, that can still be workable. For workloads and agents, inconsistent decisions create broken reachability or overexposed paths.
Practical implication: Map where policy decisions are still made independently and identify the control that owns the final access decision for each identity type.
Why workload-to-workload traffic breaks human access assumptions
Human access models often rely on an intermediary that terminates traffic, inspects content and then re-establishes the session. Workload connections do not behave that way. They are usually symmetric, frequent and mutually authenticated, so inserting a broker can break end-to-end trust, add latency or expose data to an unnecessary third party. That is why machine connectivity needs different identity handling than remote human access, even when the same zero trust language is used for both. Read Guide to SPIFFE and SPIRE.
Practical implication: Treat workload-to-workload paths as a distinct trust problem rather than a repackaged remote-access use case.
MCP and AI agent access need scoped reachability
When an AI agent, LLM gateway or MCP server accesses tools and data on behalf of a user or process, the identity problem shifts from login to delegated scope. The challenge is not only proving who the agent is, but constraining what it can reach, what it can invoke and how fast that access can be revoked. Static secrets do not capture that runtime behaviour well, especially when the agent is acting within an approved workflow but outside an intended boundary. The governing question becomes whether policy can bind identity to action scope at runtime. Read Zero Trust for AI Agents.
Practical implication: Define agent reachability as a policy object with revocation and scope boundaries, not as a reusable secret with broad lifetime.
Threat narrative
Attacker objective: The objective is to exploit fragmented trust decisions so an authorised identity can move beyond its intended scope without a single governing control stopping it.
- Entry begins with a legitimate session or workload connection that is trusted by separate control engines but not governed by one shared policy model.
- Escalation occurs when one control authorises the path while another lacks the context to constrain scope, allowing broader-than-intended access to tools or data.
- Impact follows when inconsistent enforcement weakens containment, exposes data paths or prevents fast revocation across human, workload or agent identities.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Zero trust is becoming a policy-integration problem, not a control-availability problem. Enterprises already own many of the right components, but separate enforcement engines do not create a governed system. When access decisions are fragmented across ownership silos, the architecture can look mature while still failing to make consistent decisions. Practitioners should treat policy unification as the core zero trust design task.
Human access and workload access cannot be governed by the same mental model. A human session tolerates mediation in ways that machine-to-machine traffic often cannot. That is why the distinction between interactive access and workload connectivity is not a product feature, it is a governance boundary. Teams that blur the two will keep compensating for architecture with exceptions.
Agent identity exposes the weakest assumption in current access programmes: identity policy is often written as if the actor is stable, predictable and reviewable over time. That assumption fails when a copilot, gateway or MCP server can act within a narrow but dynamic scope on behalf of someone else. The implication is that access governance must be expressed around delegated action scope, not only around account ownership.
Identity blast radius: fragmented zero trust controls expand the number of places where trust can fail independently. This is not just a technical inconvenience, it is a governance multiplier. The more decision engines that exist without a shared policy model, the harder it becomes to explain, audit and revoke access consistently across people, workloads and agents.
Zero trust for autonomous and non-human access will keep consolidating around policy consistency and revocation speed. Markets are moving toward models that can govern reachability, session scope and identity binding together rather than separately. Practitioners should expect procurement to shift from feature checklists toward whether a platform can preserve one decision model across all identity types.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust Identity Guide
What this signals
Policy unification will matter more than control count. Many programmes already have enough zero trust components to look complete, but the next failure mode is inconsistent policy across those components. Security leaders should measure whether access decisions are shared, explainable and revocable across identity classes, not just whether the tools are deployed.
AI agents sharpen the governance gap because runtime scope is dynamic. A delegated actor can cross from approved action into excess reach inside the same workflow, which means the decision point must move closer to issuance and action time. Teams that still rely on static entitlement review will miss the moment when access actually matters.
For practitioners
- Define one policy owner for each identity class Separate the governance for human sessions, workload-to-workload flows and agent-mediated access so each class has a clear decision authority and revocation path.
- Test zero trust decisions across mixed enforcement points Validate whether MFA, posture, segmentation and ZTNA make the same decision when a session changes context or crosses from human to workload execution.
- Treat machine connectivity as a distinct design pattern Document where mutual authentication, latency sensitivity and end-to-end trust make a brokered human access model unsuitable for services and workloads.
- Constrain agent reachability by scope and revocation Require explicit limits on what tools, data and actions an AI agent or MCP server can reach, with a revocation model that works at runtime.
- Retire shared secrets as the primary access proof Replace bearer-token style assumptions with identity-bound access paths for workloads and agents, especially where the sender must be verified as the intended principal.
Key takeaways
- Zero trust programmes can fail even when the right tools are already deployed, because separate engines do not create a shared access decision model.
- The central governance issue is not control scarcity, but inconsistent policy across human, workload and agent access paths.
- Practitioners should focus on policy unification and runtime revocation, especially where machine connectivity and delegated access are involved.
Related NHI Mgmt Group resources: Zero Trust Identity Guide · Guide to SPIFFE and SPIRE · Zero Trust for AI Agents · Dropbox Sign breach 2024
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 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 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 focuses on identity-bound access and weak sender verification for workloads and agents. |
| NHI-05 — Overprivileged NHI | The risk described is authorised identities acting beyond intended scope across disconnected policy engines. | |
| NHI-10 — Human Use of NHI | The article discusses human operators, workloads and AI agents sharing one access fabric without clean separation. | |
| Recommendation — Bind machine access to the intended principal and stop treating bearer possession as proof of identity. Constrain non-human identities to the narrowest runtime scope and revoke excess reach quickly. Separate human-mediated access patterns from NHI and agent access rules before unifying policy. | ||
| NIST Zero Trust (SP 800-207) | Access is Authorized Before a Session Is Established — Access is Authorized Before a Session Is Established | The zero trust gap is a missing shared policy model across enforcement points. |
| Recommendation — Centralise authorization decisions so every enforcement point evaluates the same policy context. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is about access permissions that diverge across identity classes and tools. |
| Recommendation — Review entitlements and authorizations as one governed model across people, workloads and agents. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The breach pattern described depends on credentials or sessions being reused beyond their intended scope. |
| Recommendation — Map inconsistent policy boundaries to credential access and lateral movement paths in detection. | ||
Key terms
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- 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.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org