Une table de preuves SOC 2 peut-elle prouver les actions des agents ?

L'activité des agents crée un problème d'audit que les journaux d'application ordinaires ne suffisent pas à résoudre. Le journal d'un compte de service peut vous dire qu'un identifiant a appelé un endpoint. Il ne permet généralement pas de savoir si un processus d'agent précis était autorisé à ce moment-là, si un humain avait approuvé l'action, si cette autorisation a ensuite été retirée ou si l'enregistrement remis à l'auditeur est bien celui qui avait été produit à l'origine.

Un dossier de preuves SOC 2 exploitable doit reconstituer une décision, et pas seulement afficher une chronologie. Pour chaque action importante, l'auditeur doit pouvoir partir de l'acteur et de son autorisation, retrouver l'appel et son résultat, puis vérifier l'intégrité de l'enregistrement conservé. Si l'un de ces liens dépend de la mémoire d'un administrateur ou d'un tableur modifié manuellement, le contrôle est moins solide qu'il n'y paraît.

Sallyport est conçu autour de cette chaîne : un agent reçoit les résultats des actions, tandis que les identifiants restent dans le coffre local chiffré et que l'application enregistre l'exécution de l'agent ainsi que chaque appel individuel. Cette conception n'est utile que si vous transformez ces enregistrements en preuves vérifiables, au lieu de traiter le journal comme un simple accessoire de conformité.

Un contrôle doit permettre de reconstituer la décision

Les Trust Services Criteria de l'AICPA, publiés en 2017, sont des critères, pas un menu de captures d'écran. Les critères communs de sécurité demandent à la direction de mettre en place et d'exploiter des contrôles qui limitent les accès logiques, surveillent le fonctionnement du système, répondent aux problèmes identifiés et gèrent les changements. L'auditeur teste le contrôle que vous décrivez, sa population et son efficacité pendant la période examinée.

Cette distinction compte pour les actions des agents. « L'agent devait obtenir une approbation » décrit un comportement du produit. « Chaque processus d'agent nouvellement démarré devait recevoir une autorisation attribuable avant de pouvoir utiliser un canal d'action protégé, et l'entreprise conservait des enregistrements reliant cette autorisation aux appels qui en résultaient » décrit un énoncé de contrôle vérifiable.

Décrivez le risque avant de rédiger la demande de preuves. Un énoncé pratique peut être formulé ainsi :

Un processus d'agent non approuvé ou dont l'approbation a été retirée pourrait appeler une API externe ou exécuter une commande SSH avec des identifiants de l'organisation, entraînant un accès non autorisé ou une modification opérationnelle non autorisée.

Le contrôle doit répondre au risque en termes simples. Les preuves doivent répondre à cinq questions plus précises :

1. Quel processus a tenté l'action ?
2. De quelle autorité disposait-il à ce moment-là ?
3. Qui lui a accordé cette autorité, le cas échéant ?
4. Quelle action externe exacte a suivi ?
5. Quelqu'un peut-il détecter une tentative de réécriture de l'historique ?

Les équipes mélangent souvent ces questions. Elles présentent une liste de destinations autorisées comme un contrôle d'approbation, une réponse API réussie comme une preuve d'autorisation, ou un export en lecture seule comme un journal immuable. Chaque affirmation décrit une chose différente.

Une restriction de destination limite les endroits où un processus peut agir. Les enregistrements d'autorisation indiquent qui a permis au processus d'agir. Les enregistrements d'appel établissent ce qu'il a tenté et ce qui s'est produit. La vérification d'intégrité indique si la séquence conservée a été modifiée. Gardez ces affirmations séparées dans la description du système et dans la table de preuves. Les auditeurs n'ont pas besoin de termes à la mode. Ils ont besoin d'un responsable de contrôle capable de formuler une affirmation délimitée et de produire l'enregistrement correspondant.

La table de preuves SOC 2 que les auditeurs peuvent tester

Utilisez une seule table de preuves comme accord de travail entre l'ingénierie, la sécurité et l'auditeur. N'en faites pas une liste de fonctionnalités. Chaque ligne doit préciser le risque, l'activité de contrôle, la population source, le mode de test et le signal d'échec.

