Task-scoped capabilities: combining Harness permissions with external enforcement

[luciobaiocchi]

Hi everyone,

I’ve been thinking about whether it would be useful to have a more explicit concept of capabilities scoped to a task/session in DeepSeek Harness.

This idea came out of a conversation with @PerryLink about dsh-permission-rules, so credit to him for helping me frame the problem much more clearly.

The use cases I have in mind are pretty simple.

1. Rename thousands of photos, but never delete them

Suppose I give an agent a folder containing years of photos and ask:

Rename and organize these files.

I want the agent to be able to:

• list files
• inspect metadata
• rename/move files

but I want a much stronger guarantee that it cannot delete the photos, even if the agent makes a mistake or generates an unexpected command.

Conceptually, I would like to give the task something like:

photo-organizer

with a bounded set of capabilities for the lifetime of that task.

2. Different authority for dev and review

Another example is a coding workflow.

During development I might want:

dev
→ read/edit code
→ run tests
→ create commits
→ no destructive repository operations
→ no merging/deploying

Later I might start a different task/session:

review
→ inspect a PR
→ review changes
→ approve/reject it
→ possibly merge, depending on the granted capability

The important part for me is that these are not just prompts telling the model what it should or shouldn’t do. They describe what the agent is actually allowed to do for that task.

---

dsh-permission-rules already seems able to model a lot of this by composing rules, presets, workspace configuration and agent identity.

What I’m wondering is whether there is value in making the idea itself explicit:

task/session → named capability profile → allowed authority

rather than having users assemble that concept themselves from multiple configuration dimensions.

Where Towel fits

I’m experimenting with this from another direction in an open-source project called Towel.

I don't want Towel to replace the Harness permission layer.

The separation I'm currently exploring is roughly:

DeepSeek Harness
    │
    │ understands intent/context
    │ tools, args, agent, task
    ▼
permission / approval layer
    │
    │ allowed operation
    ▼
Towel (separate process)
    │
    │ externally enforces the capability
    ▼
filesystem / network / credentials / external services

[PerryLink]

Thanks for writing this up, and thanks for the credit. Replying as the maintainer of dsh-permission-rules.

The two-layer diagram is exactly how I think about my plugin's boundary: dsh-permission-rules is policy at the tool-call seam - it can see intent (tool, arguments, paths, agent identity) but explicitly does not claim OS-level guarantees. So rather than a competing permission engine, Towel is interesting precisely as the layer that makes a deny hold.

Two refinements I'd add to the diagram:

1. The arrow from the permission layer to Towel should carry a decision object, with a return channel carrying a receipt - which guarantee was applied, and its evidence. Without both directions the audit trail is incomplete.
2. On disagreement, each layer stays authoritative for its own question: the harness for intent-level questions (should this tool call proceed at all), the external layer for effect-level questions (can this effect actually happen here). I'd also want the interface itself to fail closed when the external layer can't enforce - something I'm still curious about for Towel's current behavior.

On the central question - is capability-per-task worth making explicit - my honest answer: yes, eventually. Today your two scenarios are expressible only by composing rules, presets, workspace files, and env conditions. A first-class profile (named rule set + defaults like deny-by-default and network mode + optional external enforcer binding, activatable per session/task) is a much better fit, and this thread is the strongest motivation I've seen for it. It isn't on my roadmap yet, but I'll link this thread from the project.

What I'd want before building either is a small shared artifact to start with: a versioned decision envelope (request / decision / receipt) plus a small conformance corpus of test vectors. There's precedent for the vocabulary-level seam - another DSH plugin author has an open proposal for shared rule-syntax test vectors, and their tool already emits rules in dsh-permission-rules YAML - so a second consumer would turn that into a pattern. Happy to prototype this incrementally rather than design a spec upfront; the corpus alone is a fine first step.

[luciobaiocchi]

Thanks Perry — this framing matches very closely how I’d like Towel to evolve.

For the first prototype, I’d keep the scope intentionally narrow: credential-backed HTTP capabilities, which Towel already enforces today. The Harness can make the intent-level decision, while Towel independently checks its stored capability constraints, keeps the credential outside the Harness process, executes the request, and returns a receipt.

One invariant I’d like to preserve is:

Harness policy may further restrict Towel authority, but it must never be able to widen it.

So even if the Harness sends allow, Towel still verifies the destination, method, path and capability itself and fails closed if enforcement is unavailable or the request exceeds the stored authority.

I really like the idea of starting with just a versioned decision envelope + receipt + a small shared test-vector corpus, rather than designing a larger policy language upfront.

For the first E2E, I’d suggest something like:

github-read → Harness allows the invocation → Towel enforces GET + path + fixed destination + protected credential → receipt comes back with the same correlation ID.

Then we deliberately send an invalid DELETE and prove that Towel still denies it even if the Harness-side decision were wrong.

Filesystem/process enforcement is interesting later, but I’d rather prove this seam first using the enforcement Towel already has.