# Export d'activité d'agent pour un examen juridique : constituer les preuves

Un **export d'activité d'agent** doit permettre à une personne extérieure de répondre à quatre questions simples sans faire confiance à la personne qui l'a constitué : quelles actions ont eu lieu, quand elles ont eu lieu, si les enregistrements ont été modifiés et qui a contrôlé les éléments après leur collecte. La plupart des équipes peuvent répondre à la première question. Les trois autres sont celles qui transforment un incident ordinaire en débat sur les preuves.

N'attendez pas une assignation, un conflit avec un salarié, un incident de sécurité ou une réclamation client pour décider quoi conserver. À ce moment-là, les tâches de rétention peuvent déjà avoir supprimé des journaux, des personnes peuvent avoir ouvert et réorganisé des fichiers, et un ingénieur pressé peut n'avoir exporté que les enregistrements qui semblaient pertinents. C'est compréhensible. C'est aussi exactement ainsi qu'un dossier perd sa crédibilité.

Voici une méthode pratique pour préparer des enregistrements d'actions d'agent destinés aux avocats, à une enquête interne, à un examen de conformité ou à un examinateur externe. Elle ne remplace pas un avis juridique. Elle fournit toutefois aux avocats quelque chose de bien plus utile qu'un tableur au nom rassurant.

## Traitez le dossier comme une preuve, pas comme un rapport

Un dossier de preuves conserve les éléments sources et explique comment ils ont été traités. Un rapport sélectionne, interprète et argumente à partir de ces éléments. Vous aurez peut-être besoin des deux, mais les mélanger sans précaution crée des difficultés.

Un rapport peut dire : « L'agent a tenté d'exécuter une commande SSH sur cet hôte à cette heure. » Le dossier de preuves doit permettre à un examinateur de retrouver l'enregistrement d'action sous-jacent, de voir la représentation de l'heure, d'examiner le résultat enregistré, de confirmer quel système l'a produit et de vérifier si l'export a changé. Le rapport doit se trouver à côté du dossier, pas dans son unique copie.

La distinction compte lorsqu'une première hypothèse s'avère fausse. Les enquêteurs réduisent souvent leur champ à mesure qu'ils en apprennent davantage. S'ils ont exporté une sélection manuelle d'événements « problématiques » puis supprimé les enregistrements voisins, ils ne peuvent plus vérifier si une nouvelle tentative, une approbation, un changement de session ou une action d'opérateur explique l'événement. Le contexte n'est pas décoratif. Il fait souvent la différence entre une action réellement non autorisée et une suite trompeuse d'échecs ordinaires.

Définissez le périmètre de collecte avant de commencer. Écrivez une phrase courte qui précise :

- les identifiants des processus ou sessions d'agents concernés
- les canaux d'action concernés, comme HTTP et SSH
- les heures de début et de fin en UTC
- les systèmes ou comptes couverts
- les exclusions connues et la raison de chacune

N'élargissez pas le périmètre en silence par la suite. Ajoutez plutôt une collecte complémentaire. Par exemple, si le premier dossier couvre une fenêtre d'incident de six heures et qu'un examinateur demande ensuite la journée précédente, créez un second dossier avec son propre manifeste et ses propres hachages. Reliez-le au premier dans le relevé de conservation. Vous préservez ainsi le fait que la première décision avait une limite.

C'est aussi à ce stade que les équipes commettent une erreur lourde de conséquences : elles confondent une vue d'activité avec un enregistrement source complet. Un tableau de bord peut être utile pour le triage, mais il applique souvent des filtres, une pagination, des préférences utilisateur et des limites de rétention invisibles sur une capture d'écran. Collectez les enregistrements bruts ou l'export source le plus proche disponible, puis créez des vues lisibles à partir de ce matériau.

## Séparez authenticité et exhaustivité

L'authenticité et l'exhaustivité sont deux affirmations différentes. Un bon dossier étaye chacune séparément.

