Guia · Atualizado em 10 de novembro de 2026 · Por Cameron Voss e West Mao
DeepSeek SuperAgent Security: permissões, modo de observação e configuração segura (novembro de 2026)
Uma lista de verificação de segurança prática para avaliar o protótipo de pesquisa em um repositório GitHub.
Comece com um repositório descartável, uma conta GitHub exclusiva para o agente, uma lista restrita de solicitantes autorizados e um ambiente de execução isolado. Mantenha a revisão humana e a proteção de branches. O modo Observe limita tarefas inferidas, mas não impede solicitações explícitas nem isola o worker em uma sandbox.
DeepSeek SuperAgent é um protótipo de pesquisa construído no DeepSeek Harness, não um produto oficial da DeepSeek ou software pronto para produção. Ele precisa de um provedor de modelo configurado separadamente. Este guia segue a documentação publicada; não executamos uma implantação completa para este artigo.
O protótipo público coordena o trabalho do agente nas conversas do GitHub. Um plano de segurança deve considerar quem pode solicitar trabalho e o que o worker resultante pode alcançar. Este artigo explica o projeto documentado e recomenda um teste restrito; não é uma certificação de segurança nem o resultado de um teste de penetração.
O que o agente pode acessar quando é executado?
A documentação de implantação publicada diz que suas predefinições de roteador e de trabalho são executadas com danger-full-access como usuário do sistema operacional do serviço. Um trabalhador pode executar programas e ler arquivos disponíveis para esse usuário. Ele também pode usar as credenciais do GitHub do agente para interagir com seu repositório configurado.
Uma identidade GitHub dedicada é útil para atribuição e limitação de acesso ao repositório, mas não isola o processo local. Um diretório por ticket ou árvore de trabalho Git separa as alterações para organização; ele não bloqueia o acesso ao sistema de arquivos, à rede ou a credenciais.
O que o modo de observação realmente faz?
| Modo de aceitação | Candidatos inferidos | Solicitação autorizada explícita |
|---|---|---|
off | A atividade inferida não se torna uma candidata. | Ainda pode ser aceito. |
observe | Avaliado; um resultado positivo é registrado como “aceitaria” sem iniciar o trabalho inferido. | Ainda pode ser aceito. |
auto | Uma avaliação positiva pode aceitar trabalho quando uma regra habilitada corresponde. | Ainda pode ser aceita. |
Comece em observe para inspecionar se as regras gerariam trabalho útil ou barulhento. É uma configuração de política para atividades inferidas, não uma opção de simulação para todas as ações do agente. A solicitação endereçada de uma pessoa permitida pode criar um ticket e executar um trabalhador em qualquer um desses modos.
Quem pode começar a trabalhar e quem pode continuar uma conversa?
O host aplica políticas de origem e listas permitidas ao decidir se deve admitir uma nova solicitação. Uma pessoa autorizada que se dirige ao agente pode fazer uma solicitação explícita. Outras mensagens podem ser avaliadas como candidatas inferidas de acordo com a política de origem.
Depois que um ticket se inscreve em um thread, as mensagens nesse thread podem acessá-lo como contexto, incluindo mensagens de bot e CI. Eles não concedem nova autoridade por si próprios: o mandato do bilhete ainda define o seu âmbito. A documentação também diz que a mensagem de uma pessoa no próprio tópico de um ticket finalizado pode retomar esse trabalho, independentemente do remetente. Para um repositório público, considere quem pode postar ou influenciar material em tópicos assinados; uma pequena lista de permissões de solicitantes por si só não torna todas as entradas posteriores confiáveis.
Como se proteger contra injeção de prompt?
Nenhuma configuração elimina isso. Corpos de problemas, comentários, logs e arquivos de repositório podem conter instruções de pessoas que não deveriam controlar o agente. O modelo de autorização documentado trata essas mensagens como entradas em vez de alterações de permissão, mas um modelo ainda pode interpretar mal o conteúdo hostil ou agir dentro dos privilégios que já possui.
- Use um repositório de teste privado e limite quem pode contribuir ou comentar durante a avaliação.
- Execute com uma identidade de sistema operacional dedicada e apenas as credenciais e arquivos necessários para a avaliação. Considere uma VM gerenciada separadamente ou isolamento equivalente com acesso de rede restrito.
- Não coloque segredos de produção, credenciais de implantação ou repositórios privados não relacionados no ambiente do worker.
- Proteja a ramificação padrão e exija que um humano inspecione as diferenças e os testes antes da fusão.
- Monitore a conta do agente e esteja pronto para revogar suas credenciais e interromper o serviço.
Estas são medidas de redução de risco, não uma garantia. Os controles apropriados dependem do repositório, do ambiente de hospedagem e das consequências de um erro.
Como você deve configurar a primeira avaliação?
- Limite o alvo. Escolha um repositório de teste de baixo risco e uma pequena tarefa de documentação.
- Identidades separadas. Use um usuário GitHub apenas para agente e uma configuração CLI. Conceda a esse usuário acesso apenas ao repositório de teste.
- Reduza o acesso ao host. Use uma conta de sistema operacional dedicada e revise montagens, serviços acessíveis, variáveis de ambiente e acesso à rede.
- Defina a política. Permita apenas o solicitante pretendido e comece com a aceitação inferida em
observe. - Mantenha a revisão humana. Desative a mesclagem automática; use proteção de ramificação e revise cada PR e verifique o resultado.
- Teste os limites. Inspecione o estado do ticket, os arquivos reais alterados e as credenciais disponíveis para o tempo de execução. Registre o comportamento inesperado e pare se o escopo não estiver claro.
A mudança de política interrompe imediatamente o trabalho existente?
Não necessariamente. A documentação diz que as alterações na política notificam os tickets ativos afetados, mas não revogam imediatamente todos os mandatos ativos. Se você precisar interromper o trabalho, use os controles de interrupção do projeto, inspecione tickets ativos e processos em execução e revogue credenciais ou acesso conforme apropriado. Verifique o resultado em vez de assumir que uma edição de configuração interrompeu todos os workers.
O SuperAgent pode mesclar suas próprias Pull Requests?
O projeto recomenda começar com a fusão humana. Ele descreve um arranjo opcional de mesclagem automática com controles adicionais; não presuma que apenas um prompt reforça a política do seu repositório. Mantenha a mesclagem automática desativada durante o teste e use os controles do repositório do GitHub para solicitar as revisões e verificações que sua equipe precisa.
O que você deve verificar antes de expandir o acesso?
| Pergunta | Evidências a serem procuradas |
|---|---|
| O agente pode tocar apenas nos repositórios pretendidos? | Associação à conta do agente e permissões de repositório. |
| Um trabalhador pode acessar segredos não relacionados? | Conta do sistema operacional, montagens, ambiente, armazenamentos de credenciais e regras de rede. |
| As decisões são compreensíveis? | Candidatos observados, solicitantes permitidos, mandatos de tickets e registros. |
| Todas as alterações serão revisadas? | Proteção de filial, requisitos de revisor e um processo de mesclagem manual. |
| A equipe pode parar e recuperar? | Parar procedimento, revogação de credenciais, backup e um operador nomeado. |
Para saber os requisitos e custos operacionais, leia o guia de custos e configuração do SuperAgent. Para o fluxo interno entre fontes, tickets e trabalhadores, consulte o guia de arquitetura.
Perguntas frequentes
O modo de observação é seguro para uso com credenciais de produção?
O modo de observação não protege credenciais de uma tarefa explícita nem isola trabalhadores. Mantenha as credenciais de produção fora de uma avaliação.
Um usuário dedicado do GitHub coloca o worker em sandbox?
Não. Separa a identidade do GitHub; Os controles do sistema operacional e da infraestrutura controlam o que o processo pode alcançar.
O protótipo está pronto para produção?
Os mantenedores o descrevem como um código de pesquisa para revisão e adaptação, e não um software pronto para produção.