anonymize-data

Anonymiser des données

Opérez le projet canonique oai-trial. Ne dupliquez pas son moteur de correspondance, ses adaptateurs de format, son vérificateur, ses schémas ou sa gestion d'erreurs dans cette compétence. L'interface argparse CLI existante du projet est intentionnellement conservée ; ce wrapper n'ajoute pas de CLI ou de service Python.

Configuration et fonctionnement principal

ANONYMIZE_DATA_ROOT remplace le répertoire de travail principal par défaut ci-dessus. La configuration nécessite uv et installe les dépendances de développement/découverte déclarées du projet. Les opérations d'exécution ne nécessitent ni mémoire, ni identifiants de fournisseur, ni LLM, ni réseau, ni service de base de données.

./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

L'entrée est un fichier .csv, .json, .txt ou .sqlite, ou un répertoire contenant ces fichiers. La politique doit être un fichier régulier séparé. Utilisez un répertoire de sortie vide dédié, en dehors des entrées. Les originaux sont copiés dans un instantané temporaire privé ; la sortie réussie contient uniquement corpus/ et report.json.

L'interface de bundle existante reste disponible :

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

Un bundle contient policy.json et corpus/. La politique, l'identité canonique, les règles de valeur protégée, les échecs typés et le schéma du rapport appartiennent au projet. Lisez son README.md, docs/ANONYMIZATION_SEMANTICS.md et schemas/report.schema.json lors de leur interprétation. Ne déclarez pas le succès uniquement à partir d'un code de sortie : lisez le rapport réel, validez ses champs de préparation et inspectez la sortie pour le format demandé. Les rapports corrompus ou manquants ne sont PAS PRÊTS (READY).

Découverte optionnelle RapidFuzz : jamais de remplacement automatique

./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

La découverte compare les valeurs de chaînes structurées entières et les lignes de texte entières par rapport aux entrées de politique de type name. Ce n'est pas une extraction de spans NLP ou un scanner PII général. Par défaut : seuil de similarité 90, marge de séparation 5 ; configurables avec --threshold et --margin. Les égalités, quasi-égalités, valeurs protégées, valeurs contenant des chiffres ou une ponctuation d'identifiant telle que @, /, _, et les littéraux déjà connus ne sont pas proposés. Les apostrophes, traits d'union et points sont autorisés dans les textes en forme de nom ; la similarité n'est jamais une preuve que deux personnes sont une seule.

Demandez à l'opérateur d'approuver des IDs candidats spécifiques. N'approuvez jamais uniquement à partir du score de similarité. L'approbation re-dérive les propositions par rapport à la politique/au corpus actuel, rejette les révisions obsolètes/modifiées et compile une politique de correspondance exacte. Les propositions non approuvées n'affectent jamais l'anonymisation. release_ready: false est obligatoire sur les reçus de découverte/approbation.

Les fichiers de révision et de politique approuvée contiennent des noms bruts : conservez-les en dehors des versions, des journaux et des rapports partagés. Ils sont créés en mode 0600 et n'écrasent jamais un fichier existant. Les instantanés temporaires sont par défaut sur le disque d'artefact ; remplacez avec ANONYMIZE_DATA_WORK_DIR si nécessaire.

Docker reste l'interface autonome

Depuis le répertoire du projet :

docker build -t anonymization-trial .
docker run --rm anonymization-trial
# Image optionnelle activant la découverte ; l'image par défaut garde la dépendance exacte du moteur sans surcharge.
docker build --build-arg INCLUDE_DISCOVERY=1 -t anonymization-trial:discovery .

Montez uniquement l'entrée/la politique demandée en lecture seule et un répertoire de sortie dédié. Le même CLI du projet s'exécute à l'intérieur de l'image ; l'évaluateur n'a pas besoin de cette compétence. Voir docs/DISCOVERY.md du projet pour des exemples complets de commandes montées.

Limites d'échec et de preuve

Le wrapper conserve les codes de sortie du projet et les codes d'erreur nettoyés. Un projet/manquant et des chemins de packages installés incorrects échouent avant le traitement. Utilisez --help pour le contrat d'argument réel. La découverte est du matériel de révision, pas une version, une garantie d'anonymat, une probabilité de confiance ou une autorisation humaine.

