~/.claude.json を悪用して通信を中継し、トークンを自分の環境に流し込めるSecurityWeekの記事が伝えているのは、Claude CodeのMCP連携を悪用して、OAuth tokenを盗み出せる可能性があるという話です。
まず前提から整理すると、Claude Codeは開発者向けのAIエージェント的なツールです。
ここでいう「agentic system」は、ただ質問に答えるだけではなく、外部ツールとつながって何かを実行するタイプのAIです。便利です。かなり便利。
でも、便利なものほどセキュリティ的には面倒で、動く範囲が広いぶん攻撃面も広がるのが定番です。
その接続の仕組みに使われるのが MCP（Model Context Protocol） です。
ざっくり言えば、AIが外部サービスやツールと会話するための“共通の接続口”みたいなものです。
問題は、ここで使う OAuth token。
これは「このユーザーとしてアクセスしてよい」という通行証のようなものです。
もしこれを盗まれたら、攻撃者はそのトークンを使って、接続されているSaaSツールにユーザー権限で入れてしまう。記事の表現を借りれば、master key に近い扱いです。これはかなり嫌な話です。
Mitiga Labsの研究によると、攻撃者はClaude Codeの設定ファイル ~/.claude.json を狙います。
ここにはMCPの設定とOAuth tokenが保存されているとのことです。
攻撃の流れは、ざっくりいうと次のような感じです。
~/.claude.json を編集し、MCPサーバーの接続先を攻撃者のプロキシに向けるこれ、すごく地味なんですが、だからこそ怖いです。
派手なマルウェアみたいに「感染しました！」と叫ぶのではなく、設定を書き換えて、いつもの通信に見せかけて盗む。
セキュリティの世界では、こういう「正規の動作に見せかけた悪用」がいちばん厄介だと思います。
Mitigaの指摘で面白いのは、単に盗むだけではなく、ユーザーが気づきにくいように再設定を維持する点です。
たとえば：
つまり攻撃者は、盗んで終わりではなく、設定を“居座りやすい形”で保つわけです。
これは本当にいやらしい。
単発の情報窃取ではなく、持続的な侵入経路を作ってしまうからです。
記事では、攻撃者が得る状態を次のように表現しています。
被害者のSaaS認証情報を、攻撃者が管理するインフラへ持続的にリダイレクトし、トークンローテーションにも自動で追従し、端末のUIからは見えず、提供元から見ても正規通信と区別できない
要するに、見えない・止まらない・バレにくいの三拍子です。これはかなり強い。
OAuth tokenは、パスワードそのものではありません。
でも、現実にはパスワード級、あるいはそれ以上に危ないことがあります。
理由は単純で、トークンがあれば：
記事では、これを “MFA-bypassing golden key” と呼んでいます。
MFAは多要素認証、つまりパスワード以外の確認を挟む仕組みですが、トークンが有効な状態だと、その確認を横からすり抜けられる場合がある。
ここは個人的にも重要だと思います。「MFAがあるから安心」は、連携トークンが漏れた瞬間に崩れることがあるからです。
記事で繰り返し強調されているのは、何も起きていないように見えることです。
つまり、ユーザー視点では「特に異常なし」に見えやすい。
これが本当に怖いところです。
セキュリティ事故は派手なアラートより、静かに正規業務へ溶け込む形のほうが長生きします。これは昔からそうですが、AIエージェントの時代になるとさらに目立つ気がします。
Mitigaは、対策として「何かが壊れてから対応する」のではなく、設定変更や異常な通信を監視すべきだと提案しています。
具体的には、次のようなポイントです。
Claude Code の設定変更MCP server URL の変更OAuth refresh の挙動の異常このあたりは、今後かなり重要になると思います。
AIエージェント系ツールは、**“何を見れば異常と判断するか”** がまだ成熟していません。
従来のEDRやログ監視だけでは、こういう「正規の設定操作に見える攻撃」を見落とす可能性があるからです。
Mitigaはこの件を 2026年4月10日 にAnthropicへ報告したものの、4月12日 に「out of scope」と返されたと記事は伝えています。
理由としては、以前の Adversaの “TrustFall” disclosure と同じく、
「ユーザーはすでに、そうしたことが起きうると同意している」という考え方が背景にあるようです。
ここはかなり議論を呼びそうです。
個人的には、**“同意していること”と“安全であること”は別問題**だと思います。
利用規約上の同意があるからといって、攻撃者が設定ファイルを書き換えてMCPをハイジャックできることまで正当化されるわけではないでしょう。
もちろん、最終的な責任分界はサービス設計次第ですが、少なくともユーザーにとっては「そんな前提で使えと言われても…」という感じです。
このニュースの本質は、単なるClaude Codeの穴というより、AIエージェントが“勝手に動く”ことのリスクだと思います。
AIが外部ツールと連携して仕事を進めるほど、
みたいな要素が絡み合い、攻撃者にとっての足場が増えます。
しかも、AIは「人間がいちいち操作しない」ことが前提なので、静かに乗っ取られても発見が遅れる。ここが厄介です。
私は、この手の話を見るたびに、AIエージェントは便利さの代償として“見えない権限管理”の難しさを爆増させるなと思います。
人間が直接操作するなら、変な挙動に気づきやすい。でも、AIが裏で何本もツールをつないでいると、もうログを丹念に追うしかない。かなりしんどい世界です。
今回のSecurityWeekの記事は、Claude CodeのMCP連携を悪用してOAuth tokenを盗む攻撃が成立しうることを伝えています。
しかもその手口は、ユーザーに見えにくく、設定を戻されても再感染のように復活する、かなり厄介なものです。
AIコーディング支援やagentic systemが広がるほど、私たちは「AIが何をできるか」だけでなく、「そのAIに渡した権限をどう守るか」を真剣に考えないといけない。
便利だからこそ、裏側の権限設計が主役になる。そんな時代に入ってきたのだと思います。
参考: Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking