Where the Work Lives: Zones, Services, and Trust Boundaries
The subject here is the internal shape of AI-oriented cloud and high-performance computing infrastructure: not the list of machines, but the zones and services that decide who may enter, where a job may run, and how data is reached. The practical question is where access should stop instead of cascading through the system. By tracing users, administrators, schedulers, storage requests, and provider-managed services, we can see why security boundaries are operating decisions rather than lines drawn around a building.
The previous chapter established that an AI workload crosses a chain of services. This chapter makes that chain concrete with NIST’s four-zone HPC reference architecture and then connects it to the cloud layers used to train and serve models. The two descriptions are not the same blueprint. They are two useful views of a system in which authority, state, and responsibility are distributed.
Four zones, four operating domains
NIST divides an HPC system into an Access Zone, a Management Zone, a High-Performance Computing Zone, and a Data Storage Zone. Each zone offers different services, has different performance requirements, and faces different threats. That division matters because “the cluster” is not one undifferentiated trust domain. A user who can enter the system does not thereby become an administrator. A process that can run on an assigned compute node does not thereby gain a direct login to storage servers. A storage administrator does not need every privilege held by a scheduler administrator.
The Access Zone is the point through which authorized users and administrators reach the system. It may support ordinary login and the initial exchange of requests, but it is not a universal pass into everything behind it. NIST’s guidance for remote administrative access calls for an organizationally defined and approved path into the Management Zone, such as a gateway or bastion host. It also recommends restricting paths from other zones and avoiding overlap between user access and API access. The point is not that every deployment must use one named appliance. The point is that management access should have a deliberate route that is distinct from the path used by ordinary work.
The Management Zone is where the system is administered. It contains functions and services that control the environment rather than execute a user’s research job. NIST recommends that access to this zone be limited to system administrators and that administrators be separated according to their duties. Someone responsible for the scheduler, for example, need not automatically receive unrestricted access to storage or every management function. This separation limits the consequences of a stolen credential or a mistaken administrative action. It also makes accountability more legible: a change to scheduling policy and a change to storage protection do not have to be made by the same role.
The Computing Zone is where authorized jobs run on high-performance nodes. The batch scheduler is central here. A user may be allowed to log in through the Access Zone, but access to particular compute nodes is granted through scheduler control. The scheduler therefore does more than organize a queue or improve utilization. It participates in authorization by deciding which account can run on which resources. If that decision is too broad, a user may reach nodes or workloads outside the intended assignment. If it is too restrictive, the system may fail its mission. Security and resource allocation meet at the same interface.
This is also why administrative privilege needs context. NIST notes that administrators may use elevated privileges to schedule maintenance jobs, such as a rolling upgrade, but should not use root access to run user-type jobs in the Computing Zone. The distinction is operational rather than symbolic. A maintenance action may require broad authority for a defined task, while a user job should remain within the permissions and data paths assigned to that job. Reusing the most powerful account for both activities would erase a boundary the architecture is meant to preserve.
The Data Storage Zone has a different relationship to the rest of the system. It provides data services to other zones, but ordinary users generally do not log in directly to storage servers or nodes. They reach data through service interfaces, such as a mounted POSIX file system, which makes a request to the corresponding storage service. In this arrangement, using data is not the same as entering the administrative domain that stores it. A user may have permission to read a dataset or write an output without having permission to change the storage service itself.
The resulting access model is deliberately non-cascading. NIST says that privileges granted in one zone should not automatically flow into another. A user’s login access in the Access Zone does not imply management access. An administrator’s authority in one function does not automatically produce blanket access throughout the system. This is a useful correction to a common assumption about infrastructure: once a person is “inside,” all internal paths are equally available. In a performance-oriented environment, the most important boundary may be between two services that share a network or a building but have different roles and consequences.
The dashed relationships in the diagram are not claims that a network packet is physically impossible. They represent paths that the security design should not grant as ordinary authority. That distinction is important. Segmentation is useful only when it changes what an identity, process, or service is allowed to do. A system can have separate labels and still behave as one trust domain if every role can bypass them.
Cloud layers change who owns the boundary
The four-zone model explains how an HPC operator can separate functions inside one system. Cloud AI adds another question: which parts are operated by the customer, and which are operated by the provider? The Atlantic Council brief describes cloud infrastructure for AI in layers that include compute and virtualization services, orchestration platforms, data and storage services, observability and logging, identity and access management, AI-specific runtimes and serving frameworks, and web or API gateways. These layers overlap with the functions described by the HPC zones, but a cloud customer may consume them as managed services rather than administer their underlying machines.
Compute and orchestration are the clearest example. A provider may operate the service that allocates processing power and manages the environment in which an AI workload runs. The customer still determines what workload to submit, what data to use, and which identities or applications should be allowed to request it. The provider’s control plane and the customer’s workload are therefore related but not identical. A customer may be unable to inspect or change every implementation detail of the provider’s orchestration, while remaining responsible for the permissions and data choices made through that service.
Data and storage create a similar division. Training datasets, model weights, and inference outputs may be stored through managed databases or object storage. The customer cares about access, retention, recovery, and integrity, but the provider may operate the service components that enforce those properties. This does not make storage a single undifferentiated resource. The relevant questions remain: which identity can request which object, which service can retrieve it, and which operator can change the policy or configuration that governs the request?
Observability makes the ownership problem more visible. Logging and telemetry are essential for detecting anomalies and investigating incidents, but the system that produces or retains those records may be partly managed by a provider. The customer may see workload-level events while the provider controls infrastructure-level evidence. If a service flaw does not require customer action, the customer may also have limited visibility into whether the provider has identified or disclosed it. A boundary around a managed service is therefore an information boundary as well as an access boundary.
Identity and access management spans the same divide. A provider may authenticate a customer account or expose an authorization service, while the customer defines roles for applications, projects, and users. In the HPC model, NIST warns against allowing privileges to cascade across zones. In cloud AI, the comparable danger is assuming that a provider-managed identity layer automatically expresses the customer’s intended separation between data, training jobs, model-serving endpoints, and administrators. The service can supply a mechanism, but the resulting boundary still depends on how identities and permissions are assigned.
AI runtimes, serving frameworks, and gateways add an outward-facing edge. A runtime loads or scales a model; a gateway exposes an interface to users or other applications. The security consequences differ from those of a storage service or a scheduler. An error in the gateway can broaden who can call the model. An error in a runtime can affect the workload environment. A flaw in storage can expose training data or model outputs. The Atlantic Council brief emphasizes that distinct cloud categories present distinct vulnerabilities, so treating them as one generic “cloud layer” hides the mechanism that determines the impact.
This is why a provider relationship should not be reduced to the phrase “shared responsibility” without specifying the boundary. The phrase is useful only when it answers three concrete questions. What does the provider operate? What can the customer configure or observe? What happens when the relevant component fails or contains a vulnerability that the customer cannot patch directly? The selected sources do not provide a provider-by-provider answer, and the Atlantic Council brief is not an architecture audit of any named company. They do support the broader conclusion that managed service consumption changes ownership and visibility without eliminating security responsibility.
The distinction between using a service and entering its administrative domain is a useful guide. A user can request data through a storage API without receiving a storage-server login. A model-serving client can call a gateway without receiving control of the runtime that loads the model. An AI team can submit a workload to provider-operated compute without owning the provider’s orchestration plane. At each boundary, the goal is not to deny all interaction. It is to permit the intended interaction while refusing the authority that would make an unrelated function reachable.
That design also creates failure conditions that a component list would miss. If a scheduler authorizes too many nodes, the Computing Zone’s assignment boundary weakens. If administrators share a blanket role, a compromise in one function can spread to another. If storage APIs expose more data than intended, the lack of direct server login does not protect the dataset. If a provider-managed runtime is opaque, customers may be unable to determine whether a weakness affects their workload or other platforms as well. The boundary must therefore be tested by behavior: what can cross it, under which identity, for how long, with what evidence, and with what ability to revoke or repair the transition?
Once those questions are explicit, the system stops looking like a collection of isolated services. It becomes a set of controlled paths. The HPC zones show how an operator can separate entry, administration, computation, and storage. The cloud layers show how those functions can be split across provider and customer responsibilities. In both cases, the security boundary is meaningful only when it changes authority and preserves enough visibility to detect a bad transition.
The next difficulty follows directly from this design. The same paths that carry large data flows and long-running jobs are also the paths where inspection, logging, session controls, and authentication operate. A boundary can be correctly drawn and still be difficult to enforce without affecting the work it protects.