🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね❤️ していただけると励みになります 🙌
はじめに
2026年に公表された情報漏えいを手口別に眺めていて、無視できない変化に気づきました。VPNの脆弱性や正規アカウントの悪用に混じって、AIエージェントそのものが侵入経路になった事例が並び始めています。shellツールの実行を経由してJWT（認証トークン）を抜かれたもの、Web入力に仕込まれた指示で情報をDNS越しに流出させたもの（通称 Salesbleed）、MCPサーバーの認証情報を不正に再利用されたもの。
これは他人事ではありません。Claude CodeもDevinも、まさに「ツールを実行し、外部の情報を読み、ネットワークに出る」エージェントです。この記事では、トレンドになっている実被害の型を分解し、それがClaude CodeとDevinでどう起こりうるのか、そして各ツールが何で守っているのかを、公式ドキュメントに沿って整理します。
結論を先に言うと、鍵は「lethal trifecta（致命的な3条件）」という考え方ひとつです。これを押さえると、どの対策が本当に効くのかが見えてきます。
先に3行でまとめると
- 危ないのは ①機密アクセス ②信頼できない入力 ③外部送信チャネル、の3つが揃ったとき（lethal trifecta）。AIコーディングエージェントはこの3つを同時に持ちやすい
- 2026年の実被害（AgentCore shell→JWT窃取、Salesbleed、MCP認証再利用）も、Devinで報告された .env 流出も、すべてこの枠組みで説明できる
- 守りの本質は 3本の脚のどれか1本を確実に断つこと。Claude Code（権限モード・sandbox・WebFetch要約・ネット制限）とDevin（Autonomousのsandbox・Vault・組織ポリシー）はそのための道具を持っている
この記事に出てくる用語の位置づけ
| 用語 | ざっくりの意味 |
|---|---|
| プロンプトインジェクション | AIへの指示を、データに紛れ込ませた悪意ある文章で乗っ取る攻撃 |
| 間接プロンプトインジェクション | エージェントが読んだIssueやWebやMCP出力の中に指示が仕込まれているパターン |
| lethal trifecta | 「機密アクセス」「信頼できない入力」「外部送信」の3条件。揃うと情報流出が成立する |
| exfiltration（流出） | 機密を外部へ持ち出すこと。curl・ブラウズ・DNS・画像URLなどが経路になる |
| MCP | エージェントに外部ツールをつなぐ標準プロトコル。便利な反面、信頼と認証が論点 |
| サンドボックス | ツール実行をファイルシステム・ネットワークごと隔離する仕組み |
危ないのは「3つが揃ったとき」
個々の機能が危険なのではありません。危ないのは、次の3つが同時に成り立つときです。
-
機密にアクセスできる：
.envやトークン、リポジトリ、DB、社内API - 信頼できない入力を読む：Issue・PR・Webページ・MCPツールの出力・リポジトリ内のファイル
- 外部へ送信できる：shell（curl）・ブラウズ・MCP送信・DNS・画像URL
この3つが重なると、②に仕込まれた指示でエージェントが①を読み、③で外に流す——という一連が成立します。逆に言えば、どれか1本を確実に断てば、この流出は成立しません。これがセキュリティ・コミュニティで「lethal trifecta」と呼ばれる整理です。
実際、冒頭の事例もこの3脚で説明できます。AgentCoreの件はshell実行（③）で認証トークン（①）を抜いた話、Salesbleedは外部から投入されたWeb入力（②）の指示でDNS（③）に流した話、MCP認証の再利用は①の経路が緩かった話です。
実被害の型を Claude Code / Devin に当てはめる
同じ型が、Claude CodeとDevinでも起こりえます。実際、Devinは間接プロンプトインジェクションでenvironment変数やシークレットを流出させられるという報告があります。攻撃者がGitHub上に悪意ある指示を置き、Devinにそれを触らせると、Devinがshellツールやブラウズツールを使って、curlで攻撃者のサーバーへ送る・URLに埋め込む・markdown画像として描画する、といった経路でデータを持ち出してしまう、という筋です。これは「最小権限」と「安全な情報フロー」が破れたときの典型です。
| 実被害の型 | 揃った脚 | Claude Code / Devin で同じことが起こる面 |
|---|---|---|
| shell実行→認証トークン窃取（AgentCore） | ①＋③ | bash/shellツールに権限を与えすぎると、注入された指示で鍵を読み出して外へ |
| 外部入力→DNS流出（Salesbleed） | ②＋③ | Issue/PR/Webを読ませる自動化で、本文の指示に従って外部通信してしまう |
| MCP認証の不正再利用 | ① | 監査されていないMCPサーバーや使い回しの認証で、機密への経路が広がる |
3つの脚を、Claude Code / Devin はどう断つか
ここが本題です。両者とも、3本の脚を切るための機能を持っています。
① 機密アクセスを絞る
いちばん効くのは、そもそもエージェントに機密を渡さないことです。
-
Claude Code：クラウド実行では、GitHubの認証情報をセッションVMに入れず、Anthropic側のプロキシが送信時に付与します（VMには短命の限定クレデンシャルのみ）。手元のAPIキーやトークンはKeychainやモード
0600のファイルで保管。.envのような機密ファイルはpermissions.denyで読ませない設定ができ、Manualモードは読み取り専用から始まります。 -
Devin：Vault に預けた秘密はサンドボックスに入らず、送信時（egress）に差し込まれるので、サンドボックス内のコード（エージェントが書いたものを含む）からは読み出せません。
.envは原則 default-deny で読ませない運用が推奨されています。
② 入力を信用しない
読んだものすべてに「指示が仕込まれているかも」と疑うのが基本姿勢です。
-
Claude Code：WebFetchは多くの場合、生ページをそのまま渡さず、別のモデル呼び出しでページを要約した結果をClaudeに渡します。注入文がそのまま本体に届きにくくなる設計です。未信頼のフォルダで起動するとworkspace trustの確認が出ます。ただし注意点として、
claude -p（ヘッドレス）ではtrustダイアログもMCP承認も出ません。リポジトリの.claude配下やhooks、.mcp.jsonが無防備に走りうるので、CIや自動化では--bareで自動読み込みを止めるのが安全です。MCPサーバーはAnthropicがセキュリティ監査していないので、自作か信頼できる提供元に限定します。 - Devin：前述のとおり外部コンテンツ接触時の流出が報告されているので、危険な入力源はタスクから外す、MCPは信頼先に限る、が基本です。
③ 外部送信チャネルを断つ
最後の砦です。たとえ①②を突破されても、外に出る道がなければ流出しません。
-
Claude Code：
curlやwgetは既定で自動承認されません（Manualモードでは確認が入る）。/sandboxでファイルシステムとネットワークを隔離でき、コマンド文字列に依存しないネットワーク強制が効きます。クラウド実行はネットワークが既定で制限され、許可ドメインだけに絞れます。 - Devin：AutonomousモードはOSレベルのサンドボックス（macOSのseatbelt、Linuxのbwrap+seccomp相当）でshellを隔離したうえで自動承認します。「curlが任意のサーバーに届かないようサンドボックスする」ことが、まさに推奨される防御です。
いちばん危ないのは「無人実行」
最後に強調したいのは、人の承認を外した瞬間にリスクが跳ね上がるという点です。間接プロンプトインジェクションの最後の歯止めは、しばしば「人が実行前に止める」ことだからです。
- Claude Codeの
--dangerously-skip-permissions、Devinの Bypass のような「全部自動承認」は、trifectaの③を開けっ放しにします。 -
claude -pは前述のとおりtrust確認を出さないので、untrustedなリポジトリをそのまま走らせると危険です。 - Kafkaやcronでイベント駆動に無人で回す構成（別記事で扱いました）は便利ですが、ここに注入耐性の設計が要ります。
無人で回すなら、サンドボックス必須・ネットワーク許可制・機密は原則渡さない・副作用操作だけは人の承認を残すを初期値にするのが現実的です。組織としては、Devinなら管理者がTeam Settingsで deny/ask を敷くと個人設定で上書きできないので、ガードレールを中央で固められます。Claude Codeも managed settings で組織標準を強制できます。
実践チェックリスト
最後に、trifectaの3脚で整理した実務の初期値です。
| 脚 | やること |
|---|---|
| ① 機密を絞る | 秘密はVault/プロキシ経由にしてエージェントの手の届かない場所へ。.env は deny。鍵を環境変数で直接渡さない |
| ② 入力を疑う | Issue/PR/Web/MCP出力/リポジトリ内ファイルは「指示入り」前提。信頼できないMCPを足さない。CI/自動化は --bare 相当で最小化 |
| ③ 送信を断つ | サンドボックスでネットワーク隔離＋許可ドメイン制。curl/wgetを野放しにしない |
| 全体 | 副作用（発注・外部送信・破壊的操作）には人の承認を残す。組織ポリシー（deny/ask）とログ・監査を併用 |
おわりに
AIコーディングエージェントのセキュリティは、新しい呪文を覚える話ではなく、「機密・未信頼入力・外部送信の3つを同時に握らせない」という一点に尽きます。2026年に表に出た実被害は、どれもこの3つが揃ったときに起きていました。Claude CodeもDevinも、3本の脚を切るための道具（権限モード、サンドボックス、Vault、ネットワーク制限、組織ポリシー）を持っています。あとは、便利さと引き換えにどれかを開けっ放しにしていないかを、自分の構成で点検するだけです。
特に、エージェントを自動・無人で回し始めるときは、人の承認という最後の歯止めが外れます。そこに「どの脚を、何で断っているか」を一度紙に書き出しておくと、事故の芽をかなり減らせます。次は、この観点でClaude CodeとDevinを実際に意地悪なプロンプトで突いてみて、どこまで踏みとどまるかを確かめてみたいところです。
参考リンク
- Claude Code Security（公式ドキュメント）（権限モード・プロンプトインジェクション対策・MCP・クラウド実行の資格情報保護）
- Claude Code - Sandboxing / Permissions（公式）（FS・ネットワーク隔離、workspace trust）
- Devin CLI - Permissions（公式ドキュメント）（Autonomous/OSレベルサンドボックス、deny/ask）
- CISO's guide to agentic AI（Anthropic）（エージェント導入のセキュリティ評価フレーム）
- The lethal trifecta for AI agents（Simon Willison）（3条件の原典的な整理）