CodeWall、企業セキュリティ向け自律型攻撃エージェントの開発に向け400万ドルのプレシード資金を調達

セキュリティチームが脆弱性にパッチを適用しても、攻撃者が同じデータにたどり着く別の経路が残ることがある。より難しいのは、アプリケーション、ID、インフラにまたがる弱点を組み合わせ、実際に侵入可能な経路を構築できるかどうかだ。

CodeWallは、この問いに継続的に答えることを事業の柱に据えている。ロンドンのスタートアップである同社は、10月14日の発表によると、Osney Capitalが主導し、InReach Ventures、Antler、エンジェル投資家が参加した400万ドルのプレシード資金調達とともに、ステルス状態を脱した。

同社は、認証情報やソースコード、内部アクセスを必要とせず、外部から企業に接近する自律型攻撃エージェントを開発している。悪意ある攻撃者に悪用される前に、悪用可能な経路を発見して検証するための継続的な手段を防御側に提供することを目指している。

弱点の一覧から、攻撃経路を裏付ける証拠へ

CodeWallの技術構想の中心にあるのは、新たな証拠が得られるたびに調査を適応させることだ。同社は、攻撃側セキュリティの専門知識が限られていることや、評価が定期的にしか行われないことから、評価の合間にも変化する環境の検証に組織が苦慮していると指摘する。

同社の発表によると、専門分野に特化したエージェントが並行して調査し、継続的に維持される調査グラフを通じて発見内容を共有する。あるアプリケーションで得られた発見をもとに、次のエージェントが関連するサービス、ID、データストアを調べることができる。目指す成果物は、何が侵害され得るのか、その経路がどのように機能するのか、そしてその結論を裏付ける証拠を示す報告だ。

実際には、グラフは個々のアラートを独立した項目として扱うのではなく、発見事項間の関係を表す。個々の弱点よりも、それらのつながりのほうが重要な場合がある。ある境界での情報露出によって、別の制御に到達できるようになる可能性があるためだ。この説明はアーキテクチャ上の考え方を示すものだが、CodeWallは発表の中で、グラフが相反する発見をどのように解決するのか、また各段階の移行をどのように検証するのかを評価できるだけの実装詳細を明らかにしていない。

同社のウェブサイトによると、このプラットフォームはサービス、API、インフラ全体の信頼関係をマッピングし、調査中に戦略を適応させ、再現可能な概念実証の証拠を生成する。これらは製品に関する主張だ。企業にとっての価値は、その企業の環境で発見事項が再現可能かつ有意義なものであり続けるかどうかに左右される。

McKinseyに関する調査が示すこと

CodeWallは、大手コンサルティング会社が運営するプラットフォームの弱点を明らかにする調査をすでに公開している。3月9日に公開された、McKinseyのLilli AIプラットフォームをテストした際の報告は、AIアプリケーションを社内のナレッジと接続する企業にとって、とりわけ関連性が高い。

CodeWallによると、同社のエージェントは2時間未満で本番データベースへの読み取り・書き込みアクセスを取得した。同社は侵入の起点として、認証を必要としないインターフェースと、リクエストのフィールド名の処理方法に関わるSQLインジェクションの問題を挙げた。重要なのは、言語モデルそのものの不具合ではなく、アプリケーションの基盤となるデータや設定にアクセスできたことだった。

研究者らは、保存されたシステムプロンプトへの書き込みアクセスがもたらす影響についても論じた。アプリケーションのインフラを侵害すれば、信頼されるAI出力を制御する指示を書き換える経路が生じる可能性がある。これは報告書で述べられた潜在的な結果であり、コンサルタントが操作された助言を受けたことを示す証拠ではない。

CodeWallによると、同社は調査結果をMcKinseyに開示し、検証目的のアクセスを制限したうえで、公開前に修正を確認した。これらの詳細はベンダーによる調査報告に基づくものであり、脆弱性が現在も存在する証拠や、同社のエージェントが人間のテスターを上回ることを証明する一般的なベンチマークと受け取るべきではない。

継続的なテストが運用上の課題を変える

CodeWallによると、同社のプラットフォームは、アプリケーションの変更、新たな資産の出現、修正の導入に応じて、許可された範囲内でシステムを再検査する。これにより、経路を特定し、原因となる弱点に対処し、その経路が依然として機能するかをテストするという、有用なフィードバックループが生まれる可能性がある。

個別のチケットをクローズしても、当初のビジネスリスクが解消したとは限らないため、再テストは重要だ。修正によってある経路を遮断しても、別の経路が残ることがある。また、後続のデプロイによって以前の修正が取り消される可能性もある。

Unite.AIが以前取り上げた自律型ペネトレーションテストと修復に関する記事では、同じく検証を繰り返す方向への動きを探った。CodeWallが重視するのは、外部から調査を始め、相互につながったシステムを連携して調べることだ。同様の商業的目標を掲げていても、エージェントのアーキテクチャや実行制御まで同一とは限らない。

テストの頻度が高まるほど、運用上の境界を定める重要性も増す。このようなプラットフォームを評価する企業は、許可する対象と操作、証拠の取り扱いルール、エスカレーション手順、調査を停止できる仕組みを定めるべきだ。これらは評価基準であり、CodeWallの資金調達発表によって実証された機能ではない。

資金調達で開発するもの

創業者兼CEOのポール・プライス氏は、攻撃側のテストを恒常的な防御能力にする手段として、同社を位置づけている。CodeWallによると、すでに銀行や金融機関が悪用可能な攻撃経路を特定し、検証するのを支援している。ただし、今回の発表では、金融業界の顧客名や第三者によるパフォーマンス測定結果は明らかにされていない。

今回の資金は、エージェントが調査できる環境の拡大に加え、継続的なテスト、検証、修復のワークフローを支援する。同社はまた、ロンドンでオフェンシブセキュリティ、エンジニアリング、カスタマーサクセス、Go-to-Marketの各チームを拡大する計画だ。

導入を検討する企業にとって、重要な違いとなるのは、修復ワークフローがどこまで対応するかだ。証拠を提示して修正を提案することと、本番環境に自動で変更を加えることは異なる。今回の発表では、CodeWallが修正を独自にデプロイするかどうかは明らかにされていない。そのため企業は、承認と実行を誰が担うのかを確認する必要がある。

進捗を測るうえで最も重要なのは、そこから導かれるセキュリティ上の判断の質だ。具体的には、再現可能な攻撃経路、明確なビジネスへの影響、機密性の高い証拠の適切な取り扱い、そして修復によって脆弱な状態が解消されたことの確認が挙げられる。CodeWallは今回のプレシード資金調達により、この運用モデルの実現に向けた資金を得た。今後の課題は、継続的な敵対的テストを、企業の日常業務として定着させられるほど信頼性の高いものにすることだ。