OpenShift Sandboxed Containers 1.13: Confidential AI, Attestation and Agent Sandboxing
The hard part of confidential AI is not encrypting memory. It is proving which workload is allowed to see protected data—and containing code you do not fully trust.
A model can be confidential and still be running on infrastructure you do not fully trust. An AI agent can be isolated and still have too much access to the network. And a workload can pass an attestation check while your surrounding application design quietly defeats the protection.
That is the useful way to read OpenShift sandboxed containers 1.13: not as a list of new features, but as a set of controls that establish different trust boundaries.
The simplest way to remember it: confidential computing protects data in use; attestation establishes what is trusted; policy controls what protected resources can be released; sandboxing limits where untrusted code can execute.
Why this matters in regulated AI
For a bank, insurer, or other regulated enterprise, “encrypted” is not a complete answer. Data at rest and data in transit are well-understood controls. The difficult moment is computation: the model needs plaintext data, and the accelerator needs access to it.
That creates a three-way trust problem. The model owner wants proprietary weights protected. The data owner wants sensitive records protected even while they are processed. The platform operator needs to run the system without becoming a privileged path to the workload’s contents.
OpenShift sandboxed containers 1.13 combines hardware-backed confidential containers with remote attestation and, separately, introduces Red Hat’s build of Agent Sandbox as a Technology Preview for isolated AI-agent workloads. Red Hat’s release announcement describes confidential AI on bare metal as GA, while the product documentation makes an important distinction: NVIDIA GPU attestation through Trustee and the NVIDIA Remote Attestation Service remain a Technology Preview. Red Hat’s release announcement and 1.13 Trustee documentation should therefore be read together.
A realistic enterprise scenario
Consider a fraud-detection service that combines proprietary model weights with sensitive transaction data. The model may run on dedicated GPU infrastructure, while the platform is operated by a separate team. The organization wants evidence that the workload is running in an expected confidential environment before protected material is released.
Now add an agent that can call a browser, notebook, or internal API. The security question changes. Confidential computing helps protect data inside a trusted execution environment; it does not automatically make an AI-generated program trustworthy. The agent needs its own execution boundary and carefully scoped network and identity permissions.
That is why the architecture should separate two decisions: “Can this workload be trusted with this resource?” and “Where should this untrusted code be allowed to run?”
The mental model: four controls, four jobs
| Control | Question it answers | What it does not answer |
|---|---|---|
| Confidential container / TEE | Can the workload’s memory and execution state be protected from the surrounding host environment? | Whether the application is logically safe or authorized to access every backend. |
| Remote attestation | Is the workload running in an expected, measurable environment? | Whether the workload’s business logic is correct. |
| Trustee policy/resource release | Should a protected secret or key be released to this attested workload? | Whether the application will use that secret safely after release. |
| Agent Sandbox | Where can untrusted or AI-generated code execute with a stronger isolation boundary? | Whether the code is safe, authenticated, or allowed to reach sensitive systems. |
Red Hat’s documentation describes confidential containers as workloads using TEEs such as Intel TDX or AMD SEV-SNP, with Trustee providing secure management and attestation. The same documentation describes Agent Sandbox as a Kubernetes-native platform for isolated, stateful AI-agent workloads. OpenShift sandboxed containers 1.13 documentation
Architecture and runtime flow
- Workload enters the protected runtime. The application or AI workload is scheduled into the sandboxed container runtime rather than relying only on ordinary process isolation.
- The platform establishes a hardware-backed boundary. Confidential containers use supported TEE technologies to protect workload memory and state from the surrounding host environment.
- Attestation supplies evidence. Trustee evaluates evidence against the organization’s trust policy. For supported NVIDIA confidential GPU scenarios, Trustee can integrate with NVIDIA’s Remote Attestation Service; however, that GPU-attestation capability is still documented as Technology Preview in 1.13.
- Protected resources are released only after policy evaluation. This is the point where attestation becomes operationally useful: it can gate access to secrets or other protected resources rather than merely producing a security report.
- Agent execution follows a different path. Agent Sandbox manages isolated environments for AI-agent runtimes. Where Kata-based isolation is used, the execution boundary is VM-based, increasing separation between an untrusted guest workload and the host.
What changed in 1.13—and what the status really means
| Capability | 1.13 status | Architecture implication |
|---|---|---|
| Confidential containers on bare metal with supported CPU TEEs | GA | A production path for protecting workload data in use. |
| Confidential containers with NVIDIA H100 / DGX B200 on bare metal | GA in the documented support matrix | Enables confidential AI workloads on supported GPU platforms. |
| NVIDIA GPU attestation via Trustee + NRAS | Technology Preview | Do not treat GPU attestation as equivalent to a generally supported production control. |
| Confidential GPU workload on Azure with NVIDIA H100 | Technology Preview in the 1.13 matrix | Cloud GPU scenarios require tighter platform/version qualification. |
| Nested sandboxed-container deployments on AWS, Azure and Google Cloud | Technology Preview | Useful for evaluation, but availability and isolation characteristics differ from GA peer-pod paths. |
| Red Hat build of Agent Sandbox | Technology Preview | Strong candidate for controlled pilots of agentic workloads, not a blanket production approval. |
The 1.13 support matrix is the right authority for platform status; it distinguishes GA from Technology Preview by platform and GPU combination. See the 1.13 workload-protection matrix.
Confidential containers vs. Agent Sandbox: not X versus Y
These technologies are complementary rather than competing layers.
| Confidential containers | Agent Sandbox | |
|---|---|---|
| Primary problem | Protecting workload execution and data in use from the surrounding infrastructure. | Providing a stronger isolation boundary for AI-agent runtimes and untrusted code. |
| Trust assumption | Hardware-backed TEE plus attestation and policy. | Isolation is the control; application identity, authorization and network policy remain separate concerns. |
| Typical workload | Sensitive inference, data processing, confidential services. | Agent runtimes, development environments and code-execution workloads. |
| Key production question | What evidence must be true before data or secrets are released? | What can the sandbox reach, and how is its blast radius limited? |
A production implementation should be staged, not copied from a lab
- Assess. Map the data, model weights, secrets, identities, operators, and infrastructure that the workload currently trusts. Identify which party must be prevented from inspecting data in use.
- Design the trust model. Define the expected TEE, platform measurements, attestation authorities, and resource-release policy. Decide what evidence is sufficient before a secret or key can be released.
- Qualify the platform. Confirm OpenShift, runtime, CPU TEE, GPU, driver/operator and hosting model against the 1.13 support matrix. This is especially important for GPU and cloud combinations.
- Onboard the workload. Move the workload into the intended isolated runtime and establish how its measurements, images, and runtime state are represented in the trust policy.
- Associate protected resources. Connect secrets or keys to the attestation decision, so access depends on the expected trust state rather than only on a cluster identity.
- Secure agent execution separately. For AI-generated code, define sandbox lifecycle, network reachability, identity permissions, persistence, and tool access. Do not assume VM isolation replaces application authorization.
- Validate. Test successful attestation, deliberate policy failure, workload changes, node replacement, GPU changes, certificate or trust-material rotation, and failure of the attestation dependency.
- Operate. Treat reference measurements, platform upgrades, drivers, firmware, OpenShift versions, and security policies as a change-controlled chain. Attestation is only as reliable as the evidence and policy you continue to maintain.
What this protects—and what it does not
Protects: confidentiality and integrity properties of workload execution supported by the selected TEE; protection of sensitive memory from the surrounding host environment; and policy-gated release of protected resources when the attestation chain is correctly designed.
The simplest way to remember it: confidential computing protects data in use; attestation establishes what is trusted; policy controls what protected resources can be released; sandboxing limits where untrusted code can execute.
That distinction matters in audits. “The workload runs in a confidential container” is a platform statement. “Only an approved workload can obtain this particular key, and it can only reach these services” is an architecture and policy statement.
Common mistakes and trade-offs
- Calling every GPU feature GA. The 1.13 support matrix and Trustee documentation distinguish GA confidential-container GPU support from Technology Preview GPU attestation.
- Using attestation as a compliance checkbox. Attestation should drive a resource-release decision. A quote that is collected but never tied to policy provides much less value.
- Assuming confidential computing solves agent security. A confidential agent can still make an unauthorized API call. The agent needs least-privilege identity, network controls, and tool governance.
- Ignoring version coupling. Confidential GPU support depends on OpenShift and runtime capabilities. The documented 1.13 matrix includes minimum platform versions and feature gates that can materially affect the design.
- Leaving permissive runtime policy in production. Red Hat explicitly warns against the default permissive Kata Agent policy for production confidential containers and recommends a restrictive policy. See the 1.13 production configuration guidance.
- Treating Agent Sandbox as production-ready because the operator exists. Agent Sandbox is a Technology Preview, and its release notes document a known unauthenticated-router limitation that is unsuitable for production or multitenant clusters without additional network-level controls. See the 1.13 Technology Preview notes.
Troubleshooting by symptom and cause
| Symptom | Likely architectural cause | What to investigate |
|---|---|---|
| Attestation succeeds, but the workload cannot obtain a secret | Attestation and resource-release policy do not agree on the expected identity, measurements or reference values. | Trace the policy decision and the evidence that was actually evaluated. |
| A previously working confidential workload stops after an upgrade | Platform, image, firmware, driver or measurement changes invalidate the trust policy. | Compare the new evidence with the registered reference state and support matrix. |
| GPU workload is available but cannot satisfy the intended trust requirement | GPU availability and GPU attestation are separate capabilities; the latter may still be Technology Preview. | Check the exact GPU, TEE, OpenShift and Trustee support combination. |
| Agent sandbox is reachable from more clients than expected | Router exposure or network policy is broader than the intended trust boundary. | Review route reachability, router authentication mode and network-level restrictions. |
| Agent workload is isolated but can still access sensitive APIs | Runtime isolation was mistaken for authorization. | Review service identity, egress policy, API authorization and tool permissions. |
FAQ: the questions architects actually ask
Does confidential computing mean the data is never decrypted?
No. The purpose is to protect data while it is being processed inside a hardware-backed trusted environment. Applications still need usable plaintext semantics inside the protected execution boundary.
Is GPU support in OpenShift sandboxed containers 1.13 fully GA?
The documented support matrix shows GA support for supported bare-metal confidential-container GPU configurations such as NVIDIA H100 and DGX B200. But GPU attestation through Trustee and NRAS is separately documented as Technology Preview. Treat those as different claims.
Does Trustee replace a normal secrets manager?
Not automatically. Trustee adds an attestation-aware policy point for releasing protected resources to trusted workloads. An enterprise still needs a broader secrets and key-management architecture, lifecycle controls and ownership model.
Is Agent Sandbox a confidential-computing solution?
Not by itself. Agent Sandbox is primarily an isolation and lifecycle platform for AI-agent workloads. It can integrate with OpenShift sandboxed containers for hardware-level isolation, but the two concepts solve different parts of the trust problem.
Can confidential containers stop prompt injection?
No. Prompt injection is an application and agent-control problem. Confidential computing can protect the execution environment and data in use; it does not decide whether an agent should follow a malicious instruction.
What is the biggest operational risk?
Trust drift. Hardware, firmware, OpenShift versions, images, drivers and policy reference values evolve. A production design must make those changes visible and deliberate instead of treating attestation as a one-time installation step.
The takeaway
The most important change in OpenShift sandboxed containers 1.13 is not a single checkbox for “secure AI.” It is the ability to reason about AI security as separate trust decisions.
Protect the workload. Use confidential computing where the infrastructure itself is part of the threat model. Prove the workload. Use attestation and policy before releasing sensitive resources. Contain the agent. Give untrusted or AI-generated code a stronger execution boundary and keep its network and identity permissions narrow.
That separation is what makes the architecture defensible in production—and much easier to test, operate and explain to security teams.
Next: from attestation to secrets lifecycle
Once a workload can prove where and how it is running, the next question is more practical: how should an enterprise bind that proof to the lifecycle of keys, secrets, and protected data? That is the natural next step for a deeper look at Trustee, policy design and enterprise secrets management.
