100monkeys.ai

Blog · Guide · 28 octobre 2026

Comment AEGIS scelle un appel d'outil : la passerelle SEAL, étape par étape

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

Transparence : chez 100monkeys.ai, nous développons AEGIS et la passerelle SEAL ; lisez donc ce guide comme le récit de leur fabricant. Il a été rédigé par l'un de nos agents d'IA à partir de la documentation publique (en anglais), principalement les pages SEAL Protocol, Integration with AEGIS et Security Contexts, et relu par l'entreprise ; cette version française est une traduction du guide original en anglais. Les champs, codes et flux ci-dessous sont ceux de la documentation, pas des sorties que nous aurions capturées pour ce guide.

AEGIS by 100monkeys.ai, in beta, ne fait pas confiance à l'appel d'outil d'un agent au seul motif que l'agent l'a émis. Chaque appel est emballé dans une enveloppe signée et contrôlé par la passerelle SEAL avant que quoi que ce soit hors de l'exécution ne soit touché. Ce guide suit un appel depuis le démarrage d'une exécution jusqu'à l'enregistrement d'audit qu'il laisse.

À quoi sert SEAL

SEAL signifie Signed Envelope Attestation Layer. La documentation nomme quatre lacunes des protocoles d'appel d'outil ordinaires : aucune preuve du client qui a envoyé une requête, des permissions en tout ou rien par session, des contenus modifiables en transit, et aucun enregistrement prouvant quel appelant a fait quoi. Son exemple est une injection de prompt : une page récupérée demande au modèle de supprimer /workspace. "With SEAL, the caller's SecurityContext has no fs.delete capability. The gateway blocks it before it ever reaches the tool." (Avec SEAL, le SecurityContext de l'appelant n'a pas la capacité fs.delete. La passerelle bloque l'appel avant même qu'il n'atteigne l'outil.)

La passerelle est d'abord autonome. Selon la documentation, c'est "the same aegis-seal-gateway binary" (le même binaire aegis-seal-gateway) que l'orchestrateur AEGIS "deploys alongside itself" (déploie à côté de lui). Avec AEGIS, vous n'avez rien de plus à faire pour obtenir les étapes ci-dessous ; "it is the default." (c'est le comportement par défaut.)

Étape 1. L'orchestrateur ouvre une session pour l'exécution

Quand une exécution passe à l'état Running, l'orchestrateur génère une nouvelle paire de clés Ed25519 pour cette exécution et l'enregistre auprès de la passerelle : POST /v1/seal/sessions avec un session_id (l'identifiant de l'exécution, "so audit trails line up", pour que les pistes d'audit concordent), la public_key, le security_context et un expires_at borné par le budget de temps de l'exécution. Seul un appelant détenant le scope seal.session.create peut le faire ; "agents themselves cannot self-register." (les agents eux-mêmes ne peuvent pas s'enregistrer.)

Étape 2. La clé privée va à l'agent, et nulle part ailleurs

La moitié privée est écrite dans la configuration d'exécution éphémère du conteneur de l'agent, "a tmpfs mount, never persisted" (un montage tmpfs, jamais conservé), avec l'URL de la passerelle et l'identifiant de session. Chaque exécution a donc sa propre clé, et "a leaked private key is bounded to a single execution's lifetime." (une clé privée divulguée est limitée à la durée de vie d'une seule exécution.)

Étape 3. La session est liée à un seul contexte de sécurité

Un contexte de sécurité est une politique nommée sur la passerelle : une deny_list et une liste ordonnée de capabilities, chacune avec un tool_pattern et, en option, path_allowlist, command_allowlist, subcommand_allowlist, domain_allowlist et max_response_size. Les agents lancés s'exécutent sous aegis-system-agent-runtime, pas sous le contexte de palier de la personne qui a fait la demande. L'orchestrateur fixe le contexte au provisionnement, et l'agent "cannot escalate by claiming a different scp in its envelope" (ne peut pas élever ses droits en déclarant un autre scp dans son enveloppe).

Étape 4. L'agent signe un message canonique

La signature ne porte pas sur le JSON brut. Elle porte sur trois clés, payload, security_token et timestamp, sérialisées avec les clés triées à chaque niveau, sans espace, un horodatage Unix entier et en UTF-8. Toute autre suite d'octets donne une autre signature, et "the gateway will reject the envelope." (la passerelle rejettera l'enveloppe.)

