top of page

AnthropicのAIエージェント侵害主張、クローズド開発のセキュリティを問い直す

15 時間前
読了時間: 18分

Cathedralが、AIエージェントによって12時間未満でAnthropicの業務システムへの経路を見つけたと主張したことを受け、Anthropicには疑問が向けられている。このAnthropic AIエージェント侵害主張は、社内Slackの議論へのアクセスが報じられたことを含め、同社に接続された外部ソフトウェアに関するものだ。Anthropicは限定的な業務システムへのアクセスを認めている一方、研究者はClaudeの会話、ソースコード、あるいはモデルの基盤となる数値パラメータであるモデル重みには到達していないとしている。

Hugging Face CEOのClément Delangueによるものとされる反応は、密室で開発されるAIへの信頼に対する試練としてこの出来事を位置付けている。ただし、この分析では彼の特定の投稿を独自に認証できなかった。そのため、基礎となるセキュリティ報道が実質的な議論を支えているとしても、彼の立場として責任をもって提示できる内容には限界がある。

中心的な緊張関係は、AIモデルへのアクセスを統制することと、そのモデルを開発する組織を保護することの間にある。これらの責務は重なり合うが、必要となる証拠は異なる。Hugging Faceは、自社のセキュリティ開示がオープン性によってインフラのリスクがなくなるわけではないことを示しているため、有用な比較対象となる。

Anthropic AIエージェント侵害主張が実際に示していること

報じられた侵入口は業務ソフトウェアであり、周辺組織がセキュリティ上の問題の中心となる。

Gadgets 360による業務システムへのアクセスの報道によれば、Cathedralは接続されたツールを通じてタスクを実行するソフトウェアであるAIエージェントを用い、第三者アプリケーションを調査した。これらはAnthropicが管理業務や営業活動に使用していたアプリケーションだった。

Cathedralは、会議の文字起こし、報酬・採用情報、先進モデルに関するSlackメッセージへの経路を説明したと報じられている。この作業はAnthropicの外部セキュリティテストプログラムを通じて実施された。この文脈は重要だ。開示プログラムの下でテストを行う研究者を、外部から攻撃を仕掛ける犯罪者として自動的に扱うべきではない。

Anthropicは、営業、人事、情報技術システムの一部へのアクセスを認めたと報じられている。同社は、露出した情報には業務上の連絡先と基本的なアカウント記録が含まれると述べた。また、顧客メッセージ、モデル応答、ソースコード、モデル重みにはアクセスされていないとしている。

これらの説明が示すのは、研究者がClaudeを盗んだことを示唆する見出しよりも限定的な話だ。一方で、取るに足らないウェブサイトの欠陥よりも重大な問題も示している。モデルの提供を担うシステムが報告された露出の範囲外にあったとしても、社内の業務記録は保護に値しうる。

アクセスと窃取の違いには、特に慎重な扱いが必要だ。情報への経路を見つけること、記録を閲覧すること、集まりをダウンロードすること、コピーを保持することは、それぞれ異なる行為を表す。責任ある評価には、影響を判断する前にどの行為が起きたかを確定する必要がある。

同じ注意はSlackにも当てはまる。モデルに関する議論を読むことは、モデル自体へのアクセスを示すものではない。逆に、モデルファイルにアクセスできないからといって、関連する議論が無害になるわけでもない。その機密性は、内容、参加者、運用上の重要性に左右される。

公開された時系列も慎重に扱う必要がある。Washington Postの最初の調査報道は10月26日に掲載され、退職した研究者をJacob Coxonと特定している。掲載日は侵入日として扱うべきではない。

こうした氏名の区別が重要なのは、報道が拡散するにつれて解説に誤りが蓄積しうるためだ。名前の誤りは繰り返されやすい。より重大な誤りには、報じられたアクセス経路を確認済みのデータ窃取へと変えてしまうことや、研究者の所要時間に関する主張を独立して計測されたベンチマークとして扱うことが含まれる。

したがって、読者にとっての当面の要点は明確だ。Cathedralは、接続された業務アプリケーションを通じたAI支援型のアクセスを報告した。Anthropicは保護されたカテゴリーを説明しつつ、限定的な露出を認めた。残る課題は、両社の外部にいる人々も評価できる証拠によって、その境界を明らかにすることだ。

Anthropicとそのベンダーは異なる問いに直面している

Anthropicは露出範囲を説明し、影響を受けたベンダーは自社ソフトウェアが報じられたアクセスをどのように許したのかを説明しなければならない。

