Blog · Guide · 28 octobre 2026

Lire un journal d'exécution AEGIS : ce qu'enregistre un appel d'outil scellé

Aussi en: English, Español, Português, 日本語, Deutsch, 한국어, 简体中文, Italiano, हिन्दी · Tous les guides en français

Transparence : 100monkeys.ai développe AEGIS, lisez donc ce guide comme le récit de son fabricant. Il a été rédigé par l'un de nos agents d'IA à partir de la documentation publique d'AEGIS, principalement Deploying & Running Agents, CLI Reference, SEAL Protocol et la page Observability de la passerelle, puis relu par l'entreprise ; cette édition française est une traduction du guide original en anglais. Les lignes de journal, champs et codes ci-dessous sont les exemples de la documentation, pas des sorties que nous avons capturées pour ce guide.

AEGIS by 100monkeys.ai, in beta, exécute chaque agent dans son propre environnement isolé et fait passer ses appels d'outils par un protocole signé nommé SEAL. Ce guide lit une exécution de l'extérieur vers l'intérieur : l'enregistrement de l'exécution, le journal des itérations, puis ce que la couche SEAL enregistre sur un seul appel d'outil, autorisé ou refusé.

Pourquoi l'exécution est l'unité

La page Executions le dit clairement : "Each execution is the unit of observability and replay in AEGIS. Logs, tool calls, blackboard snapshots, and refinement trajectories are all anchored to an execution ID." (Chaque exécution est l'unité d'observabilité et de rejeu dans AEGIS. Journaux, appels d'outils, instantanés de la blackboard et trajectoires d'affinage sont tous ancrés à un ID d'exécution.) Chaque étape ci-dessous part de cet id. Une exécution tourne dans la boucle "Execute, Evaluate, Refine" (exécuter, évaluer, affiner) et se termine "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs." (quand l'agent produit une sortie qui satisfait ses critères d'évaluation, quand le budget d'itérations est épuisé, ou quand survient une erreur irrécupérable.)

Étape 1. Trouver l'id d'exécution

aegis task execute l'affiche au démarrage (Execution started: <id>). Pour les exécutions que vous n'avez pas lancées vous-même, listez-les :

aegis task list
aegis task list --agent-id <AGENT_ID>
aegis task list --limit 20

Une exécution planifiée porte son id dans la liste des exécutions de la planification ; une exécution de workflow apparaît dans aegis workflow executions list.

Étape 2. Lire l'enregistrement de l'exécution

aegis task status <EXECUTION_ID> --output json

Selon la documentation, cette commande "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores." (renvoie l'enregistrement de l'exécution, avec le statut, les heures de début et de fin, le nombre total d'itérations, et le statut et les scores de validation de chaque itération.) Lisez d'abord le nombre d'itérations. Une seule itération réussie, c'est une exécution propre ; plusieurs itérations signifient que la sortie a échoué à la validation et a été affinée, et le journal dira pourquoi.

Étape 3. Lire le journal des itérations

aegis task logs <EXECUTION_ID>

L'exemple de la documentation de ce qu'affiche une exécution, ligne par ligne :

[2026-02-23T10:00:01Z] Execution a1b2c3d4-1111-... Started
[2026-02-23T10:00:01Z] Iteration 1 Started
[2026-02-23T10:00:03Z] Tool: fs.write /workspace/solution.py (234 bytes)
[2026-02-23T10:00:04Z] Tool: cmd.run python /workspace/solution.py
[2026-02-23T10:00:05Z] Tool: fs.write /workspace/result.json (89 bytes)
[2026-02-23T10:00:06Z] Iteration 1 Completed
[2026-02-23T10:00:06Z] Validation: exit_code=PASS json_schema=PASS (score=1.0)
[2026-02-23T10:00:06Z] Execution a1b2c3d4-1111-... Completed (1 iteration, 5.2s)

Lisez-le comme trois sortes de lignes : le cycle de vie (démarrée, terminée), une ligne Tool: par appel de l'agent, et une ligne Validation: avec le verdict de chaque validateur et le score. Ajoutez --errors-only pour ne voir que les échecs, --verbose pour plus de détails et --follow pour suivre une exécution en cours. Pour un workflow, aegis workflow logs <EXECUTION_ID> --transitions n'affiche que les changements d'état.

Étape 4. Savoir ce qu'il y a derrière chaque ligne Tool

Chaque ligne Tool: est un appel passé par SEAL. "Every tool call is wrapped in a SealEnvelope" (Chaque appel d'outil est enveloppé dans une SealEnvelope) : le protocole (seal/v1), un security_token (un JWT émis à l'attestation), une signature Ed25519, le payload (pour les appels de type MCP, un tools/call JSON-RPC), un container_id et un timestamp entier.

Ce sont les claims du jeton qui relient l'appel à votre exécution : sub (l'appelant), scp (le nom du contexte de sécurité), wid (la charge de travail) et exec_id, qui "ties every call in a session to one audit chain" (rattache chaque appel d'une session à une seule chaîne d'audit). L'id d'exécution de l'étape 1 est donc la clé qui relie la ligne de journal à son enveloppe.

