Zero trust becomes incomplete when it treats network location or prior authentication as proof of trust. Sensitive data can still be exposed through cloud apps, SaaS, APIs, workloads, and AI systems unless access is evaluated against identity, context, sensitivity, and current risk. The missing control is resource-level authorization tied to the data itself.
Where zero trust breaks when the network is treated as the trust boundary
Zero trust fails in practice when it stops at the network layer. If the main control question is “is this traffic on the right segment?”, then a user, workload, or agent that already has access can still reach sensitive data in SaaS apps, cloud services, APIs, and shared platforms. The real control point is not where the packet came from, but whether the requested action is allowed for that data and context.
That is why Zero Trust Identity Guide is a useful reference here: it frames zero trust around identity-centric policy, continuous evaluation, and the reality that network location alone does not prove trustworthy access.
The same boundary problem shows up in distributed environments. Workloads and service-to-service calls can live inside a trusted network segment and still move laterally if authorization is coarse or if credentials are reused too broadly. For that reason, data-sensitive systems need decisions that combine identity, device or workload context, and policy at the resource level, not a one-time network gate.
That is also why Guide to SPIFFE and SPIRE matters in this discussion, because workload identity and attestation are what let policy follow the workload rather than the subnet.
What the missing control actually is: resource-level authorization
When zero trust remains network-centric, it tends to overprotect the perimeter and underprotect the data. The missing layer is authorization that is evaluated against the resource itself, including sensitivity, purpose, current session context, and whether the requester has the specific entitlement to read, write, export, or invoke that asset. In other words, the control should answer “is this exact action on this exact data allowed right now?”
This matters because sensitive information is often reached through indirect paths. A user may be legitimate, but the app may expose too much data; an API may be authenticated, but not properly authorized for the object being requested; a workload may be trusted on the network, but not trusted for the dataset it is querying. If policy does not follow the data, zero trust becomes a stronger perimeter model rather than a true access model.
For practitioners, that means the policy layer has to do more than authenticate entry. It must enforce least privilege at the resource and action level, including object scope, row scope, dataset scope, and function scope where applicable. NIST SP 800-207 Zero Trust Architecture is the canonical reference for that shift from implicit network trust to explicit per-request decisions.
For readers who need the access-control side of the model, IAM and IGA Basics helps connect those resource decisions to entitlements, authorization models, and governance of both people and machines.
Why data, cloud, SaaS, APIs, workloads, and AI all expose the same failure mode
The same weakness appears across modern platforms because the trust boundary has moved. Cloud apps and SaaS expose data through shared services, APIs, integration layers, and delegated permissions. Workloads exchange data without a human in the loop. AI systems can retrieve, transform, or act on content based on runtime prompts and tool calls. In each case, the risk is the same: the network may say “allowed,” while the data owner would say “not this data, not this action, not under these conditions.”
That is why resource-level authorization must be paired with current context. Context can include device posture, session freshness, location anomaly, workload attestation, sensitivity class, and risk signals from the current request path. Without that, zero trust becomes static, and static controls age badly in dynamic environments.
The practical lesson is that zero trust should narrow who can access a resource, what they can do, and under which conditions, not just where they connect from. Once policy is expressed that way, segmentation still has value, but only as a support mechanism. It is not the proof of trust.
Zero Trust for AI Agents is a useful adjacent example because it applies the same principle to autonomous software, verify the principal, enforce policy per action, and remove standing privilege.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Zero trust must limit each request to the minimum needed data action. |
| AC-3 — Access Enforcement | Resource-level authorization depends on enforcing policy at the protected object. | |
| IA-9 — Service Identification and Authentication | Workload and service calls need identity before resource authorization can work. | |
| Recommendation — Enforce least privilege at the resource and action level. Apply access enforcement at the data and API layer. Authenticate services and workloads before evaluating access. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-01 — Identity and Access Management | Zero trust here depends on identity-centric access decisions, not network trust. |
| Recommendation — Base access decisions on identity and context, not location. | ||
| OWASP ASVS | V8 — Authorization | The issue is missing resource-level authorization for sensitive actions. |
| Recommendation — Verify object and function authorization for every sensitive action. | ||
Practitioner Guidance
What to verify: Check whether your zero trust program can answer the policy question at the data layer, not just the network layer. If a user or workload is authenticated but still cannot be constrained by object, dataset, or action, the model is incomplete.
Common mistake: Treating network segmentation, VPN replacement, or conditional access as if they were the whole zero trust answer. They reduce exposure, but they do not by themselves prevent over-broad data access inside cloud apps, APIs, or shared services.
Decision rule: If a control does not evaluate the specific resource and current context, treat it as a perimeter control, not a zero trust control. Use it to reduce blast radius, but do not rely on it to protect sensitive data.
Practitioner takeaway: The strongest zero trust programs move the trust decision from the subnet to the requested data action, because that is where modern compromise usually becomes real.
Related resources from NHI Mgmt Group
- What happens when organisations rely on broad network access instead of Zero Trust for systems that process personal data?
- Why do non-human identities complicate zero trust architecture?
- Why do non-human identities increase zero trust risk?
- Why do NHIs complicate zero trust and least privilege efforts?