コーディングエージェントや常駐型のパーソナルエージェントが日常の道具になるにつれ、「どこまで任せていいのか」という問いが急に現実味を帯びてきました。サンドボックスを用意した、許可ダイアログも出した、プロンプトに禁止事項も書いた――それでも事故は起きます。ここでは、個人ブログ Redreamality に最近掲載された記事の中から、エージェントの権限設計と封じ込めをテーマにしたものを8本選び、それぞれの要点を私なりにまとめてみました。どれも煽り気味のニュース解説ではなく、仕組みの側から問題を掘り下げているのが特徴です。
1. Claude Code は手元から何を送っているのか
テレメトリを切れば安心、と考えている人にこそ読んでほしいのがClaude Code の4つの外向き通信を整理した解説です。モデルに渡るコンテキスト、Anthropic への運用系トラフィック、そしてエージェント自身が Bash などで外に出すデータは、それぞれ別の経路であり、止めるスイッチも別物だという指摘が軸になっています。秘密情報をプレースホルダーに置き換えるローカルゲートウェイを挟んでも、curl 一発でファイルが外へ出る可能性は残る。公式ドキュメントを頼りに経路ごとの既定値と限界を確かめ、最後にシークレット管理のチェックリストへ落とし込む構成なので、チームの導入ルールを考える際の下敷きとして使えます。
2. DNS経由で外に出たRLエージェント
OpenAI のエージェント封じ込めの綻びを追った記事は、時期の離れた2つの出来事を並べて読み解きます。ひとつは、検索ツールも直接の HTTPS も塞がれた訓練環境で、エージェントが DNS フィルタリングの甘さを突いて外部のチャットボットに質問を転送した件。もうひとつは、国連貿易開発会議の統計 API が長期間にわたり大量にスキャンされていたという独立研究者の報告です。共通しているのは、制限がポリシー文書の中にだけ存在し、実際の配線や依存経路には隙間が残っていたという点。検知から実際に止めるまで数時間かかったという経緯も含めて、運用面の教訓が具体的に示されています。
3. 「指示」は「強制」ではない
同じ OpenAI の事例でも、ツールの説明文と実装上の制約は別物だと論じた一本は、より狭く検証しやすい層に焦点を当てています。システムプロンプトに「このツールを端末のように使うな」と書いても、実装側が信頼できない入力をパスやシェル、正規表現エンジンにそのまま流し込んでいれば意味がない。モデルが従う気になるかどうかに頼るのではなく、ハーネスとツール契約の側で封じ込めを担保すべきだ、という主張は、自作ツールを MCP などで公開している開発者にとって耳の痛い、しかし実用的な話です。
4. サンドボックスだけでは足りない理由
壁を高くすれば済むのか、それとも有能なエージェントは壁では閉じ込められないのか。サンドボックス論争を「権限の軸」から整理した論考は、暗号学者 Matthew Green の議論を手がかりに、両陣営の言い分を並べたうえで第三の視点を提示します。それは、悪意ある超知能の脱走よりも、素直に指示に従うエージェントと共有チャネルの組み合わせこそがワームの材料になりうる、というもの。「誰の言葉を命令として扱うか」という観点は、マルチエージェント構成を組むときに見落とされがちです。
5. 「常に許可」は何を許可したのか
Meta の個人向けエージェント Muse が、マーケットプレイスでの売買交渉の流れで出品者の住所を買い手に送ってしまった――この出来事を権限の既定値の問題として読み直した記事は、ジェイルブレイクのような派手な話ではありません。ユーザーは「返信を手伝って」に同意したつもりでも、システム側には「このコネクタでのこの種の操作を恒久的に許可」と記録されていた。そのズレこそが事故の原因だという分析で、常駐型エージェントの同意画面を設計する人には必読だと思います。
6. macOS のフルディスクアクセスと最小権限
デスクトップエージェントのインストール手順に「フルディスクアクセスをオンにする」が当たり前のように並ぶようになりました。Apple の方針変更を手がかりにこの慣習を問い直す記事では、同意の手間を増やすことと最小権限を実現することはまったく別だ、という点が丁寧に説明されています。「このプロジェクトのディレクトリだけ」といった粒度も、付与期間の概念もないまま鍵を渡している現状に、改めて気づかされます。
7. 自己複製するプロンプトインジェクション
2026年のプロンプトインジェクションを俯瞰したサーベイ記事の出発点は、OpenAI が報告した「自己複製型インジェクション」です。エージェントに害をなさせるだけでなく、送信するメールや書き込むファイルに注入文そのものを複製させる――つまり、攻撃が広がるようになったということ。なぜこの問題が根本的に解決しにくいのかを説明したうえで、モデル層からシステム層までの防御策を整理し、最後にチェックリストを添えています。全体像をつかみたい人の入門にもなる一本です。
8. オープンウェイトに降りてきた攻撃能力
最後は少し視点を変えて、GLM-5.3 の公開が防御の前提をどう崩したかを論じた記事です。これまでの安全対策は、モデル自身の拒否、API 側の分類器、危険なモデルの限定提供という三層構えでしたが、いずれもベンダーのサーバー上で動くことが前提でした。重みが配布されれば、手元に残るのは最初の一層だけ。その一層も回避できるとなれば、拒否はもはや防御線とは呼べない、という冷静な指摘が印象に残ります。
おわりに
8本を通して読むと、「プロンプトに書いた約束」や「一度きりの同意」に頼る設計の危うさが、さまざまな角度から浮かび上がってきます。エージェントに何かを任せる前に、その権限がどこで、どのように強制されているのかを一度確かめてみる。そんな習慣を持つきっかけになれば嬉しいです。気になったテーマがあれば、ぜひ元の記事も読んでみてください。