Mindgard、AIセキュリティテスト拡大に向け3,000万ドルを調達

Mindgardは3,000万ドルのシリーズAを調達した。企業がモデルを機密データやツールに接続するなか、AIセキュリティスタートアップに新たな資金が投入される。今回の取引は2026年8月14日、Google Newsの報道を通じて明らかになった。これはMindgardの中核的な主張、すなわち従来型のセキュリティチェックでは稼働中のAIアプリケーションに存在するすべての脆弱性を明らかにできないという考えを試す明確な機会となる。

Series A reportによると、ラウンドを主導したのはAlbum VC。Karma Ventures、.406 Ventures、Atlantic Bridge、IQ Capital、Lakestarも参加した。Mindgardはそれ以前に、.406 Ventures主導による800万ドルの資金調達を2025年1月に発表している。

新たな資金調達は、AIセキュリティベンダーが企業の防御をどこに配置すべきかをめぐって競争するなかで実施された。一部の製品はプロンプトとモデル応答を監視する。モデルをスキャンしたり、アクセス方針を強制したり、攻撃をシミュレーションしてアプリケーション全体をテストしたりするものもある。

Mindgardは、アプリケーションレベルのセキュリティテストをこのスタックの標準的な一部にしたい考えだ。課題は、継続的なレッドチーミングが、顧客が再現・優先順位付け・修正できる知見を生み出すことを証明する点にある。

3,000万ドルのラウンドがMindgardへの期待を高める

Mindgardはもはや、限定的な研究プロジェクトとして資金提供を受けているわけではない。投資家は同社をエンタープライズ向けセキュリティプラットフォームとして支援している。

このラウンドが重要なのは、同社を取り巻く期待を広げるからだ。小規模なスタートアップであれば、技術検証、初期顧客、個別のセキュリティ評価に注力できる。この規模の資金を得た企業には、再現性ある営業、統合、サポート、測定可能な成果の構築も求められる。

Mindgardは自社プラットフォームを、AIシステムを発見し、攻撃に対してテストし、リスクを評価し、運用中に保護する手段として説明している。同社は、基盤モデルだけを唯一の対象として扱うのではなく、モデル、エージェント、AIアプリケーション全体に焦点を当てている。

この違いは、AIシステムが社内文書を取得し、外部ツールを呼び出し、記録を変更し、コードを生成できる場合に重要となる。モデルの弱点は、制限されたデモの中では無害かもしれない。しかし、アプリケーションが機密情報や運用システムへのアクセスを許可する場合、同じ弱点が深刻な問題になりうる。

新たな投資家には、すでに同社を知っていた複数の企業が加わる。.406 Ventures、Atlantic Bridge、IQ Capital、LakestarはMindgardのearlier financingにも名を連ねていた。再投資は継続的な確信を示唆するが、投資参加そのものが製品の有効性を独立して裏付けるものではない。

同社は今回のラウンドにおける評価額を公表していない。公開されている発表にも、売上高、顧客数、契約の伸び、継続的にテストを実施している顧客の割合は示されていない。

こうした情報の欠落は、外部から導ける結論を限定する。資金調達はMindgardの戦略に対する投資家需要を確認するものだ。しかし、企業が同プラットフォームをどの程度広く採用しているか、あるいはその発見がどれほどの頻度で修正完了につながっているかを示すものではない。

Mindgardの従来の拡大計画は、ボストンに経営陣を置き、ロンドンでエンジニアリング業務を継続しながら米国市場を重視するものだった。今回の資金調達は、その拡大への圧力をさらに高める。北米の企業はすでに、大手プラットフォームベンダーや専門のAIセキュリティ企業からセキュリティ製品を購入している。

そのためMindgardは、攻撃ライブラリへのアクセス以上の価値を売らなければならない。低優先度の発見でチームを圧倒せず、同社のテストが開発パイプライン、セキュリティ運用、ガバナンスプログラムに適合することを示す必要がある。

最も重要なのはラウンドの規模だけではない。それに伴う責任だ。Mindgardはいま、より大きな市場を目指すのに十分な支援を得ている。一方で、顧客がテスト結果をより安全なシステムへと結び付けるのに苦労した場合、言い訳の余地は以前より小さい。

Google Newsが今、AIセキュリティの資金調達を取り上げる理由

この資金調達がGoogle Newsに掲載されているのは、AIセキュリティが研究上の懸念から、企業の購買課題へと移行したためだ。

企業は生成AIを、サポートシステム、文書検索、ソフトウェア開発、分析、社内自動化に組み込んでいる。こうした導入では、確率的なモデルが、従来のセキュリティチームがすでに保護してきたシステムに接続される。

