Identifica o que a chave permite fazer
Antes de integrar um serviço, percebe se o valor é uma credencial privada, um identificador público ou uma chave concebida para uso no navegador. As condições variam entre serviços. Para uma credencial privada, regista a finalidade, o projeto e as permissões necessárias, sem colocar o próprio valor na documentação partilhada da aplicação.
Imagina uma aplicação que envia confirmações de pedidos através de um serviço externo. A credencial usada para autorizar o envio pode permitir ações em nome da empresa. Se alguém a obtiver, o impacto depende dos poderes associados: pode existir envio indevido, acesso a informação ou consumo de recursos, conforme o serviço e a configuração.
Essa distinção ajuda a fazer perguntas concretas ao agente. Em vez de pedir para ligar a plataforma de qualquer maneira, indica a operação necessária e pede que identifique o tipo de credencial adequado. Não concedas automaticamente permissões de administração quando a aplicação só precisa de executar uma tarefa delimitada naquele serviço.
Evita espalhar a mesma credencial por projetos que não precisam de a partilhar. Separar finalidades e limitar permissões facilita perceber o alcance de um problema e substituir o acesso afetado. A organização deve saber quem gere cada credencial e que aplicações precisam de ser atualizadas quando ela muda.
Estas escolhas fazem parte de planear a aplicação antes da construção. Uma integração tem um propósito e um limite, além de uma ligação técnica que funciona. Escrever esse limite ajuda a rever a implementação e impede que a configuração mais poderosa seja aceite apenas por ter resolvido o primeiro teste.
Para preparar o próximo passo, consulta Segurança de aplicações desenvolvidas com IA.
Prepara a configuração sem colar o segredo na conversa
Pede ao agente que prepare os nomes das variáveis e os espaços a preencher, usando valores fictícios ou vazios. O valor real deve entrar através do mecanismo de configuração escolhido para o projeto. Um ficheiro de ambiente precisa de permissões e tratamento adequados; o nome do ficheiro não o torna protegido por si só.
No exemplo das confirmações, a documentação pode indicar que existe uma variável para o token do serviço de envio e explicar onde a configurar. Não precisa de conter o token. A pessoa responsável consegue preencher a configuração sem transformar a credencial num exemplo copiado para instruções, relatórios ou mensagens de apoio.
Também deves definir o que o agente pode mostrar durante a verificação. Pode confirmar que a variável está presente e que a configuração foi reconhecida sem imprimir o valor completo. Uma tentativa de ajudar, como apresentar todas as variáveis para diagnosticar um erro, pode criar uma exposição adicional no registo da conversa.
Ao preparar o ambiente para trabalhar com Claude Code, distingue o ficheiro de exemplo dos ficheiros que contêm valores reais. O primeiro pode acompanhar o projeto com instruções de instalação. Os restantes precisam de ficar fora dos materiais partilhados e de ser geridos segundo o ambiente em que a aplicação vai executar.
Confirma o que a aplicação entrega ao navegador
Guardar uma chave numa variável de ambiente não basta se a configuração ou o código acabarem por enviá-la ao navegador. Verifica onde o valor é lido e que conteúdo sai do servidor. Para uma operação com credencial privada, o navegador deve receber apenas a informação necessária ao resultado autorizado daquela operação.
Em Next.js, variáveis usadas com o prefixo NEXT_PUBLIC_ podem ser incorporadas no JavaScript entregue ao navegador. Esse mecanismo serve para valores públicos e não deve ser usado para um segredo privado. A verificação precisa de considerar a versão construída, além do nome da variável existente no ficheiro de configuração.
O servidor também pode revelar uma credencial por engano numa resposta ou numa mensagem de erro, mesmo sem usar um prefixo público. Por isso, acompanha o percurso do valor desde a configuração até à chamada ao serviço. Confirma que a resposta devolvida à aplicação não inclui informação que só a integração precisava de conhecer.
No envio de confirmações, o utilizador pede a ação prevista e recebe o estado correspondente. O sistema continua a precisar de verificar quem pode pedir esse envio e em que condições. Manter a chave privada no servidor não autoriza qualquer pessoa a usar a operação sem limites ou sem uma regra de acesso.
Revê o repositório e os materiais de apoio
A revisão deve abranger o código atual, o histórico relevante e os ficheiros que acompanham a entrega. Confirma que as exclusões do repositório se aplicam aos ficheiros certos. Acrescentar um ficheiro ao mecanismo de exclusão não retira automaticamente um conteúdo que já estava a ser acompanhado pelo controlo de versões.
Pede ao agente que identifique possíveis credenciais por localização e categoria, sem as copiar para a resposta. O relatório pode explicar que encontrou um valor suspeito num ficheiro de configuração ou numa versão anterior. Depois, a confirmação deve ocorrer por um processo que não volte a espalhar o valor encontrado.
Olha também para capturas de ecrã, exemplos de pedidos, exportações técnicas e registos de execução. Um ficheiro usado para explicar uma integração pode conter mais informação do que a necessária. Ao preparar dados de anúncios para análise com IA, o mesmo critério ajuda: separar os dados úteis da configuração e dos acessos usados para os obter.
Ferramentas automáticas de deteção podem ajudar a encontrar padrões conhecidos, mas o resultado precisa de contexto. Uma indicação pode ser um valor fictício, e a ausência de alertas não demonstra que todos os formatos possíveis foram reconhecidos. Combina a pesquisa com a revisão dos lugares onde a aplicação recebe, usa e apresenta credenciais.
Trata uma chave exposta como um acesso a substituir
Se confirmares que uma credencial privada ficou exposta, a prioridade é revogá-la ou substituí-la segundo o serviço e atualizar os locais que dependem dela. Retirar o valor do ficheiro público não invalida cópias que alguém já tenha obtido. A resposta precisa de incluir a credencial, a causa e a continuidade da aplicação.
Identifica os serviços afetados e quem tem autoridade para fazer a substituição. Confirma depois que a aplicação usa a nova configuração e que o acesso anterior deixou de ser válido. O processo deve considerar possíveis interrupções, sem manter indefinidamente uma credencial comprometida apenas porque a mudança exige coordenação entre pessoas.
Avalia ainda o período e os locais de exposição, incluindo histórico e materiais partilhados, e verifica a atividade disponível no serviço. Essa informação ajuda a perceber o que aconteceu e o que precisa de acompanhamento. Não concluas que houve abuso sem evidência, nem confundas a ausência de um alerta com prova de que nada aconteceu.
Por fim, corrige o caminho que permitiu a exposição e regista a verificação feita sem guardar o segredo no relatório. Pode ser uma regra de publicação, um registo demasiado detalhado ou um valor colocado no lado errado da aplicação. A prevenção melhora quando essa causa fica resolvida e a próxima entrega repete os controlos relevantes.