How to Set Up DeepSeek Super Agent Safely: Accounts, Permissions, and Isolation

Do not begin a dsh-superagent experiment under your everyday account or against a valuable production repository. Its deployment documentation says both router and worker presets run with danger-full-access as the operating-system user and may read that user's home directory. A dedicated account and disposable repository should come before installation and testing, not after the first unexpected action.

The public repository is a research prototype, not an official production-ready DeepSeek product. This guide turns its documented defaults into a cautious setup plan: separate identities, narrow repository access, reviewed admission rules, controlled execution, and a tested stop procedure. Enter credentials only through your own approved terminal or secret-management workflow, never into a chat conversation.

Is dsh-superagent Ready for Production?

The README explicitly says it is research code and that the published implementation differs from the internal system and some ideas in the associated design article. That status should be prominent in a deployment decision. Public availability is an opportunity to inspect the design, not assurance that the code is ready for sensitive operations.

This guide was checked against revision 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 on November 5, 2026. Pin and record the revision you actually review. If you later update the checkout, recheck prerequisites, permissions, presets, and configuration migrations before running it again.

The setup document describes an interactive plan-and-confirm workflow. Review the plan before execution. Do not treat the instruction to let a coding agent help with setup as permission for it to access unrelated credentials or install into your ordinary working profile.

The first acceptance target should be modest: one harmless request produces an understandable task and a reviewable result in a disposable repository. Test rejection and stopping behavior too. A successful happy-path demonstration does not establish production reliability or justify expanding access immediately.

Why Use a Dedicated Operating-System Account?

The deployment guide makes the host-access assumption explicit. Separate session directories and credential wrappers do not isolate the process. A worker can execute programs and access files permitted to the account running it, including that account's home directory.

Create a dedicated account containing only the files and credentials needed for the experiment. Keep personal SSH keys, cloud administrator credentials, browser profiles, production configuration, and unrelated repositories outside its accessible environment. Review group membership and mounted storage as well as the account's home directory.

For stronger separation, consider a dedicated disposable virtual machine or similarly controlled host environment. Do not assume that a container is sufficient merely because it has a different filesystem view; mounts, privileges, sockets, and networking determine the actual boundary. The deployment decision should reflect the value of the host and the code being executed.

Our architecture walkthrough explains why these controls sit at different layers. Keeping the layers separate prevents a narrow safeguard, such as a short requester list, from being mistaken for comprehensive isolation.

Cover: dsh-superagent prototype repository, GitHub-generated repository card. Repository metadata is a dated illustration, not an adoption or performance claim.

How Should You Create a GitHub Agent Identity?

Use the dedicated GitHub user-account approach required by the current prototype, rather than your personal account. The deployment guide says this implementation reads the account's notifications and does not support substituting a GitHub App as the agent identity. That is an implementation constraint, not a general recommendation against GitHub Apps in other systems.

Grant access only to the disposable test repository initially. Keep the agent's login configuration separate from your own. Use the documented wrapper approach or an equivalent approved configuration and verify which account the CLI is using before allowing the process to act. Do not infer identity from a display name in a chat.

GitHub's token guidance explains permission and expiration options. Select the minimum supported access needed for the prototype's documented operations, review any compatibility requirements, and retain a revocation route. Avoid giving the account organization administration or production deployment capabilities as a convenience.

For an initial experiment, leave merging to people. An agent that can push a branch and open a pull request does not also need authority to change repository protections or accept its own work. The identity should make authorship clear while preserving an independent acceptance decision.

How Do Allowed-User Lists and Admission Policies Work?

The authorization document distinguishes explicit requests, inferred candidates, and inputs that are not admitted. Allowed identities and scope-specific admission settings both matter. A short allowlist is useful, but it should be reviewed together with the receiving scope and rules rather than treated as the only control.

Begin with one known requester and one repository. If Feishu is unnecessary for the test, leave it unconfigured. Every additional source creates another place to verify identity, receiving scope, bot behavior, and permission to initiate work. Add sources only when the first workflow is understood.

Test policy behavior with harmless examples. Confirm what happens when an allowed person addresses the agent, when someone posts unrelated discussion, and when a follow-up requests work outside the existing task. Inspect the decision record instead of assuming that no visible reply means no action occurred.

Repository content and quoted messages should remain evidence, not policy updates. An instruction embedded in an issue or document must not silently grant access or change who may request work. Our proactive-agent comparison explains why event-connected workflows make that distinction more important than in a single supervised chat session.

Why Start With Observe Mode?

In the documented default observe mode, the system assesses inferred candidates and records which would be accepted without accepting them automatically. This is useful for learning how configured rules behave. It does not prevent authorized explicit requests from executing, so it is not a global read-only or no-action mode.

Keep the experiment's technical permissions narrow even while observing. If the objective is to inspect routing without allowing valuable changes, use disposable resources and enforce that boundary through the host and repository configuration. Do not rely on a mode label to protect assets the process can already access.

Review both positive and negative decisions. A rule that accepts too much can create unwanted work, while a rule that accepts too little can quietly miss expected tasks. Record why the expected outcome differs from the observed one before editing policy. Repeatedly broadening the rules until a demonstration works is a poor way to establish a safe default.

