DeepSeek's Harness team has shared dsh-superagent, a coding-agent research prototype that listens to GitHub and can turn an authorized request into a work item and a pull request. The initial commit is dated October 31, 2026. Its default policy records which unsolicited tasks it would accept before letting it take them on.
That gives developers a way to inspect an agent's proposed workload before enabling proactive work. There is a sharp limit: the README says this is research code, not an official DeepSeek product or production-ready software. This article examines the published documentation; we haven't installed the prototype or tested its controls.
Observe mode still allows explicit requests
The authorization guide separates explicit requests from inferred work. An allowed person addressing the agent can ask it to act. Approved bots can only propose candidates.
For inferred work, the default observe mode records a positive assessment without accepting the task. Switching to auto allows acceptance when an enabled team rule matches. The guide recommends reviewing recorded decisions first.
Explicit requests work in every acceptance mode. Observation therefore doesn't make the whole agent passive. Teams must also decide who can request work and which conversations are open to requests, as the admission rules explain.
A work directory isn't a security boundary
The execution documentation describes a separate worker session and directory for each ticket. A preparation command can use Git worktrees to create checkouts. Work that needs a person's answer or review has a corresponding ticket state, making that handoff visible rather than leaving it buried in a conversation.
Those directories organize execution. They don't establish isolation. Workers run commands without approval as the operator's OS user, according to the same execution guide.
The deployment guide makes the consequence explicit: both the worker and router presets use danger-full-access. Credential wrappers select the agent's account but don't isolate its process. A worker can execute programs by path and read the operator's home directory. The documented isolation step is a dedicated OS account containing only the agent's credentials.
Read together, these documents describe two separate controls to evaluate. Admission policy governs which messages may start work. Operating-system access determines what an accepted worker can reach. A narrow allowed list doesn't reduce the files exposed to that process.
A reference implementation with a setup cost
The README describes the agent as a bundle for DeepSeek Harness, scoped to one GitHub repository, with optional Feishu messages and a web panel for work needing human attention. It also says the published prototype differs from the team's internal implementation, and some designs discussed in its accompanying article remain unimplemented.
Setup requires a dedicated Harness profile and an agent GitHub user account with repository write access. The deployment instructions say a GitHub App cannot serve as that account because the agent reads account notifications. They also explain why the profile should be separate: the plugin changes process-wide PATH and Git settings.
Before enabling auto, teams can examine whether the agent's proposed tasks match the work they want done. The authorization guide recommends that review. Evidence from actual accepted tasks still needs to establish whether workers respect their assigned scope; reading the policy alone cannot answer that.