エグゼクティブサマリー
その Silverfort 研究チームは、AnthropicがmacOS上でClaude Code CLIの認証情報を保存する方法に問題があることを発見しました。この方法では、ユーザー自身の権限で実行されているプロセスが、ユーザーのAnthropicアカウントの認証情報、ひいては接続されているMCPサーバーの認証情報を容易に盗み出すことができます。サイレント読み取りを一度行うだけで、認証情報全体が取得され、攻撃者は別のマシンからその認証情報を再生して、ユーザーになりすますことが可能です。
macOSのキーチェーンには、要求元のプロセスに秘密情報を渡す前に、ユーザーがパスワードまたは生体認証による確認を再入力する必要がある、適切なセキュアストレージメカニズムが備わっています。Claude Desktopはこれを正しく利用しています。別のプロセスが保存された認証情報にアクセスしようとすると、macOSはユーザーに再認証を促します。しかし、Claude Code CLIはそうではありません。ユーザーモードのプロセスであれば、再認証のプロンプトなしに認証情報を取得できるような実装になっており、このブログではその詳細について説明します。
これは厳密には脆弱性ではなく、実装設計上の欠陥、つまりセキュリティ上の弱点です。本来再認証が必要なはずの認証情報が再認証を必要としないという問題があります。この脆弱性を悪用するには、標準的な「ユーザーとしてコードを実行する」以上の高度な技術は必要なく、権限昇格よりもはるかに容易です。この設計上の欠陥は、Claude Code CLI を実行しているすべての macOS ユーザーに影響します (デスクトップ版および Windows/Linux CLI ユーザーは対象外です。これらのユーザーはファイルベースのストレージを使用しており、既存の AV/EDR ヒューリスティックによって改ざんが監視されているはずです)。
結果として、悪意のあるコードがユーザーのアカウントで実行されている場合、権限昇格やパスワード入力のプロンプト、アラートなしに、Claude の認証情報を静かに読み取り、MCP サーバーに横方向にアクセスできるようになります。macOS では、ファイルベースのストレージと比較してキーチェーンの方が優れた方法ですが、Claude Code CLI が再認証ステップをスキップするため、その利点は失われ、他のプラットフォームに存在するファイルアクセスヒューリスティックのように、既存のアンチウイルス ヒューリスティックではこれを監視していません。エンドポイントが乗っ取られた場合、攻撃者はユーザーの Anthropic アカウントと接続されているすべての MCP サーバーにアクセスし、それらのサーバーが制御するあらゆるもの、つまり GitHub の企業のコードベース、Atlassian のナレッジベース、またはその他の機密性の高い MCP コネクタに影響を与えることができます。
Silverfort 6月25日、責任ある情報開示の慣行に従い、HackerOne経由でAnthropicにこの発見を報告した。Anthropicはすぐに返信し、チームと話し合った結果、セキュリティ強化策としてキーチェーンアイテムのアクセス制御の強化を追跡しており、「多層防御の変更であり、実施する価値がある」と考えていることを確認した。Anthropicは異議を唱えなかった。 Silverfort 研究成果を発表する。
防御側へのガイダンス
この問題が解決されるまで、macOS上でClaude Code CLIを実行している組織は、異なるマシン間で同じトークンが使用されている場合は常にアラートを作成する必要があります。 従来の検出と対応に加え、組織は静的または一時的な認証情報の使用を制御し、同じトークンが2つの異なるマシンから使用された場合に警告を発するIDセキュリティプラットフォームを検討すべきです。これは、認証情報が盗まれたことを示す強力な指標となります。 セキュリティチームは、Claude Code CLIで使用されるキーチェーンエントリへの異常または予期しないプロセスアクセスを監視する必要があります。この認証情報ストアへの異常なアクセスパターンは、潜在的な侵害の重要な指標であり、調査のきっかけとして扱うべきです。
経歴
AI コーディング エージェントは現在、実際の認証情報を持っています。作業を行うために、マシンにログインしてトークンを保持し、 クロード・コードCLI も例外ではありません。Claudeを実行すると、OAuthバンドル（有効期限の短いアクセストークンと有効期限の長いリフレッシュトークン）を使用してサインインします。注意すべきはリフレッシュトークンです。誰かが取り消すまで新しいアクセストークンと交換できるため、一時的なセッションではありません。ラップトップ上に常駐するアカウントアクセスなのです。
OAuthバンドルがどこに保存されるかは、オペレーティングシステムによって異なります。3つのプラットフォームのうち2つ（LinuxとWindows）では、ディスク上の通常のファイルです。macOSでは、OSキーチェーンに保存されます。これは正しい考え方ですが、注意点があります。デフォルトでは、このアイテムは作成元のプログラムにロックされますが、macOSでは、どのプロセスでも実行できるセキュリティツールです。そのため、ロックは存在しますが、実際にはロックされず、アカウント内のどのプロセスでも、ユーザーがパスワードを入力する追加のプロンプトなしにトークンを取得できます。
Claude Code CLI 認証情報を 3 つのプラットフォームすべてで追跡し、macOS の欠陥を詳しく調べ、盗まれたバンドルを再利用する低フットプリントのトリックを取り上げ、最後にすべての企業が尋ねるであろう質問で締めくくります。新しい クロードアプリゲートウェイ これを無関係にする？簡潔に言えば、答えはノーだ。
ファイルの中の秘密はもっと悪い響きだが、それはあなたが見ることができるものだ
Linux と Windows では、認証情報は OS キーストアを介さずにプレーンテキストの JSON ファイルに格納されます。これは一般的に脆弱なアプローチのように聞こえますが、ディスク上の認証情報ファイルは、防御側が既に対処方法を知っている問題です。これは古典的な攻撃対象であり、アンチウイルスや EDR などのエンドポイントツールは、トークンが詰まったファイルにアクセスするプロセスを監視できます。制御を配置する場所が既知であり、警告を発する具体的な対象があります。macOS では、後述するように、この安全網はなくなります。
Claude Code CLIのドキュメントには、ファイルの保存場所が記載されています。
「Linuxでは、認証情報は
~/.claude/.credentials.jsonファイルモード0600で。「Windowsでは、資格情報は
%USERPROFILE%\.claude\.credentials.jsonまた、ユーザープロファイルディレクトリのアクセス制御を継承するため、デフォルトではファイルへのアクセスはユーザーアカウントに制限されます。
一つだけ問題があります。 CLAUDE_CONFIG_DIR このファイルは別の場所に移動されるため、リテラルパスをハードコーディングした検出ルールでは、これらのインストールを見逃してしまう。
そのファイルの中には、取得すべきすべての情報が含まれています。OAuth アクセス トークン (sk-ant-oat…)、有効期限の長いリフレッシュ トークン (sk-ant-ort…)、expiresAt タイムスタンプ、およびトークン スコープです。同じストアには、接続した MCP サーバーの OAuth トークンとプラグイン シークレットも格納されています。重要なのはリフレッシュ トークンです。リフレッシュ トークンを一度読み取るだけで、アカウントへの常時アクセス権限が付与されます。Linux および Windows では、以下の点に注意してください。
- ファイル整合性監視。
~/.claude/.credentials.json（とCLAUDE_CONFIG_DIRバリアント) を機密オブジェクトとして扱います。必要なアラートは、claude バイナリ以外のプロセスによる読み取りまたはオープンです。Linux では、auditd ウォッチ (auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_creds) または eBPF オープン テレメトリを使用します。Windows では、SACL を使用したオブジェクト アクセス監査 (イベント ID 4663) または EDR ファイル読み取りテレメトリを使用します。 - パーミッションのずれ。Linux ファイルはここに留まるべきです。
0600もしそれがグループや世界中の人が読める状態になったとしたら、それ自体が警告の兆候です。 - コンテンツ署名。sk-ant-oat（アクセス）とsk-ant-ort（更新）という接頭辞を、DLPおよびAVの認証情報インジケーターとして扱います。設定ディレクトリ外のファイル、アーカイブ、クリップボード、および送信トラフィックでこれらの接頭辞を検出してフラグを立てます。refresh-token接頭辞に一致するケースが最も深刻です。
- アイデンティティの観点から見てみましょう。最も確実なシグナルはエンドポイント上にはありません。あるホストで最初に出現し、その後別のホストから出現するトークンは、典型的な盗難の兆候です。ローカルでの読み取り後すぐに、同じOAuthセッションが新しいデバイス、場所、またはIPアドレスから出現していないか注意してください。このようなホスト間での再利用を検出するのが、アイデンティティ脅威対策プラットフォームの役割です。
付属ファイルを保管してください。 ~/.claude.jsonこれもあなたのレーダーに入っています。秘密のストアではありませんが、アカウントIDを保持しています（oauthAccount,userID）これは作業セッションのもう半分にあたる部分です。これについては次のセクションで詳しく説明します。
ロックしないロック：macOSのキーチェーンは良いアイデアだが、正しく実装されなければならない
macOS では、CLI が認証情報をキーチェーンに保持することで、このパターンが破られています。 .credentials.json ファイル。ドキュメントには明確に記載されています。
「macOSでは、認証情報は暗号化されたmacOSキーチェーンに保存されます。」
これは正しい直感です。暗号化され、OSによって保護されたストレージは、フラットファイルよりも常に優れています。しかし、キーチェーンアイテムの強度は、それに紐づけられたアクセス制御リスト（ACL）の強度に依存しており、まさにこの点でこのアイテムは弱点を抱えています。
Claude Code CLI は、以下のコマンドを実行して Keychain アイテムを作成します。 /usr/bin/security add-generic-passwordまた、アクセス制御引数は渡されません。特定のアプリケーションを信頼するための -T オプションも、任意のアプリケーションを許可する -A オプションもありません。そのため、この項目はキーチェーンのデフォルトのアクセス制御リスト (ACL) を継承します。macOS の security(1) マニュアルページには、このデフォルトの動作が詳しく説明されています。
「デフォルトでは、アイテムを作成するアプリケーションは、警告なしにそのデータにアクセスすることが許可されています。空のアプリパス名を明示的に指定することで、このデフォルトのアクセス権限を削除できます: -T “”」
このコードパスでは、アイテムを作成するアプリケーションは /usr/bin/security それ自体。つまり、アイテムに記録されている信頼できるリーダーは /usr/bin/security座って apple-toolmacOSがApple独自の署名付きツール用に予約しているパーティション。このデフォルト設定こそが問題の根源です。 /usr/bin/security は汎用的な Apple 署名付きコマンドラインツールであり、アカウントで実行されているプロセスは特別な権限なしで呼び出すことができます。唯一の信頼できる読み取り者が である ACL は、 security ツールは、 security これは、マシン上のすべてのプロセスを意味します。ACLは、どのプログラムが秘密情報を読み取れるかを制御することを目的としています。しかし実際には、どのプログラムでも標準バイナリに読み取りを依頼することで読み取ることができるため、ACLは何も制御できません。
結果として、一行だけの無音の読み上げ画面が実現しました。
security find-generic-password -s "Claude Code-credentials" -a "$USER" -w
Touch IDも、ログインパスワードの入力も、権限昇格も必要ありません。アクセストークン、有効期限の長いリフレッシュトークン、およびそのアイテムを共有するMCPまたはプラグインのシークレットを含む、完全な認証情報JSONが返されます。
Anthropicは既にClaude Desktopでこれをうまく実現しているのだから、Claude Code CLIでも同じようにできないだろうか？
これがmacOSの制限ではなく実装上の選択であることを示す最も明確な証拠は、AnthropicがClaude Desktopで既に正しく実装している点です。Claude Desktopは同じオペレーティングシステム上で同じユーザーに対して動作し、同じ種類の秘密情報を保護します。これはElectron safeStorageを使用して実現されており、CLIとは異なる設計になっているため、その詳細を説明する価値があります。 safeStorage 暗号化キーはキーチェーンに保持され、実際のトークンは暗号化されたテキストとしてディスク上のファイルに保存されます。Electronのドキュメントには、そのキーがどのように保護されているかが記載されています。
「暗号化キーは、ユーザーの許可なしに他のアプリケーションが読み込むことができないように、キーチェーンアクセスに保存されます。」
そのキーを保持するキーチェーン項目には、署名済みのClaudeアプリのみがACLに登録されており、そのパーティションはAnthropicの開発者チームに固定されているため、セキュリティ読み取りは それ以外の場合はログインパスワードの入力を求められますディスク上の暗号文は鍵がなければ役に立たず、鍵もその指示がなければ出てきません。
2つの設計は似ているように見えますが、動作は大きく異なります。CLIはトークンをキーチェーンに保存し、ACLによってどのプロセスでもトークンを読み取ることができます。一方、Claude Desktopはキーチェーンにキーのみを保存し、そのキーを独自の署名にバインドし、暗号化されたトークンはそれ自体では役に立たないファイルに保存します。同じオペレーティングシステム、同じユーザー、同じ種類の秘密情報であっても、一方はどのプロセスでもサイレントに読み取ることができますが、もう一方はユーザーの承認が必要です。違いは、キーチェーン項目の作成方法と、それが保護する対象にあります。
根本的な原因： CLI ハンドアイテム作成 /usr/bin/security Claude Desktopに既に搭載されているパターンである、ネイティブのKeychain Services APIを使用してアイテムをClaudeバイナリ自身のコード署名にバインドするのではなく、セキュリティツールはアイテムを呼び出し元のプログラムにバインドできません。バインドできるのはネイティブAPIのみです。脆弱性の観点から言えば、これはCWE-732（重要なリソースに対する不適切なアクセス許可の割り当て）およびCWE-522（不十分な保護の認証情報）に該当します。
設定ファイルを一切変更せずにセッションを再構築する
トークンを読み取ることは、なりすましの半分にすぎません。被害者として行動するには、Claude Code CLI は誰がログインしているかを知る必要があり、それは通常、 oauthAccount ブロック内部 ~/.claude.json当然の選択肢は、そのファイルも盗むことだ。しかし、痕跡をはるかに少なく残す、より巧妙な方法がある。そして、その方法が有効である理由に関する明白な説明は間違っているため、その方法を詳しく見ていく価値がある。
攻撃者のマシン上のレシピ：
1. 盗んだアクセストークンをエクスポートし、claudeを一度実行します。
export ANTHROPIC_API_KEY=<access-token>
claude
2. 終了してから unset ANTHROPIC_API_KEY.
3. 盗んだ荷物をすべて自分のキーホルダーに隠す：
security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'
4.走る claude もう一度。あなたは被害者としてログインしました。
ここからが直感に反する部分です。環境変数はログインに使われるものではありません。 sk-ant-oat… Claude Code CLIの認証優先順位に関するドキュメントによると、ANTHROPIC_API_KEYに設定された値はX-Api-Keyヘッダーとして送信されます。しかし、これは間違ったヘッダーであり、トークンの種類も間違っています。なぜなら、OAuthアクセストークンはコンソールAPIキーではないからです。OAuthアクセストークンはモデル呼び出しを認証するものではありません。
では、エクスポートは何のために行うのでしょうか？重要なのは操作の順序です。盗まれたアクセストークンをエクスポートした最初の実行は、被害者のアカウントIDを~/.claude.jsonに書き込むステップであり、攻撃者はそのファイルをコピーする必要がありません。次に、変数を解除し、リフレッシュトークンを含む完全なバンドルをキーチェーンに配置します。ドキュメントには次のように記載されています。 unset ANTHROPIC_API_KEY これは「サブスクリプションにフォールバックする」ための方法であり、最終実行ではまさにそのように動作します。サブスクリプション認証情報としてキーチェーンバンドルを使用して認証を行い、その有効期限の長いリフレッシュトークンによって新しいアクセストークンが継続的に生成されます。この認証情報はリストの中で最も優先順位が低く、同時に最も耐久性の高いものです。
防御側がなぜこの方法に関心を持つべきなのか？それは、この方法の最大のポイントがフットプリントの小ささにあるからです。キーチェーンを一度静かに読み取るだけで、複数ファイルの取得に代わる処理となり、ソースマシンにコピーされるファイル数が少ないほど、データ流出検出の指標も少なくなります。macOSでは、そもそもファイルが存在しないため、ファイルイベントを待つことすらできません。読み取りはプロセス内で行われるため、監視すべきはプロセスそのものです。
チェーン全体、最初から最後まで
両者を組み合わせれば、攻撃は短時間で完了する。被害者側では、すべてが通常のユーザーとして実行され、プロンプトも権限も発生しない。攻撃者側では、単なるリプレイが行われるだけだ。
以下は、概念実証として、同じ処理フローを最初から最後まで実行した例です。
Claudeアプリゲートウェイを使えば、この問題は解決するのではないでしょうか？
簡潔に言うと、いいえ。ゲートウェイを設置し、独自のClaude Codeをそのゲートウェイに向けて、全く同じ窃盗攻撃を実行しました。それでも成功しました。
ゲートウェイが何であるかを正確に理解しておくことが重要です。なぜなら、その名前が示唆するよりも、ゲートウェイはより限定的な機能を持つからです。これは、通常の Claude 設定をラップするセキュリティ レイヤーではありません。ルーティング ツールであり、Claude Code を、組織が実行または選択した特定のモデル エンドポイントに向けるための手段です。これは、Anthropic のデフォルト パス (オンプレミス、Microsoft Foundry、Amazon Bedrock、Google Cloud、または組織独自の Anthropic エンドポイント) とは異なる場所です。私たちが確認した理由は、データ レジデンシーとコンプライアンス ルール、優先クラウド ベンダー、またはローカル展開など、よくある理由でした。もしあなたの組織がこれに該当しない場合、ゲートウェイは設定の一部ではなく、Keychain アイテムは、この投稿の残りの部分で説明されているとおりに公開されます。
ゲートウェイがもたらすメリットを問うのは当然です。なぜなら、何もないわけではないからです。開発者は企業のSSOでサインインし、セッションは約1時間継続します。失効はIdP経由で行われるため、組織がユーザーを無効にすると、そのユーザーのゲートウェイアクセスはセッション内で無効になります。アップストリームキー、つまりClaude APIキーまたはクラウド認証情報はラップトップ上に保存されません。これが、発表で述べられている意味です。
「開発者のマシンには、長きにわたって秘密が隠されていることはない。」
その行は文字通りに読むことが重要です。なぜなら、それは盗難ではなく、上流の鍵に関するものだからです。ゲートウェイのキーチェーンに残っているのは、更新認証情報です。ゲートウェイのみがそれを受け入れるようにスコープが設定されているかもしれませんが、そこに落とし穴があります。攻撃者がそれを盗み出し、ユーザーとしてゲートウェイに接続すれば、そのアカウントが有効である限り、新しいセッションを生成し続けることができます。1時間のセッションでは、泥棒を拘束することはできません。彼らを阻止できる唯一の方法は、組織がそれに気づいてユーザーを無効にすることですが、キーチェーンのサイレント読み取りでは、それが起こることはありません。「長期間有効な秘密情報なし」は、アイテムを読み取った者にとって、いつの間にか長期間有効なアクセス権になってしまいます。
そこで、ゲートウェイを設定し、クロードをそれに接続して、前のセクションで説明した攻撃を繰り返しました。キーチェーンの読み取り結果は変わりませんでした。同じ1行のPythonスクリプトで認証情報をプロンプトなしで取得し、それを別のマシンにコピーしました。
今回は、前のセクションで説明したような追加のブートストラップ処理も、被害者から2つ目のファイルを入手する必要もありませんでした。ゲートウェイのアドレスは、すでに盗んだ認証情報の中に含まれています。Claude Code-credentials Keychain項目に格納されている値には、トークンだけでなく、被害者がログインしていたゲートウェイの情報も記録されています。そのため、一度サイレント読み取りを行うだけで、鍵と、その鍵で開くゲートウェイのアドレスの両方を入手できます。
つまり、被害者のディスクから余分なデータを抽出する必要はありません。設定ファイルは攻撃者自身のマシン上に作成します。場所は以下です。
/Library/Application Support/ClaudeCode/managed-settings.json
そして、盗んだ認証情報から読み取ったゲートウェイURLにそれを向けます。
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
そのファイルを書き込むことは障壁にはなりません。Anthropic自体が管理設定を「セキュリティ境界ではなく、クライアント側の制御」と呼んでいるため、攻撃者は自由に独自の設定を作成できます。次に、盗んだ認証情報をロードしてClaude Codeを起動します。被害者のIDを再作成するための別の手順はありません。認証情報にはトークンが含まれており、トークンがゲートウェイに対して認証を行い、ゲートウェイは被害者のアクセス権でセッションを実行します。
ゲートウェイは、純粋なリモート攻撃者には乗り越えられない障害を一つ設けている。Claude Codeは、パブリックアドレス上のゲートウェイとは通信しない。
「/login では、Claude Code はゲートウェイのホスト名または IP アドレスがプライベート アドレス（RFC 1918、リンクローカル、CGNAT 100.64.0.0/10、IPv6 ULA fc00::/7、またはローカル開発用のループバック）にのみ解決されることを要求します。ホストするゲートウェイの場合、パブリック アドレスはすべて拒否されます。」
つまり、盗まれた認証情報は、プライベートゲートウェイにアクセスできる場所からしか機能しないということです。これは一見すると障壁のように思えますが、脅威モデルを思い出せば話は別です。攻撃者は被害者のマシン上でユーザーとして実行されていると想定されており、そのマシンはそもそもネットワーク内にあります。そこからプライベートアドレスに到達するのは簡単なことです。これは障壁ではなく、単なる摩擦に過ぎません。
正直な評価を述べましょう。ゲートウェイは他の理由で導入する価値があります。アップストリームキーをラップトップから隔離し、IdPを介して組織に中央キルスイッチを提供します。ただし、これは盗難に誰かが気付いた後にのみ有効です。しかし、この投稿で取り上げている脆弱性を解消することはできません。認証情報は依然として同じキーチェーン項目に保存され、その項目はプロンプトなしでどのプロセスでも読み取ることができ、盗まれた更新認証情報はアカウントが無効化されるまでゲートウェイに対して機能し続けます。
ネットワークチェックは迂回路であって、停止ではありません。そして、ゲートウェイに全く触れることのない大多数のユーザーにとっては、何も変わりません。
ディフェンダーはまず何をすべきか
- macOS: アイテムの ACL が Claude 署名にバインドされるまでは、検出ポイントはファイルではなくプロセスです。シグナルは /usr/bin/security find-generic-password 呼び出しで、サービス文字列は Claude Code-credentials であり、秘密情報を表示するための -w オプションが付きます。プロセス実行または Endpoint Security テレメトリでアラートを設定し、プロセス履歴を使用して誤検出を削減します。正当な読み取りは Claude バイナリに遡るため、まずそれらをベースライン化し、疑わしい読み取りはシェル ワンライナー、エディタまたは拡張機能ホスト、あるいは依存関係のインストール スクリプトから発生します。盗まれたバンドルが別のマシンに植えられる方法であるため、同じサービスについても add-generic-password を監視してください。これらのアラートは補償制御として扱います。
- LinuxおよびWindows：.credentials.jsonに対するファイル整合性監視とDLP、権限のずれに関するアラート、およびsk-ant-oatおよびsk-ant-ortプレフィックスに対するコンテンツ署名。
- あらゆる場所で、認証情報ストアの読み取りと予期しない送信トラフィックを関連付け、IDプレーンを監視して、同じトークンが複数のホストで再利用されていないかを確認します。疑わしい場合はローテーションを実行します。1回の読み取りで有効期限の長いリフレッシュトークンが渡されるため、信頼できる読み取りイベントが発生した場合は、エンドポイントをクリーンアップするだけでなく、/logout と再ログイン、さらにコンソールキーのローテーションが必要です。
- 真の解決策はAnthropic社にあり、リスクも低い。ネイティブAPIを介してCLIのキーチェーン項目を作成し、Claudeバイナリ自身のコード署名に紐付けるというものだ。これは既にClaude Desktopに搭載されているパターンである。
朗報は、難しい部分は既にAnthropicのコードベース内で解決済みであるということです。CLIは新たなセキュリティモデルを必要としません。既に隣で稼働しているセキュリティモデルを利用すれば良いのです。
情報開示のタイムライン
6月25日午後3時46分（UTC） 研究者は、再現手順、影響、および3枚のスクリーンショットを添えて報告書を提出する。
6月25日午後4時05分（UTC） Anthropicはわずか19分後にこれを情報提供としてクローズし、「Claude Codeの認証情報、構成、ログのローカルストレージ」の範囲外と判断し、同一ユーザープロセスは完全に信頼されているため、プロセスごとのキーチェーンACLは意味のある境界を追加しないと述べています。
7月2日午前11時12分（UTC） 研究者は、人間の再評価を要求し、クローズが誤った除外にマッピングされたと主張し（これはローカルストレージではなくキーチェーンACLの設定ミスであり、同じOS上のデスクトップでは正しく動作している）、概念実証（POC）ビデオを添付し、開示の調整を申し出るとともに、防御的な文書を作成する旨を通知した。
7月2日午前11時14分（UTC） アントロピック社は再評価の要請を受理し、社内で検討すると述べ、報告書は既に完成しているため公開での議論は問題ないことを確認し、事前に草案を見せてほしいと要請した。
7月22。 研究者は、Anthropicの要請に応じて、ブログの最終稿を出版前のレビューのために共有し、Claudeアプリのゲートウェイが欠陥を軽減するかどうかについての分析が新たに含まれたことを指摘した。
7月24。 Anthropicはレビューを完了し、事実関係に関する懸念事項や修正要求はなかったと報告し、記事の公開を承認しました。分類は変更されていません。同社は、Keychainアイテムのアクセス制御の強化を、多層防御の強化策として追跡しているものの、脅威モデル上は脆弱性とはみなしていないと付け加えています。
