Promises Aren’t Enough

Why “secure cloud AI” still isn’t confidential (and what privacy-by-design changes)

It’s 23:47.

A partner is reviewing a deal memo. A tax team is summarizing a client’s audit position. A general counsel is triaging a whistleblower report. The content is the kind of information that should not leak, not even “a little.”

And yet it often ends up in an AI tool that says it’s “enterprise-grade,” “SOC 2,” “encrypted,” and maybe even “zero data retention.”

Those are all good things.

They are also, very often, promises about behavior, not proof of confidentiality.

If you only read one section, read this:

• Compliance is not confidentiality. A system can be compliant and still expose plaintext to admins, logs, support workflows, and incidents.
• Encryption at rest and in transit is baseline. It does not solve “data in use,” meaning what happens while your prompt is being processed.
• “Zero retention” is usually contractual. Helpful, but it is still trust-based and rarely covers the full app stack.
• Classic cloud can be secure and well-run. It can also be non-confidential by design.
• Privacy-by-design changes the architecture. The goal is to reduce trust assumptions and make sensitive processing verifiable.

The uncomfortable distinction: compliant vs confidential

Most “security pages” are built to answer: Are you managing risk responsibly?

Confidential systems have to answer a tougher question:

Who can technically access plaintext?

Not “who is allowed,” not “who is trained,” not “who is audited.”

Who can, in principle, get to readable content?

If the honest answer includes “a cloud admin,” “support in an emergency,” “incident response,” “a logging pipeline,” or “a subprocessor,” then confidentiality is conditional. It depends on flawless operations, perfect configuration, and a world without incidents.

That can be compliant.

It is rarely truly confidential.

The market pattern: Security-Page Bingo

In legal AI and other high-sensitivity AI tools, we repeatedly see the same checklist:

• SOC 2 / ISO certifications
• Encryption in transit and at rest
• SSO (SAML), MFA, audit logs, IP allow lists
• Data residency controls
• “We don’t train on your data”
• “Zero data retention” (often framed as a contractual commitment with model providers)

You’ll find this posture across many tools that handle extremely sensitive information.

For example, vendors such as Harvey, Spellbook, and CoCounsel publicly describe enterprise controls, encryption at rest and in transit, and in some cases “zero retention” or “no training” commitments with third-party model providers in their security and trust documentation.

This is not a critique of intent or effort. It is the modern baseline.

The gap is structural:

Baseline security controls reduce risk. They do not create confidentiality.

How classic cloud architectures leak sensitive data (5 concrete scenarios)

Below are five ways sensitive content can leak in conventional cloud environments, even when vendors follow strong security practices.

1) The “it’s in the logs” leak

Most SaaS systems rely on extensive logging and monitoring to operate reliably. Over time, user content can appear in request metadata, error traces, or debug logs.

Even when teams try to prevent this, it often resurfaces during outages or incident investigations.

Why baseline controls don’t eliminate it: policies and reviews reduce risk, but logs are designed for visibility, not confidentiality.

What privacy-by-design changes: systems are built so that observability data is content-minimized by default, and sensitive processing occurs inside protected boundaries.

2) The “misconfiguration beats good intentions” leak

Major cloud providers openly describe security as a shared responsibility (see AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/ and Microsoft Azure Shared Responsibility: https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility). Customers and vendors configure identity, storage, permissions, and network access.

Industry guidance from government and cloud providers consistently shows that misconfiguration is a leading cause of cloud security incidents (for example, NSA and CISA cloud security guidance).

Why baseline controls don’t eliminate it: audits are periodic; configuration changes are continuous.

What privacy-by-design changes: even if control-plane access or storage is misconfigured, the data remains encrypted and unusable without access to protected execution environments.

3) The “support and ops need access” leak

Traditional SaaS assumes operational access. Support and engineering teams may need to inspect systems to diagnose issues.

Best-in-class vendors restrict, log, and review this access. But confidentiality still depends on governance rather than hard technical limits.

Why baseline controls don’t eliminate it: humans remain part of the trust boundary.

