On 18 February 2026 the European Data Protection Board published the results of a year-long coordinated action on the right to erasure. Thirty-two data protection authorities took part, 764 controllers responded, and nine authorities opened or continued formal investigations. Among the seven recurring problems the report names is a specific one: some controllers rely on "inefficient anonymisation techniques to handle erasure requests as an alternative to deletion."

Four months later, unrelated research put a number on the gap. For the storage layer that agentic systems are built on, a deletion request can leave enough behind to reconstruct a person's name.

AI agent data deletion is the problem of removing a person's data from an agentic system after that data has been transformed. A deletion request arrives naming a person. The system holds that person as a source row, an embedding in a retrieval index, a span in a trace store, a checkpoint in a paused workflow, and a sentence in a summary written by another agent. Only the first of those has a primary key to delete on.

The record has a key. The derivative does not.

Article 17 was drafted against a mental model of data as records. A record has an identifier, a location, and a lifecycle. Erasure is a DELETE against that identifier, and the difficulty is organisational — knowing which systems hold the record and getting them to act.

An agent pipeline breaks that model at ingestion. The moment a support ticket is embedded for retrieval, the person in it stops being a row and becomes a float array whose link to the original identifier survives only if somebody built and maintained a provenance map. Nothing about the embedding announces whose data it encodes. It is not indexed by customer ID. It is indexed by proximity in a space with no semantics a compliance team can query.

The same transformation happens several more times downstream, producing artifacts with the same property. A trace span carries the argument values of a tool call. A durable checkpoint carries the context needed to resume a paused workflow, which is the point of checkpointing. A summarisation step writes a compressed restatement of a conversation into another agent's memory. A prompt cache holds the last several thousand tokens of whatever was in the window.

The architectural failure is not that these stores are hard to delete from. It is that erasure is designed as an operation on the thing that has the key, and the copies that matter are the ones that do not.

Soft delete is the default primitive, and vendors document it as such

The layer underneath makes this worse in a way that is entirely intentional and openly published.

Qdrant's own optimizer documentation is explicit: "Like many other databases, Qdrant does not delete entries immediately after a query. Instead, it marks records as deleted and ignores them for future queries." The docs give the reason — minimising disk access, the slowest operation in the system — and describe the Vacuum Optimizer that eventually rebuilds a segment. The example configuration sets deleted_threshold: 0.2, meaning a segment carries deleted records until roughly a fifth of it is tombstoned.

This is good database engineering. It is also the exact gap between what an API call reports and what remains on disk. A deletion endpoint that returns success is describing the index's read behaviour, not the state of the bytes. For a storage engine built this way, "deleted" is a query-time property until compaction runs — and compaction runs on a schedule tuned for throughput, not for a regulator's clock.

What the researchers actually recovered

In Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases (arXiv:2606.18497, 16 June 2026), Chakraborttii and colleagues tested that gap directly. Analysing three HNSW implementations, they confirm that deleted vectors remain physically recoverable by reading the raw index files at the storage layer, bypassing API access entirely.

They then inverted them. Using the Vec2Text inversion model with no domain-specific fine-tuning, the study reports recovery of 25.5% of exact person names and 46.4% of geographic locations from a Wikipedia biographies-of-living-persons dataset. On the more structured NIH Synthea data, recovery of patient age and gender markers reached 100%. On soft-deleted image embeddings, top-1 identity recovery on facial embeddings reached 99%.

Two caveats belong on those numbers: they are a research result on selected public datasets rather than a production measurement, and the paper is marked as prepared for submission rather than peer-reviewed. What survives both is the mechanism — an off-the-shelf inversion model, applied to data the system reported as deleted, reading files the API said were gone.

The paper's proposed fix is the architecturally honest one. Epoch Key Rotation encrypts vectors and discards the key on deletion, which the authors report drops observed PII recovery to 0% in 2.5 ms for 500 vectors, with an ECDSA-signed proof of the deletion event. Note what that design concedes: erasure at the derived layer is tractable only if it was planned for before the data was written.

The platforms already tell you this

The vendors closest to the problem have arrived at the same conclusion, and they say so in their own documentation.

Amazon Bedrock exposes dataDeletionPolicy on a knowledge base data source, with valid values RETAIN and DELETE, and the field is optional. Whether the derived embeddings survive the removal of their source is therefore a deployment-time decision, made once by whoever wrote the infrastructure module, and invisible from the deletion request that arrives eighteen months later.

Arize documents a well-specified deletion path for its trace store — a GraphQL deleteData mutation, a Python toolkit, a REST API for deleting spans by ID, plus guidance on confirming the deletion and recording it for audit. And its guidance on preventing recurrence is two lines, the first of which is: "Redact or hash PII in your upstream pipelines before logging." The second is to alert on unexpected inputs.

That first line is the recommendation of a vendor with a working delete API, and it is worth reading twice. A delete API reaches the store its vendor operates. A personal-data item in an agent system is rarely in one store.

One practitioner describes the same shape from the other direction. The author of Mnemory, an open-source memory layer posted to Hacker News in 2026, put the design problem this way: "durable facts and short-lived context need different treatment, but many systems collapse everything into one retrieval bucket." One bucket means one retention policy for data held under quite different lawful bases — which is what makes a targeted erasure request impossible to satisfy without deleting much that should have stayed.

