Regras de Segurança que Todo Tech Lead Deve Aplicar
Estas são as regras de segurança enumeradas que este site resume para colocar Claude em produção - condensadas aqui como padrões aplicáveis; o raciocínio completo e os modelos de ameaça estão na cobertura dedicada de segurança e pipeline RAG deste site.
Como Usar Este Checklist
- Aplique estas regras a todos os sistemas que permitem que Claude chame uma ferramenta, leia um documento ou aja em nome de um usuário - não apenas recursos "agentes".
- Trate isso como um portão pré-lançamento para qualquer recurso que conceda a Claude acesso de escrita a um sistema real.
- Reexecute este checklist sempre que uma nova ferramenta, servidor MCP ou fonte de dados for adicionada a um agente existente.
- Combine com as Regras de Design de Ferramentas, que cobrem a contraparte em nível de ferramenta de várias regras aqui.
Regras de Escopo de Permissão
- Aplique o menor privilégio a todas as credenciais que um sistema com Claude pode acessar. Uma ferramenta, servidor MCP ou chave de API deve ter exatamente o acesso que sua tarefa requer - sem concessões mais amplas "caso seja necessário mais tarde".
- Escopare credenciais por ferramenta ou por integração, não por agente. Uma única credencial superprivilegiada significa que um bug ou uso indevido em qualquer ferramenta individual pode afetar tudo o que essa credencial pode acessar.
- Nunca conceda acesso de escrita por padrão. Comece cada nova integração como somente leitura e adicione acesso de escrita deliberadamente, com revisão, assim que o caminho somente leitura se provar confiável.
- Expire e rotacione as credenciais das quais os sistemas com Claude dependem. Chaves de API de longa duração e nunca rotacionadas são um risco permanente, independentemente de quão cuidadosamente a própria ferramenta seja projetada.
- Mantenha as credenciais de produção e staging completamente separadas. Uma ferramenta testada contra staging nunca deve estar a uma única alteração de configuração de tocar dados de produção.
Regras de Validação de Saída
- Trate a saída do modelo como entrada não confiável, não como uma instrução confiável. O texto gerado e os argumentos da ferramenta devem passar pela mesma validação que qualquer entrada externa e não autenticada - nunca execute um comando ou consulta gerado pelo modelo diretamente.
- Nunca interpole a saída do modelo diretamente em um comando de shell, consulta SQL ou caminho de arquivo. Use consultas parametrizadas, comandos permitidos em lista e validação de caminho exatamente como faria para qualquer valor enviado pelo usuário.
- Valide a saída estruturada contra um esquema antes de agir sobre ela. Uma resposta malformada ou com formato inesperado deve ser rejeitada e retentada, não parcialmente confiável.
- Sanitize qualquer saída do modelo renderizada de volta para os usuários finais. A saída destinada à exibição pode conter marcação ou formatação injetada de entrada adversarial anterior na conversa - sanitize antes de renderizar, o mesmo que qualquer outro conteúdo influenciado pelo usuário.
- Assuma que qualquer conteúdo externo que Claude lê (documentos, páginas da web, dados recuperados) pode conter instruções adversariais. Projete ferramentas e prompts para que as instruções incorporadas no conteúdo recuperado não possam substituir silenciosamente a autoridade real do prompt do sistema.
Regras de Registro e Auditoria
- Registre cada chamada de ferramenta sensível independentemente da transcrição da conversa. Uma transcrição pode ser editada, truncada ou perdida; um log de auditoria dedicado para chamadas destrutivas ou que tocam dados sobrevive independentemente e suporta a revisão de incidentes.
- Registre quem ou o que acionou uma ação sensível, não apenas que ela ocorreu. Para sistemas agentes, capture o usuário, a sessão e a versão do prompt que acionaram a ação, juntamente com a própria ação.
- Retenha logs de auditoria por mais tempo do que o histórico de conversas subjacente. As necessidades de conformidade e revisão de incidentes normalmente excedem as janelas de retenção de conversas normais - não deixe que a retenção de logs herde silenciosamente um padrão mais curto.
- Alerta sobre padrões anômalos de chamadas de ferramentas, não apenas falhas individuais. Uma única chamada de ferramenta falha é ruído; um aumento repentino no volume de chamadas de uma ferramenta específica ou uma sequência incomum de chamadas é um sinal que vale a pena alertar.
Regras de Segredos e Credenciais
- Nunca coloque segredos em um prompt, mensagem do sistema ou arquivo de memória. Tudo o que o modelo pode ler, ele também pode potencialmente repetir - credenciais pertencem a um cofre, variável de ambiente ou gerenciador de segredos, nunca em texto que o modelo processa.
- Nunca permita que a mensagem de erro de uma ferramenta vaze uma credencial ou detalhe interno de volta para o contexto do modelo. Um erro de autenticação que inclui a chave tentada ou um stack trace interno entrega essa informação a quem ler a transcrição a seguir.
- Audite recursos de memória e armazenamento de longo prazo quanto à persistência acidental de segredos. Uma ferramenta de memória ou armazenamento entre sessões para a qual uma credencial foi acidentalmente gravada continuará a reproduzi-la em sessões futuras até que seja encontrada e removida.
- Use tokens de curta duração e com escopo sobre chaves estáticas de longa duração sempre que a integração suportar. Um token que expira limita a janela de danos se ele for exposto.
Regras de Injeção e Isolamento de Prompt
- Isole conteúdo não confiável de instruções que o modelo deve tratar como autoritativas. Separe claramente as instruções em nível de sistema do conteúdo fornecido pelo usuário ou recuperado para que uma injeção de prompt incorporada em dados recuperados não possa se disfarçar como uma instrução do operador.
- Nunca permita que um único agente ingira conteúdo externo não confiável e tenha acesso a ferramentas de alto privilégio na mesma vez sem revisão. O risco clássico de injeção é uma ferramenta que lê um documento influenciado por um invasor e uma ferramenta que pode executar uma ação destrutiva ambas disponíveis ao mesmo tempo - separe-as ou adicione um portão de confirmação entre elas.
- Teste agentes contra entradas adversariais antes do lançamento, não apenas entradas de caminho feliz. Inclua tentativas de injeção de prompt, argumentos de ferramenta malformados e solicitações de limite de fronteira no conjunto de testes pré-lançamento para qualquer agente que use ferramentas.
Regras de Governança
- Atribua um proprietário explícito para a revisão de segurança de cada recurso com Claude. As salvaguardas de segurança se degradam da mesma forma que qualquer outra regra sem um proprietário - veja Como Regras Opinativas Previnem Incidentes de Produção com Claude.
- Revise as salvaguardas sempre que o acesso à ferramenta ou o escopo de dados de um recurso se expandir. Um recurso que começou somente leitura e posteriormente ganhou acesso de escrita precisa ter sua revisão de segurança repetida, não ser aceito com base no lançamento original.
FAQs
Qual é a lacuna de segurança mais comum em sistemas com Claude?
Confiar na saída do modelo como se fosse uma instrução verificada, em vez de entrada não confiável - interpolar texto gerado diretamente em um comando, consulta ou caminho sem validação.
Por que a injeção de prompt é diferente de um bug normal de validação de entrada?
Porque a "entrada" é frequentemente conteúdo que o modelo é solicitado a ler e raciocinar, não conteúdo enviado diretamente por um usuário - uma instrução maliciosa incorporada em um documento ou página da web pode tentar redirecionar o comportamento do modelo no meio da tarefa, o que a validação de entrada normal não cobre.
Toda chamada de ferramenta deve ser registrada, ou apenas as destrutivas?
No mínimo, todas as chamadas de ferramenta com efeitos colaterais - gravações, exclusões, pagamentos, comunicações externas. Chamadas somente leitura também podem ser registradas para depuração, mas o requisito de trilha de auditoria é mais forte para qualquer coisa que altere o estado.
Como o menor privilégio se aplica a um único agente com muitas ferramentas?
Cada ferramenta deve carregar sua própria credencial com escopo em vez de o agente possuir uma credencial ampla que todas as suas ferramentas compartilham - dessa forma, um bug ou uso indevido em uma ferramenta não pode acessar sistemas aos quais apenas uma ferramenta diferente precisava de acesso.
Qual é o risco de armazenar segredos em um recurso de memória ou armazenamento de longo prazo?
Tudo o que é persistido na memória é reproduzido no contexto das sessões futuras - uma credencial gravada uma vez, mesmo que acidentalmente, continua sendo lida pelo modelo em cada sessão subsequente que monta essa memória até que alguém a encontre e remova.
Por que separar as credenciais de produção e staging?
Porque uma ferramenta testada com dados de staging, com credenciais com escopo de staging, nunca deve estar a uma única alteração de configuração de operar em produção - separá-las remove uma classe inteira de incidentes de "acidentalmente testado em produção".
Essas regras se aplicam a integrações somente leitura também?
Sim, embora com menor urgência - o acesso somente leitura ainda precisa de escopo de menor privilégio e ainda pode vazar dados sensíveis através da saída do modelo, mesmo sem um caminho de escrita.
Com que frequência uma revisão de segurança deve ser repetida?
No mínimo, sempre que o acesso à ferramenta ou o escopo de dados de um recurso mudar, e periodicamente, caso contrário - um recurso que não mudou ainda pode se tornar arriscado se o cenário de ameaças ou os dados que ele toca mudaram.
O que deve ser incluído nos testes adversariais pré-lançamento?
Tentativas de injeção de prompt incorporadas em conteúdo recuperado, argumentos de ferramenta malformados ou que ultrapassam limites, e solicitações projetadas para fazer o agente executar uma ação fora de seu escopo pretendido - não apenas solicitações típicas de caminho feliz.
Alertar sobre o volume de chamadas de ferramentas é excessivo para uma equipe pequena?
Não necessariamente - mesmo um alerta de limite simples em um pico incomum no número de chamadas de uma ferramenta sensível detecta loops descontrolados e uso indevido muito antes de descobri-lo durante uma auditoria manual ou uma reclamação de cliente.
Como essas regras se relacionam com a cobertura mais aprofundada de pipelines RAG de segurança neste site?
Esta página é a forma condensada e aplicável das regras; a seção de pipelines RAG de segurança cobre os modelos de ameaça completos, padrões de arquitetura e exemplos práticos dos quais essas regras são extraídas.
Relacionados
- Regras de Design de Ferramentas para Agentes Claude Seguros e Componíveis - a contraparte em nível de ferramenta de várias regras nesta página.
- Como Regras Opinativas Previnem Incidentes de Produção com Claude - por que essas regras precisam de um proprietário para permanecerem aplicadas.
- As Regras Principais do Claude: Uma Lista de Referência Rápida - a versão condensada dessas regras junto com todas as outras categorias.
- Melhores Práticas das Regras Claude - todas as regras nesta seção reestilizadas como um checklist.
Versões da Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5 - e o SDK oficial
anthropicpara Python (última versão 0.x). Nomes de modelos, preços e versões de SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.