Comment examiner les actions d'un agent IA sans conserver les prompts

Les relevés d'examen des agents autonomes doivent expliquer une action externe sans devenir une seconde copie, mal protégée, de toute la mémoire de travail de l'agent. Il faut donc enregistrer qui a exécuté l'agent, quelle autorité a permis l'exécution, quelle frontière l'action a franchie et ce qui s'est passé. Il ne faut pas conserver éternellement chaque prompt, message d'outil, brouillon interne et charge utile d'API.

Les équipes commencent souvent par les transcriptions de conversation, faciles à capturer et qui donnent une impression de complétude. Puis un incident survient, et la transcription contient des données client, du code source, des jetons collés, des instructions spéculatives et des pages de contenu sans rapport avec l'action examinée. Pendant ce temps, l'examinateur ne peut toujours pas répondre à la question essentielle : quel exécutable a envoyé quelle requête à quel service, avec quelle autorisation, quelle portée d'identifiant et quel résultat ?

Un relevé d'examen doit suivre l'action, pas la conversation. Ce choix réduit l'exposition et produit des éléments qu'un opérateur peut réellement utiliser.

Un relevé d'action répond à une autre question qu'une transcription

Un relevé d'action indique si un processus donné a franchi une frontière et ce que le système externe a fait en réponse. Une transcription indique quel texte est passé dans le contexte d'un agent. Ce sont deux artefacts différents, avec des besoins d'accès, des durées de conservation et des modes de défaillance différents.

Imaginons qu'un agent lise un long fil de tickets, examine un dépôt, rédige une note de version et appelle une API pour créer un déploiement. Une exportation de la conversation peut contenir des milliers de lignes. Le relevé utile peut être beaucoup plus court :

• Identité du processus et identifiant de session.
• Décision d'autorisation couvrant l'action.
• Destination, méthode, catégorie de ressource et référence de l'identifiant.
• Résultat, avec le statut et un résumé sûr.
• Horodatages et données d'intégrité.

Ce relevé permet à un ingénieur de reconstituer l'événement opérationnel : un processus signé a démarré à une heure donnée, a reçu une approbation pour une session, a envoyé POST à un hôte d'API et à un point de terminaison de déploiement identifiés, a utilisé l'identifiant de déploiement et a reçu un statut de réussite avec un identifiant de déploiement. Si nécessaire, l'examinateur peut demander des éléments plus détaillés au propriétaire du service de destination.

La transcription peut expliquer pourquoi l'agent pensait devoir déployer. Elle prouve rarement qu'il l'a fait. Le texte du contexte d'un agent peut être hypothétique, obsolète, inventé par un modèle ou ne jamais avoir été exécuté. L'action externe possède une piste de preuve plus étroite et plus défendable.

Conservez les éléments conversationnels dans l'environnement de développement uniquement lorsque l'équipe a une raison claire de le faire, par exemple pour évaluer la qualité ou traiter un incident précis. Ne les glissez pas dans un système d'audit sous prétexte de responsabilité.

Les prompts complets créent un entrepôt de données que personne n'avait prévu de protéger

La capture des prompts complets transforme un journal d'actions en archive de contenu à haut risque. Le danger n'est ni théorique ni limité aux secrets évidents.

Les prompts contiennent souvent des fragments de code source, des tickets clients, des résultats de base de données, des URL internes, des décisions de conception, un historique de commandes shell et des messages d'erreur copiés. Un modèle peut répéter le contexte précédent dans un argument d'outil ou une explication d'erreur. Une API peut renvoyer un en-tête ou un corps de requête soumis dans une réponse d'erreur. Si le système de journalisation considère toutes les chaînes comme des diagnostics inoffensifs, il finira par conserver des informations que l'équipe n'avait jamais prévu de collecter.

