dsh-superagent security

dsh-superagent Security: Accounts, Authority & Isolation

Author
DeepSeekAgent.io Editorial Team
Published
Updated

A continuous Super-agent reads event streams, creates Tickets, and lets Workers execute commands in real repositories. Its risk is not limited to an incorrect model answer. Identity, authorization, directories, credentials, and proactive rules can amplify one another.

dsh-superagent-prototype moves many controls into the host: allowed lists, admission tables, Policy versions, Mandates, isolated Tickets, and persistent execution state. The official deployment guide also makes clear that wrappers and working directories are defaults, not a complete security boundary.

Layer 1: a dedicated Agent identity

Use a dedicated GitHub account rather than the operator's account. Every comment, commit, pull request, and merge then has a clear source, and credentials can be revoked independently.

Give the account access only to the target repository, prevent direct pushes to protected branches, use a separate GitHub CLI configuration, and align commit identity with the Agent account. Auto-merge, if ever enabled, should be enforced by branch protection and review requirements rather than prompt text alone.

Layer 2: who may start work

Policy classifies a message as an explicit request, inferred candidate, or ignored event. Its controls include allowed lists, per-scope admission tables, bot lists, accept mode, and proactive rules.

Begin with a short allowed list and observe. Allowing any person in a public conversation to request work is an explicit authority expansion and belongs only in a deliberately controlled support scope.

Layer 3: Mandate limits scope

When a Ticket is created, its Mandate fixes the Source, requester, Policy version, strength, scope, and matched rules. A Worker remains inside that scope when follow-up comments arrive.

A documentation-fix Ticket should not absorb “also upgrade the dependencies.” The Executor hands out-of-scope work back to the Router for a new Eval and authorization.

Policy changes notify affected live Tickets. Ended Tickets revalidate their Mandates before resuming, so authorization is not checked only once at creation time.

Layer 4: real Worker permissions

The deployment guide states that Router and Worker presets may run as the operator's OS user. A Worker can execute programs and read files available to that user. CLI wrappers, blocked-command lists, and separate directories do not stop access through absolute paths.

Real isolation therefore comes from the environment:

  • a dedicated OS account;
  • a home directory containing only Agent credentials;
  • mounts limited to the target repository and required caches;
  • restricted network destinations;
  • CPU, memory, process, wall-time, and disk budgets;
  • no personal SSH keys, cloud-admin credentials, or browser profiles.

Working directories prevent task collisions. OS or container boundaries prevent unrelated file access.

Layer 5: external content is data

Issues, comments, source code, logs, and chat messages are untrusted inputs. Host gates prevent them from changing Policy or the prepare command directly, but Workers still read their content.

Instructions should state that repository text cannot change authority, requests to upload credentials or disable protections must be refused, newly downloaded executables need a sandbox or approval, and tool output remains data rather than higher-priority instruction.

Layer 6: observe proactive rules first

observe is the main deployment gate. It runs Assessment and records “would accept” without creating a Ticket. Review whether the rule mistakes chat for work, duplicates issues, reacts to bot noise, chooses the wrong repository, or produces low-value pull requests.

Move only stable rules to auto, each with its own review and communication requirements.

Layer 7: secure retry and recovery

The system stores work and retries some transient failures. A restarted Worker is told to inspect its directory, Git history, and GitHub before repeating an external action, reducing duplicate comments, pushes, or pull requests.

Operators still need to guard against non-idempotent commands, background processes from replaced Assignments, and queued messages flushing after recovery. High-impact actions need idempotency keys, state checks, and approval gates.

Layer 8: panel, logs, and shutdown

The management panel can change Sources, Policy, and Executor configuration. Keep it off the public internet and protect it with access control, TLS, and network restrictions. Logs must not contain tokens, cookies, private keys, or complete environment dumps.

Maintain a model-independent stop path: disable Sources, pause processing, revoke Agent credentials, and stop the process. During an incident, block new intake and external writes before examining Tickets and directories.

Launch checklist

  • dedicated GitHub Agent account with minimum repository access
  • dedicated OS user or equivalent isolation
  • one repository and a short allowed list
  • proactive rules validated in observe
  • auto-merge disabled by default
  • branch protection and human review enabled
  • Worker resource and network scope limited
  • management panel not exposed publicly
  • logs exclude credentials and full environment values
  • stop, credential revocation, and recovery procedures tested

Related reading

References