Conservation de l'activité des agents IA : des enregistrements auxquels les enquêteurs font confiance

Les agents IA transforment un problème familier de journalisation en problème de preuve. Un humain peut passer un après-midi à cliquer dans une application ; un agent peut effectuer de nombreux appels externes pendant qu'un développeur lit son résumé. Si l'enregistrement dit seulement « l'agent a terminé la tâche », il ne peut pas répondre aux questions qui apparaissent après une suppression accidentelle, une modification inattendue en production ou un transfert contesté.

De bonnes règles de conservation préservent les faits nécessaires pour reconstituer une action sans créer une deuxième copie, mal protégée, de chaque secret et de chaque donnée client rencontrés par l'agent. Cette distinction détermine ce que vous collectez, la durée de conservation, les personnes autorisées à modifier les données et le moment où la suppression doit être suspendue.

La conservation commence par la question à laquelle l'enquêteur doit répondre

Un enregistrement d'activité ne mérite d'être stocké que s'il répond à une question d'enquête prévisible. Commencez par les questions, pas par un nombre de jours par défaut copié d'un autre produit.

Pour un agent capable d'appeler une API HTTP ou d'ouvrir une session SSH, les enquêteurs doivent généralement établir cinq éléments :

• Quelle identité d'exécution a effectué la requête, et quel humain ou service a autorisé cette exécution ?
• Quelle capacité l'agent a-t-il tenté d'utiliser et vers quelle destination ?
• Quelle opération a-t-il demandé à la destination d'effectuer ?
• Quel a été le résultat, y compris un refus, un délai d'attente, une réussite partielle ou une erreur distante ?
• L'équipe peut-elle montrer que l'enregistrement n'a pas été discrètement modifié après l'événement ?

Ces questions séparent les preuves d'action du bruit opérationnel. Un graphique de processeur peut aider à expliquer un délai d'attente, mais il ne prouve pas qu'un agent a émis DELETE /customers/42. Une transcription du prompt peut expliquer pourquoi l'agent pensait la suppression appropriée, mais elle ne prouve pas que la requête a atteint le service distant.

La publication spéciale 800-92 du NIST, Guide to Computer Security Log Management, présente la gestion des journaux comme un cycle de vie : générer, transmettre, stocker, analyser et supprimer les journaux. L'intérêt de ces recommandations n'est pas de fournir une durée de conservation magique. Elles exigent surtout que l'organisation définisse le but de ses journaux et tienne compte du stockage, des accès et de la suppression. Les équipes qui travaillent sur des agents passent souvent directement à la collecte parce qu'elle est facile. La discipline des accès et de la suppression détermine si ces enregistrements aideront ou nuiront plus tard.

Rédigez une phrase décrivant l'enquête pour chaque classe d'enregistrements. Par exemple : « Nous conservons les résultats des actions assez longtemps pour identifier et reconstituer une modification externe non autorisée après sa détection et son triage habituels. » Cette phrase oblige à justifier la durée et les champs. « Conserver tous les journaux d'agents pour toujours » évite cette discussion et crée un stock permanent de données sensibles.

Un enregistrement peut servir plusieurs objectifs, mais nommez-les séparément. L'enquête de sécurité, la réponse aux incidents, le support client, le débogage des versions, le rapprochement de facturation et la conformité peuvent nécessiter des informations et des durées différentes. Si un usage de débogage peu important maintient une charge utile complète pendant des années, la politique de conservation a échoué.

Un enregistrement d'action a besoin de contexte, pas d'une transcription

La conservation de l'activité d'un agent IA dépend d'abord du schéma d'événement. Capturez le plus petit ensemble de faits permettant à un enquêteur compétent de reconstituer l'action et de la relier à une session, sans conserver de données d'identification ni de contenu sans rapport.

J'utilise quatre niveaux d'information.

1. Contexte d'identité et d'autorisation. Enregistrez un identifiant d'événement immuable, un horodatage avec fuseau horaire, l'identifiant du processus agent, le chemin de l'exécutable ou l'identité du paquet, l'autorité de signature du code lorsque le système d'exploitation l'expose, l'identifiant de session et l'identité de l'approbateur ou du service associé à la session. Enregistrez la décision d'autorisation et le mode d'approbation utilisé.
2. Action demandée. Enregistrez le canal, l'hôte de destination, le port lorsqu'il est pertinent, la méthode HTTP et la route normalisée ou la classe de commande SSH, l'alias de l'identifiant ou sa référence interne, ainsi qu'une description sûre de l'opération demandée.
3. Résultat observé. Enregistrez la réussite, le refus, l'annulation, le délai d'attente, l'échec du transport, le code d'état distant lorsque cela s'applique, la classification de la réponse, le nombre d'octets envoyés et reçus si nécessaire, ainsi qu'un résumé d'erreur expurgé.
4. Liaisons de preuve. Enregistrez le hachage de l'enregistrement précédent, le hachage de l'enregistrement courant, la version du schéma et les identifiants reliant les tentatives, les nouvelles tentatives et les actions de suivi.

