Como configurar o DeepSeek Super Agent em segurança: contas, permissões e isolamento

Não comece uma experiência com o dsh-superagent usando a sua conta habitual nem num repositório de produção valioso. A documentação de implementação indica que as predefinições do router e do worker são executadas com danger-full-access como utilizador do sistema operativo e podem ler a pasta pessoal desse utilizador. Deve criar uma conta dedicada e um repositório descartável antes da instalação e dos testes, e não depois da primeira ação inesperada.

O repositório público é um protótipo de investigação, não um produto DeepSeek oficial e pronto para produção. Este guia transforma as predefinições documentadas num plano de configuração prudente: identidades separadas, acesso restrito ao repositório, regras de admissão revistas, execução controlada e um procedimento de paragem testado. Introduza as credenciais apenas através do seu próprio terminal aprovado ou do fluxo de gestão de segredos, nunca numa conversa de chat.

O dsh-superagent está pronto para produção?

O README afirma explicitamente que se trata de código de investigação e que a implementação publicada difere do sistema interno e de algumas ideias do artigo de conceção associado. Este estatuto deve ter destaque numa decisão de implementação. A disponibilidade pública permite inspecionar a conceção, mas não garante que o código esteja pronto para operações sensíveis.

Este guia foi verificado com base na revisão 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 em 5 de novembro de 2026. Fixe e registe a revisão que efetivamente analisar. Se atualizar posteriormente a cópia de trabalho, volte a verificar os pré-requisitos, as permissões, as predefinições e as migrações de configuração antes de a executar novamente.

O documento de configuração descreve um fluxo de trabalho interativo de planeamento e confirmação. Reveja o plano antes da execução. Não interprete a instrução para pedir a ajuda de um agente de programação na configuração como autorização para aceder a credenciais sem relação com essa tarefa ou instalar no seu perfil de trabalho habitual.

O primeiro objetivo de aceitação deve ser modesto: um pedido inofensivo produz uma tarefa compreensível e um resultado que pode ser revisto num repositório descartável. Teste também o comportamento de rejeição e de paragem. Uma demonstração bem-sucedida do percurso ideal não comprova a fiabilidade em produção nem justifica alargar imediatamente o acesso.

Porquê usar uma conta dedicada do sistema operativo?

A guia de implementação torna explícita a premissa de acesso ao anfitrião. Diretórios de sessão separados e wrappers de credenciais não isolam o processo. Um worker pode executar programas e aceder aos ficheiros permitidos à conta que o executa, incluindo a pasta pessoal dessa conta.

Crie uma conta dedicada que contenha apenas os ficheiros e as credenciais necessários para a experiência. Mantenha as chaves SSH pessoais, as credenciais de administrador da nuvem, os perfis do navegador, a configuração de produção e os repositórios não relacionados fora do ambiente a que a conta pode aceder. Reveja a pertença a grupos e o armazenamento montado, além do diretório pessoal da conta.

Para obter uma separação mais forte, considere uma máquina virtual descartável dedicada ou um ambiente de anfitrião sujeito a controlo semelhante. Não parta do princípio de que um contentor é suficiente só por ter uma vista diferente do sistema de ficheiros; são as montagens, os privilégios, os sockets e a rede que determinam os limites efetivos. A decisão de implementação deve refletir o valor do anfitrião e do código executado.

A nossa visita guiada à arquitetura explica por que razão estes controlos se situam em camadas diferentes. Manter as camadas separadas evita que uma salvaguarda limitada, como uma lista curta de solicitantes, seja confundida com um isolamento abrangente.

Capa: repositório do protótipo dsh-superagent, cartão de repositório gerado pelo GitHub. Os metadados do repositório são uma ilustração datada, não uma alegação de adoção ou desempenho.

Como criar uma identidade de agente GitHub?

Utilize a abordagem de conta de utilizador GitHub dedicada exigida pelo protótipo atual, em vez da sua conta pessoal. O guia de implementação indica que esta implementação lê as notificações da conta e não permite substituir a identidade do agente por uma GitHub App. Trata-se de uma limitação da implementação, não de uma recomendação geral contra as GitHub Apps noutros sistemas.

Conceda inicialmente acesso apenas ao repositório de teste descartável. Mantenha a configuração de início de sessão do agente separada da sua. Utilize a abordagem documentada com wrapper ou uma configuração equivalente aprovada e confirme que conta a CLI está a utilizar antes de permitir que o processo execute ações. Não deduza a identidade a partir de um nome apresentado numa conversa.

As orientações do GitHub sobre tokens explicam as opções de permissões e expiração. Selecione o nível mínimo de acesso suportado necessário para as operações documentadas do protótipo, reveja quaisquer requisitos de compatibilidade e mantenha uma forma de revogar o acesso. Evite conceder à conta capacidades de administração da organização ou de implementação em produção por conveniência.

Numa experiência inicial, deixe a integração a cargo de pessoas. Um agente que pode enviar uma ramificação e abrir um pedido de integração não precisa também de ter autoridade para alterar as proteções do repositório ou aceitar o próprio trabalho. A identidade deve deixar a autoria clara e preservar uma decisão de aceitação independente.

