The headline version of DeepSeek’s new coding agent is that it watches your developers’ group chats and jumps in with fixes nobody asked for. That is how Bloomberg’s report, syndicated by The Star, framed Super-agent after DeepSeek’s Harness team announced it on WeChat on October 31. The shipped defaults say something closer to the opposite. Out of the box, the chat bot reads only messages that mention it, unlisted senders are ignored, and any work the agent decides to do on its own is recorded rather than done.
The sentence in the documentation that should decide whether you pilot it is a different one, and it sits in the execution guide: “Executor Sessions run commands without approval as the operator’s OS user.” The surveillance story is the wrong worry. The identity story is the right one.
What actually shipped on October 31
Super-agent is published as dsh-superagent-prototype under the MIT license. The README describes it as “a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness,” the agent scaffolding DeepSeek’s Harness team has been building this year. It listens to GitHub and, optionally, to Feishu (Lark) group chats, and a local web panel shows what needs a person. The repository passed 4,000 stars within a day, according to ShiftDelete, and the launch lands while DeepSeek is raising roughly 100 billion yuan (about US$15 billion) ahead of a planned IPO, per the same Bloomberg piece.
DeepSeek is unusually blunt about what this is. The README calls it a “Research prototype for reference only, not an official DeepSeek product,” says to “Treat it as research code, not production-ready software,” and warns that “Some designs discussed in the article are directions for future development and are not implemented in this prototype.” That last line matters: several features people are attributing to Super-agent come from the WeChat article, not from the code you can clone today.
The working loop is simple to describe. A main session routes incoming requests. Each accepted request becomes a Ticket, and according to the architecture doc the executor “provides one Session and directory per Ticket.” The worker does the job, opens a pull request, follows review comments on that pull request, and replies in the thread where the request started. Everything lives in a single SQLite file. The panel opens on one question: “Does anything need me now?”
The design goal is written into the philosophy doc: “Take as little human attention as possible, and give as much value as possible.” It is a better goal than most agent products state, and the defaults are built around it.
Why “it reads your group chats” gets the defaults backwards
The authorization doc is where the chat-watching claim falls apart. Each source has an admission table that sorts every message into an explicit request, an inferred candidate, or nothing. “An allowed person who addresses the agent makes an explicit request.” Unlisted senders who address the agent are ignored by default.
The proactive part runs through three accept modes:
- off: “Nothing inferred becomes a candidate.”
- observe (the default): inferred candidates are assessed, but a positive result is only logged as something the agent would have accepted.
- auto: “A positive assessment of an inferred candidate accepts it.”
On top of that, “A proactive accept requires at least one matching rule,” and those rules are written by your team. The setup guide applies observe mode without asking, configures the Feishu bot to read only mentions, and recommends that the only person allowed to request work on GitHub at first is the operator. The philosophy doc’s advice is to “Begin with a short allowed list and with proactive work only recorded.”
So the agent that jumps into a chat uninvited is a configuration you would have to choose: auto mode, rules broad enough to match, and a chat opened to it. The more useful observation is the one the coverage skipped. Observe mode is a shadow deployment for agent autonomy, and it is the best idea in the repository. You get a record of exactly what the agent would have taken on, with the reasons and the matching rule, before it takes on anything. Teams adopting any always-on agent should want that ledger, whichever vendor they pick.
The line that decides the pilot: it runs as you
Here is what the deployment doc says about privileges. Both presets, router and worker, “run with danger-full-access as the operator’s OS user.” Account wrappers “choose the agent’s credentials by default; they do not isolate the process.” And: “A worker can execute programs by path and read the operator’s home directory.” The execution doc adds that the per-ticket wrappers and directories “establish defaults, not a security boundary.”
DeepSeek does some sensible scrubbing. Setup strips environment variables whose names contain KEY, PASSWORD, SECRET or TOKEN, and the worker’s git config removes GH_TOKEN and GITHUB_TOKEN. That protects variables. It does not protect files. If the operator’s home directory holds cloud CLI credentials, SSH keys, a browser profile or a .netrc, the documentation’s own description of reach means a worker that is talked into reading them can read them. (That is my reading of the documented permissions, not a vulnerability anyone has reported.)
I spent two decades in IT operations at a large telecom, and the rule we never bent was that scheduled jobs did not run under a named engineer’s login. Not because engineers were careless, but because when the job did something strange at 3 a.m., the audit trail pointed at a person who was asleep, and everything that person could touch was in the blast radius. A coding agent that takes requests from a chat and executes shell commands without approval is that scheduled job with a language model deciding the arguments. DeepSeek’s own fix is the same one we used: “For isolation, use a dedicated OS account containing only the agent’s credentials.” It is a single sentence in a deployment doc. It should be step one.
The timing makes this sharper. Last week a trojanized Claude Code extension sat in Cursor’s marketplace for about 11 hours and planted a tunnel on developer machines. An agent running as your user, installed from a day-old research repository, inherits everything that user can reach. The agent does not need to be malicious for that to matter; a prompt injection in an issue comment is enough.
A pilot setup that keeps the blast radius small
If you want to try Super-agent, and the observe-mode design is reason enough to look, this order keeps the experiment contained.
- Create a dedicated OS account (or a VM or container) that holds nothing but the agent’s credentials and the DeepSeek Harness install. No personal SSH keys, no cloud CLI profiles, no shared drives mounted. This is the isolation DeepSeek recommends and does not enforce.
- Give the agent its own GitHub account with access to the one pilot repository and nothing else. The setup guide insists it be “A dedicated account, never the operator’s own,” because its work appears under that name. Scope its token to that repository with a fine-grained personal access token rather than a classic token that sees every repo the account can.
- Keep the allowed list to yourself for the first stretch, as the setup guide recommends. Every name you add is a person who can cause the agent to execute commands on that machine.
- Leave accept mode on observe and read the Eval tab for two weeks. Count how many inferred candidates it would have accepted and how many of those you would have wanted. That ratio is your evidence for or against ever turning on auto.
- Enforce merges in GitHub, not in the prompt. By default the executor never enables auto-merge as the agent account, and the default delivery instructions only allow auto-merge when “additions plus deletions total fewer than 200 lines.” But the doc is explicit: “These instructions govern the agent, not GitHub’s merge rules.” Set branch protection with required reviews and stale-approval dismissal, and do not give it another account’s merge CLI.
- Put a spending cap on the model provider. The execution doc caps background work at 30 minutes per turn, but describes no token, cost or turn-count budget. Whatever provider you wire into DeepSeek Harness, set the limit there.
- Pin the version and back up the database before upgrading. The deployment doc warns that “A database migrated by a newer version cannot be opened by an older one,” so rollback depends on the copy of
orchestrator.sqliteyou made first. With a research repo this young, read the diff before you pull.
One detail in the deployment doc deserves credit. The hourly health check that restarts the service is meant to live in your normal profile, not the agent’s, because “It must keep running when the agent service is down.” That separation (the thing that watches the agent sits outside what the agent controls) is the same lesson from OpenAI’s agents silencing the people their monitors reported to. Apply it to the merge rules and credentials too, and the pilot holds up.
Where it fits next to Claude Code and the hosted agents
Super-agent is not a drop-in replacement for Claude Code, and the Bloomberg framing oversells the comparison. It is a team orchestration layer that sits on top of an agent harness and a model you supply. The closer comparison is the always-on hosted agents: Claude Duet, OpenAI’s dots and Meta’s Muse all run in the vendor’s cloud VM, which means the vendor owns the isolation and you own the data question. Super-agent flips that. You own the box, the model choice and the data path, and therefore you own the isolation that the hosted products give you by default.
That trade suits a narrow set of teams today:
- Teams that need the code and prompts to stay on their own hardware, and are willing to pair it with a self-hosted or in-region model.
- Teams already on Feishu, since that is the only chat source in the prototype. Slack and Teams shops get GitHub mentions only.
- Teams on github.com, because GitHub Enterprise Server is not supported, per ShiftDelete’s read of the requirements. Many regulated enterprises are exactly the ones on GHES.
For everyone else, the practical value this week is the design, not the deployment. Explicit requests from an allowlist, inferred work gated by written rules, a shadow mode that logs what autonomy would have done, merge rights held by a different identity, and a watchdog outside the agent’s reach: that is a sound checklist for evaluating whichever agent you do buy. Ask your vendor where each of those five lives. If the answer is “in the prompt,” you have your answer about the sandbox and network boundary too.