L'authenticité consiste à déterminer si un enregistrement particulier provient bien de la source indiquée et si quelqu'un l'a modifié après sa collecte. Les hachages, signatures, stockages en ajout uniquement et chaînes de hachage contribuent à cette démonstration. L'exhaustivité consiste à déterminer si le dossier contient tous les enregistrements qui devraient entrer dans son périmètre déclaré. Les requêtes, les décomptes de la source, les paramètres de rétention et les notes de collecte contribuent à cette démonstration.

Les équipes accordent souvent trop de portée à un hachage de fichier. Un hachage SHA-256 peut montrer que `activity.jsonl` correspond aujourd'hui à la version hachée précédemment. Il ne prouve pas que le fichier contient toutes les actions de la période, que l'horloge du système était exacte ou que le fichier provient du système indiqué dans la note. Un hachage est une excellente preuve de continuité octet par octet. Ce n'est pas un sceau universel de vérité.

De même, une chaîne d'audit peut révéler une suppression ou une modification dans la séquence qu'elle couvre, mais elle ne corrige pas une mauvaise définition du périmètre. Si vous ne collectez qu'une session d'agent alors que l'incident en concernait deux, une chaîne intacte pour la première session ne rend pas le dossier exhaustif.

Utilisez un manifeste pour rendre ces affirmations vérifiables. Il doit identifier la source, le périmètre, la personne qui a effectué la collecte, l'heure de collecte, l'inventaire des fichiers et les éléments de vérification. Conservez-le dans un format texte simple qui ne nécessite pas une application particulière pour être lu.

```text
case_reference: IR-2025-017
package_id: 2025-017-agent-actions-01
collected_at_utc: 2025-03-08T14:27:19Z
collected_by: employee-id-1842
source_system: macOS workstation, asset WS-042
scope_start_utc: 2025-03-07T18:00:00Z
scope_end_utc: 2025-03-08T02:00:00Z
channels: HTTP, SSH
included_files:
  - original/activity-records.jsonl
  - original/session-records.jsonl
  - original/audit-verification.txt
  - derived/action-timeline.csv
exclusions: Browser history and local shell history were outside this collection.
```

Le répertoire `original` doit contenir les éléments sources collectés. Le répertoire `derived` peut contenir une chronologie CSV, une note d'examen ou une copie masquée. Cette séparation évite un problème courant : quelqu'un ouvre un fichier JSON, l'enregistre avec un éditeur qui modifie les fins de ligne ou l'encodage des caractères, puis découvre que le hachage original ne correspond plus.

Les Federal Rules of Evidence traitent de l'authenticité dans la Rule 901, au moyen d'éléments suffisants pour établir qu'un objet est bien ce que son auteur affirme. La Rule 902(14) traite spécifiquement des données certifiées copiées depuis un appareil électronique, un support de stockage ou un fichier, lorsqu'une personne qualifiée les identifie au moyen d'un procédé d'identification numérique. Ces règles ne permettent pas au personnel technique de négliger la documentation. Elles font du processus d'identification une partie de la preuve.

## Figez la source avant de la rendre lisible

Effectuez une seule collecte, préservez-la, puis faites le tri et la mise en forme sur des copies. Cela peut sembler tatillon jusqu'au jour où un enquêteur doit expliquer pourquoi un fichier a changé après que l'équipe l'a déclaré comme preuve.

Commencez par créer un répertoire de dossier à accès restreint. Notez l'emplacement exact du système depuis lequel les enregistrements ont été collectés, le compte utilisé et le fait que la source soit restée active ou non après la collecte. Si la source peut continuer à recevoir des événements, indiquez-le. Un système actif n'est pas une pièce statique, et prétendre le contraire produit des chronologies confuses.

Effectuez ensuite un export direct de la source. Évitez d'ouvrir les fichiers dans un tableur avant de les hacher. Les tableurs réinterprètent régulièrement les dates, tronquent les valeurs longues, modifient les séparateurs et traitent les identifiants comme des nombres. Cela peut être acceptable dans un fichier d'analyse de travail. C'est inadmissible pour la copie préservée.

