How do scope and metadata filters on agent memory reads prevent cross-user leakage?

## Why this is a retrieval problem and not just an access-control problem A memory store is queried by meaning. "Does this person have any allergies on file?" is close in embedding space to every allergy note ever written, for every patient, in every session. The store has no concept of who owns a row unless someone tells it. That makes memory retrieval a place where a conventional authorization mistake produces an unconventional consequence: the leaked data does not appear in an API response where a test might catch it, it appears inside a model's context, is paraphrased into an answer, and reaches the wrong person as fluent prose with no obvious provenance. The canonical incident shape is small: a clinic assistant retrieves an allergy note recorded under one patient while handling a different patient's booking, because the recall call carried the query but not the patient scope. Nothing crashed, nothing 500'd, and the only artefact is a sentence in a transcript. ## What scope actually means Scope is rarely one dimension. A production memory store usually partitions along several at once: - **Tenant or organization** — the hard boundary; crossing it is a reportable incident. - **User or subject** — whose memories these are, which for an assistant acting on behalf of staff is not the same as who is operating the agent. - **Session or thread** — scratch memories that should not outlive the conversation. - **Project, case or entity** — the working context, such as one patient file or one incident. - **Agent or role** — which agent in a multi-agent system may read this. And metadata beyond identity matters for the same reason: sensitivity class, source, consent state and retention flag all constrain what may be read into a given context even when the identity checks pass. A memory the user asked to be forgotten should be unreachable by every read path, not merely absent from the UI. ## The three rules that make the filter trustworthy **Bind scope from the session, not from the model.** This is the rule people get wrong when they move to agentic recall. Exposing `search_memory(query, user_id)` as a tool schema puts the security-critical parameter in the model's hands, where any injected instruction sitting in retrieved content or tool output can set it. The harness should accept only the query from the model and inject the scope itself from the authenticated request. If the agent legitimately needs to work across subjects, model that as an explicit, audited capability with its own allowlist, not as a free parameter. **Filter inside the search, not after it.** Pre-filtering — restricting the candidate set before ranking, or querying a per-tenant namespace or index — keeps foreign rows out of the result path entirely. Post-filtering fetches k globally and discards non-matching rows afterwards, which leaks into logs, traces and eval dumps, and quietly returns fewer than k useful results, tempting an engineer to raise k rather than fix the scope. Strong isolation goes further and gives each tenant its own namespace so a missing filter fails closed with no results rather than open with someone else's. **Make the shared tier explicit.** Almost every system has global material — policies, product facts, procedures — alongside per-user memories. Model that as a named scope the read explicitly opts into, so "which tier is this memory in?" is answerable, and so a write cannot land in the global tier by default. In practice the most common leak is not a broken filter at all: it is a memory extracted from one user's conversation and written to a shared or wrongly-keyed scope, after which every filter behaves correctly and the data is still in the wrong place. ## Multi-agent and tool-chain amplification Scope has to survive delegation. When an orchestrator spawns subagents, each must carry the same scope constraint, and a subagent's summary returned to the parent inherits whatever it read. A background or scheduled agent running without an interactive session is the classic hole: with no request context to bind from, someone hardcodes a broad scope and the job reads across users by construction. ## Proving it, not asserting it This is the part interviews reward. Seed **canary memories** — distinctive, synthetic facts under a known identity — and run assertions in CI that queries under every other identity, including adversarial ones that name the canary directly, return nothing. Add a runtime invariant: every read carries a scope key, and reads without one are rejected rather than defaulted. Log the scope on every retrieval so a transcript can be audited after the fact. And test the injection path explicitly, by planting content that instructs the agent to look up another subject and confirming the harness ignores it, because that is the failure the tool schema invites and the one a functional test will never find.