How Confidential Computing Is Transforming Cloud Security: 7 Key Technologies Protecting Even AI Data

\n

When You Need Data That Even Cloud Operators Cannot See

You encrypted your data and stored it in the Cloud, then transmitted it securely using TLS. But the moment an application reads and processes that data, it is decrypted into plaintext in memory. If so, is that data truly protected from end to end?

This is precisely where the need for Confidential Computing begins.

Traditional Cloud security has largely focused on two areas:

• Data At Rest: Encrypting data stored on disks, databases, and object storage
• Data In Transit: Encrypting communications between users and servers, and between services, using TLS and other technologies

However, real-world processing necessarily takes place after data is loaded into memory for computation. In other words, data can become plaintext while In Use. This stage is exposed to a range of risks, including operating systems, hypervisors, administrative privileges, memory dumps, and malware intrusions.

The Cloud environment is particularly challenging because it is built on a multitenant structure in which multiple customers share the same physical infrastructure. Conventional access controls and encryption remain essential, but highly regulated industries are asking an even more fundamental question:

“Can we prevent even the cloud provider’s operators or anyone with infrastructure-level administrative privileges from seeing our data?”

The technology that turns this requirement into reality is Confidential Computing. Confidential Computing leverages a TEE (Trusted Execution Environment) inside the CPU to execute sensitive code and data within an isolated area. Even when data is decrypted for processing in this environment, the general-purpose operating system, hypervisor, and other virtual machines cannot directly read its contents.

Put simply, if traditional security is about “locking the door and transporting data safely,” Confidential Computing is about turning the workspace where data is processed into a space that cannot be viewed from the outside.

This shift matters not only to finance, healthcare, and public institutions, but also to companies adopting generative AI. To use highly sensitive data—such as customer information, internal documents, source code, model parameters, and prompts—in the Cloud, organizations need an architecture that protects not only data at rest and in transit, but also data while it is being processed.

Ultimately, the core of Cloud security today goes beyond asking, “Who can access the data?” The more fundamental question—and an increasingly important competitive advantage—is now: Can we make data impossible to see, even for those who have the authority to access it?

The Blind Spot in Cloud Security: Confidential Computing for Protecting Data in Use

Data is encrypted when stored, and it is protected with TLS while moving across networks. But what happens the moment data is executed—when an application decrypts, computes, and processes it?

At that point, data may exist in plaintext in memory. In traditional Cloud security models, risks remain that operating systems, hypervisors, highly privileged administrator accounts, or compromised host environments could access this data in use. Encryption for data at rest and data in transit alone cannot completely close this final gap.

The technology that emerged to address this gap is Confidential Computing.

Why Does Encryption Become Vulnerable at the Moment of Execution?

Conventional security models generally protect data in two states:

• Data At Rest: Data stored on disks, in databases, or in backup files
• Data In Transit: Data moving between users and servers, or between servers

However, for a service to process an actual request, data must ultimately be decrypted in memory. For example, to analyze a customer’s national ID number, payment information, medical records, or AI prompt in a Cloud environment, an application must read and process those values.

This Data In Use is the core problem.

Encrypted data in storage
        ↓ Decryption
Processing in application memory
        ↓
Return of computation results

In traditional environments, it is difficult to completely eliminate the possibility that sensitive data loaded into memory could be exposed to highly privileged layers such as the operating system or hypervisor. This becomes even more significant when Cloud provider operations staff, malicious administrator accounts, and compromised hosts are included in the threat model.

Confidential Computing turns this execution phase into a separately protected environment, designed to preserve confidentiality even while data is being processed.

TEE: A Hardware Vault for Data in Use

At the heart of Confidential Computing is the TEE (Trusted Execution Environment). A TEE is a hardware-based isolated space established inside a CPU or accelerator.

Within this space, code and data are processed separately from the general execution environment. The key point is that access is not restricted merely through software permissions; the hardware itself enforces the restrictions.

A TEE typically provides the following capabilities:

• Memory Encryption: Encrypts data in use at the memory level.
• Mandatory Isolation: Prevents other processes, the operating system, and the hypervisor from reading or modifying the protected memory.
• Integrity Protection: Verifies that the code and data being executed have not been tampered with.
• Remote Attestation: Allows external users to cryptographically verify that trusted hardware and approved code are actually running.

Simply put, a TEE is much like an “execution vault that even the operator cannot open” inside a Cloud server. Sensitive data and critical logic are processed only inside this vault, while only the necessary results are sent outside.

What Makes an Enclave Different?

Inside a TEE, an isolated execution space called an Enclave is typically created. Rather than placing an entire application inside it, the common approach is to isolate only particularly sensitive functions—such as cryptographic key handling or personal data analysis—in the enclave.

