Confidential containers tighten workload trust for AI and critical systems

At a glance

What this is: This is Anjuna's case that confidential containers can narrow the attack surface for containerised workloads by keeping sensitive code, data and runtime state protected in use through hardware-backed TEEs and attestation.

Why it matters: For IAM, PAM and NHI teams, the relevance is that access decisions move from assumed identity and static infrastructure trust toward verified workload state, which affects how secrets, agents and sensitive services are released.

Context

Confidential containers are a workload security model in which the application runs inside a hardware-backed trusted execution environment, so runtime state stays protected while it is being processed. That matters because many cloud and AI programmes still assume the surrounding host, administrator layer and shared infrastructure can be implicitly trusted, which is no longer a safe assumption for sensitive workloads.

The governance gap is not just about encryption at rest or in transit. It is about whether secrets, models, prompts and mission data should be released to a workload before the platform can prove what is actually running; that is where workload identity and attestation become security controls, not implementation details. Treat confidential computing as the control model behind that decision.

Key questions

Q: How should security teams evaluate confidential computing for protecting AI workloads and sensitive data?

A: Security teams should evaluate confidential computing when they need stronger isolation for model weights, inference data, or other sensitive processing in shared infrastructure. The key question is whether the workload needs protection while in use, not just at rest or in transit. Teams should also assess hardware support, operational complexity, and whether the approach aligns with broader privacy and governance requirements.

Q: Why do confidential containers matter for zero trust architecture?

A: Zero trust requires decisions based on verified evidence, not assumed identity or platform trust. Confidential containers add hardware-backed proof that the expected workload is running before secrets or sensitive data are released, which moves zero trust from network policy toward execution-layer assurance.

Q: What is the difference between ordinary container isolation and confidential computing?

A: Ordinary container isolation separates workloads from each other, but it still leaves the underlying host and much of the platform in the trust chain. Confidential computing adds a hardware-backed boundary plus attestation, so the workload can prove its runtime state before it receives sensitive inputs or credentials.

Q: How do teams prove that a sensitive AI service is safe to access?

A: Use attestation and policy together. The team should require a verified workload measurement, approved environment policy and the expected deployment context before allowing prompts, retrieval data, model assets or tool credentials to be released to the AI service.

Technical breakdown

How confidential containers change the trust boundary

Confidential containers move the trust boundary from the host and cluster administrator to the workload itself. The container runs inside a trusted execution environment, or TEE, which isolates code and memory from other software layers and from most privileged operators. Attestation then proves that the expected workload is running before policy allows access to secrets or sensitive data. This is different from ordinary container isolation, which still leaves the platform operator and underlying node in the trust chain. For regulated or multi-tenant environments, the key change is that runtime trust is verified, not assumed.

Practical implication: Use attestation as a release condition for secrets, models and data, not as a post-deployment audit signal.

Why attested runtime matters for AI and agentic systems

AI workloads create a stronger version of the same problem because prompts, model weights, retrieval context and tool access are all runtime-sensitive. If the platform cannot verify the code and environment at execution time, it cannot reliably distinguish a legitimate inference session from a compromised one. Confidential containers therefore help protect AI services where the real exposure window exists during execution, not just during storage or transit. That is especially relevant where agents invoke tools or retrieve sensitive context from external systems, because the policy decision must occur before the model or agent is allowed to act. See the AI Infrastructure Workload Identity Guide.

Practical implication: Tie runtime attestation to AI agent and model access so the environment is verified before tool use or context release.

How shared infrastructure risk changes under confidential computing

Shared infrastructure increases the number of actors and control planes that can influence a workload, including operators, platform services and third parties. Confidential computing reduces the amount of the stack that needs to be trusted by protecting the application while it is live. That does not remove the need for access control, but it changes what access control protects: the sensitive service can keep operating even when the surrounding environment is not fully trusted. In practice, this makes blast-radius reduction a workload property rather than only an identity policy outcome. See the Container Image Security Guide.

