Topic starter
24/10/2026 8:48 pm
TL;DR: Runtime verification, not storage protection, is the key control for AI data in containers, with Fortanix describing attestation, conditional key release, and confidential execution for CPU and GPU workloads. Pod proof becomes the gate before sensitive data, weights, or secrets are released.
Editorial analysis by NHI Mgmt Group, based on content published by Fortanix: “Confidential AI at Container Speed”.
Key questions
Q: Why do encrypted AI systems still expose risk at runtime?
A: Because encryption protects data before and after processing, but not necessarily while the model is actively using it.
Q: What breaks when Kubernetes nodes are treated as trusted for confidential workloads?
A: The trust boundary collapses to the host, which means the operator, hypervisor, or node-level compromise can expose pod contents even if the container itself is isolated.
Q: How should security teams govern sensitive data used by AI systems?
A: Security teams should treat AI as a data consumer that needs policy boundaries, not just authentication.
Practitioner guidance
- Define which AI workloads require in-use protection Classify workloads that process regulated data, customer prompts, model weights, or sensitive inference outputs, then assign confidential execution requirements to those use cases.
- Gate key release on successful attestation Require attestation proof before releasing any decryption key, secret, or encrypted asset to a pod or VM, and fail closed when verification is incomplete or mismatched.
- Separate pod trust from node trust Update Kubernetes security standards so the node, hypervisor, and host OS are not treated as implicit trust anchors for confidential AI workloads.
Bottom line: Confidential AI moves the control point from storage protection to runtime verification, because data in use is the exposure that traditional encryption does not solve.
Glossary terms: Confidential Computing, Confidential Containers, Remote Attestation, Trusted Execution Environment
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:11 am
Confidential AI creates a runtime governance problem, not just a data protection problem. Encryption at rest and in transit does not answer who gets to see data once a model starts processing it. That shifts control from storage security to execution-time trust, which is exactly where traditional infrastructure assumptions become fragile. Practitioners should treat runtime verification as part of the identity and access model for workloads, not as an optional cloud feature.
A question worth separating out:
Q: Should organisations choose confidential VMs or confidential containers for AI systems?
A: Choose the model that matches how the workload is built and operated. Confidential VMs fit lift-and-shift systems and VM-centric teams, while confidential containers fit Kubernetes-native AI pipelines. Many programmes will need both, but the decision should follow workload shape, not infrastructure preference.
👉 Read our full editorial: Confidential AI in containers shifts trust to attested pods
This post was modified 6 days ago by NHI Mgmt Group