An agent can retain useful memory while its provider has no ordinary access to the stored contents. A security team can also retain agent activity while the model provider holds no copy. September brought concrete proposals for both: Google's private server-side memory architecture and Anthropic's Enterprise Frontier Safeguards. Together they expose a problem with describing an agent as simply having “memory” or “zero retention.” Neither label says who can read which record, for what purpose, or for how long.

For agent discovery and verification, the useful unit is a particular record and its access conditions. A conversation, a remembered preference, a tool response and a security alert deserve separate answers. Our proposal is to describe those answers explicitly, and to keep the provider's declaration separate from evidence that an outside observer can verify.

Two architectures, different readers

Google's September 23 technical update describes encrypted persistent storage, keys held on personal devices, and temporary decryption within a protected cloud environment. It also describes a public record of server software that devices can check before releasing personal data. The announcement is forward-looking; it does not establish that every Gemini interaction already uses this memory path. Google Private AI Compute Team, September 23.

Anthropic's September 1 proposal addresses enterprise monitoring. EFS would allow activity records to reside in customer-controlled cloud storage, with automated monitoring and flags reviewed by the customer's own staff. Customer-owned storage, customer-managed encryption keys and automated review are individually optional. The announced rollout is phased, with broader availability targeted for the fall. Those choices require a deployment-specific description: the product name alone cannot establish which controls a customer enabled. Anthropic, September 1.

These are different services solving different problems. Comparing them as a privacy ranking would require a shared threat model and implementation evidence we do not have. The useful comparison is narrower: both separate the existence of persistent data from the provider's ordinary ability to inspect it.

Retention has a purpose

A third September announcement makes the distinction especially clear. Anthropic's Life Sciences Verification Program ties access to declared uses and monitors for activity outside that scope. Its launch documentation requires 30 days of retention for LSVP traffic and says integration with EFS features is being explored. It does not announce that EFS eliminates that requirement. Anthropic, September 17.

The architectural implication is that memory and monitoring need separate lifecycle policies. Removing a preference from an assistant's recall should have a defined effect on that preference's future use. It should also produce a separate answer about any record retained for investigation. Otherwise “forget this” becomes an ambiguous instruction: forget for generation, delete from primary storage, remove derived summaries, or expire every retained copy.

A specification could make these operations explicit without forcing the same retention period on every record. The important design choice is to identify the object being deleted and the purpose for which any remaining copy may be used. This is an infrastructure proposal, not a statement about the deletion behavior of either announced product.

A declaration a verifier could use

We would start with six fields for each class of retained data. These are proposed metadata, not fields standardized by A2A or MCP.

Field	Question it should answer
Record class	Is this conversation content, derived memory, tool output or a security event?
Purpose	Can it support future inference, incident review, or both?
Storage controller	Which party administers the storage and its access policy?
Readers	Which software and human roles can obtain plaintext, under which conditions?
Expiry and deletion	What ends retention, including derived copies and documented exceptions?
Evidence	Which deployment, configuration or attestation supports the declaration, and when was it checked?

The last field prevents a familiar measurement error. A public document can establish what a supplier promises. It cannot establish that a particular endpoint uses the promised configuration. Even a signed declaration authenticates the declaration; evidence about execution still needs its own scope.

A verifier should therefore publish two records: the declared policy and the observation supporting it. The observation might be a dated configuration review, a verified attestation or a controlled deletion experiment. Where no observation is available, the correct value is unknown. Turning an inaccessible control into a positive badge would erase the distinction the metadata was meant to preserve.

Delegation needs an explicit handoff

For an agent that calls another agent, we propose a further rule: state which retention policy applies to the information crossing that boundary. A caller's protected memory does not, by itself, establish the recipient's storage behavior. That follows directly from the scope of a local control: it governs the system implementing it.

A useful handoff record would identify the recipient, the selected data classes, the declared downstream purpose, and the policy version considered when the call was authorized. It should avoid copying sensitive payloads merely to document their transfer. Where a later audit needs contents, access and retention for that audit copy should be specified separately.

This creates a practical test for a registry: can it show the evidence behind a retention claim without collecting the private records that claim is meant to protect? Public declarations and evidence references can be discoverable while raw conversations remain with their authorized custodians. No crawl statistic can answer whether that custody was correctly enforced, so we do not attach a registry-wide privacy percentage to these announcements.

What we are watching

The next useful evidence is implementation detail: which configurations become available, what an attestation covers, how key loss and revocation affect access, and how deletion propagates to derived memory. For monitoring, we want a precise account of which records automated systems read and which records a human reviewer can obtain.

For agent infrastructure, the immediate work is smaller and achievable: give each retained record a purpose, a reader set and an evidence trail. That would make privacy claims comparable without pretending that every system should remember, forget or disclose the same things.

Sources

Advancing Private AI Compute with secure, server-side memory — Google Private AI Compute Team, September 23, 2026.
Developing Enterprise Frontier Safeguards with our customers — Anthropic, September 1, 2026.
Introducing the Life Sciences Verification Program — Anthropic, September 17, 2026.

Cite this post

@misc{hilbers2026agentmemorycustody,
  author = {Hilbers, Sebastiaan},
  title = {An agent can remember without its provider keeping the keys},
  year = {2026},
  month = sep,
  url = {https://agenstry.com/blog/agent-memory-custody-and-audit},
  publisher = {Agenstry}
}