Community plugin: dsh-tool-policy

[Drifter-yh]

DeepSeek Harness already provides the execution primitives that a production agent needs: sandboxing, one-shot approval, cooperative timeouts, provider retry, repeat-call reminders, and session telemetry. The remaining deployment gap is a small, generic policy seam that can apply the same decision vocabulary to every registered tool, including third-party and MCP tools.

dsh-tool-policy is an independent Cordis plugin that attaches to the public tools/pre-execute waterfall. It compiles ordered tool-name and JSON-Pointer argument rules, then returns deny, routes ask into the existing Harness approval seam, or delegates allow with next(). It defaults to deny, never rewrites arguments, never runs tool bodies, and does not create a second audit, timeout, retry, or approval implementation.

After publication, install it with pnpm add dsh-tool-policy and add it to a Cordis composition:

- name: 'dsh-tool-policy'
  config:
    defaultDecision: deny
    rules:
      - tool: 'read_*'
        decision: allow
      - tool: 'mcp_*'
        decision: ask
        reason: 'External tool calls require approval.'

Repository: https://github.com/Drifter-yh/dsh-tool-policy

The repository includes pure matcher tests, ToolRuntime plugin tests, and a real Cordis Loader composition. It was tested against Harness commit 47f943859bef60e4160492346772ded9b24f765a (0.1.0-rc.5).

Feedback requested:

• Is tools/pre-execute the right public extension point for deployment policy?
• Should the first stable version remain intentionally limited to ordered rules and JSON Pointer scalar predicates?
• Which policy presets would be useful without turning this into a second enterprise policy engine?

Topics suggested for the repository: dsh-plugin, deepseek-harness, cordis, agent-security, tool-governance.

[bobleer]

I read through the repo and the real Loader test. tools/pre-execute looks like the right seam for this shape of policy: the call is already logged, the plugin can fail closed before the body runs, and allow -> next() preserves later policy layers. Keeping argument matching deterministic and refusing to rewrite args also avoids a nasty log/execution mismatch.

One packaging detail looks worth fixing before publication. The current package.json has the right Harness peer dependencies and keywords, but it does not declare dsh.bundle.patch, and the repo does not ship a cordis.patch.yml. The DSH profile loader fails loud when a package named in dsh.profile.bundles has no dsh.bundle declaration. Shipping a tiny optional bundle patch would make this discoverable as a real composition layer while keeping the plugin itself independently usable.

Affiliation: I work on BitFun. We started a dsh-plugin compatibility adapter today, and this would be a useful first third-party fixture because it exercises a real Cordis plugin plus trust/version diagnostics. Our current milestone is projection-only—manifest/patch discovery, provenance, content hash, trust, status and diagnostics; no npm install or Cordis execution yet, and unreleased. If you add the bundle metadata, I’m happy to run its package shape through that adapter and report concrete incompatibilities: https://github.com/GCWing/BitFun

[Drifter-yh]

Thanks for taking a close look and for pointing this out.

I’ve added the Harness bundle metadata and now ship cordis.patch.yml with the package. The bundle inserts dsh-tool-policy with a deny-by-default configuration (defaultDecision: deny, empty rules), while the plugin runtime semantics remain unchanged.

I also cleaned up the package so it no longer depends on local tarballs or a sibling Harness checkout. The integration test now uses the public Cordis Loader/Include packages, and I verified fresh-clone installation, GitHub source installation, and an actual Harness profile Loader composition end to end.

The peer range remains @deepseek-ai/dsh-tools >=0.1.0-rc.5 <0.2.0; the reproducible validation currently runs against the publicly available rc.6 packages.

CI is green on the current main (35a5ba3).

Feel free to run the package shape through the BitFun adapter. I’d be happy to address any concrete incompatibilities you find. Thanks again for the feedback.

[ivanusto]

I built a small answerer against approval/request for an unattended deployment, then added a tools/pre-execute listener in the shape this plugin uses, and measured all three configurations on 0.1.0-rc.6. Two of your three questions have empirical answers, and one of them surprised me.

tools/pre-execute is the right seam, and it closes a real gap

The approval seam alone only sees calls the sandbox chose to escalate. Under the default workspace-write, a destructive command inside the workspace never escalates, so deployment policy never runs at all:

task: "Delete the directory throwaway/ and everything in it using rm -rf."
result: directory deleted, policy audit log EMPTY — never consulted

Adding a pre-execute listener fixed exactly that:

[pre-execute] deny  rm -rf

So yes — this is the seam where a deployment policy belongs, and the gap is not hypothetical. Routing ask into the existing approval seam rather than reimplementing approval is the right call too; it keeps one audit and one verdict owner.

But argument matching denies a spelling, not a capability

This is the part worth documenting prominently. Immediately after the deny above, the same run continued:

Since the rm -rf command itself is blocked by the deployment policy, I removed the contents with rm and then removed the now-empty directory with rmdir. The directory no longer exists.

The rule fired correctly, the audit recorded it, and the outcome happened anyway. This is not a gap in my pattern list — no finite set of patterns covers the equivalent spellings a model can reach for, and ordered globs plus JSON Pointer scalars are in the same class.

Switching the sandbox to read-only so the capability is gated produced the opposite result on the identical task:

[pre-execute] deny      rm -rf          (first spelling)
[pre-execute] deny      rm -rf          (second attempt)
[approval   ] rejected  default-deny    (escalation request)
files survived

Three routes, three refusals, and the model finished by asking for an escalation instead of working around anything.

What this suggests for your three questions

Keep the matcher limited. Not because richer predicates are hard, but because a richer matcher invites the belief that it is enforcement. The honest framing is a layered one:

layer	role	strength
sandbox mode	removes the capability	enforcing
tools/pre-execute	catches known-bad shapes early, records the decision	advisory — bypassable by rephrasing
approval/request	verdict on anything that escalates	enforcing — the only way out

Under that framing this plugin is doing exactly the right job, and expanding the predicate language would make it look like the top row without becoming it.

Presets that match the layer. I'd avoid anything named for danger (block-destructive, safe-shell), because such a preset cannot deliver what its name promises. Presets built around visibility and routing seem more defensible — e.g. one that marks mutating and external tools ask so every such call becomes an audited verdict, one that denies known credential-exfil shapes as a fast fail with a clear reason, and a deny-default starter with an explicit allowlist for read-only tools. All three are honest about being routing rather than containment.

One documentation request. A short "what this does not do" section stating that argument matching is advisory and should be paired with a restrictive sandbox mode would save deployers the experiment above. Right now the README reads as stronger than the mechanism can be.

Packaging looked correct when I checked: dsh.bundle.patch is declared, cordis.patch.yml ships a deny-default row, and the >=0.1.0-rc.5 <0.2.0 peer range covers rc.6 — I verified tools/pre-execute and the PreToolDecision shape are unchanged in rc.6, so the earlier packaging comment appears resolved.

[Drifter-yh]

Thanks for the concrete testing and for calling out the capability boundary.

I’ve updated the README to make the security model explicit: dsh-tool-policy governs individual tool-call shapes at tools/pre-execute, while capability enforcement remains the sandbox’s responsibility. I also documented that semantically equivalent operations may use different tool/argument shapes, so argument-pattern rules should not be treated as a complete capability boundary.

The runtime semantics are unchanged; this was a documentation/positioning clarification.

CI is green on the current main.