Consider, for example, a credit-scoring API for a financial service.

User request
   ↓
General web/API server
   ↓
Credit-scoring logic inside the Enclave
   ├─ Decrypt customer data
   ├─ Calculate risk
   └─ Generate result
   ↓
Return only the score or approval result externally

In this structure, the general web server can receive requests and return results. However, the customer’s original data, decryption keys, and the core logic of the evaluation algorithm never leave the enclave.

As a result, even if administrative privileges in the Cloud operating environment are compromised, it becomes far more difficult for an attacker to directly read plaintext data or secret keys inside the enclave.

Remote Attestation Completes the Chain of Trust

A TEE alone is not enough. From the customer’s perspective, there must be a way to verify whether the correct code is running in a genuinely trusted Cloud environment without having been tampered with. This is the role of Remote Attestation.

Remote attestation is a process that uses a cryptographic certificate generated by the execution environment to verify the following:

1. Is the requested TEE hardware actually being used?
2. Is an approved version of the application code currently running?
3. Do the boot configuration and security policies match the expected state?
4. Can encryption keys be delivered only to the verified environment?

This process becomes even more powerful when combined with a Key Management System (KMS). A KMS can be configured to provide decryption keys only when the attestation results meet the required policies.

In other words, if the code has been modified or is running in an unauthorized environment, it cannot receive the key. Without the key, sensitive data cannot be decrypted. This goes beyond simply “denying access”; it creates a structure in which the data itself becomes unusable unless the conditions for trust are satisfied.

Why It Matters Especially in Cloud Environments

Cloud is a multitenant environment in which multiple customers share physical infrastructure. Virtualization, IAM, network segmentation, and encryption are already powerful security measures, but Confidential Computing takes protection one step further.

While conventional security controls “who can access” the data, Confidential Computing addresses a deeper question:

Can we make data invisible even to highly privileged operators or infrastructure layers?

This question is especially important for workloads such as:

• Generative AI services handling customer prompts and internal company documents
• Financial transactions, credit-scoring, and fraud-detection systems
• Collaborative analysis of medical data between hospitals and research institutions
• Data collaboration between companies without exposing their original data
• B2B SaaS applications processing source code, cryptographic keys, and model parameters

Confidential Computing is not a universal technology that solves every security problem. Application vulnerabilities, misconfigured IAM policies, input-based attacks, and data-leaking logs still require separate controls. Performance overhead and limited debugging environments must also be considered during the design phase.

Even so, TEEs and remote attestation extend the trust boundary of Cloud security all the way down to the hardware level. By protecting data not only when it is stored or transmitted, but also during its most sensitive moment—the moment of execution—Confidential Computing is gaining attention as a key technology for closing the final gap in encryption.

Cloud Confidential Computing: No Key, No Data Access

What happens if even a single line of code inside a confidential VM is tampered with?

The answer is simple: remote attestation fails, and the VM does not receive the encryption key. Without the key, the data cannot be decrypted, and sensitive computations cannot begin.

This is the core distinction between confidential computing and conventional encryption in Cloud environments. It does not merely encrypt data at rest. Instead, it allows access to keys and data only within a verified execution environment.

What Does Remote Attestation Verify?

Remote attestation is the process in which a client or key management system asks a confidential VM questions such as:

• Is the environment currently running a trustworthy TEE?
• Was it booted with approved hardware and security settings?
• Do the operating system, boot chain, and application code match the expected values?
• Are there any known vulnerable configurations or signs of tampering?

In response, the confidential VM generates hardware-based attestation evidence. This typically includes measurements of the execution environment, code hashes, security policy information, and more.

The key management service (KMS) or the customer’s verification system checks this evidence. Only when the verification result matches the policy does it deliver the data encryption key to the VM.

Until the environment proves that it is trustworthy, the key is not delivered.

What Happens When the Code Hash Changes?

Suppose, for example, that there is a Cloud application analyzing financial data. The hash of the legitimate code is registered in advance, and the key management system is configured to provide the decryption key only to confidential VMs whose hash matches that value.

Now imagine that someone adds just one line of code to the application. It could be code that sends data externally, or code that writes debug logs.

Even a minor code change alters the measurement. The result is clear:

1. The confidential VM generates remote attestation evidence.
2. The KMS compares the current measurement against the registered policy.
3. It detects a code hash mismatch.
4. Verification is denied.
5. The decryption key is not delivered.
6. The encrypted data cannot be opened.

In other words, even if an attacker takes control of the VM, a real attack becomes far more difficult if they cannot obtain the key required to access sensitive data.

A Stronger Security Architecture with Cloud KMS

