ブログ · ガイド · 2026年10月28日
AEGIS がツール呼び出しを封印する仕組み: SEAL ゲートウェイを一歩ずつ
開示: AEGIS と SEAL Gateway は 100monkeys.ai が開発しているため、このガイドは作り手による説明として読んでください。公開ドキュメント、主に SEAL Protocol ページ、Integration with AEGIS、Security Contexts をもとに当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文ガイドの翻訳です。以下のフィールド、コード、流れはドキュメント自身のもので、このガイドのために取得した出力ではありません。引用は英語のまま示し、訳を添えています。
AEGIS by 100monkeys.ai, in beta は、エージェントが行ったからといってそのツール呼び出しを信用しません。呼び出しはすべて署名付きエンベロープに包まれ、実行の外にあるものに触れる前に SEAL Gateway が検査します。このガイドでは、実行が始まった瞬間から、呼び出しが残す監査記録までを一つの呼び出しについて追います。
SEAL は何のためにあるか
SEAL は Signed Envelope Attestation Layer の略です。ドキュメントは、一般的なツール呼び出しプロトコルにある 4 つの穴を挙げています。どのクライアントがリクエストを送ったかの証明がないこと、権限がセッション単位で全部か無しかであること、本文が転送中に改ざんされうること、どの呼び出し元が何をしたかを証明する記録がないことです。例はプロンプトインジェクションで、取得したページがモデルに /workspace を削除するよう指示します。"With SEAL, the caller's SecurityContext has no fs.delete capability. The gateway blocks it before it ever reaches the tool."(SEAL があれば、呼び出し元の SecurityContext には fs.delete の権限がありません。ゲートウェイはそれがツールに届く前に止めます。)
ゲートウェイはまず単体で動くように作られています。ドキュメントの言葉では、AEGIS オーケストレーターが "deploys alongside itself"(自分と並べてデプロイする)のは "the same aegis-seal-gateway binary"(同じ aegis-seal-gateway バイナリ)です。AEGIS では、以下の手順を得るために追加の作業は要りません。"it is the default."(それが既定です。)
ステップ 1. オーケストレーターが実行のためのセッションを開く
実行が Running に入ると、オーケストレーターはその実行用に新しい Ed25519 鍵ペアを生成し、ゲートウェイに登録します。POST /v1/seal/sessions に、session_id(実行 ID。"so audit trails line up"、監査証跡がそろうように)、public_key、security_context、実行の実時間予算に収まる expires_at を渡します。これができるのは seal.session.create スコープを持つ呼び出し元だけで、"agents themselves cannot self-register."(エージェント自身は自分を登録できません。)
ステップ 2. 秘密鍵はエージェントにだけ渡る
秘密鍵の側は、ゲートウェイの URL とセッション ID とともに、エージェントのコンテナの一時的なランタイム設定に書き込まれます。それは "a tmpfs mount, never persisted"(tmpfs マウントで、永続化されない)場所です。そのため実行ごとに鍵があり、"a leaked private key is bounded to a single execution's lifetime."(漏れた秘密鍵の影響は一つの実行の寿命に限られます。)
ステップ 3. セッションは一つのセキュリティコンテキストに結び付けられる
セキュリティコンテキストは、ゲートウェイ上の名前付きポリシーです。deny_list と、順序付きの capabilities のリストからなり、各 capability は tool_pattern と、任意の path_allowlist、command_allowlist、subcommand_allowlist、domain_allowlist、max_response_size を持ちます。起動されたエージェントは、依頼した人のティアのコンテキストではなく aegis-system-agent-runtime の下で動きます。オーケストレーターはプロビジョニング時にコンテキストを刻み込み、エージェントは "cannot escalate by claiming a different scp in its envelope"(エンベロープで別の scp を名乗って権限を上げることはできません)。
ステップ 4. エージェントが正規化したメッセージに署名する
署名の対象は生の JSON ではありません。payload、security_token、timestamp の 3 つのキーを、すべての階層でキーを並べ替え、空白なし、整数の Unix タイムスタンプ、UTF-8 でシリアライズしたものです。それ以外のバイト列では署名が変わり、"the gateway will reject the envelope."(ゲートウェイはエンベロープを拒否します。)
ステップ 5. エージェントがエンベロープを送る
エンベロープには、protocol(常に seal/v1)、security_token(アテステーション時に発行される JWT で、既定の有効期間は 1 時間)、Ed25519 の signature、payload(MCP 形式の呼び出しでは JSON-RPC の tools/call)、任意の container_id、timestamp が入ります。送り先はゲートウェイの呼び出しエンドポイント POST /v1/invoke です。ゲートウェイの既定のポートは 8089、AEGIS オーケストレーター自身の API は 8088 です。
ステップ 6. ゲートウェイが 9 つの検査を行う
- protocol フィールドが
seal/v1である。 - トークンをクレームにデコードできる:
sub、scp、wid、exec_id、iat、exp、jti。 - トークンの署名がゲートウェイの鍵で検証でき、
algヘッダーも明示的に確認される。 - トークンが期限切れでない。
- そのセッションについて、呼び出し元の登録済み公開鍵が見つかる。
- 正規化したメッセージを組み立て直す。
- エンベロープの署名が、その鍵とメッセージで検証できる。
- タイムスタンプがサーバーの時計から 30 秒以内である。
scpに書かれたセキュリティコンテキストを読み込み、呼び出しを評価する。
"Every check must pass before the payload is unwrapped and forwarded."(ペイロードを取り出して転送する前に、すべての検査に合格する必要があります。)
ステップ 7. セキュリティコンテキストが判定する
評価は決まった順序で行われます。deny_list のパターンに一致すれば呼び出しは拒否され、そうでなければ "the first capability whose tool_pattern matches the tool name owns the decision"(ツール名に tool_pattern が一致する最初の capability が判定を持ちます)。どれにも一致しなければ拒否されます。"there is no implicit allow."(暗黙の許可はないからです。)fs.* のようなファミリーパターンは fs.read に一致し、fs や fsx.read には決して一致しません。
ステップ 8. 呼び出しは転送されるか、コード付きで拒否される
許可された呼び出しはペイロードが取り出されてツールに送られ、ツールが資格情報を必要とする場合はその時点で解決されます。拒否された呼び出しは数値コードを返します。ポリシー関連は 2000 から 2006(許可されていない、拒否リストにある、パス・コマンド・ドメインが許可リストの外、レート制限、一致する capability がない)、署名・トークン・セッション関連は 1001 から 1006、アテステーション関連は 3000 から 3002 です。ドキュメントの助言は "Switch on error.code, not on the status."(ステータスではなく error.code で分岐してください。)
ステップ 9. すべての判定が監査イベントを残す
ゲートウェイは ToolCallAuthorized や PolicyViolationBlocked などのイベントを発行します。そこには、エンベロープの署名、タイムスタンプ、jti、トークンの sub、scp、wid、exec_id、ツール名、ペイロードのダイジェスト("payloads are not logged by default"、ペイロード自体は既定では記録されません)、判定とその根拠になったルールが入ります。エンベロープに署名できたのはセッションの秘密鍵だけなので、この記録は否認防止になります。
ステップ 10. セッションは実行とともに終わる
実行が成功、エラー、タイムアウト、キャンセルのいずれかで終わると、オーケストレーターは DELETE /v1/seal/sessions/{session_id} を呼びます。ゲートウェイは鍵を消し、その後に再送された捕獲済みのエンベロープは拒否されます。
ドキュメントが答えていないこと
- レート制限。SEAL Protocol ページは検査の一つに "rate limit not exceeded"(レート制限を超えていない)を挙げ、コード
2005を載せていますが、Security Contexts ページはrate_limitを "reserved for a future enforcement phase"(将来の適用フェーズのために予約)としています。現在制限が適用されているかは書かれていません。 - 終了後の再送は
session_not_foundで失敗するとされていますが、エラー表では1005SESSION_NOT_FOUNDと書かれています。その場合にクライアントが受け取る本文は示されていません。 - 単体のゲートウェイで監査イベントがどこに保存されるか、
PolicyViolationBlockedがそのgateway_eventsテーブルに現れるかは、これらのページには書かれていません。
次に読む
実際の実行の中でこれらの呼び出しを見つけるには、AEGIS の実行ログを読むをお読みください。試すには、100monkeys.ai に載っているコマンドで AEGIS をインストールします。
curl -fsSL https://get.100monkeys.ai | bash