Como funcionam as listas de utilizadores autorizados e as políticas de admissão?

O documento de autorização distingue pedidos explícitos, candidatos inferidos e entradas não admitidas. Tanto as identidades autorizadas como as definições de admissão específicas do âmbito são importantes. Uma lista de permissões curta é útil, mas deve ser revista em conjunto com o âmbito de receção e as regras, em vez de ser tratada como o único controlo.

Comece com um solicitante conhecido e um repositório. Se o Feishu não for necessário para o teste, deixe-o por configurar. Cada fonte adicional cria outro local onde é necessário verificar a identidade, o âmbito de receção, o comportamento do bot e a autorização para iniciar trabalho. Adicione fontes apenas quando o primeiro fluxo de trabalho estiver compreendido.

Teste o comportamento das políticas com exemplos inofensivos. Confirme o que acontece quando uma pessoa autorizada se dirige ao agente, quando alguém publica uma discussão não relacionada e quando um pedido de seguimento solicita trabalho fora da tarefa existente. Inspecione o registo de decisões em vez de presumir que não ocorreu nenhuma ação por não haver uma resposta visível.

O conteúdo dos repositórios e as mensagens citadas devem continuar a ser provas, não atualizações de políticas. Uma instrução incorporada num problema ou documento não deve conceder acesso silenciosamente nem alterar quem pode solicitar trabalho. A nossa comparação do proactive-agent explica porque é que os fluxos de trabalho ligados a eventos tornam esta distinção mais importante do que numa única sessão de conversação supervisionada.

Porquê começar pelo modo de observação?

No modo predefinido documentado observe, o sistema avalia os candidatos inferidos e regista quais seriam aceites sem os aceitar automaticamente. Isto é útil para perceber como se comportam as regras configuradas. Não impede a execução de pedidos explícitos autorizados, pelo que não é um modo global de apenas leitura ou de inatividade.

Mantenha restritas as permissões técnicas da experiência, mesmo durante a observação. Se o objetivo for inspecionar o encaminhamento sem permitir alterações valiosas, utilize recursos descartáveis e imponha esse limite através da configuração do anfitrião e do repositório. Não confie num rótulo de modo para proteger ativos a que o processo já consegue aceder.

Reveja tanto as decisões positivas como as negativas. Uma regra demasiado permissiva pode gerar trabalho indesejado, enquanto uma regra demasiado restritiva pode deixar passar silenciosamente tarefas esperadas. Registe o motivo da diferença entre o resultado esperado e o observado antes de editar a política. Alargar repetidamente as regras até uma demonstração funcionar não é uma boa forma de estabelecer uma configuração predefinida segura.

Não mude para auto como etapa habitual de instalação. Esse modo aumenta a capacidade do sistema para iniciar tarefas inferidas que correspondam às regras. Qualquer expansão posterior deve ter um responsável explícito, um conjunto de regras revisto, um registo de avaliação controlado e um método testado para interromper ou revogar o acesso.

Como proteger tokens, segredos e ficheiros locais?

Mantenha as credenciais fora dos prompts, dos ficheiros do repositório, das capturas de ecrã e dos registos comuns. Utilize o início de sessão por CLI aprovado ou o armazenamento de segredos no ambiente dedicado. As orientações da OWASP sobre gestão de segredos fornecem informações sobre controlo de acesso e ciclo de vida, mas o requisito imediato é simples: o ambiente do agente não deve conter credenciais sem relação com a tarefa.

Analise também o percurso até ao fornecedor do modelo, além da identidade do GitHub. O código e os prompts podem ser tratados pelo fornecedor configurado, e as ferramentas podem introduzir destinos adicionais. Um checkout local não implica inferência local nem tratamento exclusivamente local. Confirme que o fornecedor selecionado e a configuração dos registos estão aprovados para o material de teste.

Evite copiar um diretório pessoal ou a configuração da shell para a conta dedicada só para facilitar a configuração. Isso pode incluir auxiliares de credenciais, variáveis de ambiente, configurações da cloud e histórico privado. Recrie deliberadamente apenas as dependências mínimas e mantenha um inventário, sem dados secretos, do que foi adicionado.

A nossa lista de verificação do acesso do agente pessoal inclui uma etapa de preparação relacionada. Antes da primeira execução, verifique no ambiente real do agente a que diretórios, credenciais, serviços e destinos de rede é possível aceder. Se o acesso for mais amplo do que o necessário para o teste, corrija os limites antes de avançar.

Como isolar o repositório e rever as alterações?

Utilize um repositório descartável com exemplos sintéticos e sem segredos de produção. A documentação de configuração indica pré-requisitos, incluindo uma versão compatível do Node.js, pnpm, Git, tmux, Python, GitHub CLI e DeepSeek Harness. Consulte o package.json atual e o guia de configuração para confirmar a compatibilidade exata, em vez de instalar versões arbitrárias com base numa lista antiga de comandos.

Siga esta sequência de preparação antes de executar o plano de instalação:

