DeepSeek's open-source dsh-superagent, explained: who can give it work, and what it can run

DeepSeek posted dsh-superagent, an MIT-licensed research prototype of a coding agent that takes requests from GitHub and Feishu and answers with pull requests. We read its authorization and execution docs and explain the permission model, the safe defaults, and the one line every operator should read before installing it.

This explains reporting by

deepseek-ai/dsh-superagent-prototype on GitHub (MIT license). Read the original first:

https://github.com/deepseek-ai/dsh-superagent-prototype

In one minute #

• dsh-superagent is a coding agent for one GitHub repository, packaged for DeepSeek Harness. It listens to GitHub and, optionally, Feishu, and answers in the same conversation, for example with a pull request.
• DeepSeek calls it a research prototype, not an official product, and says it differs from its internal version.
• A request counts as explicit only when an allowed person addresses the agent. Bots can never make explicit requests.
• Work nobody asked for needs a rule the team wrote, and the default mode, observe, only records what the agent would have done.
• Each piece of work gets its own worker session and folder, and that worker runs commands without approval as the operator's OS user. Give it its own user or machine.

What it is #

The repository describes a proactive coding agent for one GitHub repository. When an allowed person asks for work, it opens a work item, called a Ticket, does the work in its own session and folder, and replies where the request was made. A web panel lists only what needs a person.

Its stated principle is to take as little human attention as possible and give as much value as possible. It confirms a request once, stays quiet while working, and writes again when a result is ready, a decision is needed, or it cannot finish.

Setup is done by asking a coding agent to follow SETUP.md, one question at a time. The README does not name which model runs it.

Who can start work #

Each incoming message gets a strength.

explicit      an allowed person addresses the agent,
              or follows up on a thread that already has a Ticket
inferred      an unlisted person follows up on a Ticket's thread;
              a bot on the Source's bot list addresses the agent
not admitted  any other bot; anything the admission table ignores;
              every inferred case while accept mode is off

Each Source has an admission table with safe defaults. An allowed person who does not address the agent: inferred. An unlisted person who addresses it: ignored. An unlisted person who does not address it: ignored.

Setting the unlisted-and-addressed cell to explicit lets anyone in that chat request work by mentioning the agent. The docs suggest it for a dedicated support chat. It is also the setting to be most careful with.

Work nobody asked for #

Proactive work needs a written rule, and the accept mode decides what happens.

• off: nothing inferred becomes a candidate.
• observe, the default: inferred candidates are assessed, and a yes is recorded as "would accept", but nothing runs.
• auto: a positive assessment starts the work.

Explicit requests work in every mode. The docs say to start in observe and switch to auto only after reviewing what it would have done.

Mandates: permission that can be taken back #

Every accepted Ticket carries a Mandate recording why it was allowed: the rule, the sender, the policy version. Only three things change a Mandate: accept creates it, a person's stop withdraws it, and a failed check revokes it.

Before an ended Ticket resumes, the host checks the Mandate again. Remove a person from the allowed list and Tickets that rested on that person can fail the check. Messages, comments and quoted documents are inputs, the docs say; they cannot change permissions. That is the right line against prompt injection through an issue comment.

The line to read before installing #

From docs/003-execution.md: each Ticket gets a worker session named worker- plus the Ticket ID and its own folder under the execution root, by default the state directory's work folder. Executor sessions run commands without approval as the operator's OS user.

So the agent has whatever your user account has: SSH keys, cloud credentials, other repositories. Shell commands move to the background after 5 seconds, and background work gets at most 30 more minutes after a turn before jobs are killed.

Our reading: the authorization model controls who can ask. It does not limit what a worker can touch once it runs. That part is on you.

A setup checklist #

• Run it as a dedicated OS user on a spare machine or VM with no personal keys.
• Give its GitHub account access to the one repository only.
• Start with a short allowed list and accept mode at observe, as the docs advise.
• Leave the unlisted-and-addressed cell at ignore unless the chat is a closed team space.
• Read what it posts in your name; the docs say the operator owns every message it sends.

Who is affected #

What to do #

• Read docs/000, 002 and 003 before running SETUP.md.
• Create a separate OS user or VM for the agent.
• Keep accept mode on observe until you have read its recorded decisions.
• Scope its GitHub token to one repository.

What is still unknown #

• Which model the agent uses by default. The README does not say.
• How the published code differs from DeepSeek's internal version.
• How well the authorization rules hold up against a determined prompt injection. We found no outside test.
• Whether DeepSeek will keep maintaining it. It is labeled a research prototype.

Sources #

• deepseek-ai/dsh-superagent-prototype on GitHub (MIT license) — the original report
• dsh-superagent docs, 002 Authorization
• dsh-superagent docs, 003 Execution
• dsh-superagent docs, 000 Philosophy

AI News Report· every headline, every morning.