Confidential Computing, Part 1: User-Selected Execution

Cortex Confidential Mode brings hardware-rooted isolation, workload measurement, composite attestation, and protected key release to AI coding and engineering workflows.

Enterprises have spent decades protecting data at rest and data in transit. Storage encryption protects information on disk. Transport encryption protects it as it moves between systems. AI introduces a third state that is just as important: data in use.

To generate code, analyze a repository, inspect a production trace, or reason over customer context, an AI system must process information in memory. Traditional infrastructure controls can encrypt the path into and out of a workload, yet privileged infrastructure layers may still sit beneath the application while that information is being processed.

That creates a consequential gap for organizations working with proprietary source code, credentials, regulated records, financial data, customer information, private models, or sensitive operational context. The input may be encrypted before it reaches the AI service and the output may be encrypted after it leaves, but the work itself still needs a defensible execution boundary.

Pervaziv AI is introducing Cortex Confidential Computing to address that gap.

This first article covers user-selected confidential execution and key release. It establishes the protected environment in which approved Cortex models, orchestration, tools, and supporting services can process confidential plaintext. Part 2 introduces Cortex Confidential, the twelfth specialized Cortex model, which adds semantic privacy and egress-risk intelligence inside that established boundary.

The distinction matters. Confidential execution determines where sensitive AI work is allowed to happen. Cortex Confidential later helps determine whether information attempting to leave that environment carries semantic disclosure risk.

Confidential Mode is a workflow property

Cortex Confidential Computing is designed as a mode of the existing Cortex experience rather than a separate coding product.

An authorized user can select Confidential Mode for an eligible workload, session, workspace, or repository. An organization can require it through policy. Cortex then admits the request only to an approved confidential backend whose current hardware evidence, measured workload identity, model release, and deployment controls satisfy policy.

The security property follows the complete derived workload. It does not end after the first model call.

A confidential session may include routing, planning, coding, analysis, verification, terminal actions, repository retrieval, tools, subagents, retries, background compaction, and streaming output. Any component that receives plaintext must remain inside the measured boundary. Once confidential data enters the session, a retry or recovery path cannot quietly move the work to ordinary infrastructure.

The user does not need to select a different coding model merely because the execution is confidential. Cortex Code still generates and changes code. Cortex Analysis still investigates complex findings. Cortex Planner still organizes multi-step work. Cortex Verify still performs independent review. The approved specialists keep their responsibilities; the execution environment changes around them.

This produces a simple user-facing contract:

• The user or organization selects the required protection level.
• Cortex verifies that an approved confidential environment is ready.
• Eligible Cortex specialists perform the work inside that environment.
• Derived operations inherit the confidential requirement.
• If the protected path is unavailable, Cortex fails explicitly rather than downgrading.
• A bounded receipt can identify the protected execution without exposing raw attestation evidence or customer content.

Confidential Mode is therefore not a label on a request. It is an enforceable property of the workflow.

The four pillars of Confidential Computing

There is no single universally adopted list called the four pillars of Confidential Computing. Some frameworks emphasize memory encryption, hardware isolation, remote attestation, and secure key management. The terminology varies, but the underlying principles substantially overlap.

For Cortex Confidential Computing, this article uses the four essential platform capabilities described in VMware’s technical foundations of Confidential Computing: Isolation, Measurement, Sealing, and Attestation.

Together, the four capabilities form a trust sequence:

1. Isolation creates the protected execution environment.
2. Measurement establishes the identity of the workload.
3. Attestation proves that the environment and measured workload are trustworthy.
4. Sealing and secret protection safeguard secrets and control access to them.

Isolation without measurement protects an unknown workload. Measurement without attestation cannot prove its state to a remote relying party. Attestation without secret protection can establish trust but cannot safely provision what the workload needs. Sealing without isolation would release secrets into an environment that cannot adequately protect them.

At its core, this chain protects data in use, complementing encryption at rest and in transit.

Isolation creates the protected execution environment

Isolation prevents privileged infrastructure layers from reading or modifying protected code and data through their normal administrative capabilities.

For accelerated AI, isolation must cover both sides of the execution path. The confidential CPU environment protects the guest, orchestration, tools, and general-purpose memory. The confidential GPU environment protects model execution, device memory, and sensitive inference state. Protected communication between them keeps prompts, model weights, activations, and intermediate tensors within the intended boundary.