Les références aux critères sont des points de départ, pas une promesse de couverture. La description de votre service, votre évaluation des risques, les limites du système et le jugement de l'auditeur déterminent la correspondance finale. En particulier, ne rattachez pas de force chaque enregistrement d'agent à CC8.1. Les exemples et recommandations de l'AICPA traitent la gestion des changements comme le contrôle des modifications apportées aux programmes d'application et aux technologies associées. Un appel qui modifie un compte client, envoie une réponse au support ou redémarre un processus distant est une action opérationnelle. Il ne devient une preuve de gestion des changements que lorsqu'il s'inscrit dans une modification approuvée et testée du système lui-même.

La table évite aussi un échec fréquent pendant la semaine d'audit : réunir un artefact parfait pour une seule journée. Un examen de type 2 cherche à déterminer si les contrôles décrits ont fonctionné efficacement pendant toute une période. La colonne de population n'est pas une formalité administrative. Elle indique l'univers complet que vous devez pouvoir produire avant tout échantillonnage.

L'approbation d'une session prouve l'autorité du processus, pas la gouvernance des identités

L'approbation par session prouve qu'une exécution précise d'un agent a reçu l'autorisation d'utiliser la passerelle d'action. Elle ne prouve pas que votre entreprise a correctement géré les accès des employés, provisionné un compte auprès du fournisseur d'identité ou révisé un rôle d'administrateur cloud. Ces éléments nécessitent leurs propres contrôles et enregistrements.

L'affirmation utile est plus restreinte. Le premier appel protégé d'un nouveau processus reçoit une décision d'approbation avant que la session puisse agir. L'enregistrement doit conserver un identifiant de session, l'identité du processus, l'autorité de signature du code lorsqu'elle est disponible, l'heure de la décision, l'identité de l'approbateur et l'état de terminaison. Dans Sallyport, la carte d'approbation met en avant l'autorité de signature du code du processus. La décision humaine porte ainsi sur l'exécutable qui a réellement demandé l'accès, plutôt que sur une étiquette vague fournie par l'agent.

Cette distinction est importante. Un agent peut se donner le nom qu'il veut dans une invite, un titre de terminal ou un argument de processus. Un contrôle qui approuve un nom déclaré par l'agent invite à un contournement simple. Un contrôle qui affiche l'autorité de signature du code fournit au réviseur un attribut stable à évaluer. Cela ne supprime pas la nécessité de faire confiance au logiciel signé, mais la limite de confiance est formulée honnêtement.

Pour tester l'approbation d'une session, demandez à l'auditeur de sélectionner un échantillon dans la population des sessions, puis de retracer chaque enregistrement dans les deux directions :

• Partir de l'approbation de session et retrouver le premier appel protégé qui l'a suivie.
• Partir d'une entrée d'activité et retrouver la session qui l'a autorisée.
• Confirmer que l'heure de l'appel se situe après l'approbation et avant la sortie ou la révocation de la session.
• Confirmer que les sessions refusées n'ont effectué aucun appel protégé réussi.
• Confirmer que l'enregistrement de session identifie le processus avec suffisamment de précision pour le contrôle décrit.

Ne vous appuyez pas sur une capture d'écran de la boîte de dialogue d'approbation. Les captures d'écran peuvent documenter la conception du contrôle, mais elles ne constituent pas une preuve de population. Un enregistrement doit rester disponible après la fermeture de la boîte de dialogue, être interrogeable par identifiant et se relier à l'enregistrement d'activité sans qu'une personne décide quelle ligne semble correcte.

Évitez également d'affirmer que l'approbation de session applique le moindre privilège si ce n'est pas le cas. Une décision de session peut déterminer si un processus est autorisé à agir. Le moindre privilège dépend des identifiants, de la portée des destinations, des opérations et des permissions disponibles après l'approbation. Si un agent approuvé peut utiliser un identifiant disposant de droits de production illimités, l'approbation est une barrière, pas une réduction de portée. Décrivez-la comme telle.

L'approbation par appel s'applique aux actions qu'il est risqué de regrouper

Un contrôle d'approbation par appel fournit une garantie différente de celle de l'approbation de session. Il demande une nouvelle décision humaine au moment où une utilisation précise d'un identifiant est sur le point d'avoir lieu. Utilisez-le pour les actions où le risque vient de l'invocation individuelle, et pas seulement de l'autorisation donnée à un processus d'agent de commencer son travail.

