Permissions, Sandbox, and Runtime Invariants

A security label is not a complete guarantee. DeepSeek Harness has separate layers for instruction, tool policy, approval, and process sandboxing.

Sandbox Modes

• read-only rejects filesystem writes apart from required sinks.
• workspace-write permits the workspace and backend-provided temp area.
• danger-full-access bypasses confinement.

This sandbox vocabulary governs filesystem effects, not network or process visibility. “Never use the network” needs a network control or no exposed network capability.

Backends report full or partial enforcement. Platform, kernel, or ACL limitations can make the boundary partial; workflows requiring an absolute guarantee must not treat that as equivalent to full enforcement.

Prefer Enforceable Invariants

Ask in order:

1. Can the rule be a type or Schema?
2. Can registration reject it early?
3. Can sandbox or approval enforce it?
4. Only then should policy judgment live in a Skill or prompt.

Runtime invariants such as paired tool calls/results, replayable event order, and cleanup on plugin disposal are more reliable than asking the model to remember internal consistency.

Permission Matrix Exercise

For “scan dependencies and produce a report,” permit reading manifests, optionally writing one report directory, reject installation, explicitly decide whether a vulnerability database may be contacted, and do not expose unrelated environment secrets. Start read-only and widen only the one capability proven necessary.

Destructive actions need an explicit target in the contract, approval showing the actual command, a preview or backup, and independent post-action verification.

Next: Reliable Tool Design.