Sur macOS, calculez un inventaire SHA-256 depuis le répertoire du dossier après y avoir placé les originaux :

```sh
find original -type f -print0 | sort -z | xargs -0 shasum -a 256 > SHA256SUMS.txt
cat SHA256SUMS.txt
```

La sortie contient une ligne par fichier, avec un condensé hexadécimal de 64 caractères suivi du chemin du fichier. Enregistrez la sortie de la commande dans le dossier et notez qui l'a exécutée. Vérifiez ensuite avec le même inventaire :

```sh
shasum -a 256 -c SHA256SUMS.txt
```

Une vérification réussie affiche chaque chemin suivi de `OK`. Si un chemin affiche `FAILED`, cessez de considérer le dossier comme inchangé. Conservez la copie en échec, documentez le résultat et déterminez si un transfert, un changement de nom, une conversion des fins de ligne ou une véritable modification en est la cause. Ne régénérez pas le fichier de hachages pour poursuivre discrètement.

Les noms de fichiers doivent être sobres et stables. Incluez si nécessaire l'identifiant du dossier, la catégorie de source et l'heure de collecte en UTC. Évitez les noms comme `final-final-v3` ou `suspicious stuff`. Un examinateur ne devrait pas avoir besoin d'une histoire orale pour distinguer un export original d'une feuille de travail filtrée.

La publication spéciale 800-86 du NIST, Guide to Integrating Forensic Techniques into Incident Response, insiste sur la préservation des données et la documentation de la collecte et du traitement. Ses recommandations sont antérieures aux outils d'agents, mais la discipline reste pertinente. Les actions d'agents évoluent rapidement. Cela justifie de meilleures notes de collecte, pas un niveau d'exigence inférieur.

## Enregistrez les horodatages avec le contexte de leur horloge

Un horodatage sans horloge définie est un fait incomplet. Préservez la valeur originale, son fuseau ou son décalage, le nom du champ et tout identifiant d'ordre connu.

Utilisez l'UTC comme référence du dossier. Exprimez-la au format ISO 8601, par exemple `2025-03-08T14:27:19Z`. Conservez aussi exactement les horodatages tels qu'ils ont été exportés. Si une source affiche l'heure locale, indiquez son fuseau configuré et si le système synchronisait son horloge avec un service approuvé. Ne remplacez pas un horodatage source simplement parce que l'équipe préfère un autre format d'affichage.

Une action d'agent peut générer plusieurs heures. Un enregistrement peut contenir le moment où l'agent a demandé une opération, celui où une approbation est apparue, celui où une personne l'a approuvée, celui où le système l'a exécutée et celui où un service distant a répondu. Ces moments ne sont pas interchangeables.

Pour obtenir une chronologie utile, étiquetez-les par événement au lieu de les réduire à une seule colonne `timestamp`. Une demande à 10:00:01, une approbation à 10:00:28, une exécution à 10:00:29 et un échec distant à 10:00:31 racontent une histoire différente d'une exécution survenue avant l'approbation. L'ordre peut établir ou réfuter l'existence d'un contrôle humain.

Capturez les identifiants de séquence lorsqu'ils existent. Une séquence d'audit croissante, un numéro d'appel propre à la session ou un identifiant de demande peut départager deux enregistrements dont la précision temporelle est identique. Si les enregistrements ne fournissent que des horodatages à la seconde, dites-le. Ne créez pas une précision à la milliseconde en enregistrant l'heure de l'export.

Les désaccords entre horloges méritent une note distincte. Si le poste local et une API distante présentent plusieurs minutes d'écart, conservez cette observation et identifiez les sources. Ne « corrigez » pas un enregistrement pour rendre la chronologie plus nette. Un examinateur devra peut-être déterminer si les systèmes utilisaient des horloges différentes ou si un événement a franchi une limite temporelle.

Le dossier doit contenir une courte déclaration temporelle comme celle-ci : « Tous les affichages de la chronologie utilisent l'UTC. Les valeurs sources restent dans les fichiers originaux. Le poste indiquait un décalage UTC de +00:00 pendant la collecte. Aucune comparaison indépendante des horloges n'a été effectuée. » Cette dernière phrase peut sembler insatisfaisante, mais elle est honnête. Une certitude non étayée cause plus de dommages qu'une limite documentée.

