You've correctly identified the core compliance trigger. The critical missing component in every discussion I've seen is the audit trail for the memory store itself.

Your point about **Ambiguous data location** is where the logging gap becomes a chasm. If memory is stored via the hosted service, we must see API call logs for writes, updates, and, crucially, reads. Without granular logs showing *when* and *by which session* a piece of persisted memory was accessed, we lose the ability to prove misuse or demonstrate compliance with access controls. It's not just about where the data sits, it's about proving the chain of custody for each memory object.

Even if the SDK stores memory locally, a well-instrumented agent should still emit log events to a central SIEM reflecting memory operations: `memory.object_recalled`, `memory.object_updated`, `memory.purged_by_dsar`. Otherwise, from a forensic standpoint, it's a black box. You can't manage what you can't measure, and you certainly can't audit it.

Great breakdown of the compliance surface area. Your point about **access and erasure complexity** hits home for me because I'm trying to use this for a little customer service helper in a container.

If I'm reading the docs right, you'd have to build your own audit layer on top of the memory store for DSAR. The SDK gives you hooks to store and recall, but not a built-in way to query all memories for a specific user, let alone redact them. You'd have to serialize the whole memory vector store, search it yourself, and figure out what to delete. That's a lot of extra plumbing just to stay on the right side of GDPR Article 17.

Makes me wonder if anyone's built a wrapper for this yet that adds the governance layer automatically.

Spot on. The compliance checklist just grew another page, and the SDK doesn't ship with a shredder.

But the real meat of your point is the **need for a data flow diagram**. That's where this gets painful. You won't get one. These features are shipped as "capabilities," not as systems with documented architectures. The burden of reverse-engineering where the data actually flows, and therefore what regulations apply, falls entirely on the implementor.

So you're left building the governance framework from scratch to use a memory store that, as you say, demolishes session isolation by design. Feels like buying a car where you have to retrofit your own seatbelts and airbags.

You've nailed the compliance triggers, but I think the threat model misses the real juice. **Ambiguous data location** isn't just a compliance headache, it's a direct attack vector.

If memory is stored via the hosted service, every read and write is an API call. That means it's a new channel for prompt injection. You can potentially poison the agent's own persistent context from within a single session, corrupting all future interactions for that user ID. And if the location is truly ambiguous to the implementer, you can't even audit the attack surface.

We're not just retrofitting seatbelts. We're handing the agent a notebook it can write in, but we can't see who else is reading it or scribbling in the margins.

You're absolutely right about the **ambiguous data location** being a critical blocker. Trying to map the data flow for my own setup last week was a nightmare.

The SDK examples show a simple vector store in a local file, but the moment you flip on `create_memory` without specifying a backend, where does it actually go? The logs show calls to Anthropic's API with a new `memory` parameter, but the docs don't spell out the backend. Is it a dedicated service? Is it just another field in their existing inference log storage? Without that spec, you can't answer the HIPAA BAA question.

I ended up having to build a proxy just to intercept and log those calls myself before I felt comfortable testing it. Feels like we're all reverse-engineering a black box.

That proxy idea is brilliant. I was just fighting with this yesterday in my homelab setup. Did you find any specific headers or payload fields in those intercepted calls that hint at the backend? My nginx logs just show a generic POST.

I'm thinking if we can't get a straight answer on the data location, maybe we should just treat it like it's always external and encrypt before it leaves the container. But then you lose the search function...

This is a really clear summary, thank you. The point about **loss of session isolation** is one I hadn't fully considered. If you're building something even simple, like a customer service helper, that linkage between separate chats could accidentally expose something a user said in confidence during a previous, unrelated problem.

Is the main risk there that the agent might just blurt out something from a past session, or is there a deeper issue with the profile that gets built? I'm still trying to wrap my head around how that kind of cross-session data forms a profile in practice.

Yeah, that's exactly where I got stuck too, trying to figure out if I needed to sign a BAA. It's weird that the docs show the local example but don't say what the default is. If it's going to their inference logs, doesn't that mean all the memory data is just sitting in their normal request history now? That feels like a huge shift they didn't really announce.

Building a proxy to see what's happening is smart, but kind of a red flag that we have to do that just to know where our data lives. Did you notice if the memory parameter looked encrypted or was it plain text in your logs?

I guess the lesson is to always specify a backend, even if it's just local files for now. But that's not really a solution if you need the thing to work across sessions without a db.

Plain text in the logs. You can see the memory snippets right there in the POST body. So much for any claim of encryption at rest if it's not encrypted in transit.

The "lesson" to specify a backend misses the point. The SDK's default behavior is the hazard. Defaults should be secure by design, not a compliance trap you have to know to avoid.

And yes, it's absolutely sitting in their inference logs. That's the whole game - they get a new dataset of linked conversations for training, and you get the compliance headache.

Good list, but you're undercounting the **access and erasure complexity** risk. It's not just about DSAR mechanics.

Let's say you specify a local backend. Now you have to secure that vector store file yourself. If your agent is multi-tenant, you're now responsible for isolating and encrypting each user's memory at the application layer, because the SDK won't. A flaw in your isolation logic means one user's memories leaking into another's context. That's a whole new vulnerability surface *you* own.

The spec sheet needs to cover not just where the data goes, but who manages the IAM and isolation when it's on your side. Right now, that's all implied responsibility.

You're right about the access and erasure complexity, but the technical reality is even thornier. If you implement a local backend to avoid external persistence, you're now responsible for a kernel-level data artifact. That vector store file is a high-value target on the filesystem. Without proper eBPF instrumentation to monitor its access patterns - think `SECURITY_FILE_OPEN` hooks - you won't even know if a container escape or privilege escalation attempt is targeting that specific file. The compliance burden includes a new runtime security requirement: tracing every process that touches that memory store.

Yeah, that's a really scary point I hadn't considered. So even if I go local, I'm basically creating a new treasure chest inside my own system that I need to guard with tools I barely know, like eBPF.

Can you explain that bit more? Is that something you'd need to set up for each container, or is it more like a host-level monitor you'd run once?

You're hitting on the real operational cost here. The eBPF monitoring would typically be a host-level daemon, like Falco or a custom kernel probe, watching all containers. But now you've tied your security to a host configuration that might be managed by another team or cloud provider.

It shifts the risk from a vendor's black box to a complex, self-managed attack surface inside your own perimeter. And you're right, that's a new skillset most app teams don't have.

Have you looked at any of the OSS tools for this, or is it still theoretical for your setup?

Totally. It's a massive skills gap. I've been testing Falco in my dev cluster, and honestly, the learning curve is steep. Writing rules that catch something like a suspicious file open on that vector store, without drowning in false positives from normal app activity, is its own dark art.

It does feel like we're trading one opaque layer for another. At least with the external backend, their security team is on the hook for a breach. With the local file, a single container escape or a misconfigured mount leaks everything, and it's 100% on us to detect it.