Confidential Mode applies that isolation to customer data and Pervaziv model intellectual property. Tenant separation, privacy-preserving observability, and governed outbound access extend protection beyond the inference operation itself.

Measurement establishes workload identity

Isolation protects the contents of an environment. Measurement establishes what those contents are.

A Confidential Computing platform creates a cryptographic measurement from code, initialized data, boot state, and other security-relevant inputs. Even a small change produces a different measurement, giving the workload a tamper-evident identity.

Cortex extends that principle across the AI stack. Workload identity encompasses the approved software and models permitted to process confidential data, so trust is established for the application as well as the underlying hardware.

This changes the security question from:

Is this a confidential server with an H100?

to:

Is this an approved confidential environment running the exact Cortex workload, models, controls, and release authorized for this organization?

Any protected component that changes also changes the measured workload identity. Unknown components, substituted artifacts, and mismatched releases fail closed.

Attestation proves the environment

Attestation is the cryptographic process of asking a platform to prove its identity and security state.

For accelerated AI, that proof must cover the confidential virtual machine and the GPU. Cortex evaluates fresh, challenge-bound evidence from both rather than treating the accelerator as an opaque peripheral attached to an otherwise protected system.

Freshness is essential. Evidence is bound to a new challenge so that a valid report from an earlier environment cannot simply be replayed. The report must also connect to the measured Cortex workload. If the hardware, firmware, driver, security mode, or protected workload no longer matches policy, readiness is withdrawn.

Evidence, appraisal, and authorization are different responsibilities

Remote attestation is more than checking whether a cryptographic signature is valid. A signature establishes the origin and integrity of evidence; a verifier must still assess what that evidence says about the environment. The application then determines whether the verified state is acceptable for the requested operation.

The IETF Remote Attestation Architecture, RFC 9334 distinguishes an attester that supplies evidence, a verifier that appraises it, and a relying party that uses the result to make an application-specific decision. These are conceptual responsibilities, not a prescription for Cortex’s internal deployment topology.

For enterprise AI, the distinction separates three questions: whether the platform is authentic, whether its security state is acceptable, and whether a particular workload is authorized. Genuine hardware alone does not grant permission to process every organization’s data. Likewise, a correctly measured application is not necessarily appropriate for every task. Trust depends on both evidence and the policy under which that evidence is evaluated.

Sealing safeguards secrets

Sealing protects cryptographic keys and sensitive information so they can be recovered only by an authorized workload in the appropriate trusted environment.

For Cortex, this principle connects the measured, attested environment to protected model artifacts and runtime secrets. Approved models remain encrypted outside the confidential environment. Decryption capability becomes available only after the current evidence, workload identity, model release, and policy pass verification.

Possession of an encrypted artifact therefore does not imply possession of its secret. A copied disk, snapshot, or model bundle remains unusable unless the requesting environment can establish the authorized identity and security state.

Verification and signing remain essential supporting controls. Verification evaluates evidence against policy, while digital signatures establish the authenticity and integrity of trusted claims and software releases. Together, they make the four platform capabilities reviewable and enforceable throughout the workload lifecycle.

Azure, NVIDIA H100, and AMD SEV-SNP form the platform foundation

AI Confidential Computing must protect more than general-purpose memory. A protected GPU attached to an ordinary virtual machine would leave the orchestration layer exposed. A confidential virtual machine attached to an ordinary GPU would leave accelerated inference outside the boundary.

Cortex uses a composite CPU-and-GPU trust model. In the current platform architecture, Microsoft Azure supplies production confidential infrastructure and trust services. NVIDIA H100 extends hardware-rooted isolation and attestation into accelerated AI. AMD SEV-SNP establishes the confidential virtual-machine boundary beneath the Cortex workload.

Platform capabilities establish the protected CPU/GPU environment. Cortex binds admission and continued execution to measured workload identity, verified evidence, and policy-controlled secret access.

Azure supplies the confidential cloud platform

Azure Confidential VMs make hardware-based TEEs available as managed cloud infrastructure and combine them with measured boot, a protected virtual TPM, confidential disk options, cloud identity, networking controls, and managed key services. Azure also provides confidential GPU VM configurations that combine AMD SEV-SNP with NVIDIA H100 Tensor Core GPUs.