La réponse habituelle est : « Nous masquerons les secrets. » Cela ne fonctionne que si le chemin de journalisation voit chaque format de secret avant le stockage et comprend chaque protocole. Il manquera les URL signées de courte durée, les cookies de session, les formats de jetons propriétaires, les secrets intégrés dans des chaînes JSON et les identifiants qu'un service renvoie dans une erreur. Le masquage ne peut pas non plus rétablir la confidentialité après que le relevé original a été consulté par un groupe élargi.

L'OWASP Logging Cheat Sheet établit une distinction utile : les journaux doivent permettre la surveillance et l'enquête, mais les systèmes ne doivent pas journaliser les jetons d'accès, les mots de passe, les chaînes de connexion, les clés de chiffrement ni les données dont la collecte crée une exposition inutile à la vie privée. Appliquez ce conseil aux examens d'agents avec davantage de rigueur, pas moins. Le contexte d'un agent est particulièrement vaste et contient donc plus de données accidentelles qu'un journal de requêtes classique.

Appliquez la minimisation des données au moment de la capture. Stockez une empreinte de requête ou des métadonnées approuvées, pas le prompt brut qui l'a produite. Si une enquête a besoin du contexte, récupérez-le dans le système d'origine, avec les contrôles adaptés à ce système. Ne faites pas d'un journal d'audit l'endroit le plus facile pour parcourir toutes les conversations sensibles.

Une exception limitée existe : une équipe peut avoir besoin d'une capture temporaire et strictement restreinte pour diagnostiquer une intégration défaillante. Faites-en un mode de diagnostic explicite, avec un responsable désigné, une date d'expiration, une restriction d'accès et une date de suppression. Si la capture de diagnostic devient permanente parce que personne ne la désactive, ce n'était pas une capture de diagnostic.

L'identité du processus doit résister à un nom de processus sympathique

Un nom de processus n'identifie pas un agent. agent, node, python et shell n'apprennent presque rien à l'examinateur, et un programme malveillant ou négligent peut choisir n'importe lequel de ces noms.

Enregistrez suffisamment de données d'identité pour distinguer le programme qui a lancé la session :

• Chemin de l'exécutable et identité stable du code, par exemple une autorité de signature lorsque le système d'exploitation en fournit une.
• Identifiant du processus, identifiant du processus parent, heure de lancement et identifiant de session.
• Compte utilisateur et identifiant de l'hôte local.
• Version ou identifiant de build du client d'agent lorsque celui-ci le fournit.
• Transport ayant atteint la passerelle d'action, par exemple une connexion MCP stdio locale.

Le processus parent compte. Un éditeur signé qui lance un agent de programmation approuvé présente un scénario différent de celui d'un processus shell inconnu qui lance un binaire copié avec le même nom de commande. L'identité du parent ne prouve pas une bonne intention, mais elle donne un point de départ aux enquêteurs et rend les imitations simples plus faciles à repérer.

Ne confondez pas l'identité du processus avec une identité humaine. Un développeur peut démarrer un agent, mais le relevé d'action doit indiquer séparément ces deux faits : quel compte local a démarré le processus et quel exécutable détenait la session. Les postes partagés, shells distants, comptes de service et transferts entre outils rendent cette séparation nécessaire.

L'autorité de signature du code mérite une attention particulière lorsqu'elle est disponible, car le système d'exploitation peut la vérifier au lancement. Elle ne constitue toutefois pas un jugement moral sur l'éditeur. Une autorité de signature approuvée peut publier une mise à jour défectueuse, et un outil interne non signé peut être légitime. Le relevé doit contenir ce fait afin que l'examinateur puisse le comparer à la décision d'autorisation et au chemin de déploiement attendu.

L'autorisation a besoin d'une portée, d'une durée et d'un approbateur

Une approbation sans portée n'est qu'un souvenir vague, pas un élément d'examen. Le relevé doit indiquer ce que la personne a approuvé, quand cette approbation a commencé et quand elle a cessé de s'appliquer.

L'autorisation de session est souvent le bon choix par défaut pour une exécution d'agent dirigée par un développeur. Une personne approuve une fois un processus d'agent connu, puis le processus peut effectuer des actions jusqu'à sa fermeture. Le journal d'examen doit rattacher cette décision à la session du processus, plutôt que de prétendre que chaque appel ultérieur a fait l'objet d'un jugement humain indépendant.

