DeepSeek Harness · 3 of 6
Tools, permissions, and effects
DeepSeek’s tool runtime is a staged policy pipeline. Registration, model visibility, approval, confinement, dispatch, post-processing, and durable outcome are separate contracts.
§1
Registration is not visibility
ToolRuntime maintains a scoped registry. A per-scope restriction can remove globally registered names from the agent’s view, and the surviving definitions are assembled into the model prompt as schemas. Registration also validates definition invariants such as result rendering, output schema, timeout, and reserved names. Source · restrictions Source · prompt schemas
This implements the first two trust questions: the host can resolve a tool, and the current agent can see it. Neither answer authorizes one concrete call.
§2
The pipeline branches before execution
| Path | Stage | Responsibility | Failure meaning |
|---|---|---|---|
| Every call | Durable tool/call | Record the model proposal before execution; let UI show pending state. | A call record is not an effect record. |
| Every call | tools/pre-execute | Waterfall for hooks, permission policy, call transformation, and an allow, ask, or deny decision. | Deny skips the tool body. |
| Ask branch | ctx.approval | Resolve the ask before guard evaluation; unavailable or rejected means deny. | No answer is not consent. |
| Allowed or approved branch | Monotonic guards | Owner guards may deny or abstain; later order cannot turn denial into allow. | A guard denial is binding. |
| Permitted branch | tools/execute | Around-dispatch wrappers add timeout, retry, and metrics around the tool implementation. | Wrapper/body errors normalize into an error result. |
| Inside applicable tool bodies | Capability policy | Filesystem intent events and sandbox/subprocess providers constrain the specific effect they own. | Approval does not bypass a lower execution boundary. |
| All outcomes | tools/post-execute | Accept, block, replace, or add bounded context after the candidate result. | Post-policy can prevent unsafe output from becoming authoritative. |
| All outcomes | Finalize + tools/result | Normalize, enforce final content invariants, freeze outcome, and notify observers. | One authoritative model-facing result is committed. |
The repository’s generated pipeline documents the common phases and the allow, ask, and deny branches from call logging through result logging and additional context. Source · complete pipeline
§3
Monotonic guards make denial order-safe
Registered monotonic guards can deny a call but cannot grant it. That rule prevents listener order from accidentally undoing an owner’s denial. Generic policy can ask or transform earlier; a guard expresses an invariant that remains restrictive. Source · guard rule
The monotonic rule keeps composed security policy conservative: downstream components may narrow authority, never widen a denial they did not own.
§4
Approval, sandboxing, and filesystem policy occupy different layers
Approval resolves a human ask for one proposed call. Sandbox providers constrain subprocess execution. Filesystem mutation tools emit write/edit intent events for read-before-edit or path policy. These policies attach at generic tool or specific capability seams rather than being hard-coded into the loop. Source · policy placement
An approved command can still be wrapped for a sandbox. An allowed tool can still be denied a path. A filesystem provider can be swapped without giving every tool its own remote/sandbox fork. The composition aims to share one effective execution world.
§5
Concurrency does not erase model order
The agent driver classifies pending calls by execution mode, runs barriers and a bounded rolling pool, and commits the next model-order result when it is ready. Preparation, dispatch, finalization, and finish are explicit runtime stages. Source · runtime stages
This lets independent operations overlap while preserving a coherent sequence of durable results for replay and the next model request.
§6
The frozen result is an observation, not proof of intent
After post-policy and definition-owned finalization, tools/result observes a frozen authoritative outcome and one tool/result session event becomes model-facing. Tool-owned events can preserve richer domain facts alongside that result. Source · finalization and result
The pipeline establishes what the tool runtime accepted and recorded. The tool or a later verification step must still supply evidence that the intended external postcondition holds.