Skip to content
redactsure
Book a review

Explore.

Explainer · RedactSure Research

Does a Confidential VM Keep Sensitive Data Away From the AI? No. It Keeps the Data Away From the Provider

Chris Sowa · Founder, RedactSure
Published September 26, 2026 · Last updated September 26, 2026

No. A confidential virtual machine keeps the data away from the provider. A trusted execution environment encrypts a machine’s memory with keys the cloud operator does not hold, so the operator, its staff and anyone who compromises its infrastructure cannot read what runs inside. The AI agent runs inside. It reads everything the application shows it, exactly as it would on an ordinary machine, because the agent is the workload the enclave was built to protect. The question a confidential VM answers is who besides the agent can see this data. The question Least Exposure answers is what the agent should see for this piece of work: exactly the data the task requires and nothing more, enforced before any model reads the screen. The two questions are both worth answering, and no amount of the first answers the second. This page explains what confidential computing guarantees, why the three largest consumer AI providers built variations of it, and where the enterprise question begins. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

What does confidential computing guarantee?

A trusted execution environment is a region of a processor in which code and data are protected from everything outside it, including the operating system, the hypervisor and the cloud provider that owns the hardware. Memory is encrypted with keys held in the processor; the running code is measured and can be attested to a remote party, so the customer can verify which software is running before trusting it with data. AMD SEV-SNP, Intel TDX and AWS Nitro Enclaves are the common implementations, and cloud providers sell confidential VMs built on each.

The threat model is specific. Confidential computing defends against the host: a cloud operator’s administrator, a compromised hypervisor, a subpoena served on the operator, an insider with physical access to the machine. It was built for workloads that had to run on someone else’s hardware without that someone being able to look. Payment processing, key management and multi-party analytics were the early uses.

What confidential computing does not do is change what the workload itself can see. The code inside the enclave reads its inputs in the clear; that is the point of running it there. If the workload is an AI agent operating a claims system, the agent reads the claims screen, name and Social Security number included, inside an environment that guarantees nobody else can. The enclave has made the agent’s reading private. It has not made it smaller.

Why did Meta, Apple and the others build this?

Because the provider was the party users did not trust, and each company built architecture to take itself out of the trust equation.

Meta’s Muse runs each user’s agent in a dedicated Secure VM. Meta is candid that this first version restricts access to the user’s data by Meta personnel through operational policies, and that it does not prevent Meta from accessing data when necessary to support, secure or operate the service. The Confidential VM, planned for later in the year, is intended to cryptographically and verifiably prevent Meta from accessing data in the VM, with independent experts able to confirm it. Meta co-designed the architecture with the creator of Signal and committed to publishing binaries and a transparency log. The gap being closed, in Meta’s own framing, is the gap between what policy forbids and what architecture prevents.

Apple’s Private Cloud Compute answers the same question a different way. Apple states that user data must not be retained, including via logging or for debugging, after the response is returned; that the PCC nodes intentionally include no remote shell or interactive debugging mechanisms; that software images of every production build are published for security research; and that personal data must never be available to anyone other than the user, not even to Apple staff, not even during active processing. Statelessness and verifiable transparency instead of user-held keys, but the party being excluded is the same: the provider.

Both designs are serious engineering, and both answer a real question. A consumer handing an assistant their email, calendar and payment cards is right to ask whether the company running the assistant can read them. The architecture now says no, or will shortly.

What question is left open?

What the model received. In Muse, in Private Cloud Compute, in any confidential VM, the model is given the data in full because the model’s usefulness depends on it. A personal assistant that cannot see your email cannot manage it. The design goal was to let the agent see everything while letting nobody else, and the design achieves it.

An enterprise starts from the opposite premise. The records on the screen are not the operator’s own; they belong to claimants, patients, students, cardholders, and the organization’s obligation is to limit who and what reads them to what the work requires. The minimum necessary standard, FERPA’s legitimate-interest condition and PCI scoping all ask the organization to bound the reader, and once the reader is a model, the bound has to be enforced at the point where the model reads. Privacy from the provider does not satisfy that obligation. A model that read a full patient record inside an enclave still read a full patient record, and the enclave’s attestation will confirm exactly which software did the reading.

The consequence for prompt injection follows directly. OWASP ranks injection first among LLM application risks, and the attack works through what the model reads. A confidential VM does not reduce that surface by a single field; it guarantees that when the persuaded agent exfiltrates its context through an approved channel, no one at the provider was watching. What Does a Prompt-Injection Attack Get From an Agent That Sees Only Tokens? walks the alternative.

