Fortanix Makes Kubernetes AI Earn Its Keys. The Trust Perimeter Just Moved.

What changed: AI must prove it deserves the keys

Fortanix announced support for Cloud Native Computing Foundation Confidential Containers (CoCo) in Fortanix Confidential AI on October 18–19, 2026. The company says the integration is available now. Its premise is simple and consequential: before a containerized AI workload can decrypt sensitive models or data, the hardware execution environment must prove its identity and integrity and satisfy access policy. Fortanix Confidential Computing Manager (CCM) evaluates attestation, while Fortanix Data Security Manager (DSM) controls key release. The workload runs in a hardware-backed trusted execution environment (TEE), not merely an ordinary container sharing the host's trust assumptions. ^{1 2}

This is not a new announcement disguised as a November launch. Cisco detailed the deployment architecture in October and described a Cisco Secure AI Factory with NVIDIA demonstration. On October 31, independent InfoQ coverage dug into the mechanics, alternatives and limitations. The timely news is the claimed availability and evidence of an actual deployment path—not the invention of confidential containers or attestation, both of which predate this release. ^{3 4 5}

There is one distinction a buyer cannot afford to miss. Fortanix's announcement says the capability is available. Cisco's October design guide calls Fortanix CoCo support a public preview, warns that behavior could change before general availability, and documents validation of one Intel TDX worker, one NVIDIA H100-NVL GPU and one confidential container. The guide expressly says multi-node operation, availability and AI performance require additional qualification. An integration that can be obtained today is not the same as a fully qualified distributed production service. ⁶

None of this is a dismissal, as this is important news for making AI safe in organizations. Instead, it is precisely the sort of evidence-based distinction that separates an exciting architecture from a CIO's production commitment.

The underlying problem: AI increasingly runs on the data an organization cannot afford to lose

For years, enterprise AI adoption could be measured through relatively low-risk experimentation: document summaries, generic assistants, training data that had been scrubbed or copied outside core applications. The next stage is materially different. AI now has a pathway into live claims processing, customer relationships, underwriting, manufacturing intellectual property, patient information, financial transactions and agent-driven operations. Its value increases as it gains access to the sensitive data and privileged context previously confined to systems of record.

That creates a paradox. The data that makes an AI model useful is often the data an enterprise most needs to keep out of the hands of its infrastructure operator, external model provider or compromised administrator. Disk encryption and TLS protect data at rest and in transit. During inference, however, prompts, retrieved context and model weights normally have to be decrypted into executable memory. A cloud tenant boundary or Kubernetes permission check does not by itself protect that plaintext from a privileged or compromised host. Cisco and Fortanix identify this runtime exposure as the fundamental gap. ^{6 1}

Confidential computing changes the infrastructure trust bargain. Intel TDX or AMD SEV-SNP can provide confidential VM isolation; supported NVIDIA confidential GPUs can extend the protected execution path. Remote attestation lets a separate party compare hardware-signed evidence and measured software against an approved policy before a secret crosses the boundary. In CoCo, Kata Containers and guest-side components enable a familiar Kubernetes deployment model, while Trustee provides the upstream reference attestation and key broker services. ^{5 7}

Fortanix is packaging the enterprise control layer over those open components: CCM evaluates supported evidence and issues short-lived workload identity, and DSM releases the appropriate decryption key over an authenticated channel to the verified environment. Its documentation describes composite CPU/GPU attestation and separate guest and key-release policies. A model owner can keep control of its weights while an enterprise hosts inference; an enterprise can keep confidential data away from an external compute operator. Both benefits depend on the actual policies and hardware configuration, not the Confidential AI label. ²

The key strategic change is that a cluster can be permitted to run code without being automatically entitled to read the information that code requires. That is a much stronger separation of duties.

Why familiar controls cannot close the gap

Kubernetes RBAC, encrypted container registries, IAM, network firewalls, image signatures and secrets management remain essential. They authenticate principals and protect important parts of the software supply chain. But they do not automatically answer the question, 'Is this specific CPU/GPU execution environment trustworthy enough to decrypt this model and customer dataset right now?' Simply moving the workload into a different tenant or a private cloud does not resolve that question. ^{8 7}

Nor is a TEE a universal safety guarantee. An attested image may contain a vulnerable application or an agent authorized to leak data through an output, network call, log or tool invocation. The CoCo threat model excludes denial of service and hardware side channels; the host may still refuse to schedule or continue a workload. Trust boundaries also depend on guest components, image verification and host-to-guest API policy. Attestation says specific measurements and claims were accepted; it does not attest that every subsequent AI decision is correct or compliant. ⁸

One easy-to-miss implementation detail illustrates the danger of false assurance. Fortanix's Intel TDX deployment guide allows different treatments of GPU evidence. InfoQ observed that a 'Required' mode verifies GPU attestation, while 'Ignored' can accept the presence of evidence without validating its result. A claimed CPU-to-GPU chain of trust is substantially weaker if the GPU check is not enforced. The policy is the product. The vendor logo, enclave icon and compliance certificate do not substitute for a documented fail-closed control. ^{9 4}

