Railwayのエンジニアが、競合のPrimcloudでAIエージェントをテストしたことを認めました。Primcloudの創業者は、このエージェントが顧客のシークレットの取得を試み、同社のネットワークをスキャンしたと主張しています。
クラウドプラットフォームを運営するRailwayのエンジニアが、競合のPrimcloudに対してAIエージェントを実行したことを認めました。Primcloudの創業者が、顧客のシークレットの取得や内部システムのスキャンが試みられたと報告したことを受けたものです。Primcloudによると、同社の防御策が試行を阻止し、顧客データへのアクセスはありませんでした。
Primcloudの創業者Josh Manders氏は11月3日、Railwayに公開で問いただし、シニアプロダクトエンジニアのJake Runzer氏が一連の活動の背後にいると名指ししました。Runzer氏はエージェントを実行したことの責任を認め、その目的を、類似のプラットフォームでのサインアップと自動テストだったと説明しています。
Railwayの共同創業者兼CEOのJake Cooper氏は当初、謝罪しました。その後の声明では、当該社員は業務時間外に個人としてこのツールを作成・運用しており、Railwayは社内で対応を取ったと述べています。
この説明により、今回の争点には重要な区別が加わりました。問題になっているのは、社員自身が認めた行為であり、会社が競合に対して指示した作戦の証拠ではありません。
Primcloud、他の顧客のシークレットへのアクセス試行を説明
Manders氏の説明によると、この活動は単にプラットフォームのサインアップ手順を試すにとどまらず、はるかに踏み込んだものでした。同氏は、アカウントのアプリケーションコンテナ内で利用できる認証情報が、他の顧客のものを含むプラットフォームのシークレットを要求するために使われたと述べています。
Manders氏によれば、エージェントはクラウドプロバイダーのメタデータエンドポイントへのアクセスも試みました。さらに、コンテナの認証情報でどこまでアクセスできるかを調べ、内部名を推測してデータベースやキャッシュを探索していました。クラウドのメタデータサービスは、十分な制限なくアクセスできる場合、一時的な認証情報を露出させるおそれがあります。
Manders氏は、15分間に約24のコマンドが実行され、そのうち2回は65,536個の内部ネットワークアドレスを対象にしたスキャンだったと説明しています。これは同氏が報告したアドレス数であり、稼働が確認されたホストや露出したサービスの数ではありません。同氏は、アプリケーションは実行されず、保護されたリソースへのアクセス試行は阻止されたと述べています。
これらの技術的な詳細は、現時点ではPrimcloud側の説明にとどまります。Runzer氏はエージェントを運用していたことを認めましたが、それはManders氏が述べたすべてのコマンド、標的、結果を裏付けるものではありません。
Railway、「ツールは個人プロジェクト」と説明
Manders氏への返信で、Runzer氏は、類似のプラットフォームでサインアップやテストのためにエージェントを走らせていたと述べました。悪意はなかったと否定し、踏み込みすぎていると気づいた時点でシステムを停止したと説明しています。
Cooper氏のその後の声明によれば、このツールはバグバウンティプログラムを通じてバグを見つけて報告するための個人用ツールでした。同氏は、当該社員が個人アカウントと個人のクレジットカードを使い、DeepSeekを動かすホスティングサービスを契約していたと述べています。
Cooper氏によると、ツールは外部の1社に対して1回だけ実行され、15分以内に停止されました。同氏は、Railwayはこの行為を容認しないとして、社員に対応したと述べましたが、具体的な内容は明らかにしていません。また、この行為はRailwayが承認した社内のセキュリティテストとは別物だとも強調しました。
ツールをバグバウンティプロジェクトと説明しても、Primcloudがテストを許可していたことにはなりません。公開された声明からは、エージェントがなぜそれぞれの行動を選んだのか、人間がどの程度実行を監督していたのかも分かりません。
責任は運用者にある
リクエストを受けた企業にとって、差し迫った懸念は、そのソフトウェアが自社の環境内で何をするかです。Acalvio社のCEOであるRam Varadarajan氏はHackread.comに寄せたコメントで、エージェントの意図を見分けることは防御の根拠として信頼できないと述べました。
StudySecurity
「不正なエージェントと呼ぶか、エージェントによるテストと呼ぶかにかかわらず、防御側が目にする挙動は同じです。環境内の何かが認証情報を収集し、ネットワークをマッピングしています。残念ながら、特に自律型エージェントの場合、AIの意図を確実に分類することはできません」
Varadarajan氏は、おとり用の認証情報や偽の内部資産を置けば、人間とエージェントのどちらが起動したかにかかわらず、正当なワークフローでは起こらないはずの活動を見つけやすくなると述べました。
Noma SecurityのCISO（最高情報 セキュリティ責任者）であるDiana Kelley氏は、自社の権限で動くエージェントの行動には、組織が引き続き責任を負うと指摘しました。インシデントの調査、影響を受けた組織への通知、再発防止策の導入も、その責任に含まれます。
「エージェントは、人が一つひとつの手順を指示しなくても動作できます。しかし、それを展開する人や組織の責任がなくなるわけではありません」
Railway、10月に自社の侵害を公表
今回の争いは、Railway自身で起きた別のセキュリティインシデントに続くものです。同社は10月21日の公表で、権限のない第三者が、暗号化された顧客の環境変数にアクセスし、一部の復号済み内容を取得した可能性があると説明しました。こうした変数には、APIキーやデータベースのパスワード、その他の認証情報が含まれることがあります。
翌日に公開された予備報告書は、内部システムへの不正アクセスがあったと説明し、一部の暗号化された環境変数が復号されたことを確認しました。Railwayは顧客に対し、10月21日より前に保存した機密性の高い認証情報をローテーションするよう勧めています。
報告書は、一部の環境変数が露出したワークスペースの割合を、最大で1.85%（約100,000ワークスペース）と見積もりました。Railwayによると、予防措置として認証情報の失効を求めた対象はそれより広く、失効通知を受け取ったからといって、その顧客のシークレットが侵害されたことになるわけではありません。
翻訳元: https://hackread.com/railway-engineer-run-ai-agents-rival-cloud-platform/