1. Prepare a conta dedicada ou o anfitrião descartável e confirme os limites de acesso.
2. Crie a identidade dedicada do GitHub e um repositório de teste com as permissões limitadas adequadas.
3. Obtenha o protótipo, registe a respetiva revisão e reveja os documentos de configuração e implementação.
4. Reveja o plano de instalação proposto, o fornecedor do modelo, o perfil, a localização do estado e o mecanismo de credenciais.
5. Configure a receção de tarefas apenas pelo GitHub, uma lista curta de solicitantes, o modo observe e nenhuma integração automática para o primeiro teste.
6. Inicie a configuração revista e inspecione o estado de funcionamento e os requisitos de configuração.
7. Envie uma tarefa autorizada e inofensiva e reveja o estado resultante e a alteração proposta.
8. Teste uma entrada irrelevante, uma ampliação do âmbito e um procedimento de paragem antes de ponderar conceder um acesso mais alargado.

O comando de estado documentado é útil após a configuração:

scripts/dsh-superagent status

Execute-o a partir da cópia de trabalho revista, no ambiente dedicado. Interprete o resultado de acordo com o guia de implementação atual; um processo em execução não equivale a uma origem e política saudáveis e corretamente configuradas.

Mantenha em vigor os requisitos para ramos protegidos e a revisão humana. Inspecione as diferenças, as revisões inicial e final, os testes e os pressupostos por resolver. Utilize cópias independentes para dados valiosos; o nosso guia de ficheiros recuperáveis explica por que motivo a recuperação deve ser planeada antes de conceder acesso de escrita.

Como parar o agente e revogar o acesso?

Documente o procedimento de paragem antes da primeira tarefa. O guia de implementação atual fornece um comando para uma paragem normal:

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

Uma paragem normal pode aguardar que a execução termine; não prova que todos os efeitos externos tenham sido anulados. Inspecione o trabalho pendente e a atividade relevante do repositório. Não substitua a compreensão do que o processo está a fazer pelo encerramento forçado de sessões não relacionadas.

Em caso de incidente de acesso ou de uma experiência abandonada, revogue as credenciais dedicadas e o acesso ao repositório através dos controlos adequados do fornecedor. Interrompa a receção de tarefas e inspecione os processos ou serviços em segundo plano restantes. Guarde um registo não confidencial da tarefa afetada, da revisão e da atividade relevante, para que a equipa possa reconstituir o sucedido.

A limpeza e a recuperação são tarefas distintas. Eliminar um diretório local não revoga um token, não fecha um pull request remoto nem anula uma alteração enviada. Decida separadamente o que deve acontecer a cada artefacto e preserve as provas necessárias antes de o remover. Só alargue a experiência depois de a interrupção, a revogação e a recuperação serem tão claras como o arranque.

Para avaliar o resultado propriamente dito, utilize o procedimento de revisão de agentic-autofix. Um processo saudável e uma tarefa aceite são sinais operacionais; não comprovam que a correção proposta deva ser integrada.

Perguntas frequentes

Posso executar o protótipo a partir da minha conta de programador habitual?

Isso expõe ao processo os ficheiros e as credenciais a que a conta pode aceder. Utilize um ambiente dedicado e limitado para a primeira experiência, sobretudo tendo em conta as predefinições documentadas de acesso total.

O modo de observação torna o protótipo só de leitura?

Não. Limita a aceitação de candidatos inferidos, mas os pedidos explícitos autorizados continuam a poder ser executados. Se o objetivo do teste for impedir qualquer escrita, imponha esse limite através das permissões.

Posso utilizar uma GitHub App em vez de uma conta de utilizador dedicada?

O guia de implementação do protótipo analisado exige uma conta de utilizador devido ao seu fluxo de trabalho de notificações. Volte a verificar as revisões posteriores antes de assumir que essa limitação de compatibilidade continua em vigor.

Devo colar os tokens de configuração na conversa com o agente assistente?

Não. Utilize a autenticação CLI aprovada ou um sistema de armazenamento de segredos no seu próprio ambiente controlado. O processo de configuração não exige que exponha valores secretos na conversa.

O que comprova que é seguro alargar o ensaio inicial?

Nenhum teste isolado comprova a segurança geral. Reveja as decisões de admissão, os limites das permissões, as alterações propostas, o comportamento de interrupção e as provas de recuperação; depois, autorize apenas um âmbito adicional específico.

Conclusão

Configurar o dsh-superagent em segurança começa por compreender as suas condições de funcionamento reais: estatuto de investigação, execução com acesso total através do utilizador anfitrião e um modo de observação que ainda permite realizar tarefas explícitas. Identidades dedicadas, recursos descartáveis e revisão independente são pré-requisitos para perceber como o protótipo se comporta.

Mantenha a primeira tarefa limitada, teste deliberadamente tanto a rejeição como a interrupção, e preserve as provas por detrás de cada alteração aceite. Não transforme uma experiência de investigação útil numa implementação em produção, acumulando gradualmente credenciais e permissões sem uma nova revisão.