確率的モデルは、類似した入力に対しても異なる回答を生成しうる。また、信頼できないコンテンツを指示として解釈する可能性もある。こうした性質は、通常のソフトウェア欠陥にきれいには対応しない障害モードをもたらす。

プロンプトインジェクションはその一例だ。攻撃者は、AIアプリケーションが処理するコンテンツ内に悪意ある指示を埋め込む。モデルはその結果、開発者が意図したルールではなく、その指示に従う可能性がある。

ジェイルブレイクには別の目的がある。これはモデルの行動上の制約を回避し、提供者が防ごうとしたコンテンツを生成させようとするものだ。両者は重なり合う場合もあるが、異なる事業リスクを生み出す。

OWASPが維持するLLM risk listには、安全でない出力処理、過剰な自律性、機密情報の開示、その他のアプリケーションレベルの懸念も含まれる。これらのカテゴリーは、モデルが禁止された要求を拒否するかどうかという問題を超えている。

エージェント型システムは、この違いをより明確にする。通常のチャットボットは応答を生成する。エージェントはファイルを取得し、認証情報を使用し、コードを実行し、メッセージを送信し、業務記録を変更できる。

この能力により、誤解を招く出力は実際のアクションになりうる。侵害されたエージェントは、データを漏えいさせたり、誤ったツールを呼び出したり、ユーザーが意図した認可を超えて行動したりする可能性がある。

従来のセキュリティツールは、この環境でも引き続き重要だ。認証、アクセス制御、ソフトウェアコンポジション分析、エンドポイント保護、ネットワーク監視、安全な開発手法は、アプリケーションにAIが含まれるからといって時代遅れになるわけではない。

ただし、こうした制御だけでは、長い会話の中で、あるいは敵対的なコンテンツを読み込んだ後にモデルがどのように振る舞うかを、必ずしも説明できない。セキュリティチームには、導入前後にその挙動をテストする手段が必要だ。

このニーズがMindgardのような企業への関心を説明する。このカテゴリーは、馴染み深いアプリケーションセキュリティの取り組みと、馴染みの薄いモデルの挙動を結び付けることを約束する。

タイミングはガバナンス上の隔たりも反映している。多くの組織は、アプリケーションがAIポリシーに従っているかを検証するよりも速く、AIポリシーを公表できる。書面上の統制では、機密記録へのアクセスを禁止できるかもしれないが、ポリシー文書だけでは、その統制が攻撃に耐えられることを証明できない。

技術的なテストは、そのポリシーを観測可能な主張へと変える。チームはデータ抽出を試み、ツール選択を操作し、認可境界を検証し、アプリケーションの応答を記録できる。

Mindgardは、企業がこうした演習を継続的なセキュリティ業務として扱うようになると賭けている。Google Newsでの可視性は関心の高まりを反映するが、関心だけで永続的なカテゴリーは生まれない。購入者には、専門的なAIテストがリスク判断を変えるという証拠がなお必要だ。

アプリケーションテストがMindgardの主要な賭け

Mindgardの決定的な賭けは、セキュリティチームが分離されたモデルを評価して終えるのではなく、AIアプリケーション全体を攻撃すべきだという点にある。

同社はこのアプローチを、AI向けDynamic Application Security Testingと呼んでいる。動的テストは、モデルの挙動がプロンプト、検索システム、API、ツール、権限、ガードレールと相互作用する、実行中のアプリケーションを検査する。

Mindgardによると、同社はこれらのレイヤーにわたる敵対的テストを自動化している。プラットフォームは、プロンプトインジェクション、ジェイルブレイク、データ抽出、エージェント操作、その他の攻撃を、導入済みのAIシステムに対して試みる。

このアプローチは、馴染み深いセキュリティ原則に従うものだ。重大な障害はコンポーネント間の相互作用する箇所で生じることが多いため、アプリケーションは現実的な運用条件下で評価すべきである。

モデルはベンチマーク上で安全に見えても、周辺アプリケーションが機密コンテキストを露出させる場合がある。逆に、制限のないモデルであっても、非公開データにアクセスできず、重大な行動を実行できない場合には、事業リスクは限定的となりうる。

Mindgardは、分離されたジェイルブレイクの結果には、優先順位付けに必要な文脈が欠けることが多いと主張してきた。同社のapplication testing positionは、チームが成功した攻撃を実際のシステム、ユーザー、資産、事業上の結果に結び付けるべきだとしている。

この立場はMindgardにとって最も強い差別化要因を生む。同時に、運用上の負担ももたらす。