この責任分担は重要だ。なぜなら、サプライヤーを非難することで、顧客側のアーキテクチャ上の判断が検証されないままになる可能性があるからだ。ベンダーがソフトウェアの欠陥を抱えていた可能性はある。しかし、そのソフトウェアが受け取る情報と権限を決めるのは、それを利用する組織でもある。

これは、Anthropicが何らかの設定を誤っていたことを示すものではない。公開報道だけでは、その問いに答えることはできない。むしろ、追加の証拠が最も有用となる領域、すなわち外部アプリケーションと、それが到達できた内部リソースとの関係を示している。

企業のワークスペースに接続された仮想的な会議サービスを考えてみよう。そのサービスは、本来の機能を果たすために選択された文字起こしへのアクセスを必要とする場合がある。無関係な会話まで取得できるかどうかは、権限、統合設計、その接続を囲む統制に左右される。

この例は、Cathedralが公表していない技術手法を説明するものではない。影響を受けたアプリケーションの名前が分かったとしても、それは問いの一部にしか答えない理由を示している。購入者は、そのアプリケーションが顧客環境内で持っていた権限も理解する必要がある。

企業が先進的なAIを開発している場合、この問題はより敏感になる。社内記録には、評価手法、製品計画、人員配置、研究上の判断に関する情報が含まれる場合がある。ここで証拠なく、これらのカテゴリーが露出したと想定すべきではない。

それでも、AI安全性の議論に組織のセキュリティが含まれるべき理由は、その潜在的な重要性によって説明できる。モデル配布を制限する能力だけでは、開発中に作成されるあらゆる文書を保護する能力を確立したことにはならない。

エンタープライズ顧客は別の不確実性に直面する。自らの情報が報じられた境界を越えたのか、また対応に何らかの措置が必要かを知る必要がある。モデルセキュリティに関する一般的な保証は、関係する具体的な記録への回答に置き換わるものではない。

従業員にも別個の利害がある。インシデントが顧客向けサービスに影響したかどうかにかかわらず、個人の雇用情報は保護に値する。Claudeユーザーだけに焦点を当てた対応では、その懸念への対処として不十分になる。

Cathedralの立場も精査に値する。Reutersは以前、同社の軍事サイバーセキュリティ事業が、Gavin KligerやLuke Farritorを含む元DOGEスタッフによって設立されたと報じた。その計画には、政府向けの攻撃・防御両面のサイバーセキュリティ業務が含まれていた。

この背景は、注目を集めるセキュリティ発見に商業的な文脈があることを示している。見込み顧客が、Cathedralの手法は他社が見逃すリスクを見つけ出すと信じるほど、同社に利益がある。このインセンティブは研究を無効にするものではないが、独立して評価可能な証拠を求める根拠を強める。

同じ基準はAnthropicの対応にも当てはまる。同社には、露出が封じ込められたと説明する利益がある。読者は、安心感を与える表現だけで十分と受け取るのではなく、開示された境界、裏付けとなる調査、是正の証拠を通じてその説明を評価すべきだ。

ここに、この出来事が現在圧力を生んでいる理由がある。各組織は説明の一部を管理している一方、顧客と従業員はそれらをつなぐ説明を必要としている。深刻さ全般をめぐる競合する主張よりも、一貫したインシデント報告の方が多くの不確実性を解消できる。

クローズド開発はセキュリティ境界を定めない

モデルを非公開に保つことは配布に対処するが、開発者を守るには組織全体の接続システムにわたる統制が必要となる。

Delangueによるものとされる反応は、この区別に注意を向けている。しかし、認証されていないソーシャル投稿から、彼の正確な主張や文言を確立することはできない。したがって、より広い命題は未確認の引用に依存するのではなく、それ自体の論理によって成り立つべきだ。

クローズド開発は、モデルファイルや未公開機能へのアクセスを誰に提供するかを制限できる。しかし、どの外部サービスが社内情報を処理するかを自動的に決めるものではない。これらは別個の判断であり、調達、エンジニアリング、セキュリティ、日常業務を通じて行われる。

Anthropic AIエージェント侵害主張は、こうした判断がどこで交わるかを問う重要性を浮き彫りにしている。企業が機密性の高い業務を集約するなら、その業務の安全性はモデルの公開方針だけに依存しない。通信と管理を扱うシステムにも依存する。

これは、オープン開発であれば報じられたアクセスを防げたことを示すものではない。モデル情報を公開しても、脆弱な業務アプリケーションは修復されない。また、透明性を高めても、外部サービスに付与される権限が自動的に減るわけではない。