Confidential computing is not complete with a TEE alone. A robust architecture is typically built when TEE, remote attestation, KMS, and least-privilege policies work together.

A typical flow looks like this:

Confidential VM boots
    ↓
TEE generates code and environment measurements
    ↓
Attestation evidence is submitted to a remote attestation service or KMS
    ↓
Policy verification: Is this approved hardware, code, and configuration?
    ↓
The decryption key is delivered only if verification succeeds
    ↓
Data is decrypted and processed only inside the confidential VM

In this design, the data encryption key is not simply handed to a “privileged user.” The key can be obtained only when the specified code, running within the specified hardware-protected area, satisfies the specified security policy.

Why Operator Privileges Alone Are Not Enough

In traditional Cloud security models, administrator privileges, IAM permissions, and network access controls are extremely important. However, high privileges can always become part of the attack surface. Account compromise, misconfigured permissions, and insider threats never disappear completely.

Confidential computing’s key release policy takes security one step further:

• Even an administrator cannot obtain the key for an unverified VM.
• Even if the hypervisor or host operating system attempts to read the data, the memory remains protected.
• Replacing the VM image with unauthorized code blocks access to the key.
• Even if an attacker copies the data, they obtain only ciphertext without the key.

Of course, this does not eliminate every security threat. Vulnerabilities in the application itself, logical errors in approved code, and incorrectly configured key policies must still be managed. However, the principle of “providing keys only to verified execution environments” significantly increases the number of conditions an attacker must satisfy for an attack to succeed.

Policies You Must Define When Designing the System

When designing a confidential Cloud workload, deciding “what to encrypt” is just as important as deciding “under what conditions to release the key.”

In particular, the following items must be clearly defined:

• Measurements for the VM images and application code that will be allowed
• Approved TEE hardware and Cloud regions
• Operating system, kernel, and boot chain version policies
• Key usage periods and criteria for automatic destruction and rotation
• How the service will respond when verification fails
• Approval procedures and audit log policies for incident response

The core idea is simple. The key to sensitive data should not be an asset that people can retrieve whenever it is convenient. It should be an asset delivered conditionally to an execution environment that has proven its trustworthiness.

Confidential computing implements this principle through hardware and cryptography. If the code has been tampered with, the key does not arrive. And without the key, the data cannot be opened.

How AI and Competing Companies Can Collaborate Without Seeing Each Other’s Data: Cloud Confidential Computing

Can hospitals that do not fully trust one another conduct joint research without exposing raw patient data? Can competing financial institutions jointly improve fraud detection models while keeping customer transaction records hidden? And can companies safely operate their internal prompts and proprietary LLMs in an external Cloud environment?

Confidential Computing offers a practical answer to these questions. The key is not merely encrypting data while it is stored or transmitted, but protecting data even while it is being processed.

Creating a Zone of Trust Among Untrusted Participants

In traditional collaboration structures, participating organizations had to gather their data in one place before analysis could begin. But patient information, financial transaction records, and corporate secrets cannot easily be moved outside their original environments. Legal regulations, competitive relationships, and the risk of data breaches all stand in the way.

Confidential Computing processes data inside a TEE (Trusted Execution Environment), a hardware-based isolated area within Cloud infrastructure. This environment follows several core principles:

• Raw data is decrypted and processed only inside the TEE.
• Cloud operators, the host OS, and the hypervisor cannot view the data in plaintext.
• Participating organizations can use Remote Attestation to verify that approved code is being executed.
• Only analysis results are sent outside, while raw data and encryption keys never leave the protected zone.

In other words, participants do not need to completely trust one another. Instead, they place their trust in verifiable hardware and an untampered execution environment.

How Joint Research Among Hospitals Can Change

Suppose several hospitals are analyzing the effectiveness of treatments for a rare disease. Each hospital holds sensitive data, such as patient diagnoses, test results, and medication histories. Collecting this information in plaintext on a central server is practically impossible because of privacy regulations and internal security policies.

With a Cloud architecture based on Confidential Computing, the hospitals can collaborate through the following process:

1. Each hospital encrypts its data using its own key.
2. Only the encrypted data is sent to the confidential analysis environment.
3. Each hospital uses Remote Attestation to verify that the designated analysis code and TEE environment are operating properly.
4. Decryption keys are delivered only to an environment that has passed verification.
5. Statistical analysis or machine learning is performed inside the TEE.
6. Participants receive only aggregated results, model performance metrics, and approved research findings.

In this structure, Hospital A cannot see the raw patient data of Hospital B. The Cloud provider cannot inspect the data either. Researchers obtain the analysis results they need while minimizing the exposure of sensitive personal information.