アプリケーション全体のテストには文脈が必要だ。テスターは、どのユーザーが存在するか、各ユーザーが何にアクセスできるか、どのアクションが重要か、攻撃の成功が何を意味するかを理解しなければならない。

汎用的な攻撃プロンプトはプロセスを始められるが、すべての組織の脅威モデルを説明することはできない。医療アシスタント、コーディングエージェント、金融ワークフロー、公開チャットボットには、それぞれ異なるテストが必要となる。

このため自動化は必要だが、それだけでは十分ではない。Mindgardは再利用可能な攻撃技術と顧客固有の設定を組み合わせなければならない。そうでなければ、セキュリティチームが修正の優先順位に変換できない、印象的なデモを生み出すリスクがある。

再現性も別の課題となる。AIシステムは、モデル提供者がサービスを更新したり、開発者がプロンプトを変更したり、検索コンテンツが変化したり、temperature設定が変動したりすると変化する。

一度成功した発見が、2回目のテストでは失敗することもある。それは元の結果が自動的に無意味になることを示すわけではないが、トリアージを複雑にする。

セキュリティチームには、攻撃経路を理解するための十分な証拠が必要だ。また、ログ、影響を受けたコンポーネント、前提条件、影響、推奨される統制も必要となる。

継続的なテストは、変化をまたいで挙動を観測するため役立つ可能性がある。ただし、あらゆる変動が新たなアラートになれば、継続的なスキャンもノイズを生み出しかねない。

有用な単位は、試みた攻撃の数ではない。チームが再現し、軽減できる重大な弱点の数である。

したがってMindgardは、攻撃の高度さと同じくらい、ワークフローの品質で競争している。技術的に巧妙なエクスプロイトであっても、チケット管理、開発、リスク管理のプロセスに組み込めなければ、企業にとっての価値は限られる。

同社のプラットフォーム戦略は、この要件を理解していることを示唆する。レッドチーミングを時折行うコンサルティング業務として提示するのではなく、統合と継続的なテストを推進している。

シリーズAにより、Mindgardはこうしたワークフローを開発する能力をさらに得た。同時に購入者には、自動化が発見の品質を下げずにテストコストを削減するという証拠を求める理由が生まれる。

本当の競争はテストと想定された安全性の間にある

Mindgardの主な競争相手は、特定のスタートアップ1社ではない。モデル提供者のセーフガードと既存の統制が十分な保護を提供するという想定だ。

エンタープライズアプリケーションは、モデル提供者、クラウド環境、IDシステム、開発フレームワークから保護機能を継承する。各レイヤーはリスクを低減できる。しかし、単独で導入全体を見通すことはできない。

モデル提供者は基盤モデルをテストできるが、顧客の検索システムに配置されるすべての文書を把握することはできない。また、開発者が追加するプラグイン、ツール、権限を完全に予測することもできない。

アプリケーションセキュリティスキャナーは、脆弱な依存関係や安全でないコードパターンを発見できる。だが、正当なツールを誤用するようエージェントを説得するマルチターンの会話を検出できない可能性がある。

ガバナンス・プラットフォームは、ポリシー、責任者、承認を記録できる。しかし、特定のアプリケーションが実際に機能するプロンプトインジェクション攻撃に耐えられることまでは証明できない。

Mindgardが掲げるのは、敵対的テストがその不足している証拠を提供するという考え方だ。統制が機能していると仮定するのではなく、セキュリティチームが攻撃者がそれを突破できるかを検証する。

これは、確立されたリスク管理の考え方とも一致する。米国国立標準技術研究所（NIST）のAIリスクフレームワークは、AIシステムのライフサイクル全体にわたりリスクを測定・管理することを重視している。

テストはこのプロセスの一部にすぎない。組織には、ガバナンス、インシデント対応、アクセス管理、セキュアなエンジニアリング、監視、そして責任の所在が明確なオーナーも必要だ。

このより広い視点が重要なのは、レッドチーミング・プラットフォームが発見したすべての問題を解決できるわけではないからだ。検出事項によっては、より限定的な権限、別のシステムプロンプト、より強固な出力検証、ツールアクセスの再設計、あるいは安全でない機能の削除が必要になる可能性がある。

したがって主要な争点は、検証と信頼のどちらを選ぶかにある。企業はベンダーや開発者が提供する保護策を受け入れるべきか、それとも組み上げたシステムを繰り返しテストすべきか。

影響の大きいアプリケーションでは、反復的なテストには強い根拠がある。システムの変化があまりに頻繁であり、単一の評価では最新性を維持できないためだ。

モデルのバージョンは更新される。プロンプトは変化する。新たなツールが利用可能になる。従業員はデータソースを追加する。攻撃手法は広がる。