Les bons candidats sont notamment un identifiant de production capable de modifier des droits d'accès, de supprimer des données, de changer des informations de facturation, de publier un déploiement ou d'exécuter des commandes sur un hôte particulièrement sensible. Le but n'est pas de rendre chaque action d'agent fastidieuse. Il s'agit de placer la vérification à la frontière transactionnelle où un seul abus aurait de l'importance.

Les preuves doivent relier l'approbation à une seule utilisation. Un enregistrement d'activité solide contient au minimum :

• Un identifiant d'appel unique et l'identifiant de session associé.
• La référence de l'identifiant protégé, sans placer sa valeur secrète dans l'enregistrement.
• Le canal, la destination, l'opération et l'horodatage.
• L'état de la décision et l'approbateur pour un appel qui nécessitait une approbation.
• Le résultat, y compris lorsqu'il est refusé, échoue ou aboutit.

N'acceptez pas un enregistrement d'approbation qui apparaît simplement à proximité d'une action ultérieure. La proximité temporelle ne suffit pas à établir le lien. Si un réviseur approuve l'appel A et que l'agent exécute l'appel B avec le même identifiant, les preuves doivent montrer si B nécessitait et avait reçu sa propre approbation.

C'est souvent à ce moment que les équipes vont trop loin. Elles placent un humain devant des lectures courantes, puis les réviseurs approuvent une suite de cartes presque identiques sans les examiner. Le contrôle crée toujours des enregistrements, mais la vérification est devenue cérémonielle. Réservez l'approbation par appel à la catégorie étroite d'identifiants ou d'actions qui le justifient. Utilisez l'approbation de session pour le travail courant et réduisez séparément la portée des identifiants.

Un réviseur doit disposer de suffisamment de contexte pour décider. Pour une action HTTP, cela signifie généralement la méthode, la destination, l'identité de l'identifiant et une description sûre de l'effet de la requête. Pour SSH, cela signifie l'identité de l'hôte et la commande, ou la description d'une commande contrainte. Ne placez jamais le secret lui-même dans la demande d'approbation simplement pour enrichir les preuves. Un secret révélé à un réviseur dans une carte d'approbation reste un secret divulgué.

La révocation doit produire un refus que vous pouvez démontrer

Les preuves de révocation ne valent rien si elles enregistrent seulement une action dans l'interface. Le contrôle fonctionne lorsque l'autorité prend fin et qu'une tentative ultérieure échoue pour cette raison.

Effectuez ce test avant que l'audit ne le demande. Démarrez une session autorisée à utiliser une action de test hors production. Confirmez un appel réussi. Révoquez la session tandis que le processus continue de fonctionner. Faites ensuite tenter un second appel au même processus. Conservez les quatre enregistrements liés : le premier appel réussi, l'événement de révocation, le second appel refusé et l'état de la session.

Votre feuille de test peut rester aussi simple que ceci :

Test ID: AGT-REV-01
Session ID: ____________________
First call ID and result: ____________________
Revocation time and actor: ____________________
Second call ID and denial result: ____________________
Reason shown for denial: ____________________
Reviewer and date: ____________________

L'ordre des événements constitue le contrôle. Un événement de révocation à 14:03 suivi d'un appel réussi à 14:07 indique soit un échec, soit un problème d'horloge, soit que l'identifiant de session ne signifie pas ce que vous avez affirmé. Aucune de ces situations ne mérite une explication improvisée.

Distinguez la sortie normale d'une session de sa révocation explicite. La sortie met fin à un processus parce qu'il s'est arrêté. La révocation met fin à l'autorité parce qu'un réviseur a choisi de la retirer. Les deux doivent bloquer les appels ultérieurs, mais seule la révocation montre qu'un humain peut interrompre une exécution en cours en réaction à un problème. Conservez des types d'événements distincts dans la table de preuves.

Ce contrôle doit aussi faire partie de la pratique de réponse aux incidents. Si un réviseur repère une séquence d'appels suspecte, il doit savoir qui peut révoquer l'exécution, à quelle vitesse le refus prend effet et où l'événement apparaît dans le journal. Une procédure écrite qui dit de désactiver l'agent sans préciser l'action concrète ne suffit pas lorsque l'agent est déjà en train d'exécuter son travail.

La vérification hors ligne teste l'historique une fois l'application écartée

Un journal d'activité fournit la traçabilité. Une chaîne de hachage vérifiable indépendamment permet de déterminer si la séquence conservée reste cohérente. Ces deux éléments sont liés, mais ils ne sont pas interchangeables.