Étape 5. Lire pourquoi un appel a été autorisé

La passerelle effectue neuf vérifications avant de transmettre un appel : le champ de protocole, la signature et l'expiration du jeton, la clé enregistrée de l'appelant, la signature de l'enveloppe sur un message canonique, un horodatage à moins de 30 secondes, et enfin le contexte de sécurité nommé dans scp. Cette dernière vérification refuse tout ce qui figure sur la liste d'exclusion, n'autorise un appel que si une capacité correspond à son outil, chemin, domaine ou sous-commande et à sa limite de débit, et refuse sinon "(default deny)" (refus par défaut). Le contexte ne peut pas changer en cours de session : "callers cannot widen their context, switch contexts, or impersonate a different one." (les appelants ne peuvent ni élargir leur contexte, ni en changer, ni en usurper un autre.)

Étape 6. Lire un refus

Un appel refusé n'est pas un trou silencieux dans le journal. Sur la SEAL Gateway, il répond par un code numérique. Ceux que vous verrez le plus :

• de 2000 à 2006 : politique. Outil non accordé, outil sur la liste d'exclusion, chemin hors de path_allowlist, commande hors de command_allowlist, domaine hors de domain_allowlist, limite de débit atteinte, aucune capacité correspondante.
• 1003 TOKEN_EXPIRED : le jeton a expiré, l'horodatage sortait de la fenêtre de 30 secondes, ou le jti avait déjà été vu, ce qui est la trace d'une enveloppe rejouée.
• 1001 et 1002 : une signature malformée ou qui ne se vérifie pas.

La documentation recommande de "switch on error.code, not on the status" (se fonder sur error.code, pas sur le statut), et signale un piège : le POST /v1/seal/invoke de l'orchestrateur répond à un refus par un code texte comme TOOL_NOT_ALLOWED au lieu d'un nombre.

Étape 7. Lire l'enregistrement d'audit

La page SEAL Protocol liste les événements produits par chaque appel, dont ToolCallAuthorized et PolicyViolationBlocked, et ce que chacun capture : la signature, l'horodatage et le jti de l'enveloppe ; les sub, scp, wid et exec_id du jeton ; le nom de l'outil et le "payload digest (not the full payload, payloads are not logged by default)" (condensé du payload, pas le payload complet : par défaut, les payloads ne sont pas journalisés) ; et "the policy decision (ALLOW or DENY plus the deciding rule, if any)" (la décision de politique, ALLOW ou DENY, plus la règle décisive, s'il y en a une). C'est la signature qui assure la non-répudiation : "only the holder of the ephemeral private key could have produced a valid signature." (seul le détenteur de la clé privée éphémère a pu produire une signature valide.)

Sur une SEAL Gateway autonome, ces lignes vivent dans la table gateway_events. Il n'existe pas encore d'endpoint REST pour elles ; la documentation donne plutôt du SQL :

SELECT event_type, created_at, payload
  FROM gateway_events
  WHERE payload->>'execution_id' = 'exec-1234'   -- Postgres JSONB syntax
  ORDER BY created_at;

La table est en ajout seul : envoyez-la à votre SIEM en interrogeant les ids supérieurs au dernier envoyé.

Ce que la documentation laisse ouvert

• Les deux listes d'événements diffèrent. La page SEAL Protocol nomme PolicyViolationBlocked ; la table gateway_events de la passerelle, telle qu'Observability la liste, non. Quelle table contient un refus n'est pas dit.
• Les ports. La page SEAL place l'orchestrateur sur 8080 ; le port d'API par défaut de la CLI est 8088.
• La passerelle n'a pas encore d'endpoint de métriques ni de traces OTLP ; la page Observability le dit elle-même.

Suite

Pour ce dont la personne qui relit a besoin à côté de ces journaux, lisez la Liste de traçabilité pour agents d'IA en production.

Installer AEGIS depuis 100monkeys.ai