## Préservez l'action et le contexte de décision

Un enregistrement d'action doit fournir assez de contexte pour distinguer une demande tentée, une exécution autorisée et un effet externe accompli. Ce sont des événements différents.

Pour une activité HTTP, conservez l'heure de l'action, l'identifiant de session ou de processus, la méthode, l'hôte de destination, le chemin, les en-têtes pertinents après suppression des secrets, le traitement du corps de la demande, le statut de réponse et les métadonnées du résultat. Le dossier ne doit pas contenir de jetons porteurs réutilisables, de mots de passe ou de clés privées simplement parce qu'ils sont passés par un système d'action. Un secret peut créer un second incident au sein même du processus de preuve.

Pour une activité SSH, préservez l'hôte cible ou son alias, l'identité utilisateur utilisée par le système d'action, la commande ou sa catégorie lorsqu'elle est journalisée, le résultat de l'authentification, le code de sortie et la sortie renvoyée, selon une règle de masquage documentée. Si la sortie peut contenir des données client, conservez l'original avec un accès restreint et créez une copie d'examen qui décrit chaque masquage. Des bandes noires sans journal de masquage amènent les examinateurs à se demander ce qui a pu disparaître d'autre.

L'identité du processus compte autant que l'action. Enregistrez le processus d'agent à l'origine de l'appel, son autorité de signature de code lorsqu'elle est disponible, son identifiant de session et la durée de vie de la session. Dire que « l'agent de programmation l'a fait » est trop vague pour un examen juridique. Des processus distincts peuvent avoir des origines, des approbations et des permissions différentes, même si une personne les appelle tous de la même façon.

Les approbations doivent être formulées avec soin. Une approbation signifie qu'une personne a autorisé une opération ou une session définie conformément à la conception du système. Elle ne prouve pas que cette personne a lu chaque détail, compris toutes les conséquences ou disposait des pouvoirs requis par une politique interne. Ne faites pas ces affirmations sans éléments distincts pour les étayer.

Sallyport enregistre les exécutions d'agents dans un journal Sessions et les appels individuels dans un journal Activity, les deux vues étant générées à partir d'un même journal d'audit chiffré et chaîné par hachage. Cette conception facilite l'examen : une question au niveau de la session et une question au niveau de l'appel peuvent renvoyer à la même séquence d'enregistrements sous-jacente.

Conservez intacte la relation entre la demande originale et le résultat. Un appel échoué peut être aussi pertinent qu'un appel réussi. Des échecs répétés peuvent révéler qu'un agent a réessayé avec un identifiant bloqué, qu'un point de terminaison a changé ou qu'un opérateur a corrigé une configuration. Supprimer les échecs pour raccourcir la chronologie supprime souvent l'explication du succès important.

## Vérifiez les traces de modification tant que la source reste disponible

Effectuez la vérification d'intégrité pendant la collecte et enregistrez le résultat avec les éléments originaux. Une vérification ultérieure reste utile, mais un résultat précoce relie le dossier à l'état du système de journalisation au moment de la collecte.

Un journal chaîné par hachage relie chaque enregistrement aux éléments précédents au moyen de données cryptographiques. Une modification, une suppression ou une insertion rompt normalement le lien ultérieur. Les examinateurs disposent ainsi d'une propriété précise à tester : la séquence se vérifie-t-elle telle qu'elle a été émise ? Cela ne prouve pas que l'action journalisée était justifiée sur le plan éthique ni que chaque événement possible du système a atteint le journal. Gardez ces affirmations séparées.

Pour un journal d'audit Sallyport, exécutez `sp audit verify` sur la source collectée avant de vous appuyer sur les vues des journaux. La vérification peut être effectuée hors ligne sur le texte chiffré et ne nécessite pas de clé de coffre. Un enquêteur peut ainsi préserver un résultat d'intégrité sans obtenir les identifiants utilisés pour les actions externes.