ただし、継続的なテストには境界が必要だ。本番アプリケーションに対して無統制に攻撃を実行すると、コスト、データ、ユーザー、あるいは接続先システムに影響を与える可能性がある。

成熟したプラットフォームは、安全なテスト環境、統制されたアカウント、スコープを限定した権限、明確な認可をサポートしなければならない。シミュレートされた影響と、実際の記録を変更する行為を区別する必要もある。

ここで専業ベンダーは価値を提供できる。専門的なAIレッドチームの知見を欠くチーム向けに、攻撃手法、証拠収集、レポート、安全管理をパッケージ化できるからだ。

また、大手セキュリティベンダーが対応できる領域でもある。既存のアプリケーションセキュリティおよびクラウドセキュリティ・プラットフォームは、すでに顧客関係、テレメトリー、ワークフロー統合を保有している。

こうしたベンダーは、モデルの検出、プロンプト監視、エージェントテスト、AIポリシーの強制を追加できる。専門企業を買収したり、外部テストを統合したりできれば、すべての研究能力をゼロから再現する必要はない。

Mindgardは、自社のアプローチが独自のプラットフォームに値することを示すため、十分な速さで前進しなければならない。同社の大学発研究という背景は、技術的な信頼性を支え得る。企業での採用は、その研究をどれだけ信頼できる運用ソフトウェアへと転換できるかに左右される。

資金調達が証明しないこと

3,000万ドルのラウンドは投資家の関心を裏付けるが、自動化されたAIレッドチーミングが企業リスクを一貫して低減することを証明するものではない。

資金調達の発表は当然ながら機会を強調する。偽陽性率、是正の完了状況、テストカバレッジ、顧客維持率、セキュリティ成果を開示することはほとんどない。

これらの指標は、生成された攻撃試行の数よりも重要だ。プラットフォームは何千ものプローブを実行できても、機微なツールに到達する一連の手順を見逃すことがある。

また、重大そうに見える挙動を特定しても、それが実質的な被害につながることを示せない場合もある。基盤モデルが望ましくない回答を生成することと、認証済みエージェントが顧客記録を公開することは異なる。

第1の不確実性はカバレッジに関するものだ。有限の攻撃ライブラリで、あらゆるプロンプト、モデル、言語、アプリケーションアーキテクチャ、ツールの組み合わせを表現することはできない。

自動化システムは攻撃を変化させ、弱点を探索できる。それでも、設計者が置いた前提と顧客が提供する情報の範囲内で動作する。

第2の不確実性は評価に関するものだ。テスト・プラットフォームは、応答が成功、失敗、あるいは曖昧な挙動のどれに当たるかを判断しなければならない。

単純なケースでは決定論的なチェックを使える。出力に秘密の文字列が現れれば、結果は明確だ。

一方で、判断を要するケースもある。応答が有害な指示に部分的に従う場合、間接的な手がかりを明かす場合、あるいは別の統制に阻止される不正操作を試みる場合がある。

自動評価器は支援できるが、モデルベースの判定器には独自の不整合が持ち込まれる。影響の大きい検出事項では、人間によるレビューが依然として重要だ。

第3の不確実性は是正に関するものだ。AIの脆弱性には、必ずしも単一のパッチがあるわけではない。

開発者は入力をフィルタリングし、ツールを制限し、確認手順を追加し、データを分離し、認可を強化し、アプリケーション設計を変更できる。どの統制も、使いやすさとパフォーマンスに影響し得る。

強力なテスト・プラットフォームは、攻撃をただ繰り返すだけでなく、その判断を支援すべきだ。経路、条件、影響、提案された緩和策の効果を示す必要がある。

第4の不確実性は市場構造に関するものだ。Mindgardは、モデルスキャン、ランタイム監視、ガバナンス、ガードレール、レッドチーミングを提供する専門企業の間で事業を展開している。

以前の報道では、この市場の一部を狙う企業としてNoma、HiddenLayer、Protect AIが挙げられていた。大手セキュリティ・プラットフォームがAI領域へ拡張するなか、競争環境はさらに曖昧になり続けている。

1社のベンダーが検出、ポスチャー管理、監視、対応を組み合わせられる場合、買い手は統合製品を好む可能性がある。専門企業は、より深いテストを提供したり、大手プラットフォームが見落とすモデルやデプロイ環境をサポートしたりすれば勝機を得られる。

Mindgardは、AIコーディングツールやモデルの挙動に関する発見を含め、脆弱性研究も公開している。こうした取り組みは技術力を示し得るが、公開研究は顧客環境全体における製品性能と同じではない。

