Segurança, Conformidade e Melhores Práticas de RAG

Estas são as regras permanentes para construir aplicações Claude de produção que combinam uso de ferramentas, recuperação e dados sensíveis de forma segura. Use-a como referência durante a revisão do projeto, não apenas no lançamento.

Como Usar Esta Lista

• Trate cada regra como uma declaração positiva do que "bom" parece, vincule-a a uma regra de lint, um item de checklist de revisão de código ou um registro de decisão de arquitetura, sempre que possível.
• As regras são agrupadas pela mesma estrutura do restante desta seção: modelo de ameaças, defesa contra injeção, escopo de ferramentas, segredos, conformidade e qualidade de recuperação.
• Revise esta lista sempre que adicionar uma nova ferramenta, uma nova fonte de dados ou uma nova integração, não apenas quando algo der errado.

A - Disciplina do Modelo de Ameaças

• Mapeie conteúdo não confiável, acesso a ferramentas e escopo de permissão para cada agente antes do lançamento. Esses três fatores multiplicam o risco em vez de somá-lo, reduzir qualquer um deles a quase zero controles a exposição geral, independentemente dos outros dois.
• Reavalie o modelo de ameaças sempre que o acesso a ferramentas ou recuperação mudar, não apenas no projeto inicial. Adicionar uma nova ferramenta ou uma nova fonte de recuperação a um agente existente altera seu perfil de risco tanto quanto construir um novo agente do zero.
• Presuma que fontes de conteúdo internas não são fontes de conteúdo confiáveis automaticamente. Qualquer pessoa com acesso de edição a uma wiki interna, fila de tickets ou repositório de documentos pode inserir conteúdo que seu pipeline recuperará posteriormente; "interno" limita quem poderia ser um atacante, mas não remove a ameaça.

B - Defesa contra Injeção Indireta de Prompt

• Envolva cada pedaço de conteúdo recuperado ou originado de ferramenta em delimitadores de dados explícitos. Tags como <source> ou <retrieved_document> fornecem à Claude um limite analisável por máquina entre instruções confiáveis e conteúdo não confiável.
• Declare no prompt do sistema que o conteúdo delimitado é dado, não instruções, mesmo que afirme o contrário. O conteúdo injetado frequentemente tenta se passar por uma mensagem do sistema; aborde isso diretamente em vez de presumir que o modelo o inferirá.
• Execute um pré-filtro contra frases conhecidas semelhantes a instruções antes que o conteúdo chegue ao prompt. Um filtro regex ou de palavras-chave não é suficiente sozinho, mas é uma primeira camada barata e eficaz que captura padrões de ataque comuns.
• Aplique o mesmo padrão de isolamento aos resultados das ferramentas que à recuperação de documentos. Uma ferramenta de busca na web, uma ferramenta de leitura de documentos ou uma integração de API de terceiros trazem conteúdo não confiável assim como um banco de dados vetorial, e precisam das mesmas defesas.
• Mantenha e expanda periodicamente um conjunto de testes adversariais para resistência à injeção. Novas frases de injeção aparecem regularmente; um conjunto de testes estático do lançamento inicial para de capturar ataques reais com o tempo.

C - Escopo de Ferramentas de Menor Privilégio

• Dê a cada ferramenta o input_schema mais restrito que ainda cumpra sua função. Prefira enums e valores resolvidos internamente em vez de parâmetros de string abertos para qualquer coisa que mapeie para uma ação real.
• Emita uma credencial separada e com escopo por ferramenta em vez de uma credencial compartilhada em um agente. Uma credencial compartilhada colapsa o raio de explosão de todo o conjunto de ferramentas para o que quer que essa única credencial possa acessar.
• Valide cada argumento de ferramenta no código antes da execução, independentemente do que o modelo alegar. Trate os argumentos de chamada de ferramenta da Claude como entrada não confiável, da mesma forma que trataria um valor do corpo de uma requisição HTTP.
• Limite o raio de explosão de uma única chamada de ferramenta com limites de taxa e limites de registro. Limite quantas vezes uma ferramenta pode ser chamada por sessão e quantos registros uma única chamada pode tocar.
• Obtenha um segundo revisor, que não construiu a ferramenta, para aprovar seu escopo antes da implantação. O modelo mental do autor original de "para que isso serve" facilita negligenciar o que a ferramenta é realmente capaz de fazer.

D - Prevenção de Segredos e Exfiltração

• Nunca coloque uma credencial em uma string de prompt, prompt do sistema ou argumento de ferramenta. Carregue segredos apenas dentro do código de implementação da ferramenta, a partir de uma variável de ambiente ou de um gerenciador de segredos dedicado, nunca em qualquer lugar onde a janela de contexto do modelo possa vê-los.
• Crie uma lista de permissões de destinos para qualquer ferramenta que possa enviar dados externamente. Verifique o host ou endereço de destino contra uma lista de permissões explícita antes de executar, não confie em um destino que o modelo forneceu.
• Crie uma lista de permissões dos campos que um payload de ferramenta pode conter, usando restrições de esquema como additionalProperties: False. Isso impede que o modelo construa uma chamada fora do escopo no nível do esquema, antes mesmo que seu próprio código de validação seja executado.
• Redija conteúdo com formato de segredo e formato de PII antes que ele chegue a qualquer log, mensagem de erro ou ferramenta de observabilidade de terceiros. Roteie todos os logs através de uma única função de redação para que nenhum caminho de código possa escrever acidentalmente conteúdo não redigido.
• Registre cada tentativa de chamada de ferramenta, sucesso e bloqueio, não apenas os bem-sucedidos. Uma trilha de auditoria completa é o que permite reconstruir exatamente o que aconteceu durante um incidente suspeito.