The virtual TPM extends the trust chain above the raw processor report. It can represent measured boot state and security configuration while remaining isolated from the hosting environment. Workload measurements can then be connected to hardware-backed platform evidence rather than relying only on a VM name, subscription, or network address.

Microsoft Azure Attestation verifies evidence from the confidential environment and converts validated claims into cryptographically signed attestation results. A relying party can evaluate whether the VM is running on the expected confidential hardware and whether required boot and workload properties are present.

Azure’s managed key services can condition secret release on validated attestation claims. This creates a platform-level connection between measurement and sealing: a secret remains protected until the requesting confidential VM proves the required state.

Azure supplies the infrastructure and attestation services, but an Azure resource identity alone does not establish an approved Cortex workload. Pervaziv still evaluates the attested platform, application measurement, model identities, release, and current policy together.

NVIDIA H100 extends the boundary to accelerated AI

The NVIDIA H100 Tensor Core GPU introduced built-in Confidential Computing support for accelerated AI. Its on-die hardware root of trust, secure and measured boot, device identity, protected operating mode, and cryptographically signed attestation report allow a relying party to verify the GPU before including it in a sensitive workload.

In confidential mode, the H100 establishes protected communication with the driver inside the CPU TEE. GPU security mechanisms protect device memory and the transfer path used for model weights, prompts, activations, and inference results. This extends the trusted execution boundary across the CPU–GPU path instead of protecting only one endpoint.

GPU attestation evaluates more than the device name. NVIDIA’s architecture can establish device authenticity and appraise firmware, confidential-computing mode, driver compatibility, reference integrity measurements, secure-boot state, and revocation status. The result provides evidence that the accelerator is genuine and operating in an expected confidential configuration.

NVIDIA supports local and remote verification through its attestation tooling and services. Cortex consumes bounded verification results rather than returning raw GPU certificates or evidence to users. See the NVIDIA H100 Confidential Computing architecture and NVIDIA Attestation documentation.

AMD SEV-SNP protects the confidential virtual machine

AMD Secure Encrypted Virtualization–Secure Nested Paging, or SEV-SNP, creates a hardware-enforced TEE for an entire virtual machine. It encrypts guest memory with processor-controlled keys and adds integrity protections intended to prevent a malicious or compromised hypervisor from remapping, replaying, or modifying protected memory without detection.

SEV-SNP also protects sensitive CPU state and produces a hardware-signed attestation report containing security-relevant platform information and the guest measurement. A remote verifier can determine whether the VM is genuine, whether required protections are enabled, and whether supplied runtime data is cryptographically bound to the hardware evidence.

For Cortex, this is the host-side isolation boundary. The gateway, orchestration, model-serving runtime, tools, and approved supporting components execute inside the confidential VM. The cloud provider still operates the physical infrastructure, but normal hypervisor and host-administrator privileges are not sufficient to inspect protected guest memory or CPU state.

Microsoft’s Azure Confidential VM documentation describes SEV-SNP protections including memory encryption, unique CPU keys, register-state protection, memory-integrity controls, and firmware rollback protections.

Composite attestation joins the platform and Cortex workload

The CPU and GPU are not admitted independently and then assumed to belong to the same trusted environment. Cortex evaluates their evidence together with workload identity. The required security property is coherence: trusted components must form one authorized execution environment, not merely present individually valid claims.

The composite decision answers three separate questions:

1. Is the Azure confidential VM genuine and in an approved AMD SEV-SNP state?
2. Is the NVIDIA H100 genuine, in confidential mode, and running an approved security stack?
3. Is the exact Cortex workload inside that environment the release authorized to receive plaintext and secrets?

Only the combined result establishes readiness. Passing CPU attestation does not compensate for a GPU failure. Passing GPU attestation does not approve an altered guest, gateway, or model. A valid Azure identity does not override a workload-measurement mismatch.

This division of responsibility is intentional. Azure operates the confidential cloud platform and trust services. NVIDIA supplies the confidential accelerator and GPU evidence. AMD supplies the CPU TEE primitives. Pervaziv binds those foundations to the exact AI workload, model ensemble, and deterministic policy. No single layer supplies the complete guarantee.

Key release turns evidence into an enforceable boundary

Encryption is strongest when possession of an encrypted artifact does not imply possession of the key.