Ungoverned versus governed

An ungoverned pipeline handles an erasure request by deleting the source row, calling the vector store's delete endpoint, and closing the ticket. The controller can produce a log line showing the request was actioned. The embedding stays on disk until an optimizer decides otherwise; the trace span still holds the argument values; the checkpoint still holds the context. On the datasets Ghost Vectors tested, storage-layer file access to an index in that state produced a quarter of the exact names in it and a 99% top-1 identity match on face embeddings. That is masking substituting for deletion — the pattern the EDPB report names — at machine scale.

A governed pipeline moves the control earlier. Personal data that never entered the embedding cannot be inverted out of it. An argument value redacted before the span was written cannot be recovered from the trace store. A retention window that expired on schedule leaves nothing for the optimizer to be late about. Prevention at write time is not a stronger version of deletion at read time. It is a different control, and it reaches artifacts that have no key to delete on.

How Waxell handles this

Waxell Observe's Content policy category is written for that write-time boundary. Its published description is direct: block PII, detect prompt injection, and redact sensitive data before it leaves your stack. Content is one of 50+ policy categories published for Observe, and the SDK auto-instruments 200+ Python frameworks, LLMs and vector DBs — including the vector stores where the embeddings in question are written.

The Waxell MCP Gateway applies the same principle to tool calls agents make against systems Waxell did not build. Its audit log records what happened — the resolved identity, the decision, the rules that fired — without retaining the argument values or result bodies that passed through, with sensitive content handled by the redaction pipeline. That separation is the practical answer in an audit context: the artifact proving a tool call happened outlives the personal data that was in it, because the personal data was never written to the log.

One scope note, because it matters for planning. The gateway governs the calls that traverse it. An agent holding a direct upstream credential, or a locally registered MCP server, sits outside that path, and a redaction control at the gateway does nothing for data those calls write. Coverage here is a configuration property, not a guarantee. On the free plan, data retention runs 14 days — worth knowing, since retention periods are one of the difficulties the EDPB report singles out.

FAQ

Does deleting a record from a vector database delete the embedding?

Not necessarily, and often not immediately. Several vector databases mark records as deleted and exclude them from query results while leaving the bytes on disk until a compaction pass rebuilds the segment. Qdrant documents this directly, with a configurable threshold for when its Vacuum Optimizer runs. The delete API reports a change in read behaviour; whether the physical state of the index has changed is a separate question, and depends on the engine.

Can personal data be reconstructed from an embedding?

Published research says yes, under conditions that do not require an unusually capable attacker. The Ghost Vectors study applied the Vec2Text inversion model, with no domain-specific fine-tuning, to soft-deleted vectors and recovered a quarter of exact person names on one public dataset and 99% top-1 identity on face embeddings. Those are research figures on selected datasets, not production measurements, but the technique itself is off the shelf.

Does GDPR Article 17 apply to embeddings and traces?

Article 17 applies to personal data, not to a particular storage format. If an embedding, trace span or checkpoint relates to an identifiable person, it is in scope. The EDPB's February 2026 coordinated enforcement report identifies reliance on inefficient anonymisation as an alternative to deletion as a recurring failure, and flags retention periods and deletion from backups as persistent difficulties. Teams should take their own legal advice on how this applies to a specific architecture.

What is the practical control if deletion at the storage layer is unreliable?

Move the control to write time. Redacting or tokenising personal data before it is embedded, traced or checkpointed keeps it out of the downstream artifacts, because they never contained it. Where the data must be stored, the alternatives are cryptographic erasure — encrypting per record and discarding the key, the approach the Ghost Vectors authors propose — and short, enforced retention windows, so deletion runs on a schedule rather than on request.

How should teams inventory where agent data ends up?

Start from the write paths rather than the stores. For each point where an agent writes, ask what it persists, under what retention period, and whether a deletion request can address it by identifier. Retrieval indexes, trace stores, workflow checkpoints, agent memory, prompt caches and derived summaries are the usual set. Systematic data classification and automated deletion labelling are inventory problems before they are deletion problems.

Sources

• European Data Protection Board, "EDPB identifies challenges hindering the full implementation of the right to erasure", 18 February 2026

• European Data Protection Board, "CEF Report 2025 — Right to Erasure", February 2026

• Chandranil Chakraborttii, Jackeline García Alvarado, Sitora Abdulofizova, Shivanshu Dwivedi, "Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases", arXiv:2606.18497, 16 June 2026

• Qdrant, "Optimizer", documentation, accessed 10 August 2026

• Amazon Web Services, "DataSource — Amazon Bedrock API Reference", accessed 10 August 2026

• Arize AI, "Delete Traces with Sensitive Data", Arize AX documentation, accessed 10 August 2026

• Hacker News, "Mnemory – Persistent memory for AI agents", 2026

Related reading: AI Agent PII Protection: 3 Vectors to Stop.

Erasure requests will keep arriving, and they will keep naming people rather than artifacts. The teams that can answer them are the ones that decided what never gets written.

Start free with Waxell Observe and one governed MCP upstream at waxell.dev/signup, and see what your agents are persisting before someone asks you to delete it.