Where does the enclave fit in the RedactSure architecture?

At the bottom, as it should. RedactSure runs on AMD SEV-SNP hardware-encrypted enclaves on HIPAA-eligible AWS infrastructure, deployed into the cloud environment the customer’s compliance posture requires, with the customer holding the keys. The real values behind every token live in that enclave as ciphertext RedactSure cannot decrypt. That is confidential computing doing its job: the provider, RedactSure in this case, is out of the trust equation for the vault.

Above the enclave sits the layer it cannot supply. Inside the governed environment, render-layer tokenization replaces identifiers with consistent tokens (USER_001, SSN_001, ACCT_001) before any model reads the screen, and the agent is handed the fields the work needs rather than the whole picture. Real values resolve only at approved destinations at the moment a named person approves the action under Supervised Delegation. The enclave answers who besides the agent can see the data. The render layer answers what the agent sees. An enterprise needs both answers on file, and the second is the one no confidential VM provides.

What the record shows

A confidential VM does not keep sensitive data away from the AI. It keeps the data away from the provider, by encrypting the machine’s memory with keys the operator does not hold and attesting the code that runs there. Meta’s planned Confidential VM and Apple’s Private Cloud Compute are both built to answer that question, in their own words: to prevent the company from accessing the user’s data, verifiably. Inside each, the model reads the user’s data in full, because the agent is the workload the enclave protects. For an enterprise whose obligation is to bound what reads a record to what the work requires, privacy from the provider leaves the obligation untouched, and the injection surface unchanged. The enclave belongs at layer 01 of the stack, where RedactSure runs it with customer-held keys. What the model sees is decided one layer up, at the render, and only there.

Frequently asked questions

Is a confidential VM worth having, then?

Yes. It removes the provider from the trust equation for everything inside the machine, which is a real guarantee and the right foundation. RedactSure runs on enclaves for that reason. It is the floor, not the answer to what the model reads.

If the enclave attests the code, doesn’t that prove what the agent saw?

Attestation proves which software ran. It says nothing about which data that software was shown. The record of what the model received is the run history in the AI Control Record, held as tokens, and it exists only when the environment records the render.

Does Apple’s stateless model solve the enterprise problem?

It solves retention: nothing persists after the response. The model still received the full input, and for records law the reading is the event, not the storage. Statelessness is a strong answer to the provider question and no answer to the reader question.

Our LLM contract says no training and no retention. Is that equivalent?

Weaker. A contract governs by promise; a confidential VM governs by engineering. Both are about the provider. Neither changes what the model was handed, which is the layer an enterprise LLM contract alone cannot govern.

Can RedactSure run inside a customer’s own confidential VMs?

RedactSure deploys into the cloud environment the customer’s compliance posture requires, with core components in the customer’s account and keys the customer holds. The enclave is part of the deployment, and the render layer runs inside it.

What should we ask a vendor that says “confidential computing”?

Two questions, in order. Who holds the keys? And what did the model receive for one screen of our workflow? The first tells you whether the provider is out. The second tells you whether the agent ever held the record.

Does an AI Agent Need Its Own Virtual Machine? · Secure VM, Confidential VM, or Render Layer: Which One Decides What the AI Sees? · What Is Least Exposure? · What Is Render-Layer Tokenization? · On the RedactSure blog: Big Holes in Your Security Infrastructure in the Age of AI

Sources

Vendor documentation

  1. Meta AI Research, “How We Built Safety Into Muse: Security and Safety for AI Agents” (September 2026). https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
  2. Apple Security Engineering and Architecture, “Private Cloud Compute: A new frontier for AI privacy in the cloud.” https://security.apple.com/blog/private-cloud-compute/

Standards

  1. OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
  2. U.S. Department of Health and Human Services, Minimum Necessary Requirement, 45 CFR 164.502(b). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

RedactSure documents

  1. RedactSure, “The Two Gaps AI Agents Opened in Your Security Stack” (2026). https://redactsure.com/blog/two-gaps-ai-agents-opened-in-your-security-stack/
  2. RedactSure, “Big Holes in Your Security Infrastructure in the Age of AI” (2026). https://redactsure.com/blog/big-holes-in-your-security-infrastructure/
  3. Product behavior described on this page (enclave deployment with customer-held keys, render-layer tokenization, supervised approval) reflects RedactSure’s current design.

Bring your hardest questions.

A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.

Book a security review Book a demo · Something else

About the author

Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.