Agent Memory Is One Forgotten Filter Away From a Leak

Give an AI agent long-term memory and the easy design is one shared vector table for every customer. Ownership becomes a column, and the boundary becomes a WHERE clause that every code path has to remember to write. Most paths will. The one that doesn't is a secondary endpoint somebody added on a Friday, and it hands Customer A's notes to Customer B with full confidence.

That failure class is already showing up in AI features. In June 2025, Asana found a flaw in the MCP server it had launched for AI tools that could expose data from one organization to users in others. Asana contacted the affected organizations directly and kept the server offline from 5 to 17 June (The Register, BleepingComputer).

To be fair to the other side: that wasn't an agent's long-term memory leaking, and I don't know of a public incident where one has. But the shape is the same, a tenant boundary that lived in application logic. Agent memory is where that shape is heading next, because memory is exactly the data an agent pulls into an answer without anyone looking.

What I built

On 15 November I submitted MemShield to Startup Buildathon India 2026, run by Google DeepMind and Google Cloud with H2S, nasscom and Headstart. I entered alone, in the Open Innovation challenge, at MVP stage, and the results aren't out yet. MemShield is two open-source libraries, both Apache-2.0 and on PyPI.

adk-memshield is a drop-in memory service for Google ADK on PostgreSQL and pgvector. The table has FORCE ROW LEVEL SECURITY, the app connects through a role that cannot bypass it, and the caller's tenant, user and clearance are bound per transaction. Even a query with no WHERE clause returns only rows the caller is allowed to read. Agents of different clearance share one pool, and the policies stop both reading up and writing up.

adk-leak-arena is the proof. It runs two real ADK agents side by side on the same canary-laced data, one on an unprotected pgvector table with application filters and one on adk-memshield, across six scenarios plus a benign control (54 queries in all, 40 of them cross-boundary attacks), with the SQL and RLS state shown for every answer. It was one of 10 projects picked at GDG Cloud Bengaluru's FORK. BUILD. MERGE. at Google Ananta.

The number I'm careful with: when the app filter had one of 5 common mistakes, 97.5% of attack queries returned a row the caller may not read in our open synthetic benchmark (39 of 40). With MemShield it was 0 of 40, and authorized recall went from 86.4% to 100%, because rows the caller may not read stopped crowding out the caller's own. The dataset is small and synthetic, so read that as a reproducible failure mode, not a real-world leak rate. The MVP is verified end to end with Gemma 3 (4B) running locally, and 53 automated tests back it.

Why the database and not the app

My opinion is simple: put the boundary at the one layer every query has to pass through. Application code has many doors. The database has one.

A WHERE clause is a note on the shared fridge asking people not to eat your lunch. Row-level security is the lock. The note works right up until someone is hungry, in a hurry, or new.

The fair point is that RLS is not magic either. A superuser or a key with BYPASSRLS walks straight past it, so the role matters as much as the policy. Identity has to come from a verified login token, never from the prompt. At large scale with an approximate index, filtering happens after the index scan, and I haven't benchmarked that yet, so I make no claims there. The opinion still stands, because each of those is one thing to get right in one place, instead of a filter to remember on every path.

What I'm building next with Gemini (planned, not built)

None of this exists yet, and I'll label it that way until it does:

• Memory Guard: a Gemini Flash model screens every memory as it's written, for personal data, the right clearance and injected instructions. It can only block or down-label a memory. It can never grant access, so the database policy stays the authority.
• A Gemini red-team and leak judge: a planner model reads an agent's tools and schema and designs multi-turn attacks, and a judge catches paraphrased leaks that exact canary matching misses.
• Gemma for teams whose data can't leave: the guard and the judge running inside a bank's or a hospital's own network.

LeakArena already has a Gemini API engine, but I haven't recorded a Gemini run yet. Today's numbers were reproduced end to end with Gemma 3 (4B). I also see this as complementary to managed options like Vertex AI Memory Bank, not a replacement: the plan is for LeakArena to test any memory backend, and adk-memshield is for teams that keep their data in their own PostgreSQL.

The ask: a free agent-memory leak audit

I'm looking for a few design partners. If you run AI agents on Google ADK with long-term memory over more than one customer's or user's data, I'll run LeakArena against your agent with canary data, only with your written authorization, and give you a written report of what leaked, for free. On another backend? Tell me which, and I'll tell you honestly whether LeakArena can test it yet. As a team of one, I'm also the entire sales department, so this paragraph is me doing my job. You get evidence about your own system. I get to learn where real setups break, which a synthetic benchmark can't teach me.

Comment here or message me on LinkedIn. And if you're building agent memory yourself, write down where your tenant boundary actually lives. If the answer is "in every query we remember to filter," it's worth moving.