There is a second trap: turning the new trust plane into a captive proprietary chokepoint. CoCo already includes Trustee's attestation, reference-value and Key Broker Service components. Microsoft Azure offers Secure Key Release tied to attestation in Key Vault and Managed HSM. These alternatives differ in scope and integration, but demonstrate that attestation-linked keys are an architectural pattern, not a Fortanix invention. A CIO should buy operational assurance and portability rather than assume that enterprise-grade trust requires permanent dependence on one service. ^{10 11}

The Frontier take: execution rights are becoming a new AI control plane

Enterprise AI's next security perimeter is not the network, the model or even the cluster. It is the decision to release the keys to the executing workload. That decision can become a durable, independently governed control point wherever sensitive enterprise data meets powerful AI.

Think about three layers. Model governance determines what a model should infer. Agent and orchestration controls determine which systems it can access and actions it can take. Attestation and key policy determine whether a specific runtime is entitled to unlock the assets needed to do either. As AI becomes central to sensitive business operations, this third layer moves from a hardware-security specialty into enterprise architecture.

The operating model changes accordingly. Platform teams must reproducibly describe software and firmware measurements. Security teams must understand CPU/GPU evidence, certificate issuance, revocation and key custody. Data owners need authority over which workloads may decrypt which datasets. Procurement must demand supported hardware-and-software combinations, not partner logos. Audit must capture why a particular workload was permitted to start. These are governance changes, not just engineering additions.

There are uncomfortable trade-offs. Fail-closed key policy protects confidentiality but can also stop a healthy inference service when the verifier fails, measurements change unexpectedly, or certificates cannot be renewed. Fortanix advertises clustered CCM/DSM deployment and enterprise support, but Cisco's validation of a single worker and GPU does not demonstrate multi-node scheduling resilience, end-to-end failover or production AI performance. Both supplier claims and real-world failure modes have to be tested. ^{1 6}

Nor should the business case be reduced to encryption overhead. The real value is the portfolio of AI workloads that an organization can now consider because its data does not have to become implicitly visible to the infrastructure operator. The cost is additional hardware requirements, narrower platform choices, key-service dependencies, complexity in observability and possible latency or throughput penalties. Microsoft's own guidance acknowledges that full confidential-computing protection reduces hardware and regional options and adds cost. ¹¹

The long-term consequence is profound: confidential computing expands the permissible envelope of enterprise AI. It helps organizations put AI closer to the processes they have been reluctant to expose. Fortanix has advanced a practical route toward that future. The proof of enterprise maturity, however, will come from validated, recoverable, policy-correct production operations—not an availability headline.

Exactly three CIO recommendations

1. Make decryption authority separate from cluster authority

Action: Define a high-sensitivity AI workload tier covering regulated records, strategic intellectual property, privileged system access, proprietary model weights and high-impact agents. For that tier, require attestation-gated key release with policy owned jointly by security, data governance and the AI platform—not by Kubernetes administrators alone. Specify approved image digests, firmware, GPU verification, tenant boundaries, permitted regions and revocation rules.

Decision trigger: Mandate this architecture when a third-party infrastructure operator, privileged host administrator or external model partner must not be able to inspect the underlying data or weights.

Why now: Valuable enterprise AI is moving into data-rich operating processes where implicit host trust is an unacceptable shortcut. ^{2 8}

2. Refuse production sign-off without failure and multi-node qualification

Action: Pilot the exact planned CPU, GPU, firmware, host kernel, container runtime, driver and Kubernetes topology. Change a measurement deliberately and prove that the keys stay withheld. Require actual CPU/GPU composite attestation, then exercise node failure, scale-out, key-service outage, certificate expiry, key rotation, latency, throughput, audit evidence and recovery. Get written vendor support commitments for that precise combination.

Decision trigger: Hold high-consequence production until the actual multi-node deployment has passed these tests; a single-node reference demonstration is not sufficient.

Why now: Cisco explicitly identifies its Fortanix configuration as a public preview with only one worker, GPU and container validated. ^{6 9}

3. Protect what happens after attestation, and preserve an exit

Action: Compare Fortanix against the open Trustee baseline and relevant cloud-native key-release services. Require evidence portability, documented policy export, separation of administrative duties and a realistic migration plan. Add application-layer egress restrictions, agent tool authorization, protected logging, prompt/output handling and data loss prevention to the TEE boundary.

Decision trigger: Apply these requirements before hosting highly sensitive inference across multiple clouds, suppliers, sovereign environments or outside-operated AI factories.

Why now: Verified execution does not prevent an authorized application from disclosing information, and the new key plane should not become a single-vendor point of strategic failure. ^{10 8 11}

Sources

Fortanix: CoCo announcement, October 18–19, 2026; Confidential Containers technical FAQ; Intel TDX deployment guide.

Cisco: Confidential Containers UCS architecture and validation guide, October 2026; Cisco and Fortanix blog, October 21.

Independent: InfoQ technical analysis, October 31, 2026.

Upstream technical references: CNCF Confidential Containers overview, Trustee attestation, Trustee architecture, CoCo trust model.

Alternative architecture: Microsoft Azure Secure Key Release.