100monkeys.ai

Blog · Anleitung · 28. Oktober 2026

Ein AEGIS-Ausführungsprotokoll lesen: was ein versiegelter Tool-Aufruf festhält

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

Offenlegung: 100monkeys.ai entwickelt AEGIS, lesen Sie diese Anleitung also als Bericht des Herstellers. Einer unserer KI-Agenten hat sie aus der öffentlichen AEGIS-Dokumentation entworfen, vor allem Deploying & Running Agents, CLI Reference, SEAL Protocol und der Seite Observability des Gateways, und das Unternehmen hat sie geprüft; diese deutsche Ausgabe ist eine Übersetzung der englischen Originalanleitung. Die Protokollzeilen, Felder und Codes unten sind die Beispiele der Doku, keine Ausgaben, die wir für diese Anleitung erfasst haben.

AEGIS by 100monkeys.ai, in beta, führt jeden Agenten in einer eigenen isolierten Laufzeit aus und schickt seine Tool-Aufrufe über ein signiertes Protokoll namens SEAL. Diese Anleitung liest einen Lauf von außen nach innen: den Ausführungsdatensatz, das Iterationsprotokoll und dann, was die SEAL-Schicht über einen einzelnen Tool-Aufruf festhält, ob erlaubt oder abgelehnt.

Warum die Ausführung die Einheit ist

Die Seite Executions sagt es klar: "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." (Jede Ausführung ist in AEGIS die Einheit für Beobachtbarkeit und Wiederholung. Protokolle, Tool-Aufrufe, Blackboard-Snapshots und Verfeinerungsverläufe hängen alle an einer Ausführungs-ID.) Jeder Schritt unten beginnt bei dieser ID. Eine Ausführung durchläuft die Schleife "Execute, Evaluate, Refine" (Ausführen, Bewerten, Verfeinern) und endet "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs." (wenn der Agent eine Ausgabe liefert, die seine Bewertungskriterien erfüllt, wenn das Iterationsbudget erschöpft ist oder wenn ein nicht behebbarer Fehler auftritt.)

Schritt 1. Die Ausführungs-ID finden

aegis task execute gibt sie beim Start aus (Execution started: <id>). Läufe, die Sie nicht selbst gestartet haben, listen Sie so auf:

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

Ein geplanter Lauf trägt seine Ausführungs-ID in der Laufliste des Zeitplans; ein Workflow-Lauf erscheint in aegis workflow executions list.

Schritt 2. Den Ausführungsdatensatz lesen

aegis task status <EXECUTION_ID> --output json

Laut Doku "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores." (liefert dies den Ausführungsdatensatz mit Status, Start- und Endzeit, Gesamtzahl der Iterationen sowie Status und Validierungswerten jeder Iteration.) Lesen Sie zuerst die Zahl der Iterationen. Eine bestandene Iteration ist ein sauberer Lauf; mehrere Iterationen bedeuten, dass die Ausgabe die Validierung nicht bestand und verfeinert wurde, und das Protokoll zeigt, warum.

Schritt 3. Das Iterationsprotokoll lesen

aegis task logs <EXECUTION_ID>

Das Beispiel der Doku dafür, was ein Lauf ausgibt, Zeile für Zeile:

[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)

Lesen Sie es als drei Arten von Zeilen: den Lebenszyklus (gestartet, abgeschlossen), eine Tool:-Zeile pro Aufruf des Agenten und eine Validation:-Zeile mit dem Urteil jedes Validators und dem Wert. Mit --errors-only sehen Sie nur Fehler, mit --verbose mehr Details und mit --follow verfolgen Sie einen laufenden Lauf. Bei einem Workflow zeigt aegis workflow logs <EXECUTION_ID> --transitions nur die Zustandswechsel.

Schritt 4. Wissen, was hinter jeder Tool-Zeile steht

