Todo prompt enviado a um modelo hospedado sai do seu ambiente. Se contém uma chave de API, uma senha ou os dados pessoais de um cliente, essa informação agora está nos sistemas de outra pessoa e possivelmente em logs dos dois lados. A detecção de informações sensíveis é a prática de encontrar esse conteúdo antes de o prompt ser enviado.
Como dados sensíveis entram nos prompts
Raramente de propósito. Os caminhos habituais:
- Logs e stack traces colados que incluem tokens, strings de conexão ou cookies de sessão.
- Arquivos de configuração compartilhados para depuração:
.env, YAML, Terraform. - Código com uma credencial embutida.
- Registros de clientes em tickets de suporte, e-mails e transcrições de chat.
- Documentos recuperados que contêm mais do que a pergunta precisa.
- Arquivos de prompt em um repositório onde alguém testou com uma chave real.
- Resultados de ferramentas em um laço de agente, repassados ao modelo sem filtro.
Duas categorias, dois tipos de risco
Os segredos dão acesso: chaves de API, tokens, senhas, chaves privadas, strings de conexão. Um segredo vazado pode ser usado imediatamente. A resposta é revogá-lo e rotacioná-lo.
Os dados pessoais (PII) identificam pessoas: nomes, endereços de e-mail, telefones, endereços postais, números de cartão de pagamento, números de documentos nacionais. Enviá-los pode violar seus compromissos de privacidade ou a lei, e eles não podem ser rotacionados.
Como a detecção funciona
Os detectores combinam vários métodos, porque cada um tem pontos cegos.
Formatos conhecidos. Muitos provedores emitem chaves com prefixo e tamanho reconhecíveis. Elas podem ser identificadas com alta confiança.
Padrões de contexto. Uma atribuição como password = "..." ou api_key: ... marca o valor como credencial, qualquer que seja o formato.
Entropia. Strings aleatórias têm alta entropia de Shannon. Um valor longo e de alta entropia ao lado de uma palavra como “token” ou “secret” provavelmente é uma credencial, mesmo em um formato desconhecido.
Identificadores estruturados. Endereços de e-mail, telefones e números de cartão seguem padrões. Números de cartão podem ser confirmados com um dígito verificador.
Reconhecimento de entidades nomeadas. Modelos estatísticos encontram nomes, organizações e locais que não têm padrão fixo. Mais cobertura, mais falsos positivos, e exige um modelo.
O scanner de segurança de prompts do PromptFlowEngine usa as quatro primeiras. É determinístico e roda localmente, então o texto verificado em busca de segredos não é enviado a lugar nenhum para ser verificado.
Informe posições, nunca valores
Um detector que imprime o segredo encontrado criou uma segunda cópia do segredo, em um log ou terminal. Um scanner bem-comportado retorna apenas a categoria e a posição:
{
"hasSensitiveData": true,
"countsByCategory": { "api_key": 1, "email": 1 },
"matches": [
{ "category": "api_key", "start": 118, "end": 164 },
{ "category": "email", "start": 176, "end": 196 }
]
}
Essa é a forma que o PromptFlowEngine retorna em todas as interfaces. Veja a regra de dados sensíveis para um exemplo prático.
Ocultação
A ocultação substitui cada valor detectado por um marcador que preserva o sentido do texto ao redor.
Before: Connect with postgres://admin:hunter2@db.internal:5432/app
After: Connect with [REDACTED_CONNECTION_STRING]
Marcadores tipados como [REDACTED_API_KEY] são melhores que uma fileira de asteriscos, porque o modelo ainda sabe que tipo de coisa havia ali e pode raciocinar sobre ela (“a string de conexão parece malformada”) sem vê-la.
Para dados pessoais a que a tarefa precisa se referir, use pseudônimos consistentes dentro de uma requisição: cada ocorrência de um e-mail vira [EMAIL_1], o próximo endereço [EMAIL_2]. O modelo pode então distinguir as pessoas, e sua aplicação pode mapear os marcadores de volta depois da resposta.
Onde pôr a verificação
Detecte o mais cedo possível, e em mais de um lugar.
| Onde | O que ela pega |
|---|---|
| No editor ou na caixa de chat | Uma colagem, antes de ser enviada |
| No código da aplicação, antes da chamada à API | Dados de usuários, registros e recuperação |
| Entre as etapas do agente | Resultados de ferramentas prestes a entrar no contexto |
| Na CI, em arquivos de prompt | Credenciais commitadas em um repositório |
| Antes de gravar logs | Conteúdo prestes a ser armazenado |
A extensão do Chrome avisa enquanto um rascunho no ChatGPT, Claude ou Gemini contém um segredo e pode ocultá-lo no seu dispositivo. A extensão do VS Code executa uma proteção de privacidade antes de um prompt ser enviado ao chat, com os modos estrito, ocultar e avisar. Na CI, a barreira de verificação falha por padrão em qualquer achado crítico, então uma chave commitada interrompe o build.
Escolhas de política: bloquear, ocultar ou avisar
- Bloquear quando um segredo nunca deve ser enviado. O mais seguro, o mais disruptivo.
- Ocultar como padrão. O prompt segue sem os valores sensíveis.
- Avisar quando uma pessoa deve decidir, por exemplo diante de um possível falso positivo em código.
Qualquer que seja a escolha, aplique a detecção de segredos localmente. Uma verificação que envia o texto a um serviço remoto para descobrir se é seguro enviá-lo anula o propósito.
Limites que você deve conhecer
- Falsos negativos. Um segredo em formato incomum, ou um dado pessoal sem padrão, como a descrição de uma pessoa, pode passar. A detecção reduz o risco; não certifica que um prompt está limpo.
- Falsos positivos. Hashes, UUIDs e dados de teste podem parecer segredos. Coloque valores seguros conhecidos em uma lista de permissões em vez de desativar a verificação.
- Imagens e arquivos. Scanners de texto não leem capturas de tela nem PDFs, a menos que sejam convertidos antes.
- Contexto. Um nome é público em um cenário e confidencial em outro. Só a sua política pode decidir.
Além da detecção: envie menos
O controle mais confiável é não incluir os dados.
- Passe um ID e deixe uma ferramenta buscar o registro, para que o modelo nunca veja campos de que não precisa.
- Remova campos antes de montar o prompt.
- Mantenha credenciais na sua aplicação e entregue-as diretamente às ferramentas. Um modelo nunca precisa da sua chave de API para pedir a uma ferramenta que chame uma API.
- Use dados de teste em exemplos e em arquivos de prompt.
Se um segredo já foi enviado
- Revogue e rotacione imediatamente. Trate-o como comprometido.
- Verifique nos logs de acesso se houve uso.
- Remova-o do histórico do repositório e dos arquivos de prompt.
- Adicione uma verificação para que o mesmo caminho seja pego da próxima vez.
Para o modelo de ameaças ao redor, veja a segurança de prompts. Para ataques que tentam extrair dados depois que eles estão no contexto, veja a injeção de prompt.