Enregistrez la transcription complète du terminal, y compris la commande, le répertoire courant, l'identité du compte si votre procédure la capture, les heures de début et de fin et le code de sortie. Une capture d'écran est moins solide qu'un texte, car elle est difficile à rechercher, copier et réexécuter indépendamment. Si la commande signale un échec, conservez ce résultat. N'exportez pas uniquement les enregistrements qui semblent être vérifiés.

La vérification doit être reproductible. Notez la version de l'application, la version du système d'exploitation lorsque c'est pertinent et le chemin exact de collecte. Si l'outil dépend d'une installation locale particulière, conservez une trace de cette dépendance. Vous n'avez pas besoin d'empaqueter par défaut tous les exécutables, mais les examinateurs doivent savoir ce qu'il leur faudrait pour reproduire le contrôle.

Une note de vérification simple peut être formulée ainsi : « Le collecteur a exécuté la commande de vérification de l'audit à 2025-03-08T14:31:02Z sur le journal d'audit chiffré copié dans `original/`. La commande s'est terminée avec succès. La transcription non modifiée du terminal se trouve dans `original/audit-verification.txt`. » Si la commande n'a pas abouti, dites-le clairement et indiquez l'effet sur le dossier. Les éléments d'intégrité sont utiles précisément parce qu'ils peuvent contredire l'explication que vous préférez.

## Tenez un relevé de conservation qui nomme les personnes et les transferts

La chaîne de conservation est une chronologie de la possession et du contrôle. Ce n'est pas une page de signatures remplie après coup lorsqu'une personne en demande une.

Commencez le relevé au moment où le collecteur crée le dossier. Chaque entrée doit indiquer l'identifiant du dossier, la date et l'heure en UTC, la personne ou le compte de service qui transfère le contrôle, le destinataire, le motif, le mode de transfert, l'emplacement de stockage et le hachage du dossier ou la référence à l'inventaire des hachages. Si une seule personne conserve le contrôle pendant toute la collecte, indiquez-le également.

Utilisez des noms ou des identités internes stables que l'entreprise pourra retrouver plus tard. « L'équipe sécurité » n'est pas un dépositaire. « Jeanne du service juridique » ne suffit pas non plus. Les personnes changent de poste, quittent l'entreprise et se souviennent différemment des événements sous pression.

```text
2025-03-08T14:38:11Z
Package: 2025-017-agent-actions-01
Released by: employee-id-1842
Received by: legal-ops-id-77
Purpose: counsel review under incident hold
Method: encrypted internal file transfer
Integrity reference: SHA256SUMS.txt verified before transfer
Storage: matter workspace, restricted folder
```

Lorsqu'un transfert utilise un stockage chiffré ou un échange sécurisé de fichiers, notez le procédé, sans supposer que le chiffrement prouve la conservation. Le chiffrement protège la confidentialité pendant le transit. L'entrée de conservation établit qui a intentionnellement transféré et reçu le dossier. Demandez au destinataire d'accuser réception, puis consignez toute copie ultérieure destinée à un consultant, un assureur, un organisme de réglementation ou un avocat externe.

Les journaux d'accès peuvent étayer le relevé de conservation, mais ils ne le remplacent pas. Un journal de stockage peut montrer qu'un compte a accédé à un fichier. Il ne peut pas toujours expliquer pourquoi, confirmer que le compte appartenait à la personne attendue à ce moment-là ou établir qu'un transfert approuvé a eu lieu en dehors du système de stockage.

Évitez d'envoyer l'unique original par e-mail ordinaire. Le courrier électronique crée des copies incontrôlées, un risque de transfert automatique, des difficultés de rétention et une ambiguïté sur les versions des pièces jointes. Si les avocats ont besoin d'une copie, créez une copie de diffusion documentée, vérifiez son hachage après le transfert et conservez l'original dans l'emplacement contrôlé.

## Le masquage doit être réversible dans le processus, pas dans les fichiers