What privacy-by-design changes: provider access to plaintext is minimized or removed by default through architectural constraints.

4) The “subprocessors expand the attack surface” leak

AI platforms typically rely on subprocessors: cloud infrastructure, storage, observability tooling, and model providers.

Some vendors highlight contractual “zero data retention” commitments with LLM providers (for example, Spellbook’s ZDR statements and Microsoft/OpenAI enterprise documentation: https://www.spellbook.legal/security and https://openai.com/enterprise-privacy/). These can reduce risk at the model layer but do not eliminate exposure across the rest of the application stack.

Why baseline controls don’t eliminate it: contracts are promises; architecture determines exposure.

What privacy-by-design changes: sensitive data is isolated inside protected environments and shared with third parties only in encrypted or strictly limited form.

5) The “incident response snapshot” leak

During security incidents, teams often collect detailed forensic data: memory snapshots, full request traces, or system dumps.

These artifacts are useful for response and recovery, but they can also contain sensitive content.

Why baseline controls don’t eliminate it: incident response often increases data access at exactly the wrong moment.

What privacy-by-design changes: systems are designed so that investigation and audit rely on verifiable records rather than raw content access.

About “zero data retention”: useful, but still a promise

Many AI vendors emphasize “zero data retention” in their security materials, especially regarding third-party model providers.

In practice, these statements typically mean:

• data is not stored by the model provider beyond processing
• the commitment is contractual and scoped
• other parts of the application may still retain content or derivatives

Zero retention can meaningfully reduce risk.

It does not, by itself, create confidentiality.

What privacy-by-design changes: from trust to verification

Privacy-by-design is an architectural approach, not a policy.

It focuses on:

1. minimizing trust in people and processes
2. minimizing where plaintext can exist
3. protecting data while it is being processed
4. making system behavior verifiable
5. enabling audits without exposing customer content

Tresor’s approach (high level)

Tresor is built as a confidential AI workspace for professional teams that handle sensitive information, drawing on publicly documented approaches such as confidential computing (for example: Google Confidential Computing overview: https://cloud.google.com/confidential-computing and Microsoft Azure Confidential Computing: https://learn.microsoft.com/azure/confidential-computing).

Instead of relying primarily on policies and contracts, Tresor treats confidentiality as an infrastructure problem:

• sensitive processing occurs inside protected compute environments (confidential computing)
• the control plane is designed to operate without needing readable content
• access to keys and plaintext is tightly scoped and time-limited
• system behavior can be verified through cryptographic evidence rather than trust claims

For technical readers, this includes concepts such as trusted execution environments, remote attestation, end-to-end encryption, and signed verification records.

The key idea is simple: replace promises with enforceable boundaries and verifiable behavior.

Mini-case: an accounting and tax advisory firm

Consider a mid-sized accounting and tax advisory firm using AI to summarize client files, draft internal memos, and answer cross-year questions.

In a conventional cloud AI setup, confidentiality depends on:

• correct configuration
• strict internal access controls
• clean logging practices
• smooth incident handling

In a privacy-by-design setup, confidentiality depends primarily on architecture:

• plaintext is constrained to protected environments
• storage and routing layers handle encrypted data
• audits rely on verification records, not content access

The difference is not zero risk versus some risk.

It is governance-first risk versus architecture-first risk reduction.

Classic secure cloud AI vs privacy-by-design AI

A practical buyer checklist

When evaluating AI tools for confidentiality-bound work, ask:

1. Who can technically access plaintext?
2. Where does decryption occur?
3. How is data in use protected?
4. What exactly does “zero retention” cover?
5. What data is stored long-term?
6. What changes during incident response?
7. Can system behavior be independently verified?
8. How does access control scale across teams and projects?

Closing: security pages are not confidentiality

Certifications, encryption, and good governance matter.

But for work involving client confidentiality, trade secrets, or regulated information, promises are not enough.

Confidentiality is not a badge.

It is an architecture.

If you want to understand how Tresor approaches confidentiality-by-design, evaluate it the same way you would any other system: by asking where plaintext exists, how processing is protected, and what evidence you can verify.