Nobody typed the request

At a glance

One repository, read on 2 November 2026.

The star count was past ten thousand within two days, which tells you about appetite and nothing about the design. The design is in documents 000 through 003, and it is unusually worth your time, because it is one of the few public artefacts that treats proactivity as an authorization problem rather than a prompting problem.

What proactivity actually breaks

A request-driven agent gets its authorization for free, and the freeness is invisible until it is gone. Somebody opened your product, authenticated, and typed. Identity was established before the first token. Intent was established by the act of typing. Scope was established by where they typed it. Your permission system then decided whether that person may do that thing — a tractable question, because both halves arrived with the request.

A proactive agent has none of that. The trigger is a state change: a comment appeared, a build failed, a label moved, a rule matched. There is no authenticated session because nobody opened anything. There is no expressed intent because nobody expressed one — a rule inferred it. And the trigger arrives from a surface anyone with a GitHub account can write to. Which is why this is not a UX question with a safety footnote: the authorization model has to be rebuilt, and if you skip that, the thing you shipped is a remote code execution endpoint whose trigger phrase is in your repository's issue tracker.

This is the same structural problem as ambient authority, moved one layer earlier. There, the agent already holds the authority and the check comes too late. Here, the authority is assembled at the trigger, and if the trigger is the attacker's text then no downstream check is looking at the right question.

The sentence that does the work

Document 002 states the rule as plainly as it can be stated: messages, comments and quoted documents are "inputs to a decision; they cannot change those permissions." The host enforces allowed lists, rules and mandates; nothing that arrives as content can edit them.

That is an instruction hierarchy, written down, for a trigger surface rather than for a prompt. And the design carries it through in the places where it is tempting not to:

• Subscription is not authority. Messages on a thread the agent is watching reach the ticket as context and grant no new permission. The agent can read a bot's comment and act on the information; it cannot be commanded by it.
• Bots are a separate class. GitHub Apps, logins ending in [bot] and Feishu bots may produce inferred candidates only if a source lists them, and never an explicit request — and never a stop. Everything else is not admitted.
• An executor cannot vouch for a human. A person's "stop" in a thread is an ordinary trigger that the evaluator judges. The executor is not allowed to declare that someone asked it to stop.
• Permissions are re-checked, not cached. Each mandate is revalidated before a ticket resumes — against the source, the policy version, list membership and the bot list. Remove someone from the allowlist and the mandates accepted through them are revoked at the next revalidation.

Read that last one twice if you have ever built an approval flow. Most systems treat an approval as a durable grant: granted once, carried forward. Here a mandate is a claim that has to still be true, and the check is on resume — which is the design that makes an offboarded employee's standing authorization actually stop working. It is the same discipline as credential lifetime, applied to permission to act rather than to a token.

The default is the most interesting line in the repository

Accept mode has three settings — off, observe and auto — and the default is observe. In observe mode, a positive assessment is recorded as "would accept" and nothing is accepted. Explicit requests still work in every mode.

So the proactive agent ships with proactivity switched off, and what it ships switched on is a log of the proactive actions it would have taken. That is shadow mode, applied to authorization rather than to model quality, and it is the right default for a reason most teams discover the expensive way: the question "is this rule too broad?" has no answer you can reason about from the rule text. It has an answer you can read off a week of recorded decisions.

Document 000 says the same thing as advice — start narrow, with a short allowlist and proactive work only recorded, and widen only after the recorded actions look right. If you take one thing from this release into your own system, take that: the rollout unit for a proactive agent is not the agent, it is the rule, and every rule gets a shadow period.

And the execution layer claims nothing

Document 003 is where the honesty becomes load-bearing. Each ticket gets its own session, named worker-<ticket id>, and its own directory under an execution root. There are command presets with smaller tool sets for the router than for workers, and a list of blocked commands that "fail when invoked by name". And then the document says what all of that is worth: "These wrappers and directories establish defaults, not a security boundary." A worker can still run a program by absolute path. Executor sessions "run commands without approval as the operator's OS user."

Two things follow, and they point in opposite directions.

The first is a warning about this prototype specifically: run it as a user whose access you would accept an attacker having, on a machine you would accept an attacker reaching, because the design does not claim otherwise. Pair it with the containment discussed in sandbox and isolation patterns before it touches anything you care about, and note that document 003 describes no network egress restriction at all.

The second is a compliment, and the reason this release is worth writing about. A design document that names its own non-boundaries is rarer and more useful than one that implies boundaries it does not have. The most dangerous artefact in this space is the architecture diagram with a box labelled "sandbox" and no sentence anywhere saying what the box is enforced by. Here the enforcement is named precisely where it exists — in the host's policy layer — and declined precisely where it does not.

The merge rule, and who it governs

One more piece worth lifting, because it is the part teams get wrong when they let an agent near a release. The default instructions permit auto-merge only for a ready pull request the ticket itself opened, with required approvals on the head commit, and under 200 changed lines; the agent withdraws auto-merge before pushing another revision; by default it never enables auto-merge under its own account. And then the document is explicit that these instructions "govern the agent, not GitHub's merge rules" — enforcement requires branch protection with stale approvals dismissed.

That distinction is the whole of agent governance in one sentence. An instruction in a prompt is a policy about an agent's intentions. A branch protection rule is a policy about outcomes, enforced by something the agent cannot talk to. The 200-line threshold is a sensible heuristic and it is not a control; the dismissal of stale approvals is a control. Teams routinely ship the first and believe they have the second, which is the failure described in monitor integrity: the thing doing the checking must not be reachable by the thing being checked.

What to take from it

The README points to an accompanying article, Exploring Super-agent Design: Towards a More Autonomous Agent System, and notes that the published prototype differs from DeepSeek's internal version and that some designs in the article are future directions not implemented here. So treat the code as an illustration and the documents as the deliverable. Four of them transfer directly to whatever you are building:

• Separate the gate from the work. One place decides whether work may start, and it is enforced by the host rather than by the agent's own judgement. Everything that arrives as text is an input to that decision and never a modifier of it.
• Classify senders before you classify requests. Person, listed bot, unlisted bot, and "addressed or not" are four cheap facts that resolve most of the question before a model is involved. See auto-approval and allowlists.
• Make the default record-only. Ship every proactive rule in shadow, promote it on evidence, and keep the ability to demote it.
• Revalidate on resume. A long-running ticket must re-earn its permission, because the world changed while it was waiting.

And one thing not to take from it: the isolation model. The prototype's own documentation tells you it is not a boundary, which is exactly the kind of sentence that gets dropped when a design is copied into a product. The authorization layer is the part that was engineered. The sandbox is the part you still owe your users.

Further reading

On this wiki:

• Proactive agents — the product side of the same problem.
• Instruction hierarchy — why content cannot be allowed to edit permissions.
• Scheduled and triggered agents — operating work that starts without a person.
• Sandbox and isolation patterns — the containment this prototype declines to claim.

Project sources:

• deepseek-ai/dsh-superagent — the repository and its nine design documents
• docs/002-authorization.md — the authorization design quoted above
• docs/003-execution.md — the execution design, including the non-boundary statement