Corporate Prompts and LLM Models Can Be Protected Too

As generative AI adoption expands, companies are connecting internal documents, source code, and customer service records to LLMs. But the biggest concern is clear: “Who can see our prompts, data, and model parameters?”

With Cloud AI services built on Confidential Computing, sensitive AI processing can be moved into a protected zone.

• Customer prompts and attached documents are processed only inside the TEE.
• Search results from vector databases are combined within protected memory.
• Company-specific model weights and system prompts are isolated.
• Only inference results are returned to external applications according to policy.
• Model keys and data keys are provided only to workloads that pass Remote Attestation.

This allows AI service providers to design systems in which customer data is not exposed to the general operating environment or to other tenants. It is especially important in industries such as legal services, healthcare, finance, and manufacturing, where data confidentiality is directly tied to competitive advantage.

The Core of the Technology: Remote Attestation and Key Control

Creating a TEE alone does not complete the security architecture. Real trust is built through the combination of Remote Attestation and key management.

Remote Attestation cryptographically proves that an execution environment is running on specific hardware with an approved code state. After verifying this evidence, the data owner delivers the encryption key only when the conditions are satisfied.

This approach makes the following security policy possible:

Data can be decrypted only when approved application code is running in an approved Cloud confidential environment.

If the code has been modified, the workload is running with an unauthorized image, or the verification policy is not satisfied, the key cannot be obtained. Even if the data is stolen, there is no way to decrypt it.

Collaboration Expands, but the Design Must Become More Sophisticated

Confidential Computing opens the door to data collaboration among competing companies, but it does not automatically solve every problem. The following areas require separate design and careful consideration:

• Output leakage management: Even if only aggregated results are disclosed, it is necessary to assess whether information about a specific individual or company could be inferred.
• Access control policies: It must be clearly defined who can run an analysis, which results each person can view, and when a key may be issued.
• Logging and monitoring: Because the inside of a TEE cannot be directly observed, organizations need audit logs that do not expose sensitive information, along with an incident response system.
• Performance and cost: Memory encryption, attestation, and restricted debugging environments can increase operational complexity and cost compared with ordinary workloads.
• Output control: Data masking, differential privacy, and approval procedures should be applied together to ensure that the model’s output itself does not contain sensitive information.

Ultimately, Confidential Computing is more than a technology for “hiding data securely.” It is Cloud collaboration infrastructure that enables organizations to exchange value without disclosing their data. In the age of AI, companies and institutions that want to compete and collaborate at the same time need a strategy that shifts trust away from contracts and into a verifiable execution environment.

Beyond Cloud Security Options: Toward a New Trust Model

Will security be complete if even operators are unable to see the data? The short answer is no. Confidential computing is not the final destination of security—it is the starting point for a new approach to Cloud design.

Traditional cloud security has focused on controlling “who can access what” through IAM, network isolation, encryption, and key management. Confidential Computing takes this one step further. It includes even highly privileged entities—such as operating systems, hypervisors, and infrastructure operators—in the potential threat model, ensuring that sensitive data and code are processed only within a TEE (Trusted Execution Environment).

The key shift is that the basis of trust itself changes.

• In the past, organizations had to trust cloud providers’ operational procedures and access controls.
• Now, they trust verifiable hardware environments and untampered code.
• Encryption keys for data are no longer simply delivered to a server. Keys are provided only after remote attestation confirms that the environment is an approved TEE.

In other words, instead of relying on a policy-based promise that “operators will not look at the data,” organizations can build a structure in which operators are unable to see the data even if they try.

However, this structure also introduces new challenges. Because the inside of an enclave cannot be easily observed from the outside, debugging, performance analysis, log collection, and incident response must all be approached differently. Organizations need to establish masking policies to prevent sensitive data from appearing in logs and design which events should be exposed externally. They also need operational scenarios that account for situations such as remote attestation failures, key delivery denials, and TEE node outages.

Therefore, successfully adopting Cloud confidential computing does not mean moving every system into an enclave. The key is answering the following question:

“What data and computations in our service must be protected, and how far can we allow plaintext to exist?”

For example, an AI service could prioritize protecting customer prompts, internal documents used for retrieval-augmented generation (RAG), model parameters, and the stages where encryption keys are processed. For a financial service, it may be more appropriate to move credit assessment logic, transaction detection models, and personally identifiable information processing into a confidential execution environment.

Ultimately, confidential computing is far more than a simple security option. It is a new Cloud trust model that redefines the relationship between data, code, keys, and operational authority. Organizations that leverage this model effectively can go beyond regulatory compliance, enabling safer collaboration and creating new services built on data and models that previously could not be shared.