セキュリティ

この章では、ツール、コード、資金移動に対する技術的な制御を説明します。Chat で利用者の危険な判断を確認する機能は財務安全リマインダーを参照してください。

「この Python スクリプトを実行して、結果を見せて」と Agent に指示したとします。 スクリプトは起動します。無害なデータ処理かもしれませんし、最終行に minara swap が潜んでいて、100 USDC を攻撃者のコントラクトに送り込む コードかもしれません。

お金を動かせる Agent がコードを実行し、コマンドを入力し、ファイルを書き込む。 これは本質的に危険な組み合わせです。この章では、Minara がそれに対してどう 対処しているか、なぜ各防御が存在するか、そして現時点でどこにギャップがあるかを 説明します。

以下の設計を動機づける 3 つのシナリオ

具体的な攻撃例を見ると、設計の意図が明確になります。

1. 貼り付け攻撃。 Discord やフォーラムから「便利そうな」スクリプトをコピーして Agent に実行を依頼すると、中ほどに minara swap が埋め込まれている。
2. マルチステップインジェクション。 Agent が無害なヘルパーファイルを書き込み、 さらに 1 行追記し、その後 python helper.py を実行する。各ステップは 問題なく見える。しかし、組み合わさるとウォレットが空になる。
3. オンチェーントラップ。 スクリプトが approve(unknown_address, MaxUint256) を呼び出すか、Permit2 メッセージに署名する。これらは「明らかに悪意ある」 コマンドではなく、正規の DEX 統合でも使われる呼び出しと同じです。 ただし、spender フィールドが攻撃者になっています。

これらのどれも、単一のチェックでは検出できません。スクリプトは実行され、 ファイルは存在し、コントラクト呼び出しは有効です。それを止めるのは、 以下に示す独立したレイヤーの組み合わせです。

多層防御。4 つの独立したゲート

Minara は、LLM からアクセス可能なすべてのツールの前に、4 つの独立した セーフティレイヤーを設けています。独立しているのは意図的な設計です。 1 つを突破した攻撃者は、他のすべてをさらに突破しなければならず、 各レイヤーは異なる方式で機能します。

サンゴ色で強調された OS jail レイヤーだけが物理境界です。上位の すべてが突破されても、システムコールレベルの分離は引き続き機能します。 残りの 3 つはトリップワイヤーであり、可視性と割り込みの機会を 追加しますが、決意ある攻撃者がソースを読んでギャップを探すことは 防げません。多層防御の意味は、各レイヤー単独ではなく、組み合わせに あります。

レイヤー 1。コマンドガードトリップワイヤー

すべてのシェルコマンドに対する正規表現の拒否リストです。確認なしで ブロックするパターンを定義しています。rm -rf /、sudo、mkfs、 curl … | sh、フォークボムなどが該当します。この正規表現がすべてを 捕捉できるわけではありません（base64 してから eval するような手法は 抜け抜けます）。目的は、明らかな事故や最も一般的なプロンプトインジェクションの 1 行コードをここで確実に阻止し、残りを上位レイヤーに委ねることです。

これはトリップワイヤーであり、境界ではありません。

レイヤー 2。OS jail（実質的な境界）

execute_code や terminal が起動するすべてのサブプロセスは、Linux では bwrap に、macOS では sandbox-exec にラップされます。このラッパー内のプロセスは、~/.ssh を読めず、 169.254.169.254（クラウドメタデータ）に接続できず、ワークスペース ディレクトリの外に書き込めません。

上位のレイヤーがすべて突破されても（誤った正規表現、プロンプトインジェクション、 巧妙な難読化など）、攻撃コードは jail が許可するシステムコールセットの 中に制限されます。「物理境界」とはこの意味です。文字列マッチングではなく、 カーネルによって強制されています。

レイヤー 3。資金移動確認（二段階）

スワップ、買い、売り、送金、永続先物、Autopilot の有効化、ワークフローの アクティベーションなど、お金を動かすすべてのツールは 2 回の呼び出しが 必要です。

1. 1 回目の呼び出し（confirm パラメーターなし）：ハンドラーが 取引をシミュレートし、プレビュー（金額、ルート、スリッページ、 ガス見積もり）を返します。ブロードキャストは行いません。
2. 2 回目の呼び出し（confirm: true）：この時点で初めてハンドラーが 実際に署名してブロードキャストします。

これは LLM への丁寧なプロンプトではなく、各ハンドラー内部で強制されています。 LLM がルールを「忘れる」ことはできません。confirm: true なしで swap_tokens を呼び出しても、プレビューが返るだけで、tx ハッシュは返りません。

