Google DeepMind described a new design for persistent Private AI Compute memory on September 23. The proposed system keeps encrypted memory on servers, holds the keys on a user's devices, decrypts data inside isolated hardware, and lets devices verify the server software before sending personal data. It is a useful reminder that "encrypted" is the start of a chatbot memory review, not the conclusion.
Before approving persistent memory, ask for these six proofs. A vendor that cannot answer them should not store account history, personal preferences, or support outcomes for later conversations.
| Claim to verify | Evidence to request | Weak answer |
|---|---|---|
| Memory is encrypted while stored | Key hierarchy, storage scope, and rotation policy | "We use AES-256" |
| Memory is protected while processed | Named trusted execution environment and threat model | "Our cloud is secure" |
| Only approved code receives keys | Remote-attestation flow and key-release policy | "Access is restricted" |
| Staff cannot casually read memory | Operator roles, break-glass path, and access logs | "Only engineers can access it" |
| Deletion reaches derived copies | Timelines for records, embeddings, summaries, caches, and backups | "Deleted within 30 days" |
| Customers can verify the controls | Attestation evidence, audit scope, and software-change record | "We are certified" |
Treat that table as the first procurement screen. The rest of this guide explains what a complete answer looks like and how to grade one vendor response.
Separate storage, transport, and processing
Chatbot memory moves through several states. A browser sends a message. The application extracts a fact or summary. A database stores it. A later request retrieves it, decrypts it, and places some of it into a model request. The system may then write an updated memory and send selected context to a help desk or analytics service.
Each security control protects a different part of that route.
Encryption at rest protects database files, disks, snapshots, and backups when they are not being processed. It limits damage from stolen media or an exposed storage layer. It does not prove that an administrator, application service, or compromised workload cannot ask the key service to decrypt a record.
Encryption in transit protects data moving between the widget, application, database, and model provider. TLS is necessary, but it says nothing about what each endpoint can read after the connection ends.
Encryption in use aims to protect data while code processes it. The NIST 2026 confidential-computing draft describes the core problem plainly: conventional systems expose data in memory during computation. Trusted execution environments can restrict access to authorized code and bind key release to evidence about the hardware and software state.
Ask the vendor to draw the memory path and mark where plaintext exists. Include the browser, API gateway, queue, application logs, model request, database, analytics pipeline, support export, and backup system. A secure enclave in the middle does not repair plaintext written to logs before the request reaches it.
Find out who can release the key
The phrase "customer-controlled encryption" hides several designs. They do not provide the same control.
With provider-managed encryption, the vendor owns the key service and the application identity that requests decryption. This is still useful. It separates encrypted storage from key storage and supports rotation. It may not prevent a privileged operator or compromised application from reading memory.
With tenant-managed keys, a business controls a key in its own cloud account or dedicated key manager. The vendor's workload may receive permission to use that key under a policy. Check whether the tenant can revoke access immediately, whether revocation stops cached keys, and what happens to live conversations when the key is unavailable.
With device-held keys, a user's phone or computer may decide whether a server workload receives a data-encryption key. Google's new design uses this model for personal memory. It can reduce provider access, but it also creates hard product questions. How does a user recover memory after losing every device? Can an authorized support agent view a conversation? How does a second device join? Which information remains available for abuse investigations?
No key model wins every case. A public website FAQ may not need persistent personal memory at all. An authenticated support assistant may need a tenant-controlled key and a tightly logged staff-access path. The review should name who owns each key, which identity may request it, what evidence the key service checks, how long plaintext or unwrapped keys stay in memory, and how revocation is tested.
Require proof of the running workload
A trusted execution environment isolates code and data from much of the host system. Remote attestation supplies evidence about what is running there. The relying party can check that evidence before it sends data or releases a key.
Google Cloud's attestation documentation separates the roles cleanly. An attester supplies evidence, a verifier evaluates it, and a relying party decides whether to trust the result. That last decision matters. An attestation token has little value if the key service accepts any genuine confidential machine instead of one approved workload version.
Ask four concrete questions:
- Which hardware and confidential-computing technology produce the evidence?
- Which software measurements, container digests, boot state, or security version does the policy allow?
- Who verifies the evidence, and can the customer validate it independently?
- What happens when a deployment changes the approved measurement?
Attestation proves identity and state against a policy. It does not prove that the approved application has no bugs, that its prompt is safe, or that its memory-selection logic is correct. Those properties still need code review, access tests, and a chatbot memory regression suite.
Software transparency makes attestation easier to inspect over time. Apple's Private Cloud Compute security guide documents a stateless design, public software measurements, restricted runtime access, and research tools. Its release transparency process lets a device check that an attested software release appears in an append-only public log before releasing a key. A chatbot vendor does not need to copy Apple's architecture, but "trust our enclave" is a much weaker answer than a verifiable workload identity and a record of approved releases.
Inspect every path around the enclave
Confidential computing narrows who can see data during one processing step. Persistent chatbot memory still has edges that may sit outside that boundary.
Review application logs for raw prompts, retrieved memories, model responses, and error payloads. Check crash dumps, traces, replay tools, quality-review queues, abuse-monitoring systems, and customer-support exports. Ask whether staff can run database queries against decrypted views or impersonate an application identity. If emergency access exists, require named approvers, a time limit, a reason, and an immutable event log.
Subprocessors need the same attention. A memory service may protect its own database, then send decrypted context to a model API or analytics product under different terms. Map which fields leave the protected environment and whether the receiving service retains them. The chatbot data residency checklist helps track locations and subprocessors, while the memory isolation test checks whether one customer can reach another customer's context. Neither control substitutes for the other.
Make deletion cover the derived memory
A conversation can create more than one retained object. There may be a raw transcript, a profile fact, a summary, an embedding, an evaluation sample, an abuse flag, a search index entry, and backup copies. Deleting only the visible conversation leaves useful derivatives behind.
Request a deletion map with an identifier for every copy, the system that owns it, and the maximum removal time. Ask how the vendor proves that deleted memory no longer influences retrieval. Then test the promise with a unique fixture. Store a harmless invented preference, confirm that the bot uses it, delete the conversation and profile memory, and probe for the fact through direct questions, paraphrases, and a fresh session.
Key destruction can make encrypted data unreadable quickly. It does not automatically remove plaintext exports, logs, cached values, or a summary encrypted under another key. Likewise, a backup expiry may be reasonable for disaster recovery, but the vendor should explain whether restored backups reapply deletion records before serving traffic.
Zero retention is a different product choice. If the use case does not need memory, the zero-data-retention review helps verify that the provider never keeps the request in the first place. Do not buy a complicated confidential-memory design to retain data that the workflow can discard.
Work through one vendor answer
Suppose a vendor sends this response:
All chatbot memory uses AES-256 at rest and TLS 1.3 in transit. We run on confidential virtual machines with per-tenant keys in our KMS. Production access is limited to authorized engineers. Customer data is deleted within 30 days of a request. Our platform has a current SOC 2 report.
The response establishes useful baseline controls, but it does not pass the six-proof screen.
The storage and transport claims are specific enough to request implementation evidence. The rest remains unresolved. "Confidential virtual machines" does not name the hardware, attested state, or key-release condition. Per-tenant keys do not reveal whether one global application identity can decrypt every tenant. "Authorized engineers" omits approval, duration, purpose, and audit records. The deletion statement does not cover summaries, embeddings, logs, caches, or backups. A SOC 2 report may test relevant controls, but the buyer needs the scope and exceptions rather than the logo.
A review record for this answer could look like this:
decision: hold confirmed: - encryption_at_rest - encryption_in_transit missing_evidence: - workload_identity_and_attestation_policy - key_release_scope_and_cache_lifetime - operator_break_glass_controls - derived_data_deletion_map - audit_scope_and_exceptions next_test: - revoke one tenant key and verify memory retrieval stops - delete a canary fact and probe every retrieval path
That is a useful procurement outcome. It does not accuse the vendor of weak security, and it does not turn incomplete evidence into approval.
Put the evidence into the contract
Once the technical review passes, preserve the exact controls that earned approval. Name the memory data classes, tenant boundary, key owner, approved processing environment, operator-access process, deletion times, audit evidence, and incident-notification duty. Record which changes require notice or a fresh review.
Pay special attention to silent substitutions. A vendor may move workloads to a different confidential-computing platform, change the key manager, add a logging processor, or replace a model endpoint without changing the dashboard's "encrypted" badge. The agreement should define which architectural changes reopen security review.
Match the depth of proof to the harm the memory can cause. Remembering a preferred documentation language is not the same as retaining health symptoms, payment disputes, account-recovery details, or an employee grievance. Start with the smallest memory scope that improves the conversation. Add stronger key control and verification before adding more sensitive facts.
Good chatbot memory encryption has an answer for the moment data is stored, moved, decrypted, inspected, changed, and deleted. The vendor should be able to show those answers with policies, logs, attestations, and test results. A lock icon cannot do that work.
No credit card required.
