DeepSeek Superagent: Permission to Work Is Part of the Architecture
The difficult question about a proactive coding agent is what lets a message become work.
A GitHub comment can contain a bug report, a quotation, a suggestion or a request from someone who cannot authorize changes. If all four reach the same coding loop, a better model does not automatically resolve the permission problem.
DeepSeek’s dsh-superagent prototype makes that problem visible in its architecture. It listens to one GitHub repository and optionally Feishu, evaluates incoming activity, creates authorized work items, and gives each one an executor session and directory. Results return to the original conversation, potentially as a pull request.
The interesting part, for me, is the machinery between receiving a message and starting a terminal command.
A prototype worth reading carefully
The repository is published under DeepSeek’s GitHub organization, but its README explicitly calls it a research prototype, not an official DeepSeek product or production-ready software. It also says the public implementation differs from the internal version and does not implement every direction discussed in the accompanying design article.
That distinction should survive the headline. This is useful source code to study; its existence is not a reliability or security benchmark. I have not deployed it or measured its behavior.
Context, permission and execution have different jobs
The domain model separates several concepts that are easy to blur in an agent demo.
| Concept | Job in the documented design |
|---|---|
| Trigger | An immutable incoming event, carrying source metadata |
| Eval | The gate and assessment that decide what new work may start |
| Mandate | The scope and policy context granted when work is accepted |
| Ticket | The unit of authorized work that owns its execution and reports |
| Assignment | The connection between a ticket and an executor instance |
A ticket is not simply the current model conversation. Its state is distinct from the executor’s state, and multiple assignments can serve it over time. That gives the system a place to keep continuity when the worker that performed the last step has ended.
Editorial simplification of the original domain model. The thumbnail contains an unchanged rendering of the original Mermaid source, not a product screenshot. Source excerpt: DeepSeek Harness Team, MIT; original excerpt and license.
The authorization document makes a particularly useful distinction: messages from a subscribed thread can arrive as context without granting new authority. A worker may need a CI result or another discussion to understand its task. Receiving that information should not expand what it is allowed to do.
Follow-ups have more detailed ownership and routing rules than this short summary. The architectural point is that delivery, admission and scope are represented separately, rather than inferred from the fact that a model saw some text.
Observe before accepting inferred work
For work inferred from activity, the documented modes are off, observe and auto. In the default observe mode, a positive assessment is recorded as “would accept,” without accepting the candidate. In auto, a positive assessment can accept inferred work. Explicit requests still work in every mode.
That last sentence matters. observe is not a universal read-only switch. It changes the treatment of inferred work, not every possible request.
I would use that distinction to evaluate a deployment: inspect which events would create tickets, who originated them, and what scope the system would grant. A useful observation period should produce decisions a team can actually examine before enabling more automatic admission.
A separate directory is not a sandbox
The deployment documentation is unusually direct about a limit: both managed presets run with danger-full-access as the operator’s OS user. A worker can execute programs by path and read the operator’s home directory. Credential wrappers choose defaults; they do not isolate the process. The documentation recommends a dedicated OS account containing only the agent’s credentials when isolation is needed.
The execution document also says auto-merge is governed by the Delivery requirements prompt; the host has no merge-specific decision logic.
These are two different boundaries. A mandate describes authorized work inside the application. OS permissions determine what the process can reach. And a prompt about delivery is not the same as a repository rule enforced when a merge is attempted.
My first experiment would therefore be a disposable repository, a dedicated account, narrowly selected requesters and explicit repository protections. That is an evaluation plan, not a claim that these settings make arbitrary untrusted code safe.
Read the control plane, not just the demo
In my Lightpanda note, I looked at what a browser built for machines can remove from the stack. Superagent raises a complementary question: what structure must be added when a worker starts receiving work from a team?
For me, the useful design contribution is the explicit chain from source event to decision, mandate, ticket and execution. It gives reviewers concrete places to ask who requested a change, what was accepted, and what happened when the conversation continued.
Before asking an agent to do more, I would want that chain to be inspectable.
Sources
- Repository and research-only limitations.
- Domain model and authorization.
- Execution and merge behavior.
- Deployment permissions and isolation limits.
Sources reviewed on November 3, 2026, pinned to commit 6337fc8. Follow jpalanco.com for more notes on AI, engineering and security research.