La distinction entre une destination et une requête compte. api.example.internal est une destination. PATCH /v1/users/42 est une action. Un journal qui ne contient que l'hôte ne peut pas distinguer une consultation d'inventaire d'identifiants d'une désactivation de compte. Un journal qui ne stocke qu'un chemin peut omettre l'environnement ciblé, qui fait souvent la différence entre un test sans conséquence et un incident.

Normalisez les données avant de les stocker. Placez les identifiants variables dans un champ structuré au lieu de forcer les enquêteurs à analyser du texte libre. Enregistrez route_template: "/v1/users/{user_id}" à côté d'un champ target_identifier protégé si l'identifiant est important. Pour SSH, distinguez la commande envoyée par l'agent de la commande distante après expansion du shell si votre chaîne d'exécution permet d'observer les deux. N'affirmez pas une certitude que vous n'avez pas.

Un enregistrement JSON pratique peut ressembler à ceci :

{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}

Cet enregistrement ne contient ni le bearer token, ni l'en-tête d'autorisation, ni le corps d'une facture. Il indique toutefois à l'enquêteur qu'un processus signé précis, pendant une session approuvée, a tenté une annulation en production au moyen d'une référence d'identifiant nommée et a reçu une réponse 403.

Ne dissimulez pas les champs à haut risque dans un bloc details. Les blocs de texte libre deviennent un fourre-tout pour les prompts, les en-têtes, les données personnelles et les traces d'erreur. Ils rendent aussi impossible l'application d'une durée de conservation par classe. Si un champ a une raison d'exister, donnez-lui un nom, une classification, un groupe d'accès et une règle de suppression.

Conservez les classes de preuves pendant des durées différentes

Une seule durée pour tous les enregistrements d'agents est simple à expliquer et généralement mauvaise à exploiter. Conservez les preuves d'action compactes plus longtemps que les informations de diagnostic riches, car l'enregistrement compact peut établir ce qui s'est passé sans multiplier l'exposition.

Utilisez des classes correspondant au travail réel d'enquête. Un ensemble de départ raisonnable est le suivant :

Ce tableau propose une méthode, pas l'affirmation que chaque équipe a besoin de chaque classe. Si l'agent ne fait que lire l'état d'une compilation, une classe de charges utiles protégées peut ne servir à rien. S'il modifie des données financières, un registre d'actions qui omet l'identifiant exact de la cible peut être trop pauvre.

Évitez la recommandation courante de conserver les requêtes et réponses brutes « au cas où ». Elle est populaire parce qu'elle simplifie le débogage initial et que le stockage semble bon marché. Le stockage n'est pas la partie difficile. Les accès à la recherche, l'étendue d'une fuite, les demandes d'accès des personnes, les garanties de suppression et la capture accidentelle de secrets sont les éléments coûteux.

Conservez le condensat cryptographique d'un corps lorsque vous devez prouver qu'un corps précis a été utilisé sans en préserver le contenu. Un condensat seul n'explique pas la signification et ne sert à rien si le corps original n'existe plus ailleurs. Utilisez-le pour la corrélation et la comparaison ultérieure, pas comme substitut à la description d'une action.

Conservez les tentatives échouées et refusées. Les refus révèlent souvent un agent qui tente d'utiliser la mauvaise capacité, une procédure d'approbation défectueuse ou un processus compromis qui teste les limites. Leur durée peut différer de celle des actions réussies si leur volume est beaucoup plus élevé, mais les supprimer en premier parce que « rien ne s'est passé » enlève le contexte nécessaire après une tentative réussie.

Définissez la durée à partir de la découverte et de la réponse, pas du coût de stockage

Choisissez une durée de conservation en remontant depuis le dernier moment où vous pensez encore pouvoir enquêter sur un événement. Le calcul n'est pas élégant, mais il rend les hypothèses visibles.

Pour une classe d'enregistrements, additionnez :

• le délai crédible maximal avant la détection ;
• le temps nécessaire pour ouvrir, cadrer et attribuer une enquête ;
• le temps nécessaire pour obtenir les enregistrements associés auprès des destinations ou des fournisseurs ;
• toute obligation contractuelle, réglementaire ou juridique applicable à cette classe ;
• une marge raisonnable pour les signalements tardifs et les écarts d'horloge.