./sanity.sh exécute de véritables vérifications CLI positives, négatives et adverses. Le fixtures/agentic_eval.json conservé les répète et nécessite une relecture de l'artefact. Une qualification préalable d'essai ne qualifie pas automatiquement ces extensions post-essai.

Règle de représentation (opérateur 2026-09-11)

Les PII doivent être mises en correspondance avec la valeur, pas avec la chaîne : avant que tout scalaire JSON/SQLite ne soit transmis inchangé, le transformer canoniquement en chaîne (nombres en forme de téléphone au format E.164) et exécuter la correspondance de politique sur la forme chaînée. Les fixtures doivent inclure chaque classe de PII dans chaque type scalaire JSON. Un numéro de téléphone stocké sous forme d'entier est le même numéro de téléphone, y compris lorsque la politique l'écrit sous forme de chaîne formatée telle que 555-123-4567 et que le corpus stocke 5551234567. Les conversions numériques avec perte de précision (zéro non significatif ou flottant) doivent échouer de manière sécurisée, sauf si une règle canonique spécifique au type prouve une équivalence sûre. Voir $best-practices-skills "Matrice de représentation des valeurs".

Leçons de durcissement (ne les réapprenez pas à la dure)

L'essai a été disqualifié parce qu'un téléphone stocké sous forme d'entier JSON/SQLite a passé le vérificateur de chaîne uniquement. La cause racine était une erreur de processus : le contrôle d'acceptation a été rédigé à partir de ce que le code faisait, non dérivé de la spécification livrée. Ces règles existent pour que cette classe d'erreur ne puisse pas se reproduire.

1. Dérivez le contrôle de la spécification, pas du code. policy.json liste les valeurs sensibles exactes. Le contrôle d'acceptation correct est "aucune de ces valeurs n'apparaît dans la sortie décodée, dans aucune représentation" — lisez les valeurs du fichier de politique, jamais une liste rédigée à la main. Prouvez que le contrôle dépend de la spécification avec une sonde de dépendance (inversez une valeur de politique → le résultat doit s'inverser). Implémentation de référence : le scripts/spec_derived_check.py du projet intégré dans scripts/verify.sh.

2. Le vérificateur indépendant ne doit partager aucune hypothèse avec la transformation. Le vérificateur original avait le même angle mort de chaîne uniquement que le producteur, donc rien n'a échoué de manière sécurisée. L'oracle de vérification doit être conscient de la représentation et indépendant : analyser JSON (décoder \uXXXX), développer les scalaires numériques sous forme entière/décimale, normaliser NFC/NFD des deux côtés, scanner les cellules de table+vue SQLite ET le DDL sqlite_master ET chaque entier d'en-tête, et scanner toute la limite publiée y compris report.json — pas seulement corpus/.

3. La classe de représentation complète est une liste de contrôle, pas un seul bug. Chacun de ceux-ci peut transporter une valeur sensible au-delà d'un vérificateur naïf ; le projet corrige et conserve un garde pour chacun : scalaires numériques typés (int/float, notation scientifique), SQLite BLOB (échec sécurisé), Unicode NFC/NFD, reconstruction de vue, résidu de freelist, schéma-DB hostile (index expression/partiel, vues non déterministes, DEFAUTS calculés), littéraux de schéma-DDL et entiers d'en-tête persistants. Voir le docs/SECURITY_REMEDIATION.md du projet pour le tableau complet.

4. Prouvez-le via le chemin Docker réel, de manière déterministe. La vérification doit être un script validé qui construit l'image, exécute les commandes exactes du brief et relit les octets publiés avec des sorties PASS/FAIL dures — pas de prose d'agent. Référence : security/docker_brief_contract.py (construction + les deux commandes du brief + analyse de fuite consciente de la représentation + précondition d'entrée) et security/docker_hardening_matrix.py (trous adverses via docker run). Enregistrez le commit git et l'id de l'image construite.

5. Limitez honnêtement la portée. Les pseudonymes déterministes d'espace de noms public divulguent l'égalité/la fréquence et n'offrent aucune résistance au lien externe ; le rapport d'exécution l'indique dans key_mode et does_not_establish. Une valeur de politique égale à une constante de format SQLite obligatoire est une entrée dégénérée, pas une vraie PII ; le pipeline échoue de manière sécurisée sur celle-ci et ce résidu est documenté comme limité.