責任ある開示は、さらに複雑さを加える。ベンダー、研究者、顧客の間では、深刻度、再現性、影響を受ける構成、妥当な是正期限について見解が分かれる可能性がある。

読者は個別の開示を、特定の条件に関する証拠として扱うべきであり、製品のあらゆる導入が安全でないことの証明とみなすべきではない。

したがってMindgardに求められる適切な基準は、測定可能な顧客への影響だ。プラットフォームは攻撃者より先に重要な弱点を発見できるのか。チームはその検出事項を再現できるのか。統制を実装し、それが機能することを検証できるのか。

今回の新たな資金調達により、Mindgardにはこうした問いに答える時間が与えられる。それらに同社の代わりに答えるものではない。

Google Newsの見出し後に注目すべき3つのシグナル

次の段階を決めるのは、導入の証拠、製品統合、独立した技術検証である。

第1のシグナルは、Mindgardが再現可能な企業導入成果を開示するかどうかだ。有用な証拠には、重要な検出事項のうち是正された割合、修正を検証するまでに必要な時間、継続テストを実行している顧客の割合などが含まれる。

顧客名だけでは、得られる洞察は限られる。パイロット導入によって知名度のあるロゴを獲得できても、継続的な利用を証明するわけではない。

より有益なのは、長期的な結果だ。顧客がモデル、プロンプト、ツールの変更後にも繰り返しアプリケーションをテストするなら、Mindgardの継続的テストという論旨はより強まる。

大半の案件が単発の評価にとどまるなら、このプラットフォームは自動化されたコンサルティングに近い機能を果たす可能性がある。それでも価値はあり得るが、継続的なセキュリティ基盤よりも狭い事業を支えることになる。

第2のシグナルは、Mindgardが開発・セキュリティ運用とどれほど深く統合するかだ。継続的インテグレーションのパイプライン、モデルレジストリ、クラウドプラットフォーム、チケット管理システム、セキュリティ監視ツールとの接続に注目したい。

統合の深さは、テストが日常業務になるかを左右する。リリースごとに大規模な手動設定を必要とするセキュリティ製品を、開発者が一貫して使い続けることはない。

セキュリティチームにも、既存のワークフロー内で結果を確認できることが必要だ。独立したダッシュボードは能力を示せるが、誰も担当しない別のキューになり得る。

最も強力な実装は、検出事項を関連するアプリケーションのバージョン、責任者、影響を受ける資産、是正チケットに結び付けるものだ。その後のテストでは、修正によって実際に挙動が変わったかを検証すべきである。

この証拠の連鎖はガバナンスにとって重要だ。責任あるAIに関する抽象的な主張を、テスト済みの統制と文書化された意思決定の記録へと変える。

第3のシグナルは、Mindgardのカバレッジと精度に対する独立した検証だ。顧客、セキュリティ研究者、監査人、比較評価は、管理不能なノイズを生じさせずに、このプラットフォームが意味のある弱点を発見できるかを検証できる。

MITRE ATLASナレッジベースは、AI対応システムに対する敵対的脅威について、防御側に共通言語を提供する。認知された手法に対応付けたカバレッジは、買い手によるツール比較に役立ち得るが、フレームワークへの準拠だけで有効性が確立されるわけではない。

独立した演習には、現実的なアプリケーションの文脈を含めるべきだ。孤立したチャットボットだけをテストしても、フルシステムのリスクに関するMindgardの主要な主張を検証することはできない。

買い手は失敗事例も検討すべきだ。信頼できる評価は、プラットフォームが見逃すもの、対応する環境、人間の専門知識が依然として必要な領域を明らかにする。

この3つのシグナルが、今回の資金調達発表がカテゴリーリーダーシップを意味するのか、それとも単に競争の激化を示すのかを決める。導入の証拠は顧客が戻ってくるかを示す。統合は製品が日常業務に適合するかを示す。独立テストは、その検出事項が信頼に値するかを示す。

開発者や企業の買い手にとって、実務上の対応はGoogle Newsの見出しだけを根拠に製品を購入することではない。まず、どのAIアプリケーションが機微なデータ、ツール、または意思決定に到達できるかを特定する。

その責任者、モデル、権限、検索・取得元、期待される挙動を文書化する。この作業について検索可能な記録が必要なチームは、ナレッジベース内で技術的な証拠を整理できる。

次に、最も影響の大きい経路をテストし、修正を検証する。MindgardのSeries Aにより、自動化されたアプリケーションテストを軽視することは難しくなった。その長期的な意義は、そのテストが新たなセキュリティ上の約束ではなく、信頼できる証拠となるかにかかっている。