anonymize-data

Anonimizar dados

Opere o projeto canônico oai-trial. Não duplique seu correspondente, adaptadores de formato, verificador, esquemas ou tratamento de erros nesta skill. O CLI argparse existente do projeto é intencionalmente retido; este wrapper não adiciona nenhum CLI ou serviço Python.

Configuração e operação principal

ANONYMIZE_DATA_ROOT substitui o checkout padrão principal acima. A configuração precisa uv e instala as dependências de desenvolvimento/descoberta declaradas do projeto. As operações de execução não precisam de Memória, credenciais de provedor, LLM, rede ou serviço de banco de dados.

./run.sh setup
./run.sh --input /data/exports --policy /data/policy.json --output /data/release
./run.sh anonymize --input /data/export.sqlite --policy /data/policy.json --output /data/release

A entrada é um arquivo .csv, .json, .txt ou .sqlite, ou um diretório contendo esses arquivos. A política deve ser um arquivo regular separado. Use um diretório de saída vazio dedicado fora das entradas. Os originais são copiados para um snapshot temporário privado; a saída bem-sucedida contém apenas corpus/ e report.json.

A interface de pacote existente permanece disponível:

./run.sh run --input /data/bundle --output /data/release
./run.sh verify --input /data/bundle --output /data/release
./run.sh inspect /data/release

Um pacote contém policy.json e corpus/. A política, identidade canônica, regras de valor protegido, falhas tipadas e esquema de relatório pertencem ao projeto. Leia seu README.md, docs/ANONYMIZATION_SEMANTICS.md e schemas/report.schema.json ao interpretá-los. Não declare sucesso apenas a partir de um código de saída: leia o relatório real, valide seus campos de prontidão e inspecione a saída para o formato solicitado. Relatórios corrompidos ou ausentes não estão PRONTOS.

Descoberta opcional com RapidFuzz: nunca substituição automática

./run.sh discover --input /data/exports --policy /data/policy.json --output /data/work/review.json
./run.sh approve-discovery --input /data/exports --policy /data/policy.json \
  --review /data/work/review.json --approve CANDIDATE_ID --output /data/work/approved-policy.json
./run.sh --input /data/exports --policy /data/work/approved-policy.json --output /data/release

A descoberta compara valores inteiros de strings estruturadas e linhas de texto inteiras contra entradas de política do tipo name. Não é extração de spans de PLN ou um scanner geral de PII. Padrões: limite de similaridade 90, margem de separação 5; configurável com --threshold e --margin. Empates, quase empates, valores protegidos, valores contendo dígitos ou pontuação de identificador como @, /, _, e literais já conhecidos não são propostos. Apóstrofos, hífens e pontos são permitidos em texto com formato de nome; similaridade nunca é prova de que duas pessoas são uma.

Peça ao operador para aprovar IDs de candidatos específicos. Nunca aprove apenas com base na pontuação de similaridade. A aprovação re-deriva as propostas contra a política/corpus atual, rejeita revisões desatualizadas/editadas e compila uma política de correspondência exata. Propostas não aprovadas nunca afetam a anonimização. release_ready: false é obrigatório em comprovantes de descoberta/aprovação.

Arquivos de revisão e política aprovada contêm nomes brutos: mantenha-os fora de lançamentos, logs e relatórios compartilhados. Eles são criados com modo 0600 e nunca sobrescrevem um arquivo existente. Snapshots temporários padrão são no disco de artefatos; substitua com ANONYMIZE_DATA_WORK_DIR quando necessário.

Docker continua sendo a interface independente

A partir do checkout do projeto:

docker build -t anonymization-trial .
docker run --rm anonymization-trial
# Imagem opcional com descoberta habilitada; a imagem padrão mantém a dependência exata do motor livre.
docker build --build-arg INCLUDE_DISCOVERY=1 -t anonymization-trial:discovery .

Monte apenas a entrada/política solicitada como somente leitura e um diretório de saída dedicado. O mesmo CLI do projeto é executado dentro da imagem; o avaliador não precisa desta skill. Consulte docs/DISCOVERY.md do projeto para exemplos completos de comandos montados.

Limite de falha e prova

O wrapper preserva os códigos de saída do projeto e códigos de erro sanitizados. Projeto/instalação ausente e caminhos de pacotes instalados incorretos falham antes do processamento. Use --help para o contrato real de argumentos. A descoberta é material de revisão, não um lançamento, garantia de anonimato, probabilidade de confiança ou autorização humana.

./sanity.sh executa verificações reais positivas, negativas e adversárias de CLI. O arquivo retido fixtures/agentic_eval.json as repete e requer leitura de artefato. A qualificação prévia do teste não qualifica automaticamente essas extensões pós-teste.

Regra de representação (operador 2026-09-11)

PII deve ser correspondido contra o valor, não a string: antes de qualquer escalar JSON/SQLite ser passado inalterado, stringifique-o canonicamente (números com formato de telefone na forma E.164) e execute a correspondência da política na forma stringificada. As fixtures devem incluir cada classe de PII em cada tipo escalar JSON. Um número de telefone armazenado como inteiro é o mesmo número de telefone, inclusive quando a política o escreve como uma string formatada, como 555-123-4567, e o corpus armazena 5551234567. Conversões numéricas com perda de zero à esquerda ou precisão de ponto flutuante devem falhar fechadas, a menos que uma regra canônica específica de tipo prove equivalência segura. Consulte $best-practices-skills "Matriz de representação de valor".

Lições de hardening (não aprenda estas novamente da maneira difícil)

O teste foi desclassificado porque um telefone armazenado como inteiro JSON/SQLite passou pelo correspondente apenas de string. A causa raiz foi um erro de processo: a verificação de aceitação foi escrita a partir do que o código fazia, não derivada da especificação entregue. Estas regras existem para que essa classe de erro não possa se repetir.

1. Derive a verificação da especificação, não do código. policy.json lista os valores sensíveis exatos. A verificação de aceitação correta é "nenhum desses valores aparece na saída decodificada, em qualquer representação" — leia os valores do arquivo de política, nunca de uma lista escrita manualmente. Prove que a verificação depende da especificação com uma sonda de dependência (altere um valor da política → o resultado deve alterar). Implementação de referência: scripts/spec_derived_check.py do projeto vinculado a scripts/verify.sh.

2. O verificador independente não deve compartilhar nenhuma suposição com o transformador. O verificador original tinha o mesmo ponto cego de apenas string que o produtor, então nada falhou fechado. O oráculo de verificação deve ser ciente de representação e independente: analise JSON (decode \uXXXX), expanda escalares numéricos para formas inteiro/decimal, normalize NFC/NFD ambos os lados, escaneie células de tabelas+visões SQLite E DDL sqlite_master E cada inteiro de cabeçalho, e escaneie todo o limite lançado, incluindo report.json — não apenas corpus/.

3. A classe completa de representação é uma lista de verificação, não um bug único. Cada uma dessas pode transportar um valor sensível além de um correspondente ingênuo; o projeto corrige e retém uma proteção para cada uma: escalares numéricos tipados (int/float, notação científica), BLOB SQLite (falha fechada), Unicode NFC/NFD, reconstrução de visão, resíduo de freelist, esquema de BD hostil (índices de expressão/parciais, visões não determinísticas, DEFAULTs computados), literais DDL de esquema, e inteiros de cabeçalho persistentes. Consulte docs/SECURITY_REMEDIATION.md do projeto para a tabela completa.

4. Comprove através do caminho real do Docker, deterministicamente. A verificação deve ser um script comprometido que constrói a imagem, executa os comandos exatos do briefing, e lê os bytes liberados com saídas PASS/FAIL rígidas — não prosa de agente. Referência: security/docker_brief_contract.py (construção + ambos os comandos do briefing

   • varredura de vazamento ciente de representação + pré-condição de entrada) e security/docker_hardening_matrix.py (brechas adversárias através de docker run). Registre o commit git e o id da imagem construída.

5. Escopo honesto. Pseudônimos determinísticos de namespace público revelam igualdade/frequência e não oferecem resistência a linkage externo; o relatório de execução declara isso em key_mode e does_not_establish. Um valor de política igual a uma constante de formato SQLite obrigatória é uma entrada degenerada, não PII real; o pipeline falha fechado nela e esse resíduo é documentado como escopo.