Masquez les éléments en fonction d'un public et d'un objectif définis, mais conservez un original non masqué lorsque la loi, la politique ou l'enquête l'exigent. Ne faites pas de la version masquée le seul dossier encore disponible.

Les enregistrements d'agents peuvent contenir des secrets, du code source, des données personnelles, des données client, des noms d'hôtes internes ou des détails opérationnels qui créent un nouveau risque s'ils sont largement diffusés. Un examen juridique exige rarement un identifiant API réutilisable ou du matériel SSH privé. Excluez-les de la copie d'examen et expliquez comment le processus de collecte les a traités. Si un export source contient des secrets, restreignez davantage l'original au lieu de le distribuer à tous les examinateurs.

Utilisez un journal de masquage avec une ligne pour chaque élément masqué ou pour chaque catégorie cohérente. Indiquez le fichier, l'identifiant de l'enregistrement, le champ, la raison, la personne qui a effectué le masquage, la date et la disponibilité de l'original sous accès restreint. L'examinateur doit pouvoir distinguer un en-tête d'autorisation masqué d'un résultat d'action supprimé.

Ne vous fiez pas à des superpositions visuelles dans des PDF ou des captures d'écran. Des masquages incorrects ont suffisamment souvent exposé le texte sous-jacent pour qu'on ne puisse jamais les traiter comme un simple détail de production. Créez un nouvel élément d'examen à partir d'une copie contrôlée, inspectez-le avec des outils d'extraction ordinaires et vérifiez que le contenu sensible n'apparaît plus. Hachez ensuite séparément l'élément masqué. Son hachage ne doit pas remplacer l'inventaire original.

Une chronologie filtrée peut être utile, surtout lorsqu'un dossier couvre des milliers d'appels ordinaires. Étiquetez-la comme une pièce dérivée et incluez la logique du filtre. Par exemple : « Inclut les appels vers le locataire client indiqué entre les heures UTC précisées ; exclut toutes les autres destinations ; les enregistrements sources restent dans original/activity-records.jsonl. » Cette phrase permet aux avocats d'expliquer ce qu'est la pièce sans prétendre qu'elle constitue l'historique complet de l'audit.

## Rendez le dossier exploitable six mois plus tard

La personne qui collecte le dossier ne sera peut-être pas celle qui l'expliquera plus tard. Rédigez les notes pour la personne qui reprendra le dossier après la disparition de la conversation d'incident et l'oubli des détails par l'ingénieur d'origine.

Ajoutez un fichier readme court qui répond aux questions pratiques : quels fichiers sont originaux, lesquels sont dérivés, quel outil a produit chaque export, comment vérifier les hachages, quelle référence temporelle utiliser et où l'accès à l'original préservé est contrôlé. Gardez les opinions dans une analyse d'incident distincte, sauf si le dossier les désigne clairement comme une déclaration d'analyste.

Le verrou du coffre Sallyport, l'autorisation de session et les approbations à chaque appel peuvent produire des enregistrements utiles pour expliquer le contrôle humain autour d'une action. Conservez le niveau exact d'éléments d'approbation nécessaire au dossier, puis évitez d'affirmer qu'un contrôle produit répond à une question juridique qui relève de la politique, de l'autorité ou de l'intention.

Effectuez un exercice à blanc avant qu'une enquête ne vous y oblige. Demandez à un collègue qui n'a pas collecté le dossier d'utiliser uniquement le readme, le manifeste, les hachages et la transcription de vérification pour répondre à ces questions : quels enregistrements sources sont inclus ? Puis-je les vérifier ? Quelle référence temporelle s'applique ? Qui en avait la garde ? Si ce collègue doit poser des questions élémentaires au collecteur, le dossier n'est pas prêt.

La première amélioration utile est généralement peu spectaculaire : créez dès maintenant un modèle de répertoire de dossier, un manifeste en texte brut, une commande d'inventaire des hachages et un relevé de conservation. Lorsqu'un incident réel survient, ces quatre éléments empêchent un export réalisé dans l'urgence de devenir une histoire impossible à vérifier.