Blog · Guide · 28 October 2026

Reading an AEGIS execution log: what a sealed tool call records

Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation, chiefly Deploying & Running Agents, the CLI Reference, the SEAL Protocol page and the gateway's Observability page, and reviewed by the company. The log lines, fields and codes below are the docs' own examples, not output we captured for this guide.

AEGIS by 100monkeys.ai, in beta, runs each agent in its own isolated runtime and sends its tool calls through a signed protocol called SEAL. This guide reads one run from the outside in: the execution record, the iteration log, and then what the SEAL layer records about a single tool call, allowed or refused.

Why the execution is the unit

The Executions page puts it plainly: "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." Every step below starts from that id. An execution runs the loop "Execute, Evaluate, Refine" and finishes "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs."

Step 1. Find the execution id

aegis task execute prints it as it starts (Execution started: <id>). For runs you did not start yourself, list them:

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

A scheduled run carries its execution id in the schedule's runs list; a workflow run is listed by aegis workflow executions list.

Step 2. Read the execution record

aegis task status <EXECUTION_ID> --output json

The docs say this "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores." Read the iteration count first. One iteration that passed is a clean run; several iterations mean the output failed validation and was refined, and the log will show why.

Step 3. Read the iteration log

aegis task logs <EXECUTION_ID>

The docs' example of what a run prints, line for line:

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

Read it as three kinds of line: the lifecycle (started, completed), one Tool: line per call the agent made, and a Validation: line with each validator's verdict and the score. Add --errors-only to see only failures, --verbose for more detail, and --follow to watch a live run. For a workflow, aegis workflow logs <EXECUTION_ID> --transitions shows only the state changes.

Step 4. Know what stands behind each Tool line

Each Tool: line is one call that went through SEAL. "Every tool call is wrapped in a SealEnvelope": the protocol (seal/v1), a security_token (a JWT issued at attestation), an Ed25519 signature, the payload (for MCP-style calls, a JSON-RPC tools/call), a container_id and an integer timestamp.

The token's claims are what tie the call to your run: sub (the caller), scp (the name of the security context), wid (the workload), and exec_id, which "ties every call in a session to one audit chain". So the execution id from Step 1 is the key that joins the log line to its envelope.

Step 5. Read why a call was allowed

The gateway runs nine checks before it forwards a call: the protocol field, the token's signature and expiry, the caller's registered key, the envelope signature over a canonical message, a timestamp within 30 seconds, and finally the security context named in scp. That last check denies anything on the deny list, allows a call only when a capability matches its tool, path, domain or subcommand and rate limit, and otherwise denies "(default deny)". The context cannot change mid-session: "callers cannot widen their context, switch contexts, or impersonate a different one."

Step 6. Read a refusal

A refused call is not a silent gap in the log. On the SEAL Gateway it answers a numeric code. The ones you will meet most:

2000 to 2006: policy. Tool not granted, tool on the deny list, path outside path_allowlist, command outside command_allowlist, domain outside domain_allowlist, rate limit reached, no capability matched.
1003 TOKEN_EXPIRED: the token expired, the timestamp was outside the 30-second window, or the jti was already seen, which is how a replayed envelope shows up.
1001 and 1002: a signature that is malformed or does not verify.

The docs say to "switch on error.code, not on the status", and note one trap: the orchestrator's own POST /v1/seal/invoke answers a refusal with a string code such as TOOL_NOT_ALLOWED instead of a number.

Step 7. Read the audit record

The SEAL Protocol page lists the events each call produces, including ToolCallAuthorized and PolicyViolationBlocked, and what each captures: the envelope's signature, timestamp and jti; the token's sub, scp, wid and exec_id; the tool name and "payload digest (not the full payload, payloads are not logged by default)"; and "the policy decision (ALLOW or DENY plus the deciding rule, if any)". The signature is what gives non-repudiation: "only the holder of the ephemeral private key could have produced a valid signature."

On a standalone SEAL Gateway those rows live in the gateway_events table. There is no REST endpoint for them yet; the docs give SQL instead:

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

The table is append-only, so ship it to your SIEM by polling for ids above the last one you sent.

What the docs leave open

The two event lists differ. The SEAL Protocol page names PolicyViolationBlocked; the gateway's gateway_events table, as Observability lists it, does not. Which table holds a denial is not stated.
Ports. The SEAL page puts the orchestrator on 8080; the CLI's default API port is 8088.
The gateway has no metrics endpoint and no OTLP traces yet; the Observability page says so itself.

For what a reviewer needs beside these logs, read A traceability checklist for AI agents in production.

Install AEGIS from 100monkeys.ai