.png){kind=avatar}
Confidence in an AI platform starts with knowing how it protects your workloads. Security is hard enough when compute, networking, storage, and administration are managed in isolation. AI workloads cross all four, making a coordinated approach essential to protecting data and controlling access.
That coordination must hold as infrastructure changes. Provisioning compute, attaching storage, updating network policies, or expanding capacity must preserve the boundaries protecting each workload.
Radiant’s security architecture brings together tenant isolation, private connectivity, encryption, network policy, and hardware trust. Radiant FlightDeck gives teams control over who can access AI workloads, how their resources communicate, and how data is protected. Integrated security policies and audit trails help teams enforce access boundaries and investigate activity across the infrastructure supporting those workloads.
Hard Tenant Isolation to Protect Compute, Networks, and Data
In a shared AI environment, tenancy must govern how resources behave beneath the application layer. Separating user accounts is only one part of that responsibility. Compute, networks, data, storage, and control planes all need boundaries that prevent one tenant’s activity from crossing into another’s environment.
The tenancy architecture is designed to provide hard physical or logical isolation across these resources, separating tenant environments from one another and from infrastructure control planes. Storage forms part of that boundary, protecting datasets, model weights, and checkpoints alongside the compute resources that use them.
Isolation also shapes how the environment is operated. Provisioning a workload, attaching storage, or changing network connectivity must preserve the same tenancy boundaries. Protection needs to remain dependable as the infrastructure changes around it.
For teams running proprietary models or working with sensitive data, that consistency creates a clearer basis for deciding what can run in the environment and how access should be governed.
Private APIs and Isolated Management Networks to Limit Exposure
An AI factory has several layers of control. Platform APIs manage workloads and services, while out-of-band interfaces reach the underlying hardware. Both require protection, with access paths designed around their respective responsibilities.
The private-access design restricts API endpoints, including Kubernetes API servers, through firewall controls or private connectivity, with no direct public internet access by default. Exposure is an explicit decision governed by a defined access policy.
Baseboard management controllers (BMC) sit within a separate management-network design. Physical separation or VLAN and VRF isolation establishes a dedicated, restricted environment, with access routed through hardened bastion hosts. Direct connections from the public internet and general corporate networks are excluded.
Encryption to Protect Data in Transit and at Rest
AI infrastructure moves data between services inside a cluster, across external connections, and into persistent storage. Protecting that data means accounting for each stage of its journey.
The encryption architecture encompasses east-west and north-south traffic, pairing encryption with mutual authentication through mTLS or equivalent mechanisms. This approach protects communications while verifying the participating endpoints.
Link-level protection extends to connections between the data center and points of presence (PoPs) and object store through MACsec. For stored data, the design incorporates self-encrypting drives across local NVMe or SSD capacity and network-attached storage.
Configurable Traffic Filtering and Threat Intelligence to Control Access
Private connectivity establishes where access can originate. Network policy determines which communications are permitted once a connection reaches the environment.
The network-security design combines configurable traffic filtering with explicit enforcement points. Security groups and user-customizable access control lists express policy through five-tuple rules: source and destination IP addresses, source and destination ports, and protocol.
FlightDeck provides controls for security groups alongside private networks, IP addresses, DNS, peering, and dedicated connectivity. It also exposes network performance and configuration changes, bringing policy administration and network operations into the same operational plane.
Dedicated hardware firewalls are the planned enforcement point between internet-facing edge routers and border-leaf switches. This placement allows traffic to be inspected and filtered before it enters the cluster network.
The design brings four capabilities together:
- Configurable access policies define permitted connections around the services and workloads using the infrastructure.
- Defined enforcement points establish where traffic is inspected and how network policy takes effect.
- Threat-intelligence integration supports importing approved GeoIP, threat, and embargo feeds into security controls.
- Documented rule capacity makes the supported scale of policy enforcement clear when designing an environment.
This gives teams a practical way to align connectivity with workload needs while maintaining control over the paths into the cluster. Defined rule limits also support planning as policies and intelligence feeds become more extensive.
End-to-End Platform Trust and Compliance Controls
Security begins before a workload starts and continues as infrastructure is maintained and reassigned. The platform-security design brings together five controls to establish trust and prepare resources for secure reuse:
- SOC 2 compliance: Infrastructure operates within SOC 2 Type II compliant data centers to support stringent security and compliance requirements.
- Hardware root of trust: TPM provides a hardware-backed foundation for platform trust.
- Secure Boot: UEFI OS Secure Boot helps ensure only authorized boot software runs before workloads start.
- Data sanitization: Cryptographic erasure of drives and sanitization of persistent and volatile memory, including SRAM and GPU memory, address residual data between tenants or during hardware replacement.
- Platform state reset: Resetting TPM and BIOS state forms part of preparing hardware for its next deployment.
For an AI factory, these controls make security part of resource readiness. A dependable tenancy boundary must hold through maintenance and reassignment as well as during normal operation.
Secure your Workloads with Confidence
Radiant’s approach brings these security capabilities into the same infrastructure lifecycle. Tenant separation informs provisioning. Private access constrains administration. Encryption protects data movement and storage. Network controls govern connectivity. Hardware trust and sanitization support secure deployment and reuse.
FlightDeck connects the operational view across these layers, helping teams understand infrastructure state alongside the identities, policies, and actions associated with it. The value lies in how consistently the underlying protections and operational controls work together through deployment, daily operation, maintenance, and changes in resource allocation.
As AI infrastructure becomes more complex, that continuity becomes a core design responsibility. Radiant’s approach is designed to make security part of the infrastructure teams depend on to keep their AI workloads productive.