詳細は資金移動確認をご覧ください。

レイヤー 4。スクリプトリスクゲート（新機能）

レイヤー 3 は直接の資金移動ツール呼び出しを防ぎますが、Python スクリプトが subprocess.run(["minara", "swap", …]) を実行する場合はどうでしょうか。 このシェルアウトはプロセス内のツールレジストリをバイパスするため、 レイヤー 3 には見えません。

レイヤー 4 がそのギャップを埋めます。execute_code、terminal、 write_file、または patch が実行される前に、スクリプト本体が 静的解析されます。

• RED。自動拒否（大量削除、IMDS / SSRF、認証情報の外部送信、コンテナエスケープ、難読化＋シンクの組み合わせ、インラインでの秘密鍵署名）。
• YELLOW。一時停止してユーザーに確認（資金移動 CLI シェルアウト、approve / Permit2 / Safe オーナー変更、環境変数の汚染、特定パスの削除、リスクの高いパッケージのインストール）。
• GREEN。無音で続行（その他すべて）。

詳細はAgent がリスクを判断する仕組みをご覧ください。

Minara が守れないもの

正直なリストです。これらはバグではなく、スコープの境界です。 把握しておくことで、適切な場所で警戒できます。

• 実行時に構築されるペイロード。 os.system(a + b) のような スクリプトで、a と b が実行時に計算される場合、静的解析では 結合後の文字列を確認できません。レイヤー 2 の jail はサブプロセスの 動作を制限しますが、ゲートは dynamic_command を YELLOW として フラグを立て確認を求めます。「はい」と答える前にスクリプトを読んでください。
• 悪意あるスマートコントラクトと DApps。 コードレイヤーは、 コントラクト 0xabc… がドレイナーであるか、cool-dapp.example.com がフィッシングクローンであるかを知ることができません。それは トークン / DApp スキャンの並行する役割です。
• あなたが署名したトランザクション。 レイヤー 3 はプレビューを表示します。 確認すると、バイトが署名されてブロードキャストされます。 「はい」をクリックする前にプレビューを読んでください。
• 自分自身のタイプミスやバグ。 Minara は悪意ある意図からは守りますが、 誤ったファイルを削除したり、間違ったアドレスに送金したりする ミスからは守れません。二段階確認は自分自身のミスにも気づけるよう 存在しています。そのように活用してください。

実際の使い方への影響

日常使用における実践的なセーフティの指針です。

• 🟢 日常的で問題のない操作。 Pandas によるデータ処理、パブリック HTTPS GET リクエスト、CSV からのグラフ生成、npm ci --ignore-scripts など。 Minara は割り込みなしに実行します。
• 🟡 確認ウィジェットが表示されます（YELLOW）。 minara swap、cast send、 forge --broadcast を呼び出すスクリプト、ERC-20 の approve と Permit2 の署名、特定パスの削除、bash <(curl …) のようなプロセス置換、 NODE_OPTIONS や LD_PRELOAD の設定が該当します。ゲートが表示する 証拠を確認してから、許可またはキャンセルしてください。
• 🔴 ハード拒否（RED）。 大量削除（rm -rf *、rm -rf $UNSET/x）、 ~/.ssh/id_rsa の読み取り、IMDS エンドポイントへのアクセス、 コンテナエスケープの試み、コード内のインライン秘密鍵。これらのパターンには 正当な業務上の理由がありません。confirm: true を指定しても拒否されます。 RED になった場合、バイパスしようとしないでください。 スクリプトが何をしようとしていたか確認してください。ほぼ必ず プロンプトインジェクションかコピー&ペーストされた攻撃です。
• ⚠️ あなたの責任。 秘密鍵をリポジトリに含めないでください。 .env には chmod 600 を適用してください。インタラクティブな セッションで MINARA_SKIP_FUND_CONFIRM や DISABLE_SCRIPT_RISK_GATE を設定しないでください。レイヤー 3 のプレビューを確認してから 確定してください。

さらに詳しく

この章はオペレーター向けです。「Minara を安全に使う方法」を扱っています。 正式なトラストモデル、脅威の分類、脆弱性開示ポリシーについては、 リポジトリの SECURITY.md をご覧ください。そちらはセキュリティ研究者向けに書かれており、 こちらは Minara を使ってトレードをする方向けに書かれています。

続きを読む：

• 資金移動確認。資金移動ツールすべてに適用される二段階フロー。
• スクリプトリスクゲート。Agent が RED / YELLOW / GREEN を判断する仕組み。
• 監査とオーバーライド。決定の確認、ワークフロー免除の付与、無効化スイッチについて。