erasure-proof: provable crypto-erasure for agent memory

The same signed proof verifying offline on an iPhone and an Android phone, airplane mode on, no server involved.
Durability: a database node is killed mid-run. The committed erasure state is read back from the surviving replicas, 3 of 3 runs.
The premise: deleting the row leaves the embedding, and the embedding still names the person.
The leak, live on a Modal T4: Vec2Text rebuilds the subject's name from the stored vector alone.
The proof verified in the judge's own browser: ECDSA P-256 over the exact signed bytes.
The erasure: one SERIALIZABLE transaction destroys the key, purges the vector, appends the decision log. The same search now returns 0 rows.
Stage 1, live: a real memory stored encrypted per subject, retrieved again through the C-SPANN vector index at distance 0.0000.
A live AI forensics agent returns PROVEN from three real read-only tool calls, toned by evidence not prose.

Inspiration

I stored one sentence about myself in an agent's memory: my own bio line. Then I deleted the database row and pointed Vec2Text (arXiv:2310.06816) at the embedding that was still sitting in the vector column. It typed my name back at me.

That is the gap this project closes. Two laws now pull agent memory in opposite directions: GDPR Article 17 says a person can demand erasure, and the EU AI Act's Article 19 logging obligations (enforceable August 2, 2026, sixteen days before this hackathon's deadline) say the decision trail must be retained. Deleting rows satisfies neither: the embedding is still reconstructible, and the audit trail is gone.

What it does

erasure-proof is compliance infrastructure for agent memory, built on CockroachDB and AWS. When an erasure request arrives, one SERIALIZABLE transaction does three things atomically: destroys the per-subject encryption key (crypto-shredding: the ciphertext and the embedding become permanently undecryptable, per NIST SP 800-88 Rev. 2 cryptographic erase), retains a pseudonymized, hash-chained decision-log entry, and nulls the live vector. The transaction then anchors an ECDSA P-256 proof, signed inside AWS KMS, to S3 Object Lock in COMPLIANCE mode, where nobody, including us, can delete it.

The judge-facing console walks the whole loop live in six stages: store a real memory, watch Vec2Text recover the name from the live embedding (the leak, on a real GPU), inspect the envelope encryption, crypto-erase, survive a node kill on real Raft, and verify the signed proof in the browser over the exact stored bytes.

A live AI forensics agent runs a tool-use loop over four read-only forensic tools and returns a PROVEN / NOT PROVEN verdict with its full evidence trace; the server tones the verdict from the tool outputs, never from the model's prose. The same proof verifies fully offline on a phone: TestFlight for iOS, a signed APK for Android, pure-JS P-256, airplane mode on.

How we built it

CockroachDB is the memory layer, and it earns the position. The erasure is the reason: destroy-and-retain has to commit atomically, and a fragmented stack (a SQL database plus a separate vector store) cannot destroy an embedding and retain a log in one transaction. Four CockroachDB tools do real work:

Distributed Vector Indexing (C-SPANN): the live GTR-base 768-dim embedding is indexed with a subject_id prefix. The console runs the identical similarity search before and after erasure, live: it finds the memory at distance 0.0000, then returns 0 rows once the vector is destroyed, and it prints the database's own EXPLAIN plan line naming the index whenever the index is in the chosen plan. Managed MCP Server: the independent verification path. A least-privilege service account reads the decision-log chain head through cockroachlabs.cloud/mcp, so a verifier does not have to trust our API layer. This runs as a nightly CI gate. ccloud CLI service-account RBAC: three distinct denial boundaries, live: a control-plane 403, the MCP-layer tool check, and SQLSTATE 42501 from the database itself when the agent role tries to tamper with the append-only log. Agent Skills: a spec-conformant skill teaching any MCP-compatible agent the destroy-and-retain pattern.

AWS is load-bearing, not garnish: KMS envelope encryption with the subject bound as encryption context (enforced in IAM), KMS asymmetric signing so the proof key never exists in a process, S3 Object Lock COMPLIANCE anchoring, ECS Fargate + CloudFront serving the whole thing. Three separated IAM principals: no single credential can both destroy keys and touch the anchored proofs.

The agent inference story is honest: a new AWS account ships with a zero Bedrock quota. The Bedrock integration is wired and IAM-scoped, and the organizers pointed teams at open models as the workaround, so the live agents run on Qwen2.5-3B via llama.cpp on a serverless GPU behind the same interface, and every on-screen verdict labels which provider answered. If the pending quota lands, Bedrock becomes primary with zero code change.

Challenges we ran into

CloudFront's origin timeout versus a scale-to-zero GPU. The first live audit died at CloudFront's 30-second guillotine while the model container was still booting. The fix keeps the cold start out of the audit entirely: the page starts warming the GPU the moment it loads, the run button holds behind an honest "warming" note, and the audit always runs warm. The same ceiling, found a second time, by filming. While capturing the demo video we clicked the live-inversion button as a judge would and got a 504 at 60.17 seconds: a real GPU inversion takes one to two and a half minutes, and 60 seconds is CloudFront's maximum origin read timeout without a quota increase. Raising the timeout was not enough, so the endpoint became start-then-poll: the POST starts a single-flight background job bound to its exact embedding, and the browser polls a short status endpoint. An adversarial review of that fix caught a case where a second subject's poll could have been answered with the first subject's inversion, which is now refused rather than coalesced. Making the film was itself a QA pass on the judge path. C-SPANN's prefix rule. Any non-prefix filter, even embedding IS NOT NULL, silently disqualifies index acceleration. We proved it empirically, filed it in our tools feedback, and query on the prefix column only. COMPLIANCE mode has no undo. A mistakenly long retention is unremovable and billed, so retention decisions are human-only in our runbook, and the dev environment stays on GOVERNANCE. Claims drift. We ran a three-way audit of every number and claim on every judge-facing surface against the shipped code, found twelve stale or unevidenced statements, and fixed them with committed transcripts (the cluster version, the concurrency run, the retry-budget constant read from the library source).

Accomplishments we're proud of

The full six-stage loop runs live on a public deployment, on real data, with zero mock responses on the judged path. A gapless, hash-intact decision chain under 50-way concurrent erasure, with the honest ceiling documented: at ~100-way, the retry budget exhausts, and we say so. Proofs that verify in three places that do not trust each other: the browser, an offline phone, and the Managed MCP path. Ten CI jobs on every push, a nightly node-kill gate (3/3 must survive), and a nightly cloud-verification gate through the Managed MCP. Every capability on the trust page carries an honest tier, including what is recorded and why.

What we learned

Serializable isolation is what makes destroy-and-retain provable; everything else is commentary. The embedding, not the row, is the personal data. And honesty is an engineering discipline: the trust page, the struck-claims list, and the audit transcripts cost us nothing compared to what one overclaim would cost in front of a distributed-systems judge.

What's next

Bedrock as primary when the quota clears, REGIONAL BY ROW geo-domiciling on a multi-region cluster (built and verified locally, not enabled on the single-region demo), and contributing the Agent Skill upstream through the proposal-first process.