Jede Tool:-Zeile ist ein Aufruf, der durch SEAL ging. "Every tool call is wrapped in a SealEnvelope" (Jeder Tool-Aufruf steckt in einem SealEnvelope): das Protokoll (seal/v1), ein security_token (ein bei der Attestierung ausgestelltes JWT), eine Ed25519-signature, der payload (bei MCP-artigen Aufrufen ein JSON-RPC-tools/call), eine container_id und ein ganzzahliger timestamp.

Die Claims des Tokens binden den Aufruf an Ihren Lauf: sub (der Aufrufer), scp (der Name des Sicherheitskontexts), wid (der Workload) und exec_id, das "ties every call in a session to one audit chain" (jeden Aufruf einer Sitzung an eine einzige Audit-Kette bindet). Die Ausführungs-ID aus Schritt 1 ist also der Schlüssel, der die Protokollzeile mit ihrem Umschlag verbindet.

Schritt 5. Lesen, warum ein Aufruf erlaubt wurde

Das Gateway führt neun Prüfungen durch, bevor es einen Aufruf weiterleitet: das Protokollfeld, Signatur und Ablauf des Tokens, den registrierten Schlüssel des Aufrufers, die Umschlagsignatur über eine kanonische Nachricht, einen Zeitstempel innerhalb von 30 Sekunden und zuletzt den in scp genannten Sicherheitskontext. Diese letzte Prüfung verweigert alles auf der Sperrliste, erlaubt einen Aufruf nur, wenn eine Fähigkeit zu Tool, Pfad, Domain oder Unterbefehl und Ratenlimit passt, und verweigert sonst "(default deny)" (standardmäßig verweigern). Der Kontext kann sich mitten in der Sitzung nicht ändern: "callers cannot widen their context, switch contexts, or impersonate a different one." (Aufrufer können ihren Kontext weder erweitern noch wechseln noch einen anderen vortäuschen.)

Schritt 6. Eine Ablehnung lesen

Ein abgelehnter Aufruf ist keine stille Lücke im Protokoll. Am SEAL Gateway antwortet er mit einem numerischen Code. Die häufigsten:

Die Doku rät, "switch on error.code, not on the status" (nach error.code zu verzweigen, nicht nach dem Status), und nennt eine Falle: Das orchestratoreigene POST /v1/seal/invoke beantwortet eine Ablehnung mit einem Text-Code wie TOOL_NOT_ALLOWED statt mit einer Zahl.

Schritt 7. Den Audit-Datensatz lesen

Die Seite SEAL Protocol listet die Ereignisse auf, die jeder Aufruf erzeugt, darunter ToolCallAuthorized und PolicyViolationBlocked, und was jedes erfasst: Signatur, Zeitstempel und jti des Umschlags; sub, scp, wid und exec_id des Tokens; den Tool-Namen und den "payload digest (not the full payload, payloads are not logged by default)" (Payload-Digest, nicht den vollständigen Payload; Payloads werden standardmäßig nicht protokolliert); und "the policy decision (ALLOW or DENY plus the deciding rule, if any)" (die Richtlinienentscheidung, ALLOW oder DENY, samt der entscheidenden Regel, falls vorhanden). Die Signatur sorgt für Nichtabstreitbarkeit: "only the holder of the ephemeral private key could have produced a valid signature." (nur der Besitzer des kurzlebigen privaten Schlüssels kann eine gültige Signatur erzeugt haben.)

Auf einem eigenständigen SEAL Gateway liegen diese Zeilen in der Tabelle gateway_events. Einen REST-Endpunkt dafür gibt es noch nicht; die Doku gibt stattdessen SQL an:

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

Die Tabelle wird nur ergänzt, also leiten Sie sie an Ihr SIEM weiter, indem Sie nach IDs oberhalb der zuletzt gesendeten abfragen.

Was die Doku offenlässt

Weiter

Was eine prüfende Person neben diesen Protokollen braucht, lesen Sie in der Checkliste zur Nachvollziehbarkeit von KI-Agenten in Produktion.

AEGIS von 100monkeys.ai installieren