GmailやNotionまで任せたいのに、APIキーがOpenAIやAnthropicのログに残る——そんな不安が、AIエージェント運用の現場で急に現実味を帯びています。2026年6月、NEAR Legionは「多くのエージェントがAPIキーをそのままモデル提供者に送っている」と指摘し、OpenClawとIronClawの対比を紹介しました（元ポスト）。
本記事では、公式ドキュメントと公開された調査に基づき、なぜ秘密情報がLLMのコンテキストやログに載りやすいのか、OpenClawが提供する対策の範囲、IronClawが採るアーキテクチャの違いを整理します。
この記事でわかること
- AIエージェントでAPIキーが漏れる典型的な経路
- OpenClawのSecretRefと監査フローが守れる範囲・守れない範囲
- IronClawのボールト注入・WASM隔離・漏洩検知の仕組み
- 自社運用で最初に確認すべきチェック項目
なぜAPIキーがLLMログに載るのか
AIエージェントは、メール、Notion、決済APIなど外部サービスに触るためにトークンやAPIキーを必要とします。問題は、エージェントの「思考」と「実行」が同じLLMパイプラインを通る設計だと、秘密がプロンプトや会話履歴に混ざる点です。
セキュリティ企業Snykは、OpenClawのスキルマーケットClawHub約4,000件を調査し、283件（約7%）がAPIキーやパスワードをLLMのコンテキストや出力ログに平文で通す指示を含むと報告しています（参考）。典型例は、スキル定義（SKILL.md）に「このAPIキーを使え」と書くことで、キーが会話履歴に残り、後から「直前の操作を説明して」と聞かれたときに再出力されるパターンです。
OpenClaw本体でも、GitHubのセキュリティロードマップIssue #11829では、解決済みモデルカタログのapiKeyがプロンプトコンテキストに載る問題（#11202）、エージェントが.envを読んでチャットに表示してしまう問題（#10659）など、複数の漏洩経路が列挙されています（参考）。つまり「設定を間違えた個人」だけでなく、フレームワークのデータの流れそのものがリスクになります。
OpenClawが提供する秘密管理
OpenClawは、設定ファイルに平文を書かずに済むSecretRefをサポートします。環境変数・ローカルファイル・execプロバイダ（1Password、Vault、passなど）を参照し、ゲートウェイ起動時にメモリ上のスナップショットへ解決します。運用者向けにはopenclaw secrets audit --checkで平文残存を検出し、configure→apply→reloadで移行する流れが公式に示されています（CLIリファレンス）。
ここで押さえるべきは、公式ドキュメントが明言するエージェントアクセス境界です。SecretRefは「サポート対象の設定面と生成物から平文を減らす」仕組みであり、プロセス隔離ではないと書かれています。openclaw.json、.env、生成されたagents/*/agent/models.jsonなど、エージェントが読めるパスに平文が残っていれば、ファイル読み取りやシェルツール経由でAPIのマスキングを迂回できます。移行完了の条件は、openclaw secrets audit --checkがクリーンであることに加え、OS・コンテナ・外部プロキシによる隔離が必要だとされています。
GmailやNotion連携の場合も、統合トークンは最終的にエージェントの実行環境に存在します。Notionは内部インテグレーションシークレットを設定に書き、エージェントがページ操作する構成が一般的です。クエリ理解のためAIモデルへデータが送られる経路は残るため、「SecretRefで設定ファイルの平文を減らした」だけでは、LLMログへの載りをゼロにはできません。
OpenClawは秘密管理を強化する方向に動いており、生成models.jsonへ解決済みapiKeyを書かない修正（PR #83294）や、監査・スクラブのワークフローが整備されています。ただしこれらは移行と運用の成熟度に依存する対策であり、モデルが秘密の値そのものを「見ない」設計ではありません。
IronClawが採る「秘密はLLMに渡さない」設計
IronClawはNEAR AIが公開するRust製のエージェントランタイムで、公式サイトではOpenClawのセキュリティ重視版として位置づけられています。中核はボールトに保存した秘密を、HTTPリクエスト送信の瞬間だけホスト側で注入することです（Credential Management）。
保存と暗号化
秘密はAES-256-GCMで暗号化され、マスターキーからHKDF-SHA256で導出した鍵ごとに別々に保護されます。保存先はPostgreSQLのバイナリ列で、平文値はDBに残りません。マスターキーはmacOS KeychainなどOSのキーチェーン、またはCI向けの環境変数SECRETS_MASTER_KEYで扱います。
WASMツールとの境界
ツールはWebAssemblyサンドボックス内で動き、秘密の存在確認（secret_exists）だけが許可されます。平文の読み取りAPIは公開されていません。OpenAI APIを呼ぶ場合、ツールはURLとヘッダーの枠だけを渡し、ホストが許可リストを確認したうえでAuthorization: Bearerを注入してからHTTPを実行します。復号した値はリクエスト直後にメモリから破棄されます。
漏洩検知
送信前のURL・ヘッダー・ボディ、受信後のレスポンス、ツール出力、ユーザー入力に対し、Aho-Corasickと正規表現の二段階でスキャンします。sk-proj-（OpenAI）、sk-ant-api（Anthropic）、ghp_（GitHub）などのパターンはBlock、BearerトークンはRedact、高エントロピーな16進列はWarnと、パターンごとに動作が分かれています。悪意あるツールがhttps://evil.com/steal?key=...へ送ろうとしても、実行前に遮断されます。
OpenClawブログの紹介記事では、OpenClawが「LLMから見える」秘密扱いに対し、IronClawは「暗号化ボールト＋境界注入＋WASM隔離」と整理されています（参考）。プロンプトで「漏らさないで」と頼むのではなく、構造上モデルに値が渡らない点が設計思想の差です。
両者を並べたときの違い
| 観点 | OpenClaw | IronClaw |
|---|---|---|
| 主な言語 | TypeScript | Rust |
| 設定の平文削減 | SecretRef・監査CLI | ボールト暗号化（保存時から平文なし） |
| ツール隔離 | 同一プロセス前提 | WASMサンドボックス＋能力ベース権限 |
| モデルが秘密の値を見るか | エージェントが読めるファイル・プロンプト経路が残る | 注入はホスト境界のみ、ツールは平文非保持 |
| 外向き通信 | スキル・設定次第 | 許可リスト＋漏洩スキャン |
OpenClawは汎用パーソナルアシスタントとしての拡張性とエコシステムが強みです。一方IronClawは、秘密を扱う本番ワークロード向けに、隔離と検知を最初から組み込んだランタイムです。どちらが「正解」かではなく、扱うデータの機密度で選ぶべきです。
運用者が今日できる確認
OpenClawを使う場合、まずopenclaw secrets audit --checkを定期実行し、平文・未解決Ref・auth-profiles.jsonによるシャドウイング・生成models.jsonの残骸をゼロにします。スキル側では、SKILL.mdにAPIキーを書かない、エージェントにキーの表示やログ出力をさせない、というSnykとAPI Strongholdが共通で指摘する運用ルールを徹底します（参考）。
IronClawを検討する場合、ツールごとのallowed_secretsとHTTP許可リストを最小権限で設計します。公式ドキュメントも「必要な秘密だけ宣言する」「開発ではダミー鍵を使う」と述べています。GmailやNotionのような広範なOAuthスコープを一括で渡す前に、エージェントに本当に必要なAPI境界を切り分けてください。
共通の原則は、秘密をプロンプトや会話履歴に載せないことです。モデル提供者（OpenAI、Anthropicなど）のログは、自社のVPC内とは別の信頼境界にあります。NEAR Legionが指摘した「キーがモデル提供者のログに流れる」リスクは、フレームワーク選定とスキル設計の両方で潰す必要があります。
AIエージェントを業務に載せる段階では、機能追加の前に「秘密がどの経路でLLM・ログ・第三者スキルに触れるか」をデータフロー図に書き出す作業が効きます。OpenClawのSecretRef移行とIronClawの境界注入は、どちらもその図の上で意味を持ちます。機密を扱うなら、監査がクリーンなOpenClaw運用か、最初から隔離前提のIronClawか、要件に合わせて選ぶのが現実的な一歩です。