Cortex keeps protected model artifacts encrypted outside the authorized runtime. A key authority evaluates the verified environment and makes decryption capability available only when the current CPU evidence, GPU evidence, workload identity, model release, and policy are consistent.

This creates an important security property: copying a disk, model bundle, snapshot, or encrypted artifact is not enough to recover the protected model. The copied material must still be presented from an environment that can prove it is the authorized workload.

Secret access follows least-privilege principles. Authorization to use a protected model does not imply access to its decryption keys. Key handling remains within the trusted security boundary, separate from ordinary user interaction and application output.

The complete sequence brings the four pillars together:

1. Isolation creates the protected CPU and GPU execution environment.
2. Measurement establishes the identity of the Cortex workload inside it.
3. Attestation proves the environment and measured state to a verifier.
4. Sealing and key-release controls make secrets available only to the approved workload.
5. Deterministic policy keeps the workflow confidential without a weaker fallback.

The cryptography does not decide whether a user should choose Confidential Mode. That requirement comes from authenticated user selection, a durable workspace or repository setting, or organization policy. Cryptography enforces the consequences of the choice.

The measured boundary extends beyond model inference

A confidential AI workload is larger than a model server.

Prompts and repository content may pass through a gateway before inference. Agentic work may invoke planning, tools, terminal commands, retrieval, or subagents. A model response may be buffered, transformed, verified, summarized, or sent to a connector. Any one of those operations can undermine the boundary if it processes plaintext in an unmeasured component.

Cortex therefore treats the complete plaintext-processing path as part of the protected workload. Model inference, orchestration, and approved tools must satisfy the same confidentiality requirement. Protecting only the model while leaving supporting operations exposed would create an incomplete boundary.

Workload identity connects platform trust to application trust. It establishes that the software receiving confidential information is authorized for that purpose, rather than assuming any process inside a confidential VM is acceptable.

Signing supports this lifecycle by establishing release authenticity and integrity. Together, measurement, attestation, and signed software provenance connect the deployed workload to an approved release. Customer-facing evidence can support review without disclosing sensitive content or raw security material.

This also makes the trusted computing base an important architectural concept. It is the collection of hardware and software whose correct behavior the protection depends on. A TEE reduces reliance on infrastructure outside its boundary, but software authorized to handle plaintext inside that boundary still matters. Isolation is not a substitute for secure application design, dependency management, or least privilege.

For AI workflows, the relevant question is therefore not simply how many components run in a confidential environment, but which components actually need access to sensitive information. Minimizing unnecessary access reduces the consequences of an application defect and makes the security assumptions easier to review. Hardware protection and application security reinforce each other; neither makes the other optional.

Continuous assurance replaces one-time startup trust

An environment that was trustworthy at startup can drift later. Evidence can expire. A GPU can reset. A driver can change. A measured file can be replaced. A service can lose readiness while a long-running request is still active.

Cortex treats trust as renewable authorization rather than a permanent startup flag.

Confidential execution depends on current evidence and continuing authorization. Trust must remain valid for the duration of the work, not merely at the moment a session starts. Changes to the environment or its authorization cannot be ignored simply because an earlier verification succeeded.

If the required trust can no longer be established, confidential processing cannot continue under the expired assumption. The workflow fails closed instead of releasing information through an unapproved path. This gives customers a durable protection requirement without depending on a particular infrastructure lifecycle or recovery mechanism.

This behavior is part of the security property. Protecting memory while accepting stale authorization or allowing ordinary fallback would provide a hardware feature without a reliable confidential workflow.

Tenant isolation and fail-closed routing

Confidential infrastructure does not automatically solve multi-tenant isolation.

Model-serving systems can retain reusable state for performance. Caches, model residency, request batching, and background tasks all require explicit treatment when multiple users or organizations share infrastructure.

Cortex applies authenticated access controls and tenant separation throughout confidential execution. Shared infrastructure must not allow one organization’s information or authority to become available to another. Performance optimizations remain subordinate to that isolation requirement.

Routing follows the same discipline. Confidential work is restricted to approved resources within the protected boundary. Capacity limitations or loss of trust produce an explicit failure, not an automatic transfer to a weaker execution environment. Recovery must preserve the original confidentiality requirement.

This is one of the most important operational commitments in the architecture:

Unavailable confidentiality results in unavailable work—not weaker confidentiality.

Confidential execution in numbers