Étape 5. L'agent envoie l'enveloppe

L'enveloppe porte protocol (toujours seal/v1), le security_token (un JWT émis à l'attestation, d'une durée de vie d'une heure par défaut), la signature Ed25519, la payload (pour les appels de type MCP, un tools/call JSON-RPC), un container_id facultatif et le timestamp. Elle part vers le point d'invocation de la passerelle, POST /v1/invoke. La passerelle écoute par défaut sur 8089 ; l'API propre de l'orchestrateur AEGIS est sur 8088.

Étape 6. La passerelle effectue neuf contrôles

  1. Le champ protocol vaut seal/v1.
  2. Le token se décode en ses claims : sub, scp, wid, exec_id, iat, exp, jti.
  3. La signature du token est vérifiée avec la clé de la passerelle, l'en-tête alg étant contrôlé explicitement.
  4. Le token n'a pas expiré.
  5. La clé publique enregistrée de l'appelant est trouvée pour la session.
  6. Le message canonique est reconstruit.
  7. La signature de l'enveloppe est vérifiée avec cette clé et ce message.
  8. L'horodatage est à moins de 30 secondes de l'horloge du serveur.
  9. Le contexte de sécurité nommé dans scp est chargé et l'appel est évalué.

"Every check must pass before the payload is unwrapped and forwarded." (Chaque contrôle doit réussir avant que la payload ne soit déballée et transmise.)

Étape 7. Le contexte de sécurité décide

L'évaluation suit un ordre fixe : si un motif de la deny_list correspond, l'appel est refusé ; sinon "the first capability whose tool_pattern matches the tool name owns the decision" (la première capacité dont le tool_pattern correspond au nom de l'outil prend la décision) ; si aucune ne correspond, l'appel est refusé, car "there is no implicit allow." (il n'y a pas d'autorisation implicite.) Un motif de famille comme fs.* correspond à fs.read et jamais à fs ni à fsx.read.

Étape 8. L'appel est transmis, ou refusé avec un code

Un appel autorisé voit sa payload déballée et envoyée à l'outil ; les identifiants, là où l'outil en a besoin, sont résolus à ce moment-là. Un appel refusé répond par un code numérique : 2000 à 2006 pour la politique (non accordé, sur la liste de refus, chemin, commande ou domaine hors de sa liste d'autorisation, limite de débit, aucune capacité correspondante), 1001 à 1006 pour les signatures, tokens et sessions, 3000 à 3002 pour l'attestation. Le conseil de la documentation : "Switch on error.code, not on the status." (Aiguillez sur error.code, pas sur le statut.)

Étape 9. Chaque décision laisse un événement d'audit

La passerelle publie notamment ToolCallAuthorized ou PolicyViolationBlocked, avec la signature, l'horodatage et le jti de l'enveloppe, les claims sub, scp, wid et exec_id du token, le nom de l'outil, une empreinte de la payload ("payloads are not logged by default", les payloads ne sont pas journalisées par défaut) et la décision avec sa règle décisive. Comme seule la clé privée de la session a pu signer l'enveloppe, l'enregistrement assure la non-répudiation.

Étape 10. La session se termine avec l'exécution

Quand l'exécution se termine, par succès, erreur, délai dépassé ou annulation, l'orchestrateur appelle DELETE /v1/seal/sessions/{session_id}. La passerelle purge la clé, et une enveloppe capturée et rejouée après cela est rejetée.

Ce que la documentation laisse ouvert

Ensuite

Pour retrouver ces appels dans une vraie exécution, lisez Reading an AEGIS execution log (en anglais). Pour essayer, AEGIS s'installe avec la commande affichée sur 100monkeys.ai :

curl -fsSL https://get.100monkeys.ai | bash

Installer AEGIS depuis 100monkeys.ai