Astridのcapability境界をWASMランタイムで読む

カーネルにモデルを置かない設計

AstridのREADMEは、各能力をsealed WebAssembly capsuleとして扱い、明示的な権限だけを与え、権限範囲を広げず交換できると説明しています。カーネルはイベントを経路付けし、capabilityを強制し、sandboxを実行し、監査記録を残します。モデル、tool schema、business logicはカーネルに持たせません。

この分離は、プロンプトに従うことをセキュリティ境界とみなさないための設計です。READMEは、権限がなければファイル、ネットワーク、プロセスへ到達できないと説明します。ただし、実際のdistroやcapsuleのmanifestが広い権限を要求すれば境界内の許可範囲は広がるため、runtimeを入れただけで安全になるとは読めません。

capsuleとuplinkのイベント経路

CLI、HTTP gateway、DiscordなどのfrontendはuplinkとしてdaemonにUnix domain socketで接続し、IPC eventを話します。READMEはFrontend traitを置かず、uplinkがbusの参加者と同じようにイベントを発行・受信する形を示しています。capsule同士はbusだけで通信し、Capsule.tomlのimportsとexportsから依存グラフを解決します。

依存関係はtopological sortで起動順を決め、tool capsuleはtool.v1.execute.<name>を受け取ります。kernelはtool schemaを理解しません。この経路を採る場合、CLIの成功表示だけでなく、どのuplinkがどのtopicを発行し、どのcapsuleが応答したかを追跡します。READMEはアプリ固有のイベント定義を提供していないため、distroの資料が必要です。

WASMとastrid:* WITの許可範囲

READMEのhost ABIはWebAssembly component modelとversioned astrid:* WIT packagesです。fs、io、kv、ipc、net、http、sys、process、approval、identity、elicit、uplinkが列挙され、guestはmanifestが許したものだけをimportします。外部作用はcapability-checked host callとして境界で確認されます。

初回の安全確認では、importsを空にしたcapsuleが何をできるか、fsのパス、netのhost、processの許可がどの粒度で効くかを具体的に試します。READMEはWASMが持つすべての実行環境差やWasmtimeの版をこの概要では説明していません。ローカルファイル、DNS、HTTP、子プロセスを同じ権限とみなさず、manifestとaudit chainを個別に読みます。

initから四つのバイナリへ

Quick startはbrew tap astrid-runtime/tap && brew install astrid、astrid init --distro @yourorg/your-distro、astrid start、astrid status、astrid capsule listです。distroは自動選択されず、名前、リポジトリ、ローカルDistro.toml、署名済み.shuttle archiveを--distroで明示します。Rust 1.95以上ならcargo install astridも使えます。

READMEはastrid、astrid-daemon、astrid-build、astrid-emitの役割を分けています。利用者が呼ぶのはastridで、daemonがkernel、buildがcapsule compiler、emitがstdioからbusへのbridgeです。インストール後はstatusとcapsule listの結果、選んだdistroの出所、署名の扱いを記録します。

監査チェーンと運用上の重さ

各principalにはcapsule access、KV data、secrets、home directory、quota、audit chainが分離され、別principalのnamespaceは読めず、callerを解決できなければclosedになるとREADMEにあります。audit entryは前のhashを封印し署名され、改ざんでchainが壊れると示されます。capsuleはdaemonの再起動なしでinstall、upgrade、removeできる設計です。

この仕組みは権限と監査を細かく管理したい環境には合いますが、distroの設計、鍵管理、principalの運用、ログ保管が増えます。READMEに本番での復旧時間、監査ログの保管量、既存agentの移植コストはありません。Apache-2.0の表記とv0.10.4のタグを記録し、まず一つのcapsuleで許可と拒否をaudit entryまで追うのが妥当です。

Astridの採用判断では、capabilityを付与する側と効果を受けるcapsuleを一緒に監査します。distroの出所、署名済みshuttleの扱い、Capsule.tomlのimportsとexports、IPC topic、principalを固定し、許可したfs、net、process、httpだけが通ることを確認します。astrid statusとastrid capsule listはdaemonの状態を見る入口ですが、拒否されたhost callとhash-linked audit entryも読みます。CLI、HTTP、Discordはuplinkであり、kernelがtool schemaを管理するわけではありません。Apache-2.0とv0.10.4を記録したうえで、Rust 1.95以上の導入条件、capsule upgrade、別principalのKVとsecretsの分離を検証します。（対象リポジトリ: astrid-runtime/astrid）

Astridのcapability境界をWASMランタイムで読むについても、この確認単位を崩さないことが必要です。Astridのcapability境界をWASMランタイムで読む

この判断で見るべきなのは、READMEの宣伝文句ではなく、対象版で再現できる境界です。導入前にプロジェクト名、参照タグ、設定ファイル、入力、出力、失敗時のログを一組にして保存します。公式READMEに書かれていない既定値は、記事の事実として補いません。小さな入力で正常系を通した後、権限不足、空の入力、再起動、版の不一致を順に試します。結果が仕様と一致しない場合は、採用を急がず、その差をissueや公式ドキュメントの該当箇所と照合します。ライセンスは利用形態を確認する入口であり、認証や個人情報の扱いを判断する資料ではありません。更新時はリリースタグと変更点を記録し、前の組み合わせへ戻せる状態を残します。（対象リポジトリ: astrid-runtime/astrid）

Astridではastrid init、astrid start、astrid status、astrid capsule listを同じdistroで実行し、Capsule.tomlの許可差分とaudit chainの記録を突き合わせます。WASM capsuleにfsを与えない場合の拒否、netの対象hostを限定した場合の拒否、principalを変えた場合のKV境界を一つずつ確認します。

記事で扱った範囲には、READMEが直接説明した事実と、まだ資料に現れていない条件があります。前者はコマンド、ファイル名、タグ、API、ライセンスとして再確認できます。後者は性能、可用性、認証、保存、復旧などの運用条件です。両者を同じ確度で書かず、対象リポジトリの版を変えたときは、同じ入力と同じ設定で結果が変わらないかを記録します。採用を決める単位は製品名ではなく、実際に使う機能と責任範囲です。

編集部の結論

Astridは、エージェントやツールを明示的な権限の範囲で動かしたい開発者に向きます。既存のエージェントフレームワークをそのまま包み、設定だけで同じ実行モデルを得たい人には向きません。まずastrid init --distroで選ぶdistroを固定し、Capsule.tomlのimportsとexports、Unix socket経由のuplink、許可したfsやnetの呼び出しを監査ログで確認してください。

公式情報源

1. Official README
2. Project repository
3. Release notes