Encryption at rest protects storage. TLS protects transport. Sensitive tenant analytics and AI features still need plaintext during computation. Confidential computing changes who must be trusted while that processing happens.
The Confidential Computing Consortium defines confidential computing as protecting data in use by performing computation in a hardware-based, attested Trusted Execution Environment. The TEE can isolate code and memory from other workloads and, depending on the technology, privileged host software. That is useful when a SaaS customer does not want cloud administrators, host operators, or compromised infrastructure to see sensitive processing.
It does not make unsafe application code safe. If the measured workload contains a broken tenant filter, logs plaintext, sends prompts to an external endpoint, or returns individual records in an aggregate report, the TEE faithfully protects and runs the wrong behavior. Authentication, authorization, tenant scoping, minimization, and output controls remain application responsibilities.
Remote attestation lets a verifier evaluate evidence about a workload and platform before a relying party trusts it. RFC 9334 provides a processor-neutral architecture for attesters, verifiers, evidence, claims, and relying parties. In practice, a key broker or KMS should release a tenant data key only when fresh evidence matches approved reference values and workload policy.
A shared enclave processing many tenants can become a new concentration of risk. Keep tenant data keys separate and require policy evaluation for every release. Bind authority to tenant, dataset, purpose, workload measurement, model or query version, region, time window, and output class. A valid TEE should not automatically receive every tenant key.
Cross-tenant analytics require explicit semantics. Define minimum cohort size, permitted dimensions, differential privacy or suppression rules where appropriate, and checks against reconstruction. If the output can expose one tenant through another tenant's query, memory encryption did not solve the privacy problem.
| Threat or failure | What the TEE can help with | What still needs application or operational control | Evidence to retain |
|---|---|---|---|
| Malicious or compromised host operator | Protect workload memory and measured execution from host access within the platform threat model. | Choose the correct TEE mode, validate claims, patch firmware, and avoid plaintext host I/O. | Attestation claims, TCB version, endorsements, policy decision, and key-release log. |
| Cross-tenant application bug | Nothing if the approved workload itself reads the wrong tenant data. | Tenant-aware queries, object authorization, per-tenant keys, tests, and post-query output checks. | Tenant context, query plan, authorization result, rows or partitions touched, and output policy. |
| Compromised workload image | Attestation can identify that measurements differ from approved reference values. | Signed builds, reproducible images, vulnerability management, revocation, and deny-by-default key release. | Image digest, SBOM, signer, deployment, reference value, and rejection reason. |
| Side channel or exposed I/O | Some TEEs reduce direct memory access; protections vary by technology and configuration. | Threat modeling, constant-time code where needed, traffic shaping, encrypted channels, and metadata minimization. | Platform capability, mitigations enabled, residual risk acceptance, and monitoring. |
| Sensitive model output | The computation can remain isolated while running. | Prompt and retrieval policy, output filtering, aggregation, recipient authorization, and leakage tests. | Model version, sources, output class, disclosure checks, recipient, and approval. |
| Debugging or operational fallback | TEE may deliberately restrict introspection and dumps. | Sanitized telemetry, synthetic replay, break-glass policy, fail-closed key release, and recovery design. | Attested version, failure code, operator action, exception approval, and secret lifecycle. |
Whole-VM confidential computing improves compatibility but increases the trusted computing base. Smaller enclaves can reduce trusted code but increase integration complexity. Choose the boundary from the threat model, not from a product checkbox. Every library, model runtime, plugin, certificate bundle, and configuration inside the measurement may affect both risk and deployability.
Operational visibility must be designed in. Avoid plaintext logs and crash dumps. Emit structured, tenant-safe metrics and encrypted diagnostics. Correlate attestation, key release, job, dataset, model, and output IDs without placing secrets in telemetry. Plan for patching because firmware or image updates change measurements and can block key release until reference values and policies are updated safely.
Running inference inside a TEE can protect prompts, retrieved tenant data, embeddings, and model weights from infrastructure access. The protection ends if the workload sends that data to an untrusted model API, plugin, telemetry collector, or callback. Network destinations, protocols, DNS, certificates, and response handling belong in the attested workload policy.
For multi-party analytics, an attested environment can let separate data owners contribute encrypted inputs without giving one participant raw access to another's data. Google Confidential Space describes this pattern directly. The harder question remains what result each party is permitted to learn.
I would build a confidential analytics service with per-tenant envelope encryption, an external attestation verifier, a policy-driven key broker, signed workload images, immutable reference values, and an output gateway. Jobs would declare tenant, dataset, purpose, code or model version, expected output class, retention, and recipient before scheduling.
The operations view would show attestation health, TCB and image versions, key-release decisions, tenant workload scope, output-policy results, failed measurements, capacity, latency, and workloads blocked by patch or revocation.
Confidential computing should turn infrastructure trust into verifiable workload trust. Attest before releasing keys, scope every release to a tenant and purpose, minimize the trusted boundary, control outputs as strictly as inputs, and treat operational evidence as part of the security design.
Article about confidential computing for multi-tenant SaaS data using TEEs, remote attestation, tenant-scoped key release, confidential analytics, output controls, and operational evidence.