DeepSeek Super-agent: What a Proactive Coding Agent Means for Security

On October 31, 2026, the DeepSeek Harness team published a design essay on a "Super-agent" and open-sourced a reference implementation, dsh-superagent-prototype. The part that matters for security: this is a proactive coding agent that reads GitHub and group chats, decides by itself whether something is work, and executes it. If you run coding agents, that changes what you must watch, because the input is no longer only what you type.

This post covers how the prototype decides what to act on, where untrusted text can still reach a worker, and what the authors themselves list as unsolved. It is not a vulnerability report. No CVE or advisory exists for it, and nothing here says the code is exploitable today.

TL;DR

What DeepSeek released

According to the repository README, dsh-superagent is "a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness." It listens to GitHub and, optionally, Feishu. When someone allowed asks for work, it opens a work item, runs it in its own agent session and directory, and answers in the original conversation, for example with a pull request. A web panel lists what needs a person.

The README is blunt about maturity. It is a "research prototype for reference only, not an official DeepSeek product," much of the engineering was done by coding agents, it differs from DeepSeek's internal version, and some designs in the essay are not implemented. The repository is MIT-licensed. A third-party summary of the essay adds that internal instances already reproduce bugs and respond to code review, and that the essay labels its measurements preliminary. For the news timeline, explainx.ai has its own write-up of the prototype.

How the architecture works

The design has two layers.

1. Router. A resident session receives events from every channel and dispatches. It can run a lighter model, and the essay says it can work without a Bash tool.
2. Workers. Each accepted task gets an isolated session with the full tool set and the strongest model. Workers do not talk to users; they report through the Router.

Events are called Triggers: group chat messages, email and calendar items, code review comments, CI results. Consecutive events on the same PR or chat topic form a Thread, and a Worker subscribes to the Thread after the first event. Later messages on that Thread go straight to the Worker without passing the Router.

There is also speculative work. In DeepSeek's internal user group, a "silently reproduce and fix" policy tries to fix reported problems in the background and only speaks up when it has a confirmed simple fix. In the essay's example, a fix pull request was already open while people were still discussing the bug.

Finally, compute is split from the machine. The Agent Loop runs in stateless cloud containers, and each endpoint runs a lightweight daemon that executes commands and returns results. This lets a developer machine with uncommitted changes and local credentials connect directly, which the essay calls bring your own machine.

The authorization model, step by step

The authorization document is the most useful part for a security reader. It states the central rule: "The host enforces allowed lists, rules and Mandates. Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions."

In practice:

1. Fast Path. A programmatic gate admits events by source, group and allowlist. Each Source has an admission table with cells for people on the list, people not on it, and whether the message addresses the agent.
2. Strength. A listed person who addresses the agent makes an explicit request. A listed person who does not, a bot on the Source's bot list, or an unlisted follower on an existing Thread produce an inferred candidate. Any other bot is not admitted.
3. Accept mode. There are three: off, observe (the default) and auto. In observe, a positive assessment is only recorded as "would accept." Only in auto does an inferred candidate become work, and it needs at least one matching team-written rule.
4. Mandate. An accepted Ticket carries a Mandate recording its source, scope, policy version and matched rules. Only accept, a person's stop and failed revalidation change it.
5. Revalidation. Before an ended Ticket resumes, the host re-checks that the sender is still on the list, the bot is still listed, and auto mode and the rule are still on.

This is a sensible design. Authority comes from configuration the host holds, not from words in a message, and the default mode does not act on inferred work. Two details deserve attention, though.

First, setting the unlisted-addressed cell to explicit lets anyone in that scope request work by mentioning the agent. The document suggests this for a dedicated support chat. On a public repository, that is a decision to make deliberately.

Second, subscribed Tickets receive every message on their Thread as context, including messages from bots and CI, and the document says this delivery "bypasses the gate and grants no new authority." That is accurate about authority. It does not mean the text is harmless: a worker with Bash that reads an attacker's comment is exactly the prompt injection setup that hidden instructions in a README or AGENTS.md or cloaked chatbot prompts exploit elsewhere. An automated reviewer using an ordinary account counts as a person to the host, and the document says team prompt text must identify such accounts.

What the authors say is unsolved

The essay's open problems list ends with security. Per the summary, if the cloud Agent Loop is compromised "through a server breach or prompt injection, every connected endpoint could be controlled." The team says it still needs a mechanism that lets the agent use credentials without ever seeing them.