Supposons qu'une équipe découvre une action de production suspecte lors d'une revue mensuelle, passe deux semaines à en confirmer la portée et puisse avoir besoin d'un mois pour obtenir l'historique d'un service distant. Une conservation des actions pendant 30 jours a déjà échoué avant même le début de l'enquête. La bonne réponse n'est pas automatiquement une durée de plusieurs années. L'équipe doit choisir une durée qui couvre ses pratiques réelles de détection et de réponse, puis la confronter aux obligations des juridictions et des contrats qui lui sont applicables.

Séparez la règle de l'exception. Le calendrier normal doit supprimer automatiquement les enregistrements. Une suspension liée à un dossier doit préserver un ensemble défini d'enregistrements en raison d'un incident, d'un litige, d'un audit ou d'une instruction juridique en cours. Lorsque la suspension prend fin, la suppression doit reprendre conformément à la politique, au lieu de laisser les enregistrements indéfiniment parce que personne ne s'en souvient.

Ne confondez pas la conservation des sauvegardes avec celle des journaux. Une sauvegarde de base de données contenant des enregistrements d'activité supprimés peut les rendre disponibles longtemps après que l'application les a supprimés. Documentez le chiffrement des sauvegardes, les personnes autorisées à les restaurer, leur durée de vie et la possibilité qu'une restauration réintroduise des enregistrements supprimés. Si vous ne pouvez pas purger un enregistrement individuel des sauvegardes immuables, indiquez-le dans la politique et définissez la durée des sauvegardes en conséquence.

Pour les systèmes traitant des données personnelles, consultez le service juridique et le responsable de la confidentialité avant de définir une durée. Le droit de la vie privée ne fournit généralement pas un chiffre universel adapté aux activités des agents. Il impose en revanche la limitation des finalités, la minimisation des données et une suppression défendable. Une justification de sécurité vague ne permet pas de conserver indéfiniment des contenus complets.

La preuve d'altération exige une frontière de confiance distincte

Un enregistrement que le même administrateur peut écrire et effacer n'offre pas beaucoup de garanties après un incident grave. La protection contre les modifications exige à la fois de les empêcher et de pouvoir prouver une modification ultérieure.

Le contrôle AU-9 de la publication NIST SP 800-53 demande de protéger les informations d'audit contre les accès, modifications et suppressions non autorisés. Cette formulation compte, car un stockage qui semble immuable ne résout pas à lui seul le contrôle des accès, et le contrôle des accès ne révèle pas chaque modification abusive. Construisez les deux niveaux.

Commencez par séparer l'exécution des actions de l'administration de l'audit. Le processus qui enregistre un événement doit disposer d'une permission d'ajout, et non d'une large permission de réécrire ou de purger l'historique. Les administrateurs qui gèrent la conservation ne doivent pas pouvoir modifier facilement le contenu d'événements individuels. Utilisez un processus distinct et auditable pour les suppressions et les corrections.

Ensuite, reliez les enregistrements dans une chaîne ordonnée. Chaque enregistrement contient le hachage de l'enregistrement précédent et le hachage de son propre contenu canonique. Un éditeur qui modifie un ancien événement rompt la chaîne à cet endroit ainsi que chaque lien suivant, à moins de pouvoir régénérer toute la séquence concernée. Le chaînage par hachage est utile, mais il a une limite : un attaquant qui contrôle l'auteur et toutes les copies stockées peut réécrire toute la chaîne. Exportez des points de contrôle signés vers un emplacement indépendant, ou mettez en place un processus de revue qui compare les points de contrôle hors du contrôle de l'auteur.

Protégez ensuite le temps. Les horloges système dérivent et les attaquants peuvent les modifier. Enregistrez l'heure de réception dans le collecteur, utilisez des numéros de séquence monotones lorsque c'est possible et considérez les horodatages comme des éléments à comparer avec des enregistrements externes, pas comme une vérité isolée. La RFC 3161 définit un protocole pour les horodatages de confiance. Elle peut renforcer la preuve qu'un condensat existait à un moment donné, mais ne prouve pas que le contenu de la requête était correct ou autorisé.

Enfin, vérifiez l'intégrité au lieu de vous contenter de l'affirmer. Une commande de vérification doit indiquer la première séquence incorrecte, le hachage du prédécesseur attendu, celui observé et l'identifiant de l'enregistrement. Cette forme de sortie donne à l'opérateur une information exploitable :

$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched

Lorsque la vérification échoue, préservez le stockage concerné avant que quelqu'un ne le « répare ». Exécutez la vérification sur une copie des données, capturez la sortie, identifiez le dernier point de contrôle valide et comparez-le à des exports indépendants. Réparer d'abord la chaîne peut détruire les preuves de la modification elle-même.

Un échec plausible révèle ce que cachent les journaux trop pauvres

Prenons le cas d'un agent de programmation qui reçoit l'autorisation d'une tâche de développement, puis tente un appel HTTP vers un service de facturation en production. La passerelle d'action refuse l'appel parce que l'autorisation de la session couvre un processus différent de celui qui effectue la requête. Quelques minutes plus tard, un développeur réessaie depuis une autre exécution d'agent et l'approuve sans remarquer la destination de production.

Le service distant renvoie une réponse 200. La transcription de la conversation de l'agent dit seulement qu'il a « résolu un problème de facture ». L'équipe découvre la plainte d'un client trois semaines plus tard.

Avec un enregistrement faible, l'équipe trouve un appel réussi provenant d'un compte « agent » inconnu et un horodatage générique. Elle ne peut pas déterminer si le premier appel refusé provenait du même exécutable, si l'approbation avait eu lieu dans la même session, quel identifiant avait été sélectionné, quelle facture avait été concernée ni si quelqu'un avait modifié l'enregistrement après la plainte. Elle finit par rechercher des historiques de shell, des exports de conversations et des journaux du service distant, qui peuvent avoir une durée de conservation plus courte que son propre système.

Avec un enregistrement utile, l'enquêteur peut reconstituer la séquence :

1. Un processus signé a démarré une session et reçu une approbation liée à cette exécution.
2. Un processus doté d'une identité différente a tenté l'opération de production et reçu un refus.
3. Une session ultérieure a utilisé une référence d'identifiant précise, ciblé l'hôte de production, demandé l'annulation d'une facture correspondant à un identifiant protégé et reçu un résultat 200.
4. La chaîne d'activité est vérifiée par rapport à un point de contrôle créé avant la plainte.

Cela ne prouve pas que le développeur avait l'intention d'effectuer l'action. Cela établit toutefois quel processus a été approuvé, ce que le chemin d'exécution a fait et où poursuivre l'enquête. Les enregistrements d'audit doivent résister à la tentation de raconter les motivations. Ils doivent préserver les faits qui permettront de les évaluer plus tard.

Stockez un identifiant de corrélation entre les nouvelles tentatives, mais ne regroupez pas toutes les tentatives dans un seul enregistrement final de réussite. Les nouvelles tentatives peuvent révéler un changement de destination, un changement d'identifiants ou un test des limites avant une action autorisée. Ces détails comptent lorsque la requête finale cause un dommage.

La rédaction doit avoir lieu avant l'entrée des enregistrements dans le registre

Un stockage d'audit chiffré protège les enregistrements au repos. Cela ne rend pas acceptable la journalisation de mots de passe, de jetons d'accès, de cookies de session, de clés privées ou d'objets clients complets. Dès qu'un contenu brut entre dans un registre conservé longtemps, chaque futur enquêteur, opérateur de restauration et intervenant en cas de fuite hérite de cette exposition.

Construisez une liste blanche de champs pour chaque canal. Pour HTTP, autorisez la méthode, la destination, le modèle de route, certains noms de paramètres de requête sûrs, la longueur du contenu, le statut et la classe d'erreur. Supprimez explicitement Authorization, Cookie, Set-Cookie, les jetons API, les secrets clients et les en-têtes sensibles connus. Traitez les corps des requêtes et réponses comme interdits par défaut.

Une rédaction fondée uniquement sur la détection de motifs manquera certains formats de secrets inédits et peut altérer les preuves. Utilisez d'abord des contrôles structurels : n'ingérez pas les champs qui ne devraient jamais être présents. Appliquez la détection de motifs comme deuxième barrière pour le texte d'erreur ou les données fournies par des services distants. Conservez une version de la rédaction dans l'événement afin que les enquêteurs sachent quelles règles ont été appliquées.

Les données personnelles exigent la même discipline. Un identifiant de compte peut être nécessaire pour identifier l'objet concerné. Un profil complet, un document ou une transcription de support n'a généralement pas sa place dans un registre général des actions. La pseudonymisation peut réduire l'exposition habituelle, mais n'appelez pas anonyme un identifiant réversible et stable. Si une personne disposant d'une autre table peut retrouver l'identité, il s'agit toujours de données personnelles à des fins de gouvernance.