Pour les identifiants à risque élevé, capturez une décision distincte pour chaque appel. Le relevé doit inclure l'identité de l'approbateur, l'heure, la référence de l'identifiant, la catégorie d'action, la destination et l'identifiant exact de l'appel libéré. Une note générique comme « utilisateur approuvé » laisse trop de place aux contestations après une mauvaise action.

Un objet d'autorisation exploitable ressemble à ceci :

{
  "authorization_id": "auth_7f3c",
  "kind": "session",
  "decision": "approved",
  "approved_at": "2025-03-08T14:22:31Z",
  "approver": "local-account:maya",
  "process_session": "sess_31a9",
  "process_identity": {
    "executable": "/Applications/Agent.app/Contents/agent",
    "signing_authority": "Example Development Team"
  },
  "scope": {
    "credential_refs": ["deploy-production"],
    "expires_when": "process exits"
  }
}

Les noms et identifiants ci-dessus sont des exemples, mais la structure compte. L'approbateur est l'identité d'un compte local, pas l'affirmation qu'une personne nommée a surveillé chaque ligne de sortie. La référence d'identifiant est un libellé ou un identifiant interne, jamais l'identifiant lui-même. La portée indique si la décision couvrait une session ou un seul appel.

Ne résolvez pas ce problème avec un langage de règles tentaculaire, sauf si votre environnement d'exploitation l'exige réellement. Les équipes créent souvent des règles que personne ne peut lire pendant un incident, puis considèrent leur simple présence comme un contrôle. Un petit nombre de choix d'autorisation visibles peut être plus facile à examiner et plus difficile à mal configurer.

Les métadonnées de requête doivent décrire la frontière franchie

Un examinateur a besoin de suffisamment de métadonnées pour comprendre la portée de l'opération sans recevoir une copie brute de celle-ci. Pour HTTP, capturez l'hôte du service, le port lorsque c'est pertinent, la méthode, le modèle de route normalisé, la référence de l'identifiant, la taille de la requête, l'identifiant de corrélation et une empreinte d'une représentation canonique sûre.

Un modèle de route normalisé consiste à enregistrer /v1/projects/{project_id}/deployments plutôt qu'une URL littérale contenant un identifiant client ou une valeur opaque ressemblant à un secret. La route brute peut rester dans le service de destination, qui possède déjà ces données et ses propres contrôles d'accès.

Pour SSH, le relevé équivalent inclut l'hôte de destination, l'identité d'hôte vérifiée, le compte distant, la commande demandée ou sa classification, la référence de l'identifiant et le résultat d'exécution. Évitez d'enregistrer une sortie de commande sans restriction. Une commande peut afficher des variables d'environnement, le contenu de dépôts privés ou des identifiants provenant d'un script mal configuré.

HTTP Semantics, RFC 9110, distingue les propriétés des méthodes de requête, notamment les méthodes sûres, idempotentes et non sûres. Utilisez cette distinction comme signal d'examen, pas comme raccourci d'autorisation. Un GET peut divulguer des données sensibles. Un PUT peut être idempotent tout en remplaçant une configuration de production. Un POST peut créer un effet externe irréversible. La méthode aide l'examinateur à raisonner sur l'action, mais la destination et la route déterminent le risque réel.

Utilisez un schéma de métadonnées basé sur une liste autorisée. Ne commencez pas par l'objet de requête complet pour supprimer les champs plus tard. La bonne approche consiste à définir les champs qu'un relevé d'action peut contenir, puis à rejeter ou transformer tout le reste.

{
  "call_id": "call_c24e",
  "session_id": "sess_31a9",
  "channel": "https",
  "destination": "api.example.internal",
  "method": "POST",
  "route_template": "/v1/projects/{project_id}/deployments",
  "credential_ref": "deploy-production",
  "request_bytes": 842,
  "request_digest": "sha256:6d1d...",
  "started_at": "2025-03-08T14:24:09Z"
}

