Deep Agents

Deep Agents has no identity or authorization layer of its own: every tool the developer registers runs inside the application process with whatever credentials that process holds, and model provider keys come from the environment. The one place the library narrows authority is its local shell backend, which starts commands with an empty environment unless the developer passes inherit_env=True. Nothing checks per request whether the agent should be allowed to act, so a hijacked agent acts with the full authority of the host process.

Deep Agents can pause any tool call for human approval through LangChain's human-in-the-loop middleware, with approve, edit, reject and respond decisions, per-call predicates, and filesystem permission rules that can mark paths as needing approval. Sub-agents inherit the parent's interrupt settings. But the gate is off unless the developer passes interrupt_on or interrupt-mode permissions, and it only covers tools named in that mapping, so by default every tool call, including any shell or write tool, runs immediately.

The built-in file tools are reasonably narrow: paths are normalised and '..' or '~' components are rejected, the default backend is an in-memory virtual filesystem, and the on-disk backend resolves paths and checks they stay under its root by default. Optional permission rules can allow, deny or require approval per path. Developer-registered tools only get schema typing, and the shipped local shell backend passes a raw shell string through. The default tool set includes write, edit and delete tools and an execute tool that only works when an execution backend is configured.

With the default in-memory backend there is no code execution: the execute tool returns an error. Execution is enabled by choosing a backend. The core package's LocalShellBackend runs model-written commands through the host shell with no isolation (its docstring says so), though with an empty environment by default. The repository also ships remote sandbox backends (Daytona, Modal, Runloop, Vercel, LangSmith) that run both commands and file operations inside a provider sandbox, but all of these are opt-in and their network and lifetime settings come from the developer's provider configuration.

Tool results, file contents, sub-agent replies and remote async sub-agent outputs all enter the model's context as ordinary messages with no provenance or taint tracking, and nothing changes what the agent may do after reading untrusted content. The README states the project follows a 'trust the LLM' model and leaves boundaries to tools and sandboxes. In a typical deployment where the agent reads external content and holds tools that write or send data, a successful injection can drive those tools unattended.

Memory is opt-in: when enabled, AGENTS.md-style files are read from the backend and appended to the system prompt on every call, and the built-in prompt tells the agent to update them with edit_file as it learns. The memory block is labelled as file data to treat as reference, but writes are not validated, gated or versioned unless the developer adds permission rules. With the default in-memory backend memory lasts one thread; with the store backend it persists across threads in whatever namespace the developer's factory returns. The library loads no workspace config or .env files on its own.

The library does not launch MCP servers or download tools itself; developers pass tools in code. But at first profile lookup it imports and runs every entry point any installed Python distribution declares under its profile plugin groups, in-process, with no allowlist, pinning or integrity check. Those plugins can add middleware and change prompts and tool behaviour. Skills are markdown instructions, not code.

Provider API keys are read from environment variables by the LangChain model clients, and the library adds no masking or redaction anywhere: shell output, file contents and tool results go to the model as-is. The local shell backend does start commands with an empty environment by default, which keeps keys out of subprocesses. The library sends no telemetry of its own; LangSmith tracing is opt-in. The memory prompt asks the model not to store credentials, which is guidance, not a control.

The library writes no audit record of its own. Tool calls and results are kept in the conversation state returned to the caller, but sub-agent runs only return their final message, and nothing is persisted unless the developer adds a checkpointer or enables LangSmith tracing. When tracing is on, the library tags its runs and marks sub-agent runs so they appear in the trace tree; the tracer itself lives in LangChain, so that behaviour is inferred here.

Each agent graph is compiled with a recursion limit of 9,999 steps, local shell commands default to a 120-second timeout clamped to at most an hour, and glob searches have a wall-clock deadline. There is no token or cost budget. Each sub-agent invocation starts its own step count, so delegation is not charged against the parent's limit, and nothing caps how many sub-agents run in parallel. A shell command that times out has its shell killed, but processes it spawned in their own session are not.