Because the network boundary is not where most misuse happens. Once a subject is authenticated, the real risk appears inside the session, where data can be copied, downloaded, printed, or acted on unless those controls are enforced at the point of use.
Why This Matters for Security Teams
zero trust programmes fail when they equate “trusted access” with “secure access.” Network-layer controls can block a route, but they do not control what an authenticated user, workload, or agent does after the session is established. That gap matters because modern misuse often happens at the application, data, and identity layers, not at the perimeter. NIST SP 800-207 Zero Trust Architecture makes this point clear by treating the network as one signal, not the control plane.
For non-human identities, the risk is sharper. If a compromised token, API key, or service credential can reach a tool, database, or model endpoint, the network has already done its job and the attack has already started. NHIMG’s Ultimate Guide to NHIs — Standards frames this as an identity problem first and a routing problem second. In practice, many security teams discover the failure only after an agent, service account, or stolen secret has already moved through allowed paths and exercised permissions that the network could not see.
How It Works in Practice
A mature zero trust design moves enforcement closer to the resource and evaluates context continuously. That means access decisions should consider identity, device or workload posture, request purpose, data sensitivity, and session state, rather than assuming the network location tells the full story. The NIST SP 800-207 Zero Trust Architecture model supports this shift by treating policy as dynamic and resource-specific.
For NHI and agentic environments, that usually means:
- Use workload identity, not just network location, to prove what a service or agent is.
- Issue short-lived credentials and rotate secrets aggressively so compromise windows stay small.
- Enforce least privilege at the API, application, and data layer, not only at the firewall or VPN.
- Evaluate policy at request time, with context about the action being attempted.
- Log and alert on abnormal tool chaining, data exfiltration, and privilege escalation attempts inside the session.
This is why NHIMG’s Guide to SPIFFE and SPIRE is relevant: cryptographic workload identity gives security teams a stronger primitive than IP-based trust, especially where services and agents are ephemeral. The practical challenge is that many organisations still rely on network segmentation as the main control while leaving sessions, tokens, and backend permissions broadly open. A recent NHIMG research summary on DeepSeek breach illustrates how exposed secrets and reachable services can create cascading access far beyond the original entry point.
These controls tend to break down when legacy applications hard-code broad service trust and cannot enforce policy at the API or data access layer.
Common Variations and Edge Cases
Tighter zero trust enforcement often increases operational overhead, requiring organisations to balance stronger containment against friction in delivery and support. That tradeoff is real, especially where applications were built around flat internal networks or where automation depends on long-lived credentials. Current guidance suggests that network segmentation still has value, but it is no longer sufficient as the primary trust boundary.
One common edge case is east-west traffic inside a supposedly trusted zone. If a service account or agent can laterally call internal APIs without context-aware checks, the network can appear “secure” while the blast radius remains wide. Another is remote work and SaaS integration, where the real control point is the token, the session, or the workflow step rather than the subnet. This is also where vendor guidance often overstates readiness: there is no universal standard yet for how every organisation should combine device posture, workload identity, and runtime policy, so implementation is still maturing.
The practical lesson is that zero trust only works when it follows the subject and the action. If controls stop at the network layer, they miss the moment of misuse and allow authenticated sessions to do too much for too long.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least privilege must apply beyond network access to sessions and resources. |
| NIST Zero Trust (SP 800-207) | Zero trust is built on continuous verification, not network location alone. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Stolen or overbroad NHI credentials bypass network controls and expand blast radius. |
| OWASP Agentic AI Top 10 | A1 | Autonomous agents need runtime controls because network boundaries do not constrain actions. |
| CSA MAESTRO | MAE-2 | Agentic systems need identity, policy, and runtime enforcement beyond the network. |
Enforce least privilege at the resource layer and review entitlements tied to each service path.
