Segurança
Proteja suas credenciais, revise extensões e entenda o alcance de cada controle de segurança.
Mantenha explícito o limite do operador
Saídas do modelo e de ferramentas, texto do repositório, descrições de issues e conteúdo da web podem conter instruções incorretas ou maliciosas. Trate tudo isso como entrada, não como autoridade. Dê a cada execução o menor conjunto útil de ferramentas e o escopo mais restrito, leia as solicitações de aprovação e mantenha operações irreversíveis sob controle humano direto.
O agente selecionado determina as permissões efetivas de ferramentas. O campo allowed-tools de uma skill é metadado de compatibilidade e não impõe permissões durante a execução.
Escolha revisão e contenção
A revisão de comandos decide se uma ação deve ser executada. O sandbox limita onde um processo pode atuar depois de permitido. Eles resolvem problemas diferentes.
Abra o seletor de segurança a partir do campo de mensagem com Ctrl+S. Alt+S continua como acelerador no modo de teclado aprimorado, e /settings/controls funciona em qualquer terminal:
| Preset | Execução | Revisão |
|---|---|---|
free | Direta no host | Nenhuma |
judged | Direta no host | Juiz LLM; pergunta a você quando houver incerteza |
approval | Direta no host | Pergunta sobre comandos ainda não permitidos |
isolated | Sandbox nativo | Nenhuma |
reviewed | Sandbox nativo | Juiz LLM; pergunta a você quando houver incerteza |
protected | Sandbox nativo | Pergunta sobre comandos ainda não permitidos |
Use protected quando contenção e uma decisão humana explícita forem importantes. Não dependa somente de um juiz LLM para operações destrutivas, privilegiadas, financeiras, de release ou de produção.
Verifique a disponibilidade do sandbox
Um sandbox obrigatório interrompe a execução quando o backend selecionado — Bubblewrap no Linux ou Seatbelt no macOS — não está disponível. Um sandbox opcional pode recorrer à execução direta no host. Verifique o cabeçalho e /settings/controls; nunca deduza que houve contenção apenas porque um comando terminou.
Proteja credenciais
- Adicione chaves de provedores por
/settings/providersou pelo fluxo de credenciais do Doctor. - Mantenha no armazenamento pessoal as credenciais salvas pelos fluxos gerenciados de chaves e assinaturas. Nunca coloque segredos em
.clarvis/settings.json, prompts, skills, hooks, arquivos de agentes, manifestos de plugins ou documentos de marketplace. - Use referências de ambiente
${NAME}em ambientes e cabeçalhos de provedores e MCP, em vez de valores literais; o esquema aceita texto literal, mas isso não o torna seguro para commit. - Lembre-se de que prompts do usuário fazem parte do histórico da sessão. Não cole segredos no campo de mensagem.
- Use
/storagepara inspecionar a permissões dos arquivos de credenciais sem expor seu conteúdo. O Clarvis aplica bits de modo exclusivos do proprietário em POSIX; no Windows, depende dos controles de acesso do perfil do usuário.
O Clarvis filtra credenciais de provedores e variáveis de ambiente com formato de segredo antes de iniciar comandos de hook, mas filtragem é higiene, não isolamento. Um processo iniciado por você ainda pode ler arquivos, usar estado de ambiente herdado que não seja secreto e acessar a rede.
O confinamento por caminho não é um sandbox de gravação do sistema operacional
As ferramentas de arquivo recusam caminhos resolvidos fora do workspace, mas um processo concorrente ainda pode disputar uma gravação ao substituir um diretório pai já verificado por um link simbólico ou uma junção do Windows. Não trate a verificação padrão como proteção contra um processo hostil que altera o workspace ao mesmo tempo. Use controle de versão, revise gravações importantes e evite alterações concorrentes por processos não confiáveis.
Revise extensões executáveis
Hooks são executados a partir do workspace com seus privilégios do sistema operacional, fora do sandbox do agente. Uma correspondência de hook controla quando o comando é executado; ela não é um limite de política. Mantenha comandos pequenos, use timeouts curtos e bloqueie em caso de falha somente após testar esse caminho. Inspecione hooks e comandos nos detalhes de Plugins antes de instalar ou atualizar.
Plugins podem contribuir com agentes, skills, servidores MCP, hooks e serviços de capacidade. Siga a sequência completa:
- Inspecione o código-fonte e seus detalhes.
- Instale e ative o plugin como uma unidade completa no Extension Profile atual.
- Ao editar um Extension Profile, revise o que será ativado ou removido.
Uma instalação global pertence ao operador e não exige uma segunda aprovação do workspace. Plugins pertencentes ao repositório entram em um fingerprint endereçado por conteúdo do inventário completo do workspace antes da seleção do Extension Profile; um plugin do workspace ainda não aprovado fica retido sem desabilitar um plugin global aprovado selecionado ao lado dele.
Uma atualização pode alterar conteúdo executável, inclusive comandos MCP ou hooks. O Clarvis relata a mudança e só a aplica depois da revisão e reconexão, quando não há execução ativa. Ele recusa atualizar ou desinstalar um plugin selecionado durante uma execução ativa, e a execução atual mantém seu snapshot.
Trate servidores MCP como integrações privilegiadas
Um servidor MCP stdio é um processo local. Um servidor MCP remoto recebe solicitações pela rede. Em ambos os casos, suas ferramentas podem expor dados ou provocar efeitos de acordo com a implementação do próprio servidor.
- Conecte-se apenas a servidores e endpoints em que você confia.
- Conceda aos agentes somente as ferramentas MCP de que precisam.
- Use HTTPS para servidores remotos fora de uma rede local confiável.
- Mantenha tokens em referências de ambiente, não em cabeçalhos salvos no repositório.
- Defina
shared: truesomente para um servidor projetado para execuções concorrentes e sem solicitações humanas. - Aprove o fingerprint exato do workspace antes que o Clarvis se conecte a servidores declarados pelo repositório.
Revise configurações controladas pelo repositório
A confiança no workspace retém configurações que podem executar código, seleções de provedores executáveis de capacidades, agentes do workspace e todos os plugins de workspace pertencentes ao repositório até você aprovar o fingerprint atual. O inventário de plugins é capturado antes da seleção do Extension Profile, então uma aprovação cobre as trocas de Extension Profile até que o conteúdo de um plugin do repositório incluído no fingerprint mude. O Clarvis pergunta na entrada quando a superfície é nova ou mudou; recusar abre Extensions para remover contribuições indesejadas. Use /workspace-trust depois para revisar ou revogar quando o repositório não deva mais controlar essas superfícies. Provedores de assinatura permanecem restritos ao escopo global e nunca são ativados a partir de declarações do workspace.
O Clarvis recusa aprovação ou revogação enquanto uma execução estiver ativa, antes de alterar o registro de confiança. Quando não há execução ativa, o conjunto de extensões derivado do workspace é recomposto antes da próxima execução.
A aprovação de confiança não equivale a uma revisão geral de segurança. Configurações de sandbox e de revisão de comandos do workspace ainda participam da precedência normal. Inspecione-as ao abrir um projeto desconhecido.