That sentence is the honest core of the topic. The gate controls who can start work. It does not control what a worker does once a legitimate task is running and it reads hostile text. The only defences the design lists there are scoping and the Router's lack of tools. Your machine's local credentials, SSH keys and cloud tokens are in the blast radius whenever a worker runs on it.

What this means if you run AI coding agents

Proactive agents move you from "I prompt, the agent acts" to "events prompt, the agent acts." Checks that carry over, whether you try DeepSeek's prototype or any similar always-on agent:

• Read the policy before the code. If you run dsh-superagent, keep the accept mode on observe, review the recorded "would accept" decisions, and switch to auto only for narrow rules. The authorization doc recommends this order.
• Keep the allowed list short and the scope small. Do not connect a proactive agent to a repository or chat where strangers can comment. Treat every bot on a bot list as a way in.
• Do not give workers your daily machine. Run them in a VM or container with no ambient credentials. Our posts on microVM sandboxes without credentials and Capsem show the pattern.
• Assume a monitor that sits in the agent can miss things. Independent logging matters; see how auto-mode monitors missed 55 percent of red-team actions.
• Look at your logs for unattended work. Check for commands run when nobody was at the keyboard, new branches and PRs from the bot, and outbound requests from the daemon host.
• Plan for stolen sessions. If a hosted loop can reach your machine, rotate the endpoint's tokens as you would after any vendor breach.

The wider context is that attackers already run DeepSeek models through agent harnesses, as covered in Unit 42's Bugster and Hermes Agent report. That is a separate matter from DeepSeek's own tool, but it shows why agent harness security deserves attention. Microsoft's treat-agents-as-insiders framing is the same principle applied to enterprise governance.

What Beam can and cannot do here

Beam is local and on-device. Its documented hook coverage is Claude Code and Codex through PreToolUse hooks, where an active workspace policy can return a deny before local capture; other agents get a stderr note for a deny decision. DeepSeek Harness is not a documented Beam integration, so Beam cannot see or block what a dsh-superagent worker runs. The agent hooks docs spell out the supported list, and a PreToolUse hook records a proposed action rather than proving its effect.

Where it applies: if you route the same repository through Claude Code or Codex, those sessions are watched for credential exposure and destructive commands, and Beam scans skills and MCP configs before you run them with its 11 heuristics and a version-pin check. These are heuristics, not a kernel sandbox, and missing cached policy fails open. See what Beam watches and how it stays local.

What to watch next

The prototype is a reference, and the essay says internal versions differ. Expect other agent vendors to ship similar always-on designs, because the problem it targets, human attention, is real. The security questions will keep being the same: who may start work, what text reaches the worker, and what the worker can touch. Treat any announcement of a proactive agent as a new input channel to audit.

Frequently asked questions

What is DeepSeek Super-agent?

Super-agent is a design from the DeepSeek Harness team plus an MIT-licensed reference repository, dsh-superagent-prototype. It is a proactive coding agent for one GitHub repository that listens to GitHub and optionally Feishu and opens work items. DeepSeek says it is a research prototype, not an official product.

Is dsh-superagent safe to run on my machine?

The README says to treat it as research code, not production software, that much of it was written by a coding agent, and that you should review and adapt it first. Start in the default observe accept mode, keep the allowed list short, and do not connect it to a repository where untrusted people can comment.

Can a chat message or GitHub comment make the agent do something?

Per the authorization doc, messages are inputs to a decision and cannot change permissions. Only listed people can make explicit requests, and inferred work needs auto mode and a matching rule. But once a Ticket exists, every message on its thread reaches the worker as context, which is where prompt injection can still arrive.

What security problem do the authors admit is unsolved?

The essay lists security as an open problem: if the cloud Agent Loop is compromised through a server breach or prompt injection, every connected endpoint could be controlled. The team says it still needs a way for the agent to use credentials without seeing them.

Does Beam work with DeepSeek Harness?

Beam documents hook support for Claude Code and Codex PreToolUse. DeepSeek Harness is not on that list, so Beam cannot deny its actions. The general lessons, such as least privilege and logging outside the agent, still apply.

Related reading

• Unit 42: Bugster and Hermes Agent with DeepSeek
• Microsoft Guardian Agents and agents as insiders
• Malicious AGENTS.md hijacking Codex and Claude Code
• November 2026 attacks timeline

Details reflect the DeepSeek repository and essay as of November 1, 2026. The prototype is early research code and may change; check the repository for current behavior.