Do not switch to auto as a routine installation step. That mode increases the system's ability to start inferred work under matching rules. Any later expansion should have an explicit owner, a reviewed rule set, a controlled evaluation record, and a tested way to stop or revoke access.

How Should Tokens, Secrets, and Local Files Be Protected?

Keep credentials outside prompts, repository files, screenshots, and ordinary logs. Use approved CLI sign-in or secret storage in the dedicated environment. The OWASP secrets-management guidance offers background on access control and lifecycle, but the immediate requirement is simple: the agent environment should contain no credential unrelated to its task.

Review the model-provider path as well as the GitHub identity. Code and prompts may be processed by the configured provider, and tools can introduce additional destinations. Local checkout does not imply local inference or local-only handling. Confirm that the selected provider and logging configuration are approved for the test material.

Avoid copying a personal home directory or shell configuration into the dedicated account to make setup easier. It may bring credential helpers, environment variables, cloud configuration, and private history. Recreate the minimum dependencies deliberately and keep a non-secret inventory of what was added.

Our personal-agent access checklist provides a related preparation step. Before first execution, verify from the agent's actual environment which directories, credentials, services, and network destinations are reachable. If the answer is broader than the test requires, fix the boundary before proceeding.

How Do You Isolate the Repository and Review Changes?

Use a disposable repository containing synthetic examples and no production secrets. The setup documentation names prerequisites including a compatible Node.js version, pnpm, Git, tmux, Python, GitHub CLI, and DeepSeek Harness. Check the current package.json and setup guide for exact compatibility instead of installing arbitrary versions from an old command list.

Follow this preparation sequence before running the installation plan:

1. Provision the dedicated account or disposable host and confirm its access boundaries.
2. Create the dedicated GitHub identity and test repository with appropriate limited permissions.
3. Retrieve the prototype, record its revision, and review its setup and deployment documents.
4. Review the proposed installation plan, model provider, profile, state location, and credential mechanism.
5. Configure GitHub-only intake, a short requester list, observe, and no automatic merge for the first trial.
6. Start the reviewed configuration and inspect health and setup requirements.
7. Submit one harmless authorized task and review the resulting state and proposed change.
8. Exercise irrelevant input, a scope expansion, and a stop procedure before considering broader access.

The documented status command is useful after setup:

scripts/dsh-superagent status

Run it from the reviewed checkout in the dedicated environment. Interpret its output using the current deployment guide; a running process is not the same as a healthy, correctly configured source and policy.

Keep protected-branch requirements and human review in place. Inspect the diff, starting and final revisions, tests, and unresolved assumptions. Use independent copies for valuable data; our recoverable-file guide explains why recovery must be planned before granting write access.

How Do You Stop the Agent and Revoke Access?

Document the stop procedure before the first task. The current deployment guide provides a graceful stop command:

scripts/dsh-superagent stop
scripts/dsh-superagent status

A graceful stop can wait for execution to settle; it is not proof that every external effect has been undone. Inspect outstanding work and relevant repository activity. Do not substitute force-killing unrelated sessions for understanding what the process is doing.

For an access incident or an abandoned experiment, withdraw the dedicated credentials and repository access through the appropriate provider controls. Stop intake and inspect remaining background processes or services. Preserve a non-secret record of the affected task, revision, and relevant activity so the team can reconstruct the event.

Cleanup and recovery are different tasks. Deleting a local directory does not revoke a token, close a remote pull request, or undo a pushed change. Decide separately what should happen to each artifact, and retain needed evidence before removal. Expand the experiment only after stopping, revocation, and recovery are as understandable as starting it.

For the result itself, use the agentic-autofix review procedure. A healthy process and an admitted task are operational signals; they do not establish that its proposed patch should be merged.

FAQ

Can I run the prototype from my normal developer account?

That exposes the account's accessible files and credentials to the process. Use a dedicated, limited environment for the first experiment, especially given the documented full-access presets.

Does observe mode make the prototype read-only?

No. It limits acceptance of inferred candidates, while explicit authorized requests can still execute. Enforce a no-write boundary through permissions if that is the test objective.

Can I use a GitHub App instead of a dedicated user account?

The inspected prototype's deployment guide requires a user account because of its notification workflow. Recheck later revisions before assuming that compatibility constraint is unchanged.

Should I paste setup tokens into the assisting agent's chat?

No. Use approved CLI authentication or secret storage in your own controlled environment. The setup process does not require exposing secret values in conversation.

What proves that the initial trial is safe to expand?

No single test proves general safety. Review intake decisions, permission boundaries, proposed changes, stopping behavior, and recovery evidence, then authorize only a specific additional scope.

Conclusion

Setting up dsh-superagent safely begins with its real operating assumptions: research status, full-access execution under the host user, and an observation mode that still permits explicit work. Dedicated identities, disposable resources, and independent review are prerequisites for learning how the prototype behaves.

Keep the first task narrow, test rejection and stopping as deliberately as success, and preserve the evidence behind every accepted change. Do not turn a useful research experiment into a production deployment by gradually accumulating credentials and authority without a new review.