If you work for more than one client, you already keep them apart by habit. Separate directories. Separate credentials. Separate repositories, separate AWS profiles, separate everything. You do it without thinking, because the contracts you signed require it.

Then you add memory to your AI, and something quietly stops respecting that line — because nothing ever told it the line was there. A capture daemon watches sessions by working directory. It has no concept of a client, an NDA, or a confidentiality clause. It sees a folder.

This is about how to give it that concept. The controls take about two minutes to set up. The reasoning behind which control to use is the part worth reading, because the obvious choice is the wrong one.

The problem isn't what you think it is

The fear people name first is cross-contamination: that your AI will recall Client A's architecture while you're building for Client B. It's a reasonable worry and it does happen.

But it isn't the real exposure. The real exposure is that the data left the machine at all.

Read a typical consulting agreement and you'll find language about subcontractors and subprocessors — third parties you bring into contact with the client's information. Your client approved you. They did not approve a memory vendor they have never heard of, and in most agreements you need their consent, in writing, before routing their material to one. Whether your AI ever surfaces it in the wrong session is almost beside the point. The disclosure already happened at capture time.

Which reframes the whole thing. You're not trying to stop a retrieval mistake. You're trying to make sure certain material never becomes a record in the first place.

Three controls, ranked by how often you'll use them correctly

Engram has three. They're listed here in the order you should reach for them, which is not the order most people discover them in. All three need the CLI at 0.6.0 or newer.

1. Exclude the directory — the one you should actually use

npm install -g @getengram/cli@latest

engram exclude add ~/code/client-a
engram exclude add ~/code/client-b

Any session whose working directory sits at or under an excluded path is never queued — dropped in the daemon's message funnel, before anything touches the queue or the network. The paths live in ~/.engram/config.jsonand are re-read when the file changes, so there's no daemon to restart and no window where the old rules still apply.

Run it once per client. Then stop thinking about it, which is the entire point.

2. Commit an `.engramignore` — when the boundary has to travel

touch ~/code/client-a/.engramignore
git add .engramignore && git commit -m "Keep this repo out of AI memory capture"

An empty marker file at the repo root does the same job as a path exclusion, with one difference that matters: it lives in the repository. Clone the repo on a second machine and the boundary is already there. Hand the repo to a colleague and it protects them too, without a conversation about tooling neither of you wanted to have.

Use both. The exclusion covers your machine today; the marker file covers every machine and every person afterward.

3. Say it mid-session — the escape hatch, not the plan

Sometimes you're halfway through a conversation somewhere ordinary and it turns into something that shouldn't be recorded. Type any of these and capture stops:

engram:ignore — also engram off, engram skip, engram exclude
“don't save this to engram” · “please do not sync this conversation to engram” · “stop capturing to engram”
“engram, don't record this” · “engram should not save this session”

It isn't only a stop switch. It wipes the local queue and deletes whatever already reached the server, and that remote delete is persisted and retried until the server confirms it. So it cleans up behind itself, not just in front.

Three things to know so it doesn't fail silently:

It must contain the word “engram.”A bare “don't log this” does nothing. That's deliberate — ordinary conversation shouldn't be able to disable your memory by accident.
Only your messages are scanned.The assistant explaining this feature can't trigger it.
Only the first 4,096 characters of a message. Put it at the top, not buried under a pasted stack trace.

Why the automatic one wins

The mid-session opt-out is the feature people gravitate to, because it feels like control. You decide, in the moment, per session. If you keep one session per client, it seems made for you.

Don't build your process on it.

A control you have to invoke every single time is a control that fails on the day you're tired, or in a hurry, or two weeks into a rhythm where you've stopped noticing which directory you're in. And the failure is silent — no error, no prompt, nothing to notice. You simply find out later, if you ever look.

This is the ordinary shape of how confidential material ends up somewhere it shouldn't. Not a decision anyone made. A background process doing exactly what it was told, while the person who could have stopped it was never in the loop. A policy written for humans handling data doesn't catch it, because no human handled anything.

So spend the two minutes on engram exclude add. Keep the mid-session phrase in your back pocket for the sessions that surprise you.

Check that it actually worked

Set a boundary and then verify it, the same way you'd verify a firewall rule rather than assume it:

engram exclude list                 # the paths currently excluded
engram search "<client name>"       # should return nothing

Search for the client's name, their product names, their internal service names. If anything comes back, the exclusion is working from now on but there's history behind it — which is the next section.

Getting out what already went in

Exclusions are forward-looking. They stop new capture; they don't reach back. For anything already stored you have the full range of deletion — a single message, a whole conversation, or everything — through the CLI, the dashboard, or the API.

One piece of advice from having watched people do this: before you delete at any scale, write down what you found— what was stored, how much, over what date range, and how you identified it. If a client ever asks, “we identified and removed the following” is a completely different conversation from “we deleted something, we're not sure what.” The inventory costs you minutes and you cannot reconstruct it afterward.

Where none of this is enough

Everything above is about confidentiality — contracts, NDAs, professional judgment. If your client's data is regulated, the bar is somewhere else entirely, and we'd rather say so plainly than let a features page imply otherwise.

Engram is not a HIPAA-compliant vendor.We do not sign Business Associate Agreements. Protected health information should not go into Engram, and no exclusion setting changes that — exclusions keep data out, which is exactly the right tool, but they are not a compliance control and we won't market them as one. The same caution applies to anything else carrying a statutory regime of its own: regulated financial records, government data under a specific authorization, material covered by a court-supervised protective order.

For that category, the correct configuration is an excluded directory and a committed .engramignore, set up before the first session — not a cleanup afterward. If you're wondering whether your situation qualifies, ask the person who negotiated the contract, not us.

For everything else — the ordinary business of keeping one client's work out of another's context, and out of a vendor's store entirely — two commands per client will do it, and you can verify the result in about thirty seconds. That's the deal we think memory should offer: it remembers what you want and nothing you didn't, and you never have to take our word for which is which.