E - Conformidade SOC2 e GDPR

• Envie apenas os campos que um prompt realmente necessita e remova PII do contexto recuperado antes que ele entre em um prompt. Minimizar o que chega ao modelo em primeiro lugar é o controle de conformidade mais barato e confiável.
• Aplique limites de retenção com exclusão automatizada, não apenas com um documento de política. Uma política de retenção escrita sem um trabalho de aplicação ou TTL de banco de dados é um controle de papel que não se sustentará em uma auditoria SOC2 Tipo II.
• Aplique a lógica de retenção e exclusão aos índices do armazenamento vetorial, não apenas aos logs de conversação. Pipelines RAG retêm rotineiramente blocos contendo PII indefinidamente porque o conteúdo indexado não se parece com um log tradicional.
• Registre o acesso a PII com identidade atribuível, não uma entrada genérica em nível de aplicativo. Uma auditoria SOC2 procura especificamente quem ou o que acessou dados sensíveis; "alguém" não é evidência suficiente.
• Seja capaz de localizar e exportar ou excluir todas as interações da API Claude vinculadas ao identificador de um usuário específico. Este é o requisito operacional por trás dos direitos de acesso e exclusão de dados do titular dos dados do GDPR, e precisa ser testado antes de ser necessário, não construído durante uma solicitação ativa.

F - Qualidade de Recuperação e Fundamentação

• Ajuste o tamanho do bloco e a sobreposição contra a qualidade de recuperação medida, não apenas contra o custo de incorporação. Um tamanho de bloco menor é mais barato, mas pode degradar a qualidade da resposta de maneiras que não aparecem até que os usuários notem.
• Combine busca por palavras-chave e por incorporação para corpora com conteúdo sensível a correspondência exata. A busca semântica pura subestima códigos de produto, códigos de erro e nomes próprios que a busca por palavras-chave captura de forma confiável.
• Instrua explicitamente a Claude a responder apenas com base no conteúdo recuperado e dê a ela permissão explícita para dizer que as fontes não cobrem uma pergunta. Essa única mudança reduz respostas confiantes e não fundamentadas mais do que a maioria das camadas de verificação downstream.
• Verifique se as citações apontam para blocos que foram realmente recuperados e verifique se as alegações citadas correspondem ao texto da fonte. A presença de citação por si só não garante precisão; o modelo pode citar uma fonte real enquanto ainda a representa incorretamente.
• Mantenha um conjunto de avaliação separado de consultas reais e rastreie a precisão da fundamentação ao longo do tempo. A recuperação, a fragmentação e a solicitação de prompt mudam à medida que um corpus e uma base de código evoluem; uma avaliação única não captura regressões.

G - Pipelines Eficientes em Custo

• Armazene em cache conteúdo estável e reutilizado genuinamente, nunca conteúdo recuperado por consulta. Marcar recuperação volátil como cacheável causa um cache miss em cada requisição, enquanto ainda paga o custo mais alto de escrita no cache.
• Gere conteúdo em cache de forma determinística para que o prefixo do cache permaneça byte a byte idêntico entre as requisições. Mesmo pequenas variações de formatação no conteúdo "estável" derrotam silenciosamente o cache.
• Verifique se os cache hits estão realmente ocorrendo em produção usando dados de uso de resposta. Definir cache_control não é o mesmo que confirmar que está funcionando; verifique cache_read_input_tokens em tráfego real.

Armadilhas

• Tratar esta lista como um checklist de lançamento único em vez de uma ferramenta de revisão viva. O modelo de ameaças, o escopo das ferramentas e a qualidade da fundamentação mudam à medida que as ferramentas e fontes de dados de um agente evoluem; uma única passagem no lançamento perde essa mudança. Correção: revisite as seções relevantes sempre que uma ferramenta, fonte de dados ou configuração de recuperação mudar.
• Aplicar essas práticas de forma desigual entre ferramentas dentro do mesmo agente. Uma equipe que escopa cuidadosamente uma ferramenta e deixa outra definida de forma frouxa efetivamente escopou o agente para sua ferramenta mais fraca. Correção: aplique o checklist completo por ferramenta, não uma vez por agente.
• Presumir que os controles de conformidade (Seção E) são separados dos controles de segurança (Seções B-D). Redação, registro de acesso e escopo de menor privilégio servem a ambos os propósitos simultaneamente; construí-los uma vez para segurança satisfaz em grande parte o requisito de conformidade também. Correção: projete esses controles juntos em vez de como duas iniciativas separadas.

FAQs

Relacionados

• Entendendo o Modelo de Ameaças de Segurança e RAG da Claude - o modelo mental que esta lista operacionaliza.
• Checklist de Escopo de Ferramentas de Menor Privilégio para Agentes Claude de Produção - a versão detalhada da Seção C.
• Considerações SOC2 e GDPR para PII em Prompts e Logs - a versão detalhada da Seção E.
• Checklist de Citação e Fundamentação para Reduzir Alucinações de RAG - a versão detalhada da Seção F.

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 anthropic para 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.