Une empreinte détecte la modification d'un relevé canonique lorsque l'examinateur possède la représentation originale approuvée. Elle ne rend pas le contenu original sûr à publier. Soyez également prudents avec les hachages de secrets à faible entropie, car un attaquant peut les deviner et les comparer. Ne hachez pas un jeton court en prétendant l'avoir masqué.

Les résultats ont besoin de preuves opérationnelles, pas de vidages de réponses

Un relevé de résultat doit indiquer ce que la destination a signalé et si la passerelle a terminé l'opération demandée. Il ne doit pas enregistrer par défaut le corps de réponse complet.

Pour une action HTTP, enregistrez la fin du transport, le statut HTTP, la taille de la réponse, la durée, l'identifiant de requête du service lorsqu'il est sûr et un champ de résultat choisi avec soin. Par exemple, une API de déploiement peut renvoyer un identifiant de déploiement que l'on peut conserver, tandis que sa réponse JSON complète contient des variables d'environnement et un message de commit provenant d'un dépôt privé.

Pour une action SSH, conservez le code de sortie, la durée, le résultat de la vérification de l'hôte et un résumé choisi par l'adaptateur de commande. Si une commande doit prouver la réussite d'une opération, faites-lui produire un résultat machine lisible et limité, comme {\"release\":\"r42\",\"status\":\"published\"}. N'acceptez pas une transcription de terminal arbitraire comme résultat d'audit.

Cette distinction compte en cas d'échec. Imaginez qu'un appel de déploiement renvoie HTTP 403 avec un objet de diagnostic qui répète l'en-tête d'autorisation de l'appelant. L'agent voit l'erreur, réessaie deux fois et chaque tentative produit une entrée de journal différente. Un système d'examen négligent contient maintenant trois copies d'un identifiant exposé, toutes indexées sous un incident que davantage de personnes ouvriront.

Construisez le chemin d'erreur avant le chemin de réussite. La passerelle d'action doit classer l'erreur, supprimer les champs dangereux et enregistrer un résumé limité. Les catégories utiles comprennent l'échec réseau, l'autorisation refusée, la requête rejetée par la destination, l'expiration de la destination et l'échec d'exécution locale. Associez la catégorie à des faits sûrs comme le code de statut ou le code de sortie, pas à un bloc de texte libre provenant d'un service distant.

Les nouvelles tentatives méritent leurs propres champs. Enregistrez attempt, max_attempts et un lien causal vers l'appel d'origine. Sinon, l'examinateur voit trois requêtes destructrices et ne peut pas savoir si l'agent les a répétées intentionnellement ou si une nouvelle tentative du transport a créé des doublons. Pour les opérations non sûres, une nouvelle tentative peut exiger une autorisation renouvelée ou un mécanisme d'idempotence côté destination. La journalisation ne peut pas réparer une action appliquée deux fois par la destination.

Un schéma d'examen doit rendre les champs interdits impossibles à manquer

L'examen du schéma permet de détecter les erreurs de journalisation avant que les relevés de production ne s'accumulent. Traitez le schéma comme une frontière de sécurité, avec des champs autorisés explicites et le rejet explicite des champs libres de prompts et de charges utiles.

L'exemple suivant réunit l'identité, l'autorisation, les métadonnées de l'action, le résultat et les informations d'intégrité. Il ne contient volontairement pas de champs prompt, messages, headers, request_body, response_body ni stderr.

