Quick answer
Memory, sandboxes, and identity are separate boundaries in Managed Deep Agents. Private threads do not automatically create private durable memory, and a sandbox does not authorize a tool action. Review all three scopes together before a multi-user rollout.
Current LangChain documentation says durable memory is off by default. When enabled with agent scope, one Context Hub tree at /memories/agent/ is shared by the deployment across callers. The default sandbox scope is thread; agent scope shares a sandbox across threads. The scaffolded identity default uses a LangSmith workspace API key; the documented path for signed-in end users with private threads is Supabase.
Scope map
| Primitive | Current documented default | Main production question |
|---|---|---|
| Thread state | One durable thread | Can another caller discover or access this thread? |
| Durable memory | Disabled | If enabled, may every caller influence and receive deployment-wide memory? |
| Sandbox | Present when the sandbox/ declaration exists; thread scope by default | What files, code, commands, network paths, and secrets can this thread reach? |
| Identity | LangSmith workspace API key in the scaffold | Is this a service client or a signed-in end user who needs private threads? |
| Authorization | Application and downstream responsibility | Is every consequential tool action reauthorized for the current user and resource? |
Durable memory is a shared data surface
When memory is enabled, the runtime mounts one read/write tree at /memories/agent/. AGENTS.md is hot memory loaded into every run; other files are cold memory read when relevant. Deployments sync project-owned instructions and skills without overwriting runtime-created durable memory.
That behavior is useful for shared operating knowledge, but it creates a cross-thread boundary. Do not store user secrets, private conversation content, unreviewed personal data, raw access tokens, or tenant-confidential facts in deployment-wide memory. Define what is eligible, who may write it, how provenance is recorded, how incorrect memory is corrected, and how deletion requests propagate.
Sandbox scope controls workspace sharing
A sandbox provides an isolated filesystem and shell. With the default thread scope, each durable thread gets a sandbox that is reused across runs on that thread. With agent scope, the agent process shares one sandbox across threads.
Thread scope reduces cross-thread file exposure but does not make arbitrary execution safe. Bound command timeouts, dependencies, network destinations, writable paths, secret injection, artifact export, and cleanup. Agent scope needs a documented reason, collision handling, tenant separation, and evidence that one caller cannot read or corrupt another caller’s work.
Identity answers access, not every authorization question
The default LangSmith API-key path is appropriate for trusted SDK clients, scripts, and services. Anyone holding the workspace key can reach the deployment, so keep it server-side and rotate and revoke it like a production credential. It does not provide per-user private threads.
For browser or signed-in end-user applications, current LangChain documentation describes Supabase bearer tokens and private thread ownership. Test both directions: a user can reach their own thread, and receives 403 when trying to reach another user’s thread. This still does not prove that downstream tools enforce the same ownership. Send the verified identity through the tool boundary and recheck permissions at the system of record.
Production test plan
- Create two users, two private threads, and adversarial cross-thread access attempts.
- Enable memory only with an explicit shared-memory policy; inject a canary and test whether another user can retrieve it.
- Run file and command canaries across separate thread sandboxes and after restarts.
- Test key expiration, token revocation, malformed claims, missing identity, and replay.
- Attempt prompt-based identity spoofing and verify that tools ignore untrusted identity text.
- Exercise pause, retry, cancellation, and resume around state-changing actions with idempotency keys.
- Confirm traces and logs redact credentials and restricted payload fields.
- Delete a thread, memory item, sandbox, user, and deployment; verify the intended lifecycle in every store.
Review the public beta guide for availability, compare deployment ownership options, and use the local readiness checklist before rollout.
Frequently asked questions
Is durable memory enabled by default?
No. Current LangChain documentation says durable memory is optional and disabled by default. When enabled, the documented agent-scoped memory tree is shared across callers.
Does a LangSmith API key give each end user private threads?
No. It protects the deployment for workspace clients, but the current documentation directs signed-in end-user applications to Supabase for private thread ownership.
Is the default sandbox shared across users?
No. The default sandbox scope is thread, creating and reusing one sandbox per durable thread. Agent scope explicitly shares one sandbox across threads.
Official sources
- LangChain: Managed Deep Agents memory
- LangChain: Managed Deep Agents sandboxes
- LangChain: Managed Deep Agents identity
Source check: August 12, 2026. Recheck defaults, supported identity providers, memory paths and scopes, sandbox behavior, deletion, regions, and beta terms before use.