Lorsqu'un dossier nécessite réellement du contenu, créez une capture de preuves limitée avec un identifiant de dossier, un groupe d'accès nommé, une date d'expiration et une date de revue. Enregistrez l'existence de cette capture dans le registre des actions, mais ne copiez pas son contenu dans chaque rapport en aval. Les enquêtes ordinaires restent ainsi utiles sans donner à tous les lecteurs accès aux données les plus sensibles.

Les suppressions, suspensions et corrections doivent laisser leurs propres preuves

La conservation est un processus opérationnel, pas un paragraphe dans une politique de sécurité. Un calendrier que personne ne teste finit par devenir un stockage permanent accidentel ou une purge automatique pendant un incident.

Exécutez les suppressions au moyen d'une tâche enregistrée. Pour chaque exécution, conservez la version de la politique, la classe d'enregistrements, l'intervalle de temps sélectionné, le nombre d'enregistrements supprimés, le nombre ignoré en raison de suspensions, l'identité de l'exécutant et le résultat. La tâche de suppression doit appliquer la même discipline d'ajout seul que l'enregistrement des actions. Un opérateur ne devrait pas avoir besoin d'un accès direct à la base de données pour « nettoyer » les enregistrements.

Une suspension doit avoir une portée qu'une machine peut appliquer. Définissez-la par identifiant de dossier, intervalle de temps des événements, identifiant de session, destination, identité de l'acteur ou autre sélecteur stable. Évitez les suspensions rédigées comme une phrase dans un ticket, car une tâche de conservation ne peut pas évaluer une phrase. Enregistrez la personne qui a émis la suspension, son fondement, la date de revue et l'événement de levée.

Les corrections méritent la même attention. Les systèmes enregistrent parfois une route mal analysée, un horodatage retardé ou une classification trompeuse. Conservez l'événement original. Ajoutez un événement de correction qui nomme l'événement original, identifie l'interprétation modifiée, en donne la raison et identifie la personne ou le processus à l'origine de la correction. Les rapports doivent montrer la correction sans dissimuler l'enregistrement source.

Testez tout le processus sur une copie hors production : créez des enregistrements dans chaque classe, placez une suspension sur une partie de l'intervalle, exécutez la conservation, vérifiez les suppressions attendues, levez la suspension et exécutez de nouveau la conservation. Restaurez ensuite une sauvegarde et vérifiez qu'elle ne crée pas une archive cachée et régulièrement accessible qui contredirait le calendrier déclaré.

Une politique concise est plus facile à appliquer qu'un document parfait

Une politique de conservation doit correspondre au système chargé de l'appliquer. Le modèle suivant est volontairement simple, car chaque phrase correspond à un responsable, un champ, une tâche ou une activité de vérification.

Purpose: reconstruct externally executed agent actions and investigate misuse.

Action ledger: retain for [period].
Fields: actor identity, session, authorization decision, destination,
operation, credential reference, protected target identifier, outcome,
integrity fields. Exclude secrets and raw bodies.

Diagnostic detail: retain for [shorter period].
Fields: bounded error text and timing. Apply allowlist and redaction rules.

Protected evidence capture: case-only. Require case identifier, expiry,
access group, and documented approval.

Integrity: append records; verify chain [cadence]; export or compare
checkpoints [cadence]. Record verification failures.

Deletion: execute [cadence]. Record policy version, range, result, and holds.
Holds: suspend deletion for defined selectors. Review [cadence].
Corrections: append a correction record; never overwrite an action record.

Désignez des responsables nommément pour le schéma des enregistrements, le calendrier de conservation, la revue de la confidentialité, les suspensions liées aux incidents et les contrôles d'intégrité. Une même personne peut cumuler plusieurs rôles dans une petite équipe, mais les responsabilités doivent tout de même être attribuées. Sinon, la personne qui exploite l'agent devient aussi celle qui décide quelles preuves disparaissent après un incident.

Sallyport conserve un journal Sessions et un journal Activity issus d'un seul journal d'audit chiffré et chaîné par hachage, et sp audit verify peut vérifier cette chaîne hors ligne sur du texte chiffré. Cette conception n'est utile que si les équipes décident à l'avance quels champs intégrer à leurs enregistrements et comment leurs tâches de conservation, suspensions et exports les traiteront.

Réexaminez la politique après le premier incident réel ou un exercice de simulation délibéré. Demandez aux enquêteurs de reconstituer une action en utilisant uniquement les enregistrements qui auraient survécu au calendrier. S'ils ont besoin d'un secret, d'une transcription brute ou du souvenir d'un administrateur pour répondre aux questions élémentaires, modifiez le schéma. S'ils peuvent répondre aux questions mais que chaque enregistrement contient des données client, réduisez le schéma avant qu'il ne devienne permanent.