Hugging Face自身の履歴は、単純化した議論に対する具体的な反証を示している。同社は2024年5月のSpacesセキュリティ開示で、アプリケーションホスティングプラットフォームに関わる不正アクセスを報告した。一部の保存されたシークレット、すなわちアプリケーションが使用する機密認証情報にアクセスされた可能性があるとみていた。

Hugging Faceは、影響を受けたトークンを失効させ、認証情報の更新を推奨したと説明している。また、認証情報管理の変更と、外部専門家を交えた調査も報告した。これらは、モデルのオープン性をめぐる大きな議論とは独立した、インフラ問題に対する運用上の対応だった。

この比較は重要な限界を示している。オープンAIに関連する組織も、独自モデルを開発する組織も、接続されたインフラを保護するという課題に直面している。公開に関する理念によって、具体的な統制の必要性がなくなるわけではない。

したがって、有用な比較は観察可能な実践に関するものだ。外部アプリケーションはどの情報に到達できるのか。組織は予期しないアクセスをどのように検知するのか。どれほど迅速に権限を取り消せるのか。封じ込めに関する説明を支える証拠は何か。

これらの問いは、説明責任と露出の違いも明らかにする。企業は、認証情報や危険なエクスプロイトの詳細を公開せずに、統制に関する意味のある情報を公表できる。逆に、技術的な詳細を非公開にすることは、範囲や是正に関するあらゆる発見を非公開にすることを意味しない。

正当なトレードオフがある。詳細な開示は防御側による弱点の理解に役立つが、早すぎる公開は修復していない組織を危険にさらす可能性もある。しかし、過度の秘密主義は、影響を受ける人々が保証を評価することを妨げる。

適切な均衡は、脆弱性と是正状況に依存する。有用な公開説明は、判断を支える水準で何が起きたかを説明しつつ、不必要に悪用を可能にする詳細は伏せるべきだ。

これは、このインシデントをスローガンだけで決着する国民投票のように扱うべきではない理由である。証拠が示しているのは、業務用ソフトウェアを介したアクセスだ。オープンAIかクローズドAIかについてより広い結論を導くには、そのアクセスと開発モデルを結び付ける追加の論証が必要になる。

企業の購買担当者にとって、実務上の含意は直接的だ。機密保持の約束は、それを実装するシステムと関係性を通じて評価すべきである。企業が掲げる理念は目標を説明できるが、文書化された運用上の境界こそが、その目標が日常的なソフトウェアとの接点においてどう維持されるかを説明する。

報告された速度には、より明確なベンチマークが必要だ

短い経過時間は注目を集めるが、エージェントがどれほどの作業を独立して実行したかを示すものではない。

Cathedralが報告した所要時間は、この件を象徴する数字となっている。しかし、経過時間の主張には、明確な開始点、明確な終了点、そして投入されたリソースの説明が必要だ。こうした詳細がなければ、比較には不確実性が残る。

たとえば、計測対象の実行は、研究者が標的を選定し環境を準備した後に始まる場合がある。あるいは、その準備を含む場合もある。どちらの記述も特定の段階の所要時間を正確に伝えていたとしても、測定値は異なる。

終了点も同様に重要だ。アクセス経路の可能性を発見することは、読み取り可能な情報を確認すること、再現性を実証すること、あるいは開示を完了することとは異なる。ベンチマークでは、どのマイルストーンで計時を止めたのかを明示すべきである。

人間の関与も説明に含める必要がある。研究者は目標を定義し、発見事項をレビューし、有望な経路を選び、ツールが失敗した際に介入することがある。こうした活動がAI支援を無意味にするわけではない。ただし、それによって結果が独立した能力について何を示すのかは変わる。

現時点で入手可能な報道では、その作業分担を算出するのに十分な情報は示されていない。したがって、自律システムが意味のあるすべての工程を独力で完了したと述べるのは時期尚早である。同時に、エージェントを付随的な存在として退けるのも時期尚早だ。

有用な技術評価は、エージェントの行動を検証済みの発見と結び付けるだろう。提案と成功した操作を区別し、どこで人間の判断が結果に影響したのかを特定するはずだ。そうすれば、実用的なエクスプロイトを公開せずとも、読者は再現性を評価できる。

また、信頼できる生産性の倍率を割り当てる根拠もない。この種の比較には、同等の人間の専門性、標的に関する知識、時間、アクセスを含む意味のあるベースラインが必要となる。劇的な所要時間だけでは、こうした統制条件を満たせない。

