The design separates an incoming request or approved automation rule from a durable Ticket and its assigned Executor Session. Workers may continue with shell commands, background jobs and subagents after an individual message ends. The system documentation explicitly states that shell executes with the operator user privileges without a separate approval…
Inspect the ClaimsCase · DiggingBeagle record
DeepSeek superagent prototype gives durable mandates to shell-capable worker sessions
A research prototype gives ticket workers standing execution mandates and runs shell jobs as the operator OS user without per-command approval.
Scope
The public material is prototype documentation, not evidence of a demonstrated exploit, production reliability or successful mandate revocation.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- not established
- Evidence
- Grade C
- Remediation
- not applicable
- AI role
- WITH AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The source is primary to the described analysis, not independent replication of every outcome. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-DEEPSEEK-SUPERAGENT-MANDATES-A · DeepSeek dsh-superagent prototype, authorization and execution design
At a glance
Long-lived authorization for an agent is only as narrow as the executor tools and OS identity it controls, particularly after a rule changes.
Read the implicationsThe public material is prototype documentation, not evidence of a demonstrated exploit, production reliability or successful mandate revocation. How already-running work responds to a revoked mandate, changed repository protection or withdrawn external credential remains unmeasured.
Limits and uncertaintyFull account
The design separates an incoming request or approved automation rule from a durable Ticket and its assigned Executor Session. Workers may continue with shell commands, background jobs and subagents after an individual message ends. The system documentation explicitly states that shell executes with the operator user privileges without a separate approval for each command. This is an authority architecture to examine, not evidence that the published prototype was compromised. The security question is whether changing or revoking a mandate stops already-started effects.
The prototype distinguishes off, observe and auto operation, with persistent Tickets and Mandates determining whether work should be admitted. Once admitted, execution can run local shell tools with the operating-system authority of the worker; a mandate is not equivalent to an OS sandbox. This creates a second, time-dependent boundary: an instruction approved for one repository and policy revision may be acted on after conditions have changed. The public implementation documents intended governance, not a measured success rate for revocations or containment under a compromised worker.
Mechanism and trust boundary
- 01
Authorize a mandate
Operator-defined rules or a user request admit work into a persistent Ticket.
Boundary: Request authorization into durable agent mandate
- 02
Execute under operator OS identity
A worker session may run shell tools without per-command approval.
Boundary: Agent plan into operating system privileges
- 03
Continue background work
Tickets can retain jobs beyond a single turn until policy or lifecycle ends.
Boundary: Temporary conversation into ongoing effects
Claims & evidence
CLM-2026-NOV02-DEEPSEEK-SUPERAGENT-MANDATES-AThe DeepSeek superagent prototype documentation states that Executor Sessions execute shell commands without per-command approval as the operator operating-system user; ticket and mandate rules gate admission at an earlier boundary.supported
Basis: reported finding
- supportsDeepSeek dsh-superagent prototype, authorization and execution designprimary disclosure
Execution design: Executor Sessions and background work; linked authorization design
Implications
Long-lived authorization for an agent is only as narrow as the executor tools and OS identity it controls, particularly after a rule changes.
Controls and mitigations
- Test mandate revocation, exact tool scopes and post-cancellation jobs with harmless side effects; isolate worker OS permissions.
- Record mandate and policy revisions with every executed side effect, reject stale authority at execution, and isolate the worker OS identity from deployment credentials.
Unknowns and contradictions
- The public material is prototype documentation, not evidence of a demonstrated exploit, production reliability or successful mandate revocation.
- How already-running work responds to a revoked mandate, changed repository protection or withdrawn external credential remains unmeasured.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214