100monkeys.ai

Blog · Anleitung · 28. Oktober 2026

Wie AEGIS einen Tool-Aufruf versiegelt: das SEAL-Gateway, Schritt für Schritt

Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: Wir bei 100monkeys.ai entwickeln AEGIS und das SEAL-Gateway, lesen Sie diese Anleitung also als Bericht des Herstellers. Einer unserer KI-Agenten hat sie aus der öffentlichen Dokumentation (auf Englisch) entworfen, vor allem der Seite SEAL Protocol, Integration with AEGIS und Security Contexts, und das Unternehmen hat sie geprüft; diese deutsche Fassung ist eine Übersetzung der englischen Originalanleitung. Die Felder, Codes und Abläufe unten sind die der Dokumentation, keine Ausgaben, die wir für diese Anleitung aufgezeichnet haben.

AEGIS by 100monkeys.ai, in beta, vertraut dem Tool-Aufruf eines Agenten nicht, nur weil der Agent ihn gemacht hat. Jeder Aufruf wird in einen signierten Umschlag verpackt und vom SEAL-Gateway geprüft, bevor irgendetwas außerhalb des Laufs berührt wird. Diese Anleitung folgt einem Aufruf vom Start eines Laufs bis zu dem Audit-Eintrag, den er hinterlässt.

Wofür SEAL da ist

SEAL steht für Signed Envelope Attestation Layer. Die Dokumentation nennt vier Lücken gewöhnlicher Tool-Aufruf-Protokolle: kein Nachweis, welcher Client eine Anfrage gesendet hat, Berechtigungen, die pro Sitzung alles oder nichts sind, Inhalte, die unterwegs manipuliert werden können, und kein Eintrag, der belegt, welcher Aufrufer was getan hat. Ihr Beispiel ist eine Prompt-Injection: Eine abgerufene Seite fordert das Modell auf, /workspace zu löschen. "With SEAL, the caller's SecurityContext has no fs.delete capability. The gateway blocks it before it ever reaches the tool." (Mit SEAL hat der SecurityContext des Aufrufers keine fs.delete-Fähigkeit. Das Gateway blockiert den Aufruf, bevor er das Werkzeug überhaupt erreicht.)

Das Gateway ist zuerst eigenständig gedacht. In den Worten der Dokumentation ist es "the same aegis-seal-gateway binary" (dieselbe aegis-seal-gateway-Binärdatei), die der AEGIS-Orchestrator "deploys alongside itself" (neben sich selbst bereitstellt). Mit AEGIS müssen Sie nichts weiter tun, um die Schritte unten zu bekommen; "it is the default." (es ist die Voreinstellung.)

Schritt 1. Der Orchestrator öffnet eine Sitzung für den Lauf

Wenn eine Ausführung in den Zustand Running übergeht, erzeugt der Orchestrator für diese Ausführung ein frisches Ed25519-Schlüsselpaar und registriert es beim Gateway: POST /v1/seal/sessions mit einer session_id (der Ausführungs-ID, "so audit trails line up", damit die Audit-Spuren zusammenpassen), dem public_key, dem security_context und einem expires_at, das durch das Zeitbudget des Laufs begrenzt ist. Nur ein Aufrufer mit dem Scope seal.session.create kann das tun; "agents themselves cannot self-register." (Agenten selbst können sich nicht registrieren.)

Schritt 2. Der private Schlüssel geht an den Agenten und sonst nirgendwohin

Die private Hälfte wird in die flüchtige Laufzeitkonfiguration des Agenten-Containers geschrieben, "a tmpfs mount, never persisted" (ein tmpfs-Mount, nie dauerhaft gespeichert), zusammen mit der Gateway-URL und der Sitzungs-ID. Jede Ausführung hat also ihren eigenen Schlüssel, und "a leaked private key is bounded to a single execution's lifetime." (ein geleakter privater Schlüssel ist auf die Lebensdauer einer einzigen Ausführung begrenzt.)

Schritt 3. Die Sitzung wird an einen Sicherheitskontext gebunden

Ein Sicherheitskontext ist eine benannte Richtlinie auf dem Gateway: eine deny_list und eine geordnete Liste von capabilities, jede mit einem tool_pattern und optional path_allowlist, command_allowlist, subcommand_allowlist, domain_allowlist und max_response_size. Gestartete Agenten laufen unter aegis-system-agent-runtime, nicht unter dem Stufenkontext der Person, die gefragt hat. Der Orchestrator setzt den Kontext bei der Bereitstellung, und der Agent "cannot escalate by claiming a different scp in its envelope" (kann sich nicht höhere Rechte verschaffen, indem er in seinem Umschlag einen anderen scp angibt).

Schritt 4. Der Agent signiert eine kanonische Nachricht