{
  "event_type": "external_action",
  "event_id": "evt_91bd",
  "occurred_at": "2025-03-08T14:24:10Z",
  "actor": {
    "local_account": "maya",
    "process_session": "sess_31a9",
    "pid": 4812,
    "parent_pid": 4601,
    "executable_digest": "sha256:2a84...",
    "signing_authority": "Example Development Team"
  },
  "authorization": {
    "authorization_id": "auth_7f3c",
    "mode": "session",
    "decision": "approved"
  },
  "action": {
    "channel": "https",
    "destination": "api.example.internal",
    "operation": "POST /v1/projects/{project_id}/deployments",
    "credential_ref": "deploy-production",
    "request_digest": "sha256:6d1d..."
  },
  "result": {
    "category": "completed",
    "status_code": 201,
    "destination_request_id": "req_18c7",
    "duration_ms": 614
  },
  "integrity": {
    "previous_event_digest": "sha256:8f50...",
    "event_digest": "sha256:bd7e..."
  }
}

Ne placez pas de commentaires comme « masqué » à côté de champs qui pourraient avoir contenu des secrets. Supprimez le champ. Un champ request_body présent mais vide invite un développeur ultérieur à le remplir pendant le débogage. La validation du schéma doit rejeter les champs inconnus au niveau supérieur et les blocs imbriqués, sauf lorsqu'un adaptateur examiné contrôle leur format.

Les examinateurs ont également besoin d'une vue lisible de l'événement. Produisez-la à partir du relevé canonique au lieu de tenir un récit manuscrit séparé. Une entrée destinée à l'utilisateur peut se lire ainsi : « La session du processus approuvé a utilisé deploy-production pour créer un déploiement sur api.example.internal. Le service a renvoyé 201 en 614 ms. » Le journal conserve les identifiants nécessaires à l'inspection de l'événement sans exposer de contenu dans la vue par défaut.

L'intégrité prouve une modification, pas l'exhaustivité

Les relevés permettant de détecter les altérations ne sont utiles que si l'équipe comprend leurs limites. Une chaîne de hachage peut révéler qu'une personne a modifié, supprimé ou réordonné un événement après son entrée dans la chaîne, à condition que les examinateurs conservent les éléments nécessaires à la vérification. Elle ne peut pas prouver qu'un enregistreur compromis a bien enregistré une action dès le départ.

NIST SP 800-92, Guide to Computer Security Log Management, conseille aux organisations de protéger l'intégrité des journaux, de définir les événements qui méritent d'être enregistrés et d'examiner les journaux avec une responsabilité opérationnelle claire. L'intérêt réside dans la combinaison de ces éléments. L'intégrité sans frontière d'événement définie fournit des relevés fiables d'une histoire incomplète. Une longue liste d'événements sans intégrité fournit une histoire que quelqu'un peut modifier discrètement.

Utilisez la passerelle d'action comme point d'observation, car elle voit l'utilisation de l'identifiant et l'appel externe. Si un agent peut contourner cette passerelle et effectuer des appels directs avec des identifiants copiés, la piste d'audit ne couvre que le chemin coopératif. Corrigez le problème de distribution des identifiants au lieu de prétendre que le journal voit tout.

Gardez la vérification indépendante de la lecture normale des journaux. Une commande de vérification doit fonctionner sur des relevés chiffrés stockés et indiquer si la chaîne est intacte. Sallyport propose cette vérification avec sp audit verify, qui vérifie son journal d'audit chiffré et chaîné par hachage sans exiger la clé du coffre. Ce choix compte, car un enquêteur doit pouvoir tester la continuité des relevés sans obtenir accès aux identifiants.

Les résultats de vérification nécessitent une procédure opérationnelle. Si une vérification de chaîne échoue, préservez le stockage concerné, cessez de traiter le journal comme une preuve complète, repérez le premier point de séquence rompu et comparez les relevés du côté de la destination pour l'intervalle concerné. Ne régénérez pas simplement une chaîne propre avant de poursuivre. Cela transformerait une défaillance d'intégrité détectable en lacune impossible à expliquer.

L'accès et la conservation déterminent si le journal devient une nouvelle fuite

Un relevé minimal peut encore causer des dommages si trop de personnes peuvent le rechercher indéfiniment. L'historique des autorisations peut révéler l'activité des employés. Les noms de destinations peuvent exposer l'infrastructure. Les identifiants de projets peuvent révéler des activités commerciales. Limitez l'accès selon le rôle d'enquête, pas selon la curiosité générale.

