Segregated Compute

Expanded Definition

Segregated compute is an NHI security pattern that prevents users from attaching directly to sensitive workloads, even when they are authorised to request access. The user reaches the workload only through a controlled boundary that enforces policy, suppresses direct credential exposure, and records evidence of isolation.

In practice, this sits between classic network segmentation and identity-mediated access. It is not simply a firewall rule or a private subnet. The key requirement is that the workload remains unreachable through unmanaged paths, while access is brokered by an intermediary that can validate context, constrain tools, and preserve auditability. That makes it especially relevant for service accounts, automation jobs, and agentic systems where execution authority must be tightly bounded. Guidance varies across vendors on where the boundary should live, but the operational goal is consistent: eliminate direct trust links between the requester and the protected runtime. The NIST Cybersecurity Framework 2.0 reinforces this control-first approach by emphasizing managed access, monitoring, and recovery.

The most common misapplication is treating a bastion host or VPN as segregated compute when users can still reach the workload with standing credentials or unmanaged tooling.

Examples and Use Cases

Implementing segregated compute rigorously often introduces latency and orchestration overhead, requiring organisations to weigh tighter containment against a less direct operator experience.

• A production database is reachable only through a policy-enforcing jump service that issues short-lived access and prevents shell-level persistence.
• An AI agent runs in a constrained execution zone where tool calls are proxied, logged, and denied if they attempt to reach systems outside approved scope.
• A CI/CD job accesses secrets through an intermediary broker rather than by embedding tokens in the build runner, reducing exposure if the runner is compromised.
• A payments workload is isolated from developer laptops so even privileged engineers must use mediated access that leaves an audit trail.

These patterns align with the operational guidance in the Ultimate Guide to NHIs, especially where service accounts, secret handling, and workload visibility intersect. They also complement identity-centric access models described in the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Segregated compute reduces the blast radius of compromised credentials, malicious automation, and operator error. When a user never connects directly to a sensitive workload, attackers have fewer places to capture reusable secrets, pivot laterally, or hide activity inside interactive sessions. This matters because NHIs already dominate many enterprise environments, and NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, making unmanaged direct access especially dangerous. Segregated compute also supports Zero Trust by turning access into a continuously evaluated transaction rather than a one-time network allowance.

It is most valuable when paired with policy enforcement, secret isolation, and evidence collection. A mediated boundary can prove that the workload remained insulated from unmanaged connections, which is critical for audits, incident response, and privilege reviews. The concept also maps cleanly to identity governance in the NIST Cybersecurity Framework 2.0 and to the broader NHI risk patterns documented in the Ultimate Guide to NHIs.

Organisations typically encounter the need for segregated compute only after a workload compromise, at which point direct access paths and exposed credentials become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do platform teams and IAM teams split responsibility for AI compute governance?
• How should organisations respond when AI compute is being used as delivery infrastructure?