DeepSeek Harness production-readiness checklist
Evaluate a composable agent harness by its architecture, sandbox boundary, permissions, plugin supply chain, observability, and operational maturity.
A composable agent harness can accelerate experimentation by making models, tools, memory, permissions, interfaces, and the agent loop replaceable. The same flexibility expands the system a team must secure and operate.
The right question is not whether the architecture is elegant. It is whether the chosen configuration is safe and predictable enough for the intended environment.
Treat preview software as a pilot candidate
The Wavect review describes DeepSeek Harness, or dsh, as an MIT-licensed,
plugin-based agent platform in developer preview and notes that its own
documentation warns about breaking changes. That profile can be appropriate for
an isolated engineering pilot. It should not be mistaken for a production
guarantee.
Before adoption, pin the exact version, record the preset and plugins, and define an exit path. A pilot should answer a bounded question such as whether the harness improves completion on one internal coding workflow.
Draw the real security boundary
“Sandboxed” is incomplete without a threat model. Document which boundary controls:
- Filesystem reads and writes
- Process creation and visibility
- Network access and destinations
- Environment variables and credentials
- Package installation
- Host services and developer tools
- Persistence between sessions
The referenced review highlights that a filesystem sandbox does not necessarily restrict network or process visibility. Compensating controls may need to live outside the harness, such as a disposable container, restricted identity, network policy, and isolated secrets.
Review the plugin supply chain
Plugins execute inside a powerful development workflow. Treat presets and plugin configuration as code:
- Pin reviewed versions and hashes.
- Inspect transitive dependencies.
- Restrict installation sources.
- Record enabled capabilities.
- Require review for configuration changes.
- Reassess plugins after upstream updates.
A convenient plugin registry is not a trust boundary.
Make approvals specific
An approval dialog should explain the exact operation, target, and consequence. Approving a general shell capability is materially different from approving one read-only command.
Test whether approvals can be bypassed through another tool, nested command, plugin, or inherited process. For destructive or external actions, require an explicit checkpoint close to execution.
Evaluate the harness, not only the model
Run the same tasks across candidate harness configurations while holding the model constant. Measure:
- Task completion and test pass rate
- Unnecessary tool calls
- Permission requests and denials
- Recovery after command or test failure
- Context and memory behavior
- Runtime, token use, and cost
- Changes made outside the intended scope
Adversarial cases should include prompt injection in repository files, malicious package instructions, secret discovery attempts, destructive command requests, and unexpected network destinations.
Establish operational controls
A production path needs versioned configuration, centralized audit logs, resource limits, timeouts, incident response, rollback, and an owner for upgrades. Capture enough trace data to reproduce decisions without storing credentials or sensitive source indiscriminately.
Start with low-risk repositories and disposable environments. Expand access only after evidence supports the change.
Observe agent harnesses with Currai
Currai records model calls, tool requests, approvals, command outcomes, errors, and user interventions as one agent trace. Teams can compare harness versions, detect permission regressions, and turn incidents into repeatable evaluations.
Use the Currai integration skill, or read detecting agent-harness regressions.