The Boundaries That Make the System Usable: Evidence, Security, and Operations

With DeerFlow 2.0 configured, the important question is not simply whether the agent can run. It is under which trust, evidence, persistence, and scale assumptions that run remains safe and intelligible. This chapter examines the boundaries around model context, credentials, tools, sandboxes, artifacts, and Gateway workers, then compares local evaluation with isolated and shared deployments. The practical outcome is a conditional operating choice, not a universal “production” label.

Trust begins before the tool call

DeerFlow treats model context as a set of channels with different authority. Framework-owned instructions—such as the rules for handling a report or a tool—belong in system-level context. User input, fetched web content, MCP results, delegated reports, and compressed history are data that may contain adversarial text. The runtime frames and sanitizes those sources so a page returned by a web tool cannot simply write a new system reminder, and a delegated result cannot acquire framework authority by being copied into a later prompt.

This distinction is easy to state and difficult to preserve because an agent’s useful context is assembled from many places. A skill description may be editable user content. A remote task notification may be serialized by an external server. A summary may contain an old instruction or a model mistake. DeerFlow’s durable-context middleware therefore puts its authority contract in a system message and the selected summary, delegation, and skill data in a hidden human message marked as data. The model can consult that information, but the text inside it is not allowed to redefine the runtime’s rules.

Identity follows the same principle. User identity, sandbox leases, run traces, message sequence values, and internal runtime keys are server-owned. Gateway input handling strips or overwrites client-supplied copies before graph construction. This prevents a request from choosing another user’s memory bucket, presenting a forged sequence number, or preserving an internal lease identity after authorization has changed. The embedded client is a trusted integration path and can supply more context, but the Gateway’s untrusted HTTP boundary cannot treat arbitrary metadata as authoritative merely because it has the right field name.

Credentials are carried out of band. Request-scoped secrets enter through runtime context rather than a message, tool argument, or ordinary run metadata. A skill can declare the names it needs, and DeerFlow injects values into eligible sandbox commands for the activation scope. The command string and model prompt do not need to contain the secret. The inherited environment is scrubbed of secret-looking names before the injected request values are layered on, so a skill subprocess does not casually inherit platform credentials from the Gateway process. MCP header interceptors can use the same request-scoped carrier for a remote call.

This design has a clear failure direction. A missing or empty mapped credential is denied by default rather than silently falling back to a static discovery credential. A malformed header value is rejected before transport use, because a lower-level HTTP error may echo the bad value into a tool error that reaches the model, checkpoint, or trace. Request-scoped secrets are not a vault: they are not persisted for later runs, and a caller must supply them again when a later request needs them.