These are architecture counts, not performance claims. Confidential Computing overhead depends on workload, hardware, model selection, and deployment configuration. Production qualification evaluates security behavior and performance separately so that speed is never treated as evidence of trust.

Interactive AI also has more than one performance dimension. Initial response time, sustained generation speed, and the completion time of a tool-assisted task describe different parts of the experience. Evaluating them separately helps distinguish infrastructure costs from model and orchestration costs. A meaningful comparison holds the workload and required security properties constant rather than gaining speed by weakening the protected path.

Certification is part of the boundary

A Confidential Computing feature should not be promoted from unit tests alone.

Production qualification must establish that the protection holds during normal operation, failure, and recovery. Cortex’s qualification approach evaluates the confidential environment as an integrated AI system, including the continued enforcement of isolation, authorized access, and no-downgrade guarantees.

Qualification evidence must support security review without becoming another channel for sensitive information. The objective is to demonstrate that the intended controls hold, not to retain the confidential content processed by the system.

Approval applies to the evaluated deployment. A different environment does not inherit that assurance merely because it uses the same product name, cloud provider, or hardware family. Material changes require renewed evaluation before the same guarantees can be claimed.

This makes qualification a release requirement rather than a general statement about the capabilities of the hardware.

What confidential execution changes for customers

For developers, Confidential Mode provides a protected path for sensitive repositories and sessions without requiring a separate coding interface.

For security and compliance teams, it creates evidence-bearing controls for data in use. Approval can be tied to hardware evidence, exact workload measurement, protected key release, fail-closed routing, bounded receipts, and live certification rather than a general statement that encryption is enabled.

For platform teams, the architecture defines responsibility clearly. Azure provides the confidential cloud platform and supporting trust services. NVIDIA H100 provides confidential acceleration. AMD SEV-SNP protects the virtual machine. Cortex verifies the combined environment and governs the AI workflow.

For organizations, the core benefit is architectural: sensitive AI work can be admitted only after the environment proves what it is, continue only while that proof remains current, and fail without silently escaping to a weaker path.

The boundary protects two valuable asset classes. The first is enterprise data: private source code, customer information, regulated records, and sensitive operational context. The second is AI intellectual property, including protected model assets and the confidential state needed to perform inference. Both require protection while they are in use, not just while stored or transmitted.

The design is also explicit about its limits. Confidential Computing does not make vulnerable application code safe merely because it runs in a TEE. It does not prevent an authorized endpoint from mishandling plaintext after receipt. It does not eliminate denial of service, every physical side channel, or compromise of a trusted policy or key authority. Those risks require additional controls.

A useful trust boundary states both what it protects and where its guarantees end.

Next: Cortex Confidential, the twelfth model

The confidential execution foundation can prove that the expected hardware and software are running inside an approved boundary. It cannot determine whether a generated patch contains proprietary logic, whether several harmless-looking fragments combine into customer information, or whether a connector request creates semantic disclosure risk.

Those questions require contextual intelligence.

Part 2: Cortex Confidential, the Twelfth Specialized Model explains how model 12 operates inside the measured confidential boundary, evaluates attempted data movement, and adds semantic protection without becoming a cryptographic authority or an egress decision-maker.

Technical context and availability

Microsoft documents the SEV-SNP security properties and guest-attestation model used by Azure Confidential VMs, together with the evidence-verification role of Microsoft Azure Attestation. NVIDIA documents H100 Confidential Computing and GPU attestation in Confidential Computing on H100 GPUs and the NVIDIA Attestation documentation.

The confidential execution capability described here remains subject to successful live qualification of the intended H100 Confidential Computing deployment and production release approval. This article describes its architecture and protection commitments; it does not announce general production availability.

Third Party Products and Trademarks: Microsoft and Azure are trademarks of the Microsoft group of companies. NVIDIA is a trademark and/or registered trademark of NVIDIA Corporation. AMD is a trademark of Advanced Micro Devices, Inc. Other third party names and trademarks are the property of their respective owners. References to Microsoft Azure services, NVIDIA H100 and attestation technologies, and AMD SEV-SNP describe platform capabilities and their role in the architecture discussed here. They do not imply affiliation, sponsorship, endorsement, or approval of Pervaziv AI or Cortex. Third party products and services are subject to their respective terms, availability, licensing requirements, and applicable fees.