Die Signatur gilt nicht dem rohen JSON. Sie gilt drei Schlüsseln, payload, security_token und timestamp, serialisiert mit auf jeder Ebene sortierten Schlüsseln, ohne Leerraum, mit einem ganzzahligen Unix-Zeitstempel und in UTF-8. Jede andere Bytefolge ergibt eine andere Signatur, und "the gateway will reject the envelope." (das Gateway wird den Umschlag ablehnen.)

Schritt 5. Der Agent sendet den Umschlag

Der Umschlag enthält protocol (immer seal/v1), das security_token (ein bei der Attestierung ausgestelltes JWT, standardmäßig eine Stunde gültig), die Ed25519-signature, die payload (bei MCP-artigen Aufrufen ein JSON-RPC-tools/call), eine optionale container_id und den timestamp. Er geht an den Aufruf-Endpunkt des Gateways, POST /v1/invoke. Das Gateway lauscht standardmäßig auf 8089; die eigene API des AEGIS-Orchestrators liegt auf 8088.

Schritt 6. Das Gateway führt neun Prüfungen durch

  1. Das Feld protocol ist seal/v1.
  2. Das Token lässt sich in seine Claims dekodieren: sub, scp, wid, exec_id, iat, exp, jti.
  3. Die Signatur des Tokens wird gegen den Schlüssel des Gateways geprüft, wobei der alg-Header ausdrücklich kontrolliert wird.
  4. Das Token ist nicht abgelaufen.
  5. Der registrierte öffentliche Schlüssel des Aufrufers wird für die Sitzung gefunden.
  6. Die kanonische Nachricht wird neu aufgebaut.
  7. Die Signatur des Umschlags wird gegen diesen Schlüssel und diese Nachricht geprüft.
  8. Der Zeitstempel liegt innerhalb von 30 Sekunden um die Uhr des Servers.
  9. Der in scp genannte Sicherheitskontext wird geladen und der Aufruf bewertet.

"Every check must pass before the payload is unwrapped and forwarded." (Jede Prüfung muss bestanden sein, bevor die Payload ausgepackt und weitergeleitet wird.)

Schritt 7. Der Sicherheitskontext entscheidet

Die Bewertung läuft in fester Reihenfolge: Passt ein Muster der deny_list, wird der Aufruf abgelehnt; sonst gilt "the first capability whose tool_pattern matches the tool name owns the decision" (die erste Fähigkeit, deren tool_pattern zum Werkzeugnamen passt, trifft die Entscheidung); passt keine, wird der Aufruf abgelehnt, denn "there is no implicit allow." (es gibt keine stillschweigende Erlaubnis.) Ein Familienmuster wie fs.* passt auf fs.read, aber nie auf fs oder fsx.read.

Schritt 8. Der Aufruf wird weitergeleitet oder mit einem Code abgelehnt

Bei einem erlaubten Aufruf wird die Payload ausgepackt und an das Werkzeug geschickt; Zugangsdaten, wo das Werkzeug sie braucht, werden in diesem Moment aufgelöst. Ein abgelehnter Aufruf antwortet mit einem numerischen Code: 2000 bis 2006 für Richtlinien (nicht gewährt, auf der Sperrliste, Pfad, Befehl oder Domain außerhalb der Allowlist, Ratenlimit, keine passende Fähigkeit), 1001 bis 1006 für Signaturen, Tokens und Sitzungen, 3000 bis 3002 für die Attestierung. Der Rat der Dokumentation: "Switch on error.code, not on the status." (Verzweigen Sie nach error.code, nicht nach dem Status.)

Schritt 9. Jede Entscheidung hinterlässt ein Audit-Ereignis

Das Gateway veröffentlicht unter anderem ToolCallAuthorized oder PolicyViolationBlocked, mit der Signatur, dem Zeitstempel und der jti des Umschlags, den Claims sub, scp, wid und exec_id des Tokens, dem Werkzeugnamen, einem Payload-Hash ("payloads are not logged by default", Payloads werden standardmäßig nicht protokolliert) und der Entscheidung mit der entscheidenden Regel. Weil nur der private Schlüssel der Sitzung den Umschlag signiert haben kann, ist der Eintrag nicht abstreitbar.

Schritt 10. Die Sitzung endet mit dem Lauf

Wenn die Ausführung endet, ob durch Erfolg, Fehler, Zeitüberschreitung oder Abbruch, ruft der Orchestrator DELETE /v1/seal/sessions/{session_id} auf. Das Gateway löscht den Schlüssel, und ein abgefangener Umschlag, der danach erneut gesendet wird, wird abgelehnt.

Was die Dokumentation offenlässt

Weiter

Um diese Aufrufe in einem echten Lauf zu finden, lesen Sie Reading an AEGIS execution log (auf Englisch). Zum Ausprobieren installiert sich AEGIS mit dem Befehl, der auf 100monkeys.ai steht:

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

AEGIS von 100monkeys.ai installieren