Anthropic自身の脆弱性調整ポリシーは、関連する文脈を提供している。同社によれば、脆弱性報告は一般に、人間のセキュリティ研究者がレビューし確認した発見に基づくものだ。同ポリシーでは、影響を受けるソフトウェア保守者との開示調整についても説明されている。

このポリシーはAnthropicによる対外的な研究プロセスを説明するものであり、Cathedralの作業を独立して検証したものではない。この違いは重要だ。それでも、有用な期待値を示している。AIが生成した発見は、広範な主張を支える前に、具体的でレビュー済みの証拠へと転換されるべきである。

したがって、AnthropicのAIエージェント侵害に関する主張は、性能測定が未解決のまま残る、報告されたセキュリティ上の結果として理解するのが最善だ。AI支援の潜在的重要性は依然として大きいが、その正確な寄与を把握するには、さらに文書化が必要である。

防御側にとって、この不確実性が運用上の問いを消し去るわけではない。研究者が自動化ツールを使って接続済みアプリケーションを調査できるなら、組織はどの接続が機密情報を露出させるのかを把握する必要がある。この問いは、自動化の水準が異なっても重要であり続ける。

セキュリティベンダーにとっても、求められる基準は同じく実践的であるべきだ。経路を実証し、証拠を説明し、測定を定義する。人間の研究者を代替できるという主張は、その記録から導かれるべきであり、それに先行すべきではない。

このアプローチは、報告された速度に適切な重みを与える。それは、より良い技術的説明を求める理由にはなる。しかし、それ自体でエージェント能力の完全な尺度や、組織全体の防御に対する判定となるわけではない。

限定的な露出であっても、説明責任ある対応が必要だ

モデル窃取が報告されていないことはインシデントの範囲を狭めるが、アクセス可能だった情報に関する疑問を解決するものではない。

有用な対応は、影響を受けた人々が行動できる言葉でインシデントを説明すべきだ。そのためには、関連する情報カテゴリを特定し、アクセス境界を説明し、何がなお調査中かを述べる必要がある。こうした詳細がなければ、包括的な安心表明の価値は限られる。

企業側の立場も、同社が明示した限界の範囲で評価すべきである。研究者がモデルの重みにアクセスしなかったという説明は、重要な問いに答えている。しかし、それは他のすべてのカテゴリが影響を受けなかったことも、従業員やビジネスパートナーに影響が及ばないことも立証しない。

逆に、機密性の高い社内議論に関する説明から、研究者が実行可能なモデルや開発システムに対する無制限の制御を得たと示唆すべきでもない。これらは別個の主張だ。それらを混同すれば、公的記録が裏付ける範囲を誇張することになる。

報道には規模に関する疑問も残る。情報のカテゴリだけでは、影響を受けたレコードや人の数は分からない。読者は、可能性のあるデータ種別の一覧を、露出の完全な目録として扱わないようにすべきである。

適切な懸念の水準は、一部には内容によって決まる。会議の文字起こしには、通常のスケジュール調整が含まれることもあれば、機密の戦略的決定が含まれることもある。実際に何へアクセスできたかを知らずに、両者に同じ影響を割り当てることは、責任ある分析とはいえない。

認可はさらに別の層を加える。Anthropicの責任ある開示ポリシーは、脆弱性研究と報告に対する期待を定めている。開示プログラムはテストの枠組みを提供するが、あらゆる可能な行為を自動的に許容するものではない。

同時に、プログラムの規則は、根底にある弱点が重要かどうかを決めるものでもない。研究者の行為をめぐる論争と、技術的な露出の評価は、異なる問いに答えるものだ。どちらも調査に値し得るが、いずれかが他方の代替となるべきではない。

この区別は、非生産的な議論を避けるのに役立つ。防御側は、手続き上の意見の相違を脆弱性の隠蔽に利用すべきではない。研究者も、脆弱性の深刻さを自らの行為の説明を避ける理由にすべきではない。

参加者には異なる責任とインセンティブがあるため、独立したレビューには価値がある。レビュアーは、機密記録を公開せずに、証拠、アクセス制限、修復措置を評価できる。とはいえ、レビューの範囲とアクセス権限も開示する必要がある。

同じ原則は、より広範な国家安全保障上の影響に関する主張にも当てはまる。別の主体が類似の弱点を悪用できる可能性は、検討に値する。しかし、それは本件でそうした悪用が起きたことを立証するものではない。

ナレッジワーカーにとっても、この問題は最先端モデルという枠組みが示唆するより日常業務に近い。チームは日常的に、コミュニケーション、文書、検索サービスを接続している。接続のたびに、どの情報がどの権限を通じて到達可能になるのかという問いが生じる。

