Residency, deletion, and choosing an architecture

Lesson 5 of 5 in Multi-Tenant Isolation: One Platform, Many Customers, Zero Bleed.

Here is the compliance angle, honestly and in one paragraph, because the legal detail belongs with your counsel and the engineering consequence belongs with you. Your customer contracts will make three kinds of promise about their data: where it lives (residency — a region, sometimes a specific country, sometimes their own subscription or account), who can reach it (access control, subprocessor lists, and your internal debugging practices), and that it can be deleted on request (erasure rights under GDPR-style regimes, and plain contractual deletion). Agents complicate all three, because agents derive new data: a summary of a customer’s call, an extracted preference, a trace containing a verbatim document, an embedding of a personnel file. Those derivatives are still that person’s personal data, and they live in stores your data-map probably has not caught up with.

The engineering rule that follows is short: agent memory is personal data, and so are traces, embeddings, caches, and session volumes. A deletion pipeline that only clears the primary database is not a deletion pipeline. See foundations/agent-memory for what actually gets stored and why extraction produces derivatives you never explicitly wrote.

The deletion request that stopped at the database

When a tenant asks you to delete a user, the work is a sweep across every store that ever held a derivative. At minimum: raw interaction events; extracted long-term memory records and the vector embeddings built from them; conversation history; uploaded files and any resumable session filesystem or persistent volume; traces, spans, and logs that captured message content; prompt, semantic, and retrieval caches; eval datasets and golden sets built from real traffic; and backups.

Two agent-specific traps. First, asynchronous extraction: AWS documents that AgentCore long-term memory extraction is asynchronous, with a delay between event ingestion and record availability — so a deletion that races an in-flight extraction can be followed by a new record about the person you just erased. Sequence it: stop new writes for that subject, wait out the extraction window, delete, then re-verify. Second, the store you forgot is the one you cannot prove. Keep a machine-readable registry of every store, its tenant-key shape, and its deletion API, and make the deletion job iterate that registry — so adding a cache means adding a row, not remembering a conversation. Then re-query as the tenant to prove the sweep worked, and write down honestly what you cannot delete inside the promised window, backups included, before it appears in a contract.

Where does our data live? (residency)

Answerable only per store, so enumerate them: model inference, memory, vector index, object storage, traces, and caches can each sit in a different region if nobody checked. Managed agent platforms are region-scoped services with expanding footprints — AgentCore reached general availability in nine AWS Regions in October 2025 and added GovCloud (US-West) in May 2026, and Foundry’s Standard setup keeps conversation history, files, and vector data in your own Storage, AI Search, and Cosmos DB resources, which you place. The honest answer names a region per store and states which components are pinned by configuration versus by account creation.

Can you delete everything about one of our users?

Say yes only if a job you can run today walks a registry of stores and returns a report. The parts to disclose without being asked: derivative data (summaries, extracted memory, embeddings), telemetry retention, and backup windows. “We delete within N days, except backups which age out within M days” is a credible answer; “our database has a delete endpoint” is not.

Who at your company can read our conversations?

In most platforms the widest internal access is not the database — it is observability. If any engineer can grep a shared trace store containing full prompts and tool payloads, that is your real answer, whatever the access-control diagram says. Managed platforms make content capture opt-in for this reason: Microsoft documents chat-message-content recording in traces as opt-in because it may contain personal data. Default to redaction, scope trace access per tenant, and make cross-tenant queries privileged and audited.

Is our data isolated from your other customers?

Answer at each layer rather than in one word — session, memory, credentials, egress, observability — and say which boundary is enforced by the platform, which by your configuration, and how you test it. Customers with security teams find layer-by-layer answers reassuring precisely because they are checkable; a one-word yes invites the questionnaire that finds the cache.

Choose an isolation architecture

Interactive decision tree — outcomes:

Pooled, with hard per-tenant boundaries
One stack, one control plane, and the five layers enforced per tenant: a run per tenant, a namespace per tenant in every store, brokered per-tenant credentials, per-tenant egress allowlists, tenant-tagged traces with scoped access, and per-tenant budgets. Cheapest to operate and the easiest to keep patched — provided the boundary is enforced in one place per layer and re-tested on every deploy with canary tenants.
Pooled by default, siloed for the few
Run the long tail pooled and give the handful of accounts that need it their own stores, keys, VNet, or account — while keeping one codebase and one deployment pipeline across both. This is where most successful platforms end up. The discipline is refusing to let the siloed tenants fork the code: everything tenant-specific must be configuration, or you have quietly signed up to maintain two products.
One deployment per tenant
Justified when residency or contractual single-tenancy demands it and you can automate the fleet. Understand what you are buying: N times the upgrade, patch, eval, and incident surface, and per-tenant drift as the default failure mode. Price it accordingly, and keep create-time-only decisions — like Foundry network injection, which cannot be changed after account creation — in the provisioning template rather than in a runbook.
Do not promise a fleet you cannot operate
Hand-built per-tenant stacks age badly: the third tenant is fine, the tenth is unpatched, and nobody can say which version each one runs. Offer the isolation you can actually operate — dedicated stores, customer-managed keys, a dedicated namespace and quota inside one automated control plane — and invest in provisioning automation before you sell single-tenancy to the next prospect.
Fix the data path before you sell isolation
If tenant scoping lives in scattered application code, your isolation claim depends on every future code path remembering a filter — and one of them already forgot. Consolidate to a single data-access layer with a non-optional tenant predicate, add the credential broker, and stand up canary-tenant tests. Only then is “tenants are isolated” a statement you can defend in a security review.

Tool: Cloud Deployment Wizard — Take a tenancy profile — tenant count, residency demands, regulated accounts — through the Deployment Wizard and compare the pooled, hybrid, and siloed architectures it proposes.

Interactive flashcard deck.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.