Sallyport construit les vues de session et d'activité à partir d'un journal d'audit chiffré unique, accessible en écriture seulement. La commande hors ligne sp audit verify vérifie la chaîne sur le texte chiffré et n'a pas besoin d'accéder au coffre. C'est une preuve utile, car le vérificateur peut tester l'historique conservé sans demander au système qui a produit le rapport de déchiffrer des identifiants ou d'accorder l'accès à son coffre.

Ne prétendez pas que cela prouve davantage. La vérification d'une chaîne de hachage peut détecter un enregistrement manquant, réordonné ou modifié dans le périmètre vérifié, selon la conception de la chaîne et les éléments conservés. Elle ne prouve pas que l'application a émis chaque événement qui aurait dû exister. Elle ne prouve pas non plus que la source temporelle était exacte, que l'approbateur a pris une bonne décision ou que l'API externe a fait ce qu'elle prétendait. Ce sont d'autres questions de contrôle.

Conservez un enregistrement de vérification pour une plage définie et conservée. Ce format de document de travail suffit à de nombreuses équipes :

{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}

N'inventez pas un résultat positif après une vérification échouée. Enregistrez l'échec, conservez les éléments, déterminez s'il provient de la gestion de l'export, de la conservation, d'un défaut logiciel ou d'une altération présumée, puis traitez-le selon la procédure de gestion des incidents. Un contrôle d'intégrité échoué ne constitue pas automatiquement une violation. C'est un événement qui doit faire l'objet d'une enquête, car votre chaîne de preuves n'est plus digne de confiance.

Effectuez la vérification selon une fréquence adaptée au volume et au risque de l'activité des agents, puis de nouveau avant de constituer le dossier de preuves. Une tâche mensuelle peut suffire dans un petit environnement. Une équipe qui laisse des agents exploiter des systèmes de production toute la journée ne devrait pas attendre la fin du trimestre pour découvrir un problème d'intégrité. La fréquence importe moins que la capacité à montrer que la vérification a été exécutée régulièrement et que les échecs ont été traités.

Les actions opérationnelles et les changements du système nécessitent des preuves distinctes

C'est la limite la plus souvent brouillée. Une action d'agent peut modifier quelque chose. Cela n'en fait pas pour autant un changement contrôlé du système au sens de CC8.1.

Considérez trois exemples. Un agent utilise une API pour modifier le statut d'abonnement d'un client. Il s'agit d'une opération métier qui nécessite une autorisation, une traçabilité et éventuellement une vérification. Un agent modifie un fichier d'infrastructure dans un dépôt source, la pull request est révisée, les tests réussissent et un pipeline de déploiement l'applique. Il s'agit d'un changement du système. Un agent exécute une commande SSH qui modifie directement un fichier de configuration en production. Il s'agit à la fois d'une action opérationnelle à risque élevé et probablement d'une violation du processus de changement si votre politique exige des déploiements révisés.

Le dossier de preuves doit rendre ces chemins visibles, au lieu de laisser un réviseur les déduire de la prose. Ajoutez une classification de l'action à l'enregistrement d'activité ou à l'analyse des preuves :

CC8.1 attend de la direction qu'elle autorise, conçoive, développe ou configure, documente, teste, approuve et mette en œuvre les changements touchant l'infrastructure, les données, les logiciels et les procédures. Un journal d'agent peut enrichir ce récit en montrant qu'un agent a ouvert une pull request ou lancé une action liée à un déploiement. Il ne peut pas remplacer la révision, les preuves de test et l'enregistrement du déploiement.

Cette distinction est parfois mal accueillie, car un seul journal d'audit semble devoir répondre à toutes les questions. Il ne le peut pas. Conservez la piste d'activité de l'agent comme preuve de l'action déléguée. Conservez vos enregistrements de changements techniques comme preuve que les modifications du système ont suivi le parcours requis. Ne les reliez que lorsque l'agent a participé à ce parcours.

Constituer le dossier de preuves à partir d'une population, pas d'un dossier de captures d'écran

Constituez un dossier reproductible pour chaque période examinée. La première tâche consiste à définir la population. Pour l'activité des agents, il s'agit généralement de toutes les sessions, de tous les appels protégés, de tous les refus d'appel, de toutes les révocations et de toutes les vérifications de journaux effectuées pendant la période. Si vous ne pouvez pas produire de décomptes ou un export complet, vous ne pouvez pas affirmer de manière crédible que l'auditeur a sélectionné son échantillon dans la population complète.

Préparez ensuite un petit manifeste de preuves qui renvoie vers des artefacts sources immuables ou conservés. Ne téléversez pas une pile de fichiers nommés « final-final-audit ». Utilisez des identifiants stables, l'emplacement source, la période, le responsable et une note expliquant ce que l'artefact prouve.

Un réviseur peut suivre cette séquence :

1. Obtenir les populations de sessions et d'activités de la période, ainsi que les enregistrements de vérification d'intégrité.
2. Rapprocher le nombre d'identifiants de session référencés par les entrées d'activité avec la population des sessions, puis examiner les enregistrements sans correspondance.
3. Sélectionner des échantillons parmi les sessions approuvées, les tentatives refusées, les appels sensibles, les révocations et les différentes plages temporelles.
4. Pour chaque appel sélectionné, remonter jusqu'à son autorisation et suivre son résultat, puis examiner l'enregistrement de vérification du journal qui couvre sa plage conservée.
5. Pour les changements apportés à la passerelle ou aux contrôles de production associés, retracer séparément la pull request, les tests, l'approbation et l'enregistrement du déploiement concernés.

Cette séquence révèle rapidement les lacunes. Si un appel n'a pas de session, le lien avec l'autorisation a échoué. Si une session n'a pas d'identité de processus, vous ne pouvez pas tester l'affirmation concernant le processus. Si une révocation n'est suivie d'aucun test de refus, vous savez seulement que quelqu'un a cliqué sur un bouton. Si les enregistrements de vérification couvrent une archive impossible à reproduire, l'affirmation d'intégrité est fragile.

Conservez les notes du réviseur avec l'échantillon. Une courte note comme « L'appel 54b correspond à la session 12a ; la session a été approuvée par l'employé A ; l'approbation par appel était requise et présente ; le résultat de l'activité est terminé ; la vérification de la plage d'audit a réussi » est plus utile que dix captures d'écran. Elle indique au prochain réviseur ce qui a été testé et laisse une trace lorsque le contrôle évolue.

Les preuves échouent lorsque les responsables ne savent pas expliquer les exceptions

Même la meilleure table de preuves échoue si personne ne prend en charge le parcours des exceptions. Des actions d'agent seront refusées. Des demandes d'approbation expireront. Des appels échoueront sur l'endpoint distant. Des sessions seront révoquées. Une vérification pourra signaler un problème. Ces résultats doivent apparaître dans la population et l'équipe doit savoir lesquels nécessitent une action.

Définissez un ensemble raisonnable de catégories d'exception : tentative non autorisée, rejet de l'approbation, échec de l'action distante, tentative après révocation, lien manquant entre les enregistrements et échec de vérification. Attribuez à chacune un responsable, une fréquence d'examen et un enregistrement attendu. Ne transformez pas chaque requête API refusée en incident de sécurité. Des refus répétés provenant d'un processus signé inattendu méritent probablement plus d'attention qu'un ingénieur qui refuse sa propre commande expérimentale.

Le test utile consiste à déterminer si quelqu'un peut expliquer une exception sélectionnée sans reconstituer une histoire à partir de messages de discussion. L'enregistrement d'activité doit indiquer la raison immédiate. L'enregistrement de session doit identifier l'exécution. Le suivi doit préciser si l'équipe a accepté le résultat, corrigé la configuration, révoqué l'accès ou lancé la procédure de gestion des incidents.

C'est également à ce stade que les changements de contrôle doivent être gérés avec rigueur. Si vous modifiez le comportement des approbations, les indicateurs d'identifiants, les champs de journalisation ou la procédure de vérification des journaux conservés, traitez cela comme un changement de l'environnement de contrôle. Mettez à jour le descriptif du contrôle, testez le nouveau comportement et enregistrez le déploiement dans votre processus technique existant. Sinon, votre table de preuves décrira le système du trimestre dernier alors que les agents de ce trimestre utilisent autre chose.

N'attendez pas que l'auditeur vous dise si les preuves sont reliées. Choisissez cette semaine une session réelle, retracez-la de l'autorisation au résultat de l'appel, révoquez-la dans un environnement sûr et vérifiez hors ligne la plage d'audit conservée. Si votre équipe ne peut pas effectuer cet exercice avec les enregistrements déjà disponibles, corrigez le parcours des preuves avant de débattre de la formulation du contrôle.