Séparez les vues opérationnelles des vues forensiques. La plupart des ingénieurs ont besoin d'une liste récente des actions, des statuts, des destinations et des identités de session pour diagnostiquer une exécution défaillante. Un groupe plus restreint peut avoir besoin des empreintes d'événements, des informations de signature, des détails d'approbation et de l'accès aux relevés chiffrés bruts pendant un incident. Les personnes qui utilisent un agent n'ont pas automatiquement besoin d'un accès permanent à l'historique de tous les autres développeurs.

Définissez la conservation en répondant à deux questions : combien de temps l'équipe peut-elle réellement enquêter sur une action contestée, et combien de temps la destination conserve-t-elle son propre relevé faisant autorité ? Si la destination conserve brièvement l'historique des déploiements, gardez les métadonnées d'action assez longtemps pour établir la corrélation. Si une obligation légale ou contractuelle modifie cette durée, documentez-la ainsi que son responsable. « Tout conserver » signifie généralement qu'aucune décision n'a été prise.

La suppression a elle aussi besoin d'éléments de preuve. Enregistrez la version de la politique de conservation et le fait qu'une suppression ou une agrégation planifiée a eu lieu. Ne conservez pas le contenu supprimé simplement pour prouver sa suppression. Pour l'analyse des tendances à long terme, regroupez les totaux par catégorie d'opération et par résultat après l'expiration des relevés détaillés.

Construisez le relevé à la passerelle, puis testez les mauvais scénarios

L'implémentation la plus sûre capture les données d'examen là où l'action utilisant l'identifiant a lieu. Un agent doit demander une action par une interface limitée, la passerelle doit authentifier le processus local et appliquer l'autorisation, puis la passerelle doit exécuter l'opération HTTP ou SSH. L'agent reçoit le résultat, tandis que le relevé d'examen capture les faits de l'action.

Sallyport suit cette architecture pour les agents compatibles avec MCP : le shim local sp mcp achemine les actions HTTP et SSH via l'application, dont le coffre chiffré conserve les identifiants API et SSH hors du contexte de l'agent. Son journal de sessions et son journal d'activité sont produits à partir du même journal d'audit chiffré en écriture aveugle. L'autorisation de session et les appels individuels restent ainsi liés sans que l'agent détienne de secret.

Testez la conception avec des échecs que les démonstrations ordinaires du scénario idéal évitent :

1. Envoyez une requête qui échoue après que la destination a renvoyé un faux en-tête d'autorisation. Vérifiez que le relevé contient une catégorie d'erreur et un statut, pas l'en-tête ni le corps de réponse.
2. Démarrez deux processus portant le même nom affiché, mais des identités d'exécutable différentes. Vérifiez que la vue d'examen sépare leurs sessions.
3. Approuvez une session, terminez-la, puis démarrez un nouveau processus. Vérifiez que l'ancienne approbation ne s'applique pas à la nouvelle exécution.
4. Forcez une expiration, puis effectuez une nouvelle tentative. Vérifiez que les relevés relient les tentatives à un seul appel et indiquent que le résultat est incertain.
5. Modifiez un événement de test stocké et lancez la vérification d'intégrité. Vérifiez que le système signale l'échec et que l'équipe dispose d'une procédure écrite.

Faites cela avant d'ajouter des tableaux de bord, des résumés ou des explications générées par un modèle. Un flux d'activité soigné ne peut pas compenser un relevé qui divulgue un jeton ou qui ne distingue pas un exécutable d'un autre.

Les relevés d'examen gagnent la confiance lorsqu'ils sont assez limités pour être protégés, assez précis pour permettre une enquête et ancrés à l'endroit où une action externe se produit réellement. Si un relevé ne peut pas vous dire qui a agi, quelle autorité couvrait l'action, quelle frontière elle a franchie et quel résultat est revenu, ses champs doivent être améliorés. S'il contient toute la conversation, il contient trop de choses.