検索可能なナレッジベースは、社内資料をより使いやすくできる。それに伴う責任は、特に情報がサービス間を移動したり、追加のツールを通じて利用可能になったりする場合に、アクセス境界を理解することにある。

これは一般的な含意であり、特定のナレッジ製品がこのインシデントを引き起こした証拠ではない。関連する教訓は、情報の移動に関するものだ。組織は、機密資料がどこへ移動し、その途中で誰が取得できるのかを把握する必要がある。

3つの開示が、このインシデントの意味を決める

次に重要となる展開は、技術的説明、ベンダーによる修復の証拠、そして露出に関するより明確な説明である。

第一に、Cathedralによる最終報告書、またはその発見について独立したレビューを受けた説明に注目すべきだ。最も有用な文書は、アクセス経路、研究条件、計測の境界、人間の関与を説明するものだろう。実証されたアクセスと推測された可能性を区別すべきである。

限定的な介入で再現可能な結果を記録していれば、その開示はAI支援による攻撃能力についての議論を強める。結果が準備や手作業による指示に大きく依存していたなら、包括的な自律性の主張は弱まる。どちらの結果でも、理解は深まる。

この報告書が有用であるために、機密記録を露出させる必要はない。慎重に選定された証拠と独立した検証により、基礎となる情報を配布せずとも結論を裏付けられる。信頼できる説明では、レビュアーが実際に確認した主張を明確にすべきだ。

第二に、影響を受けたソフトウェアベンダーからの情報に注目すべきである。その説明は、問題が製品の欠陥、顧客固有の設定、統合における権限、あるいはそれらの組み合わせに関係していたのかを判断する助けとなる。これらの可能性は、他の組織にとって異なる意味を持つ。

共有ソフトウェアに影響する文書化された欠陥は、顧客全体にわたるより広い露出の根拠を強める。限定的かつ特定の設定に関する証拠であれば、その結論は制限される。いずれの発見も、Anthropic自身の対応を評価する必要性をなくすものではない。

ベンダーによる修復では、ソフトウェアの修正とアクセスの削減も区別すべきである。これらの行為は関連するが異なるリスクに対処する。パッチは不要な権限を残したまま欠陥を修正する可能性があり、権限を削減すれば、根本的な製品を修正せずに露出を制限できる。

第三に、影響を受けた情報と封じ込めに関するAnthropicの更新された説明に注目すべきだ。顧客と従業員には、誰が影響を受けたのか、どのカテゴリが関与したのか、何らかの対応が必要かどうかについて、より明確な説明が必要である。意味のある不確実性は、明示されたままでなければならない。

業務システムの周囲に独立して裏付けられた境界があれば、この事象に関するより限定的な解釈を強化することになる。その境界を超えたアクセスの証拠があれば、解釈を見直す必要がある。評価は最初の見出しに固執するのではなく、発見に従うべきだ。

これらの開示は、Delangueに帰される反応を見通しよく捉えることにもつながる。非公開の場での自信に対する批判はガバナンス上の問いを提起するが、その問いを解決するには、統制と説明責任に関する証拠が必要である。公開モデルだけでは答えられない。

現時点で得られる最も強い結論は、運用上のものだ。AI開発企業のセキュリティは、その業務を支える一般的なソフトウェアにも部分的に依存している。先進的なモデルの安全性に関する主張は、社内コミュニケーション、従業員情報、取引関係を扱うシステムと併せて検証に値する。

AnthropicのAIエージェント侵害に関する主張を、クローズド開発かオープン開発かの判決として扱う前に、意思決定を変える証拠を追うべきだ。最終的な技術報告書、ベンダーの修復に関する声明、Anthropicの露出評価を確認する。それぞれの文書が範囲を説明し、限界を認めているかを問う。チームが社内文書、メッセージング、検索サービスを接続しているなら、このインシデントを、そうした接続を通じて誰が情報を取得できるかを検証する契機にしてほしい。報告されたアクセスを、盗まれたモデルや独立したエージェント能力に関する仮定と切り離して考える。次に問うべき有用な問いは具体的だ。接続済みアプリケーションが失敗したとき、どの情報がなお保護され、どの証拠がその境界を裏付けるのか。

 
 

無料で始めましょう

ローカルファーストのパーソナル知識管理付きAIアシスタント

より良いAI体験のために、

remio は現在、 Windows 10+ (x64)とM-Chip Mac のみをサポートしています。

仕事のAIパートナー
remioでもっと仕事が進む

計画・作成・仕上げまで
すべてをひとつに

bottom of page