Practical implication: Classify sensitive workloads by execution-layer exposure and require stronger isolation for shared or multi-tenant platforms.

Breaches seen in the wild

• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Confidential containers are becoming a control-plane answer to a trust problem that identity alone cannot solve. The article's core point is that sensitive workloads need verified runtime state before secrets, models or mission data are released, because static identity checks do not prove what code is actually executing. That shifts control from who asked for access to what environment is asking, which is a meaningful evolution for both workload governance and NHI release policies.

AI and agentic systems make execution-time assurance more important, not less. The article ties confidential computing to prompts, model weights, retrieval context and agent-to-tool interactions, all of which can be abused after login and before output. AI infrastructure workload identity becomes relevant because the security question is whether the runtime itself is authorised to touch sensitive context. Practitioners should treat attested runtime as the point where AI access decisions are enforced.

Trusted execution, not perimeter expansion, is the named concept this topic now demands. Modernisation and multi-tenancy keep adding infrastructure layers, third parties and operator paths, but the article argues for reducing how much of that stack must be trusted. That is a governance shift away from compensating controls built around broad platform trust and toward workload-level evidence that access is justified. Practitioners should reframe sensitive workload approval around attested execution boundaries.

For critical infrastructure, the security value is containment, not just prevention. The article emphasises limiting the value of compromise by protecting services even when the surrounding environment is under strain. That aligns with resilience thinking: assume the platform may be imperfect and design the workload so exposure does not automatically become total loss. Practitioners should assess which mission services can survive with narrower trust assumptions rather than broader exemptions.

Compliance evidence becomes stronger when the control is built into the workload path itself. A hardware-backed confidential computing model can show that sensitive data and mission logic are isolated and only released to verified workloads under approved policy. That is more defensible than relying on procedural claims or ACLs alone. Practitioners should look for control evidence that ties policy, attestation and execution together.

From our research library:

• Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
• Read next: Confidential Computing Guide

What this signals

Trusted execution, not broader platform trust, is the governance pattern that will matter most for sensitive workloads. As more AI services and regulated applications move into shared cloud environments, the decision point becomes whether the runtime can prove its own state before access is granted. That makes execution-layer evidence a programme requirement, not an architecture nicety.

The practical implication for identity teams is that access policy will increasingly need to consume workload evidence, not just human or service identity claims. When a secret, prompt or model is released, the control should answer whether the workload is in the approved state, inside the expected boundary and operating under the intended policy.

For practitioners

• Define which workloads require attested release Classify the containerised services that handle sensitive data, AI prompts, model weights or mission logic, then require attestation before any secret or dataset is released to them.
• Gate secrets on verified runtime state Stop treating secret delivery as a simple identity check. Release credentials only when the workload measurement, environment policy and deployment context match the approved profile.
• Separate multi-tenant trust domains For shared infrastructure, distinguish between the platform layer that hosts the workload and the workload execution boundary that must remain protected even if the platform is compromised.
• Document execution-layer control evidence Map confidential computing controls to audit evidence showing that sensitive services, mission data and AI assets are accessible only to verified workloads under approved policy.

Key takeaways

• Confidential containers shift the security question from who requested access to what runtime environment is actually executing the workload.
• The article's main control idea is attested execution, which narrows trust in hosts, administrators and shared infrastructure without removing access governance.
• For practitioners, the immediate task is to tie secret release and sensitive data access to workload verification rather than static identity alone.

Related NHI Mgmt Group resources: Confidential Computing Guide · Container Image Security Guide · AI Infrastructure Workload Identity Guide

Key terms

• Confidential Containers: A deployment pattern that runs each container pod inside a lightweight confidential virtual machine. This lets Kubernetes workloads keep their normal operational shape while the pod executes inside a trusted execution environment with host-side visibility reduced.
• Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
• Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and workload identity. It is designed for practitioners who need to connect identity controls to runtime trust decisions across modern environments.