Schéma d'événement d'audit des agents IA : actions, outils, approbations et résultats
Un événement d'audit d'agent IA est un enregistrement durable qui relie une action demandée à l'identité, à l'autorité déléguée, à la politique, à la revue humaine, aux effets d'outils, au résultat métier et à la preuve d'intégrité. Ce contrat public est indépendant de tout éditeur ; les producteurs KLA actuels n'apparaissent que dans le tableau de rattachement.
JSON Schema draft 2020-12 · Publié le 28 juillet 2026 · Noms de champs normatifs en anglais
Repères essentiels
- Définition
- Un événement d'audit d'agent IA est un enregistrement durable qui relie une action demandée à l'identité, à l'autorité déléguée, à la politique, à la revue humaine, aux effets d'outils, au résultat métier et à la preuve d'intégrité.
- Champ d'application
- À utiliser pour les actions d'agent à fort enjeu, y compris un refus de politique ou une tentative en échec. Appliquez à la mise en oeuvre les exigences locales en matière juridique, de vie privée, de conservation et de secteur.
- Preuve minimale
- Identifiants stables, identité de l'acteur et du propriétaire, composants versionnés, autorité demandée, résultat de politique, approbation le cas échéant, effets, résultat, ordonnancement, mesures de protection des données et état de vérification.
- Cas pratique
- L'enregistrement complet suit une décision de crédit fictive, de la demande jusqu'à require_approval, la revue par une personne habilitée, un effet d'outil, un résultat métier et une signature Ed25519 valide.
01
Schéma et enregistrements assainis
Les quatre URL versionnées et immuables servent à l'implémentation, à la validation, aux feuilles de travail d'audit et aux tests de non-régression.
/ai-agent-audit-event/v1/schema.jsonTélécharger Exécution complèteAction approuvée valide, avec effet aval./ai-agent-audit-event/v1/examples/complete-execution.jsonTélécharger Action refuséeDécision `block` valide, sans aucun appel d'outil./ai-agent-audit-event/v1/examples/denied-action.jsonTélécharger Altération détectéeEnregistrement structurellement valide dont la charge signée a été modifiée./ai-agent-audit-event/v1/examples/tamper-failure.jsonTélécharger 02
Une action détaillée
L'enregistrement complet décrit une décision de crédit fictive. La politique exige un souscripteur habilité avant que l'outil en écriture ne s'exécute.
- 01DemandeUn utilisateur délègue à un agent une décision de crédit au périmètre restreint.
- 02PolitiqueLa version de politique 4.2.1 renvoie require_approval pour le montant consigné.
- 03Décision humaineUn souscripteur senior examine la preuve présentée et approuve la demande liée.
- 04Effet d'outilUn appel d'outil idempotent met à jour la cible fictive et consigne les digests avant et après.
- 05PreuveL'empreinte de la charge signée canonique et la signature Ed25519 se vérifient avec la clé d'exemple publiée.
{
"schema_version": "1.0.0",
"event_id": "evt_01JZ8V4R9K2Q7M1W3D5N6P8X0A",
"actors": {
"agent": "agent_credit_review",
"accountable_owner": "role_head_credit_operations"
},
"requested_action": "credit.application.set_disposition",
"policy_decision": "require_approval",
"approval_decision": "approved",
"tool_status": "succeeded",
"business_outcome": "achieved",
"verification": "valid"
}03
Frontières entre enregistrements
Chaque artefact répond à une question d'audit différente. Une procédure d'assurance en production a généralement besoin des quatre.
| Artefact | Question | Contenu habituel | Frontière d'intégrité |
|---|---|---|---|
| Journal d'exploitation | Qu'a rapporté un composant ? | Messages, métriques, erreurs, latence et contexte d'exécution local. | Utile à l'exploitation. L'exhaustivité, l'identité, l'autorité et la conservation peuvent rester non spécifiées. |
| Événement d'audit | Qui ou quoi a demandé une action gouvernée, sous quelle autorité, et que s'est-il passé ? | Identité, versions, finalité, ressource, politique, approbation, effet d'outil, résultat, protection des données et références d'intégrité. | L'enregistrement a un schéma stable et un résultat de vérification explicite. L'exhaustivité de la population source demande encore une réconciliation. |
| Traçabilité d'exécution | Comment une exécution a-t-elle progressé, dans quel ordre ? | Spans ou événements ordonnés, relations parent-enfant, reprises, appels d'outils et statut. | La traçabilité fournit la séquence et la causalité. Elle peut renvoyer à plusieurs événements d'audit et artefacts sources. |
| Dossier de preuves | Quels artefacts conservés étayent une affirmation d'audit ? | Manifeste, événements d'audit, traçabilité, enregistrements de politique et d'approbation, accusés sources, empreintes, signatures, omissions et caviardages. | La vérification du dossier teste l'appartenance des artefacts, les empreintes, les signatures, les preuves de registre et les omissions déclarées. |
04
Dictionnaire des champs
Les champs obligatoires s'appliquent à tout enregistrement. Les champs conditionnels s'appliquent lorsque le composant ou le chemin de cycle de vie nommé existe. Les champs facultatifs conservent un détail portable.
Enveloppe et ordonnancement
| Champ | Statut | Rôle |
|---|---|---|
| schema_version | Obligatoire | Sélectionne le contrat de compatibilité utilisé pour lire l'enregistrement. |
| audit_event.event_id | Obligatoire | Identifie de manière unique cet événement d'audit. |
| audit_event.event_type | Obligatoire | Classe une action aboutie ou refusée. L'état de vérification reste dans integrity. |
| audit_event.occurred_at / recorded_at / sequence | Obligatoire | Sépare l'heure de l'événement de l'heure de collecte et préserve un ordre déterministe. |
| audit_event.correlation.correlation_id / execution_id | Obligatoire | Relie les enregistrements de politique, d'approbation, d'outil, de résultat et de preuve sans jointure par horodatage. |
| audit_event.correlation.trace_id / span_id / parent_event_id | Facultatif | Relie l'enregistrement à OpenTelemetry ou à une trace équivalente et à un événement parent. Les identifiants W3C entièrement à zéro sont invalides. |
Périmètre et identité
| Champ | Statut | Rôle |
|---|---|---|
| audit_event.scope.organization_ref | Obligatoire | Porte une référence de périmètre pseudonyme ou maîtrisée par l'organisation. |
| audit_event.scope.environment / retention_class | Obligatoire | Nomme la frontière d'exploitation et le traitement de conservation approuvé. |
| audit_event.scope.region / legal_hold | Facultatif | Consigne la localisation régionale et tout gel qui suspend la suppression ordinaire. |
| audit_event.actors.requester / agent / accountable_owner | Obligatoire | Lie la demande, l'identité de l'agent et le rôle humain ou organisationnel responsable. |
| audit_event.actors.delegated_user / service_identity | Conditionnel | Consigne l'autorité pour le compte d'autrui et l'identité de charge de travail lorsqu'elles existent. |
Versions et autorité demandée
| Champ | Statut | Rôle |
|---|---|---|
| audit_event.components.agent | Obligatoire | Fixe la Release de l'agent et le digest de configuration facultatif. |
| audit_event.components.model / prompt_template / orchestrator | Conditionnel | Fixe chaque composant ayant influencé l'action. |
| audit_event.requested_action.action / purpose | Obligatoire | Énonce la capacité proposée et la finalité métier approuvée. |
| audit_event.requested_action.resource / data_boundary_ref / environment | Obligatoire | Définit la cible, la frontière de données gouvernée et l'environnement d'exécution. |
| audit_event.requested_action.amount | Conditionnel | Utilise une chaîne décimale et une devise ISO 4217 lorsque la valeur financière conditionne la politique. |
Politique et décision humaine
| Champ | Statut | Rôle |
|---|---|---|
| audit_event.policy.decision_id / policy_id / policy_version | Obligatoire | Identifie la décision exacte et la version de politique applicable. |
| audit_event.policy.policy_digest / inputs_digest | Obligatoire | Lie l'évaluation aux représentations protégées de la politique et des entrées. |
| audit_event.policy.decision | Obligatoire | Porte allow, warn, require_approval ou block. |
| audit_event.policy.matched_rule_ids / reason_codes / evaluated_at | Obligatoire | Rend le résultat explicable et ordonnable avant tout effet. |
| audit_event.approval | Conditionnel | Obligatoire lorsque la politique renvoie require_approval. Les effets d'exécution exigent une demande tranchée et approuvée par un relecteur humain. |
| audit_event.approval.reassigned_from / override / appeal | Facultatif | Conserve les faits de cycle de vie exceptionnels lorsque le système source les prend en charge. |
Exécution et résultat
| Champ | Statut | Rôle |
|---|---|---|
| audit_event.tool_calls[] | Obligatoire | Liste chaque appel d'outil tenté. Les actions bloquées, non approuvées ou non démarrées exigent un tableau vide. |
| audit_event.tool_calls[].arguments_digest / result_digest | Obligatoire | Lie les arguments et résultats protégés sans placer de secret dans l'événement. |
| audit_event.tool_calls[].downstream_effects[] | Conditionnel | Consigne les accusés des systèmes cibles et les digests d'état avant et après lorsqu'un effet se produit. |
| audit_event.execution.status / business_outcome | Obligatoire | Sépare l'aboutissement technique du résultat métier et fixe la sémantique d'événement abouti ou refusé. |
| audit_event.execution.rollback / incident_ref | Conditionnel | Relie le rétablissement et l'investigation lorsque l'un des chemins est emprunté. |
| audit_event.lineage | Obligatoire | Relie l'action à un Lineage Record et à ses identifiants d'événements ordonnés. |
Preuve, données personnelles et intégrité
| Champ | Statut | Rôle |
|---|---|---|
| audit_event.evidence.manifest_ref / artifacts[] | Obligatoire | Identifie le manifeste du dossier et les digests des artefacts qui le soutiennent. |
| audit_event.privacy.classification / redaction_status | Obligatoire | Énonce la protection et la transformation appliquées à l'enregistrement. |
| audit_event.privacy.redactions[] / access_policy_ref | Obligatoire | Localise les champs protégés et la politique qui régit l'accès. Les entrées correspondent au statut de caviardage déclaré. |
| integrity.canonicalization / hash_algorithm / record_hash | Obligatoire | Définit et consigne le digest des métadonnées d'enveloppe signées canoniques et de audit_event. |
| integrity.previous_event_hash | Facultatif | Relie les enregistrements lorsque l'implémentation utilise une chaîne d'empreintes. La signature protège ce lien. |
| integrity.signature | Obligatoire | Porte l'algorithme, l'identifiant de clé, la clé publique d'exemple et la signature détachée du digest. |
| integrity.verification | Obligatoire | Consigne valid, failed ou not_performed, avec la version du vérificateur et les codes de défaillance. |
05
Vérification de l'intégrité
La validité du schéma et l'intégrité cryptographique sont deux contrôles distincts. L'exhaustivité de la population reste une procédure d'audit à part.
- 01Valider l'enveloppe avec le JSON Schema versionné.
- 02Construire la charge signée à partir de schema_version, audit_event et des métadonnées integrity autres que record_hash et signature.value.
- 03Canonicaliser la charge signée avec le JSON Canonicalization Scheme de la RFC 8785.
- 04Calculer SHA-256 et comparer avec integrity.record_hash en utilisant le préfixe sha256:.
- 05Résoudre la clé de confiance par key_id. Vérifier sa validité et son état de révocation à occurred_at.
- 06Vérifier la signature Ed25519 sur le digest de 32 octets.
- 07Vérifier chaque previous_event_hash face à son voisin ordonné et face à une ancre de premier maillon conservée indépendamment avant d'accepter l'ordre de la séquence.
- 08Réconcilier les identifiants d'événements et les digests d'artefacts avec la traçabilité, les effets dans les systèmes sources et le manifeste de preuve.
- 09Consigner chaque code de défaillance. Un contrôle en échec ou indisponible ne peut pas produire valid.
Exemples approuvé et refusé
Les deux se valident, reproduisent leurs empreintes publiées et se vérifient avec la clé publique Ed25519 d'exemple.
Exemple d'altération
L'enveloppe reste valide au regard du schéma. Son résultat métier a changé après la signature : l'empreinte recalculée diffère et la vérification consignerecord_hash_mismatch.
La clé d'exemple embarquée rend les fichiers auto-vérifiables. En production, la confiance dans les clés doit passer par un registre distinct. Une clé fournie par le seul enregistrement ne peut pas établir l'identité de l'émetteur.
06
Corrélation OpenTelemetry
Le contexte de trace relie la télémétrie et la preuve d'audit. Il ne porte pas l'affirmation d'audit complète.
Propager
Propager le traceparent W3C à travers l'agent, la politique, l'approbation, la passerelle d'outils et les appels aval. Recopier trace_id et le span_id de l'action dans correlation.
Lier
Ajouter des attributs stables execution_id, event_id, decision_id, request_id et call_id. Garder les entrées protégées, les jetons et le contenu brut du modèle hors des attributs de span ordinaires.
Conserver
La conservation de la télémétrie peut être plus courte que celle de l'audit. Préserver l'enregistrement d'audit et une référence de traçabilité résolvable après expiration des traces chaudes.
07
Compatibilité et versionnement
Versionnez le contrat indépendamment des versions des producteurs et des outils.
Correctif
Les clarifications, descriptions et exemples peuvent changer sans modifier le comportement de validation. Les URL v1 stables conservent un contenu de fichier immuable : un artefact corrigé reçoit une nouvelle URL de version.
Mineure
Un nouveau champ facultatif ou une extension d'énumération exige un nouveau schema_version et une nouvelle URL versionnée. Les consommateurs doivent rejeter les versions inconnues tant qu'ils ne déclarent pas les prendre en charge.
Majeure
Un champ supprimé ou renommé, un sens modifié, un statut obligatoire renforcé ou une canonicalisation modifiée exigent un nouveau chemin majeur. Les producteurs peuvent écrire en double pendant la migration.
Les consommateurs doivent conserver les enregistrements inconnus à des fins d'investigation et cesser tout traitement sémantique lorsque la version de schéma n'est pas prise en charge. Ils ne doivent jamais convertir en silence un résultat de politique ou un statut de vérification non pris en charge.
08
Rattachement aux producteurs KLA actuels
L'enveloppe portable est plus large que n'importe quel producteur KLA. Ces sources définissent la vérité d'implémentation actuelle.
| Domaine du contrat | Source actuelle | Rattachement | Statut |
|---|---|---|---|
| Identité de l'événement d'audit et ajout durable | services/api/src/services/audit-logger.ts | AuditEvent fournit événement, tenant, utilisateur, ressource, action, résultat, corrélation et contexte de sécurité. Le journaliseur recopie les événements bornés au tenant dans ImmuDB. | Source actuelle |
| Producteurs d'événements outil, politique et approbation | services/execution-worker/src/services/audit-events.ts | Les producteurs du worker hachent les entrées et résultats d'outils, capturent l'identité d'exécution et de politique, ajoutent les événements de demande et de résolution d'approbation, et attachent l'identifiant de trace OpenTelemetry actif. | Source actuelle |
| Quatre résultats de politique | services/shared/src/policy/contracts.ts | GateDecisionValueSchema définit allow, warn, require_approval et block. D'anciens utilitaires d'audit du worker peuvent encore écrire le résultat bloqué sous la forme deny. | Source actuelle, avec normalisation |
| Décision d'approbation durable | services/execution-api/src/services/approval-audit-outbox-worker.ts | L'API d'approbation utilise une outbox idempotente à bail pour ajouter un enregistrement de décision rattaché au tenant. Le producteur côté demande reste distinct. | Source actuelle |
| Traçabilité d'exécution et corrélation de trace | services/execution-worker/src/services/lineage-trace-publisher.ts | Les exécutions gouvernées publient des spans racine et des spans d'étape bornés à l'exécution. workflow-observability.ts émet aussi des attributs de politique et d'approbation via OpenTelemetry. | Source actuelle |
| Sealed Evidence Bundle et vérification hors ligne | packages/evidence-contract/src/index.ts | Le manifeste du dossier lie tenant, export, artefacts, racine de Merkle, empreinte de manifeste, métadonnées de signature, demande de fabrication, omissions et caviardages. packages/evidence-verifier réalise les contrôles indépendants. | Source actuelle |
Abstractions assumées et champs non couverts
- •KLA n'émet pas aujourd'hui cette enveloppe publique comme un enregistrement natif unique. Cette référence normalise plusieurs producteurs faisant foi en une seule unité d'audit.
- •Le propriétaire responsable, les digests complets de configuration de modèle et de prompt, les versions d'outils, les résultats métier, le rétablissement et les références d'incident ne sont pas renseignés de manière uniforme sur tous les chemins d'exécution KLA.
- •La réassignation, la dérogation et le recours d'une Decision Request sont des champs de cycle de vie portables. Les producteurs KLA actuels n'exposent pas les trois comme un contrat normalisé au niveau de l'action.
- •Le contrat consigne le rôle requis et l'identité du relecteur humain. Les consommateurs en production doivent vérifier que le relecteur détenait bien ce rôle au moment de la décision.
- •KLA signe et vérifie le manifeste du Sealed Evidence Bundle et valide les preuves de registre et d'artefacts. Les enregistrements KLA actuels ne portent pas tous la signature Ed25519 par enregistrement utilisée dans ces exemples portables.
- •Les exemples publient une clé publique d'exemple afin que les fichiers soient auto-vérifiables. En production, les clés de confiance doivent être résolues via un registre gouverné indépendamment, et la révocation testée à l'heure de l'événement.
Appliquer le contrat
Inscrire l'enregistrement dans une méthode d'audit complète.
Servez-vous du contrôle d'accès des agents IA pour définir le périmètre et les tests de contrôle, et du guide des permissions pour réconcilier les populations, échantillonner les actions, évaluer la preuve et signaler les écarts.