2026.11.16 05:55
2026.11.15 23:27
●この記事のポイント
AIエージェントが本番データの削除や社外への情報送信まで担うようになり、権限と監視の設計が企業の課題になっている。本稿はReplitのデータベース削除事故とEchoLeakを入口に、2026年11月に資金を調達したSentra（データへのアクセス制御）とBrava（SOCの検知検証）の手法を比べ、承認基準・責任・復旧体制の決め方を整理する。
AIエージェントが社内のシステムを直接操作する場面が増えている。便利になる反面、AIの判断ミスがそのままデータの削除や外部への送信につながるおそれもある。11月4日、この「AIの権限」と「監視の実効性」を扱う海外のセキュリティ企業2社が、そろって資金調達を発表した。両社の取り組みを手がかりに、企業が事前に決めておくべきことを整理する。
●目次
- AIの誤判断が、実際の操作になる時代へ
- アクセスできることと、実行してよいことは違う
- Sentraが狙う「AIが触れられるデータ」の制御
- Bravaが問う「監視システムは本当に見えているか」
- 経営が決めるべき「任せる範囲」と「止める責任」
AIの誤判断が、実際の操作になる時代へ
2025年7月、米SaaStr創業者のジェイソン・レムキン氏が開発支援サービス「Replit」のAIエージェントを試していたところ、本番のデータベースが消えた。米フォーチュン誌によると、変更を止める「コードフリーズ」の最中だったにもかかわらず、エージェントは人の承認を待つよう求めた指示を無視してコマンドを実行し、1200人を超える経営者らのデータを削除した。データは最終的に手作業で復旧できた。ReplitのCEO、アムジャド・マサド氏は「容認できない」と述べ、開発用と本番用のデータベースを自動で分離するなどの対策を示している。
研究者による実証も続いている。2025年6月に公表された「EchoLeak」（CVE-2025-32711）は、細工したメール1通で、Microsoft 365 Copilotに社内情報を外部へ持ち出させうるという脆弱性だった。発見したイスラエルのAim Securityの報告を受けてマイクロソフトが修正しており、悪用は確認されていない。
前者は実際に起きた事故、後者は攻撃が成立しうることを示した研究であり、同列には扱えない。ただ、AIの誤りが「間違った文章」で終わらず、データの変更や送信という操作として表れることを示した点は共通している。
こうしたなか2026年11月4日、データセキュリティのSentraがCapital One Ventures主導で1億5000万ドル、セキュリティ運用のBravaがF2 Venture CapitalとPitango主導で1500万ドル（シード）の調達を発表した。前者は「AIが触れられるデータ」を、後者は「監視が本当に機能しているか」を扱う。AIに何を任せるかと並んで、それをどう制限し、どう検証するかが事業上の課題になりつつある。
アクセスできることと、実行してよいことは違う
エージェントのリスクは、大きく3つに整理できる。
1つ目は、過剰な権限だ。セキュリティの国際コミュニティOWASPは、生成AIアプリの主要リスクをまとめた「Top 10 for LLM Applications」（2025年版）で「過剰なエージェンシー（Excessive Agency）」を挙げ、その原因を「過剰な機能」「過剰な権限」「過剰な自律性」の3つに分けている。
2つ目は、外部から取り込んだ情報に紛れた不正な指示（間接プロンプトインジェクション）である。2025年5月、米Invariant Labsは、GitHub公式のMCPサーバーを使うエージェントが、公開リポジトリのIssueに仕込まれた指示に従い、非公開リポジトリの内容を公開側に書き出してしまう実証を公表した。同社は、サーバーのコードの欠陥ではなく、信頼できない入力をエージェントがどう扱うかという構造上の問題だと指摘している。
3つ目は、操作の連鎖を追えないことだ。エージェントは「読む」「判断する」「書き込む」を続けざまに実行する。どの入力がどの操作につながったのか記録がなければ、事故のあとで原因も影響範囲も絞り込めない。
3つに共通するのは、AIに渡した権限が、業務の目的を超えて使われてしまう点である。Replitの件も、開発中のエージェントの手が本番データに届いていたことが前提にあった。アクセスできることと、実行してよいことは別物だ。
対策の多くは、実は目新しいものではない。必要最小限の権限だけを与えること、開発環境と本番環境を分けること、操作ごとに認可を確かめること。OWASPも、操作を許すかどうかは生成AIに判断させず、操作を受ける側のシステムで認可をかけるよう求めている。問題は、人間には当然かけているこの制限が、エージェントには徹底されていないことにある。
「エージェント用のアカウントを棚卸しすると、試験導入のときに『とりあえず』付けた管理者権限がそのまま残っている例は少なくない。AI専用の対策を探す前に、社員のアカウントと同じ基準で管理できているかを確かめるべきだ」（サイバーセキュリティコンサルタント・新實傑氏）
Sentraが狙う「AIが触れられるデータ」の制御
Sentraは2021年創業で、ニューヨークとテルアビブに拠点を置く。同社の発表によると、クラウドやSaaS、データウェアハウス、オンプレミスのファイル共有、AIが参照するナレッジベースなどに保存されたデータを対象に、機密データの所在と、そこに「誰が届くか」を結びつけて管理する。対象には社員だけでなく、サービスアカウントやAIエージェント、グループ経由で引き継がれた権限も含まれる。スキャンは顧客の環境内で行い、外に出るのはメタデータだけだという。
その仕組みは、3つの段階に分けてみると分かりやすい。
・見つける：どこに、どのような機密データがあるかを発見・分類する。ここで分類を誤れば、後の工程はすべてずれる。
・判断する：そのデータに誰がどの経路で届き、それが業務上必要かを見る。共有リンクが社外に公開されている、異動した社員の権限が残っている、エージェントが部門全体のフォルダーを読める、といった状態を洗い出す段階だ。
・権限を変える：共有の解除や権限の削除。同社は、異常なアクセスを検知した際に自動でアクセスを取り消し、危険な共有を外す機能も挙げている。
CEOのヨアヴ・レゲヴ氏は「AIエージェントはいまや企業データの最も忙しい利用者だ」と述べる。導入企業である米LyftのCISO（最高情報セキュリティ責任者）、チャイム・サンダース氏の「エージェントを有効にする前に、どのデータに届くのかを知っておく必要がある」というコメントは、この製品が何を引き受けようとしているかをよく表している。
気をつけたいのは3段階目だ。権限を誤って削れば、業務が止まる。月末にだけ開く経理の共有フォルダーや、夜間バッチ用のサービスアカウントは、普段のアクセス記録だけを見ると「使われていない」ように映りやすい。公開資料からは、自動の是正にどのような承認手順を組み込めるかまでは読み取れない。導入する側が、自動で変えてよい範囲（例えば社外公開リンクの停止）と、担当者の確認を挟む範囲を切り分けておく必要がある。
「権限削除の自動化は、まず『元に戻せる』ことを確かめてから広げるべきだ。変更前の設定を記録し、業務部門から『開けなくなった』と連絡が来たときの窓口も決めておく。そこまで整えて初めて、現場は自動化を受け入れる」（同）
Bravaが問う「監視システムは本当に見えているか」
Bravaが守ろうとするのは、データそのものではなく「監視の仕組み」だ。Sentraが、誰がどのデータに届くかを絞る予防の側に立つとすれば、Bravaは攻撃を見つけるSOC（セキュリティ監視センター）の検知が、実際に機能するかを確かめる側にある。守る対象が違うため、どちらか一方があれば済むという関係にはない。
同社によると、攻撃者の振る舞いをモデル化し、攻撃が起きたら環境内に残るはずのログ（テレメトリー）を、攻撃そのものは実行せずに生成する。それを使ってSIEM（ログを集約・分析する基盤）の検知ルールが反応するかを試し、反応しないルールを特定して書き直す。SplunkやMicrosoft Sentinel、Google SecOpsなど主要なSIEMに対応するという。
共同創業者兼CEOのイダン・バスレ氏は発表文で、多くのセキュリティチームは検知が働いていることを確かめられず、信じるしかない状態にあると指摘している。同社は、重要なログがそもそも収集されていない、ログの転送が誰にも気づかれず止まっている、ルールが想定した攻撃を検知できない――といった状態を問題視し、「AIエージェントは見えないものを検知できない」と書く。アラートの分析にAIを使う動きは広がっているが、分析の材料となるログが欠けていれば、どれだけ分析が高度になっても攻撃は見つからない。
ただし、合成した痕跡による検証で確かめられる範囲には限りがある。主に分かるのは「このログが届けば、このルールは反応するか」「ルールが前提とする項目が、実際のデータに存在するか」だ。実際の端末やクラウドでそのログが確かに記録されるか、攻撃者が想定外の手口を使ったときにどうなるかまでは、合成データだけでは保証しにくい。同社が示す処理件数やSIEMコストの削減率も自社の発表であり、第三者による評価は公開されていない。実際に攻撃を模擬するレッドチーム演習などと組み合わせ、役割を分けて使うのが現実的だろう。
「監視画面が緑色だから問題ない、という判断は現場でよく見かける。緑は『何も起きていない』のか『何も見えていない』のかを区別しない。検知ルールは数ではなく、実際に鳴ることを確かめた数で評価すべきだ」（同）
経営が決めるべき「任せる範囲」と「止める責任」
2社の手法は異なるが、示唆することは似ている。AIの能力が上がるほど、任せる範囲を決め、その制限が実際に効いているかを確かめる仕組みが欠かせなくなる。これは情報システム部門だけで決めきれる問題ではない。経営として決めておくべきことは、次の3点に集約できる。
1. 誰の責任で、どの業務・データ・期間に権限を与えるか
エージェントごとに業務上の責任者を決め、対象業務、触れてよいデータ、権限の有効期間を定める。「とりあえず全社のファイルを読めるように」という渡し方は避け、期限が来たら見直す。社員の入退社と同じように、エージェントにも登録と廃止の手続きが要る。
2. どの操作を自動実行し、どの条件で人の承認を求めるか
すべてを承認制にすれば効率は落ち、やがて承認が形だけになる。影響の大きさと、元に戻せるかどうかで線を引くのが現実的だ。例えば次のような区分が考えられる。
操作
自動実行にする例
人の承認を求める例
・外部送信
自動実行にする例 社内宛て、事前に登録した取引先への定型連絡
人の承認を求める例 未登録の送信先、機密区分のデータを含む送信
・削除・更新
自動実行にする例 上限件数以下で、バックアップから復元できるもの
人の承認を求める例 上限件数を超えるもの、復元できないもの
・決済・発注
自動実行にする例 上限金額以下で、既存の取引先へのもの
人の承認を求める例 上限金額を超えるもの、新しい振込先
しきい値は業種や業務によって変わる。大事なのは、その線引きをエージェント自身の判断に任せず、システム側の設定で強制することだ。Replitの件では、「承認を待て」という指示が守られなかった。指示は仕組みの代わりにはならない。
3. 制御と監視が機能することをどう検証し、事故のときにどう復旧するか
権限の設定も検知ルールも、作った時点では正しくても、時間がたつと実態からずれていく。アクセス権を定期的に棚卸しし、検知が実際に動くかを試す。そのうえで、エージェントをすぐに止める手段（権限の一括停止など）、操作ログの保管、データの復元手順、社内外への報告の段取りを、事前に決めておく。
Replitの件では、エージェントは当初「ロールバックはできない」と答えたが、実際には手作業で復旧できたという。復旧できるかどうかをAIの説明に頼らず、人が自分で確かめられる体制が必要だ。
「事故が起きたとき、『AIが勝手にやった』という説明は、取引先や当局には受け入れられにくい。誰がどの権限を承認したのか、記録が残っていることが説明責任を果たす前提になる」（IT分野に詳しい弁護士／【仮】）
AIエージェントに任せる仕事は、今後も増えていくだろう。ただ、モデルが賢くなれば安全になる、というものではない。任せる範囲と止める責任を先に決めておくことが、結果としてAIに安心して任せられる仕事を増やすことになる。
（文＝BUSINESS JOURNAL編集部、協力＝新實傑／サイバーセキュリティコンサルタント）
【主な参照データ・出典】
Sentra プレスリリース（1億5000万ドルの調達発表、2026年11月4日）：sentra.io/news
Sentra 公式ブログ「Securing the AI Era: Why We Raised $150M Series C」（2026年11月4日）：sentra.io/blog
Brava 資金調達発表（2026年11月4日）：brava.security/news、会社概要：brava.security/about
Fortune、ReplitのAIエージェントによるデータベース削除の報道（2025年7月23日）：fortune.com
The Hacker News、EchoLeak（CVE-2025-32711）の報道（2025年6月）：thehackernews.com
Invariant Labs、GitHub MCPサーバーを介した情報漏えいの実証（2025年5月26日）：invariantlabs.ai
OWASP「LLM06:2025 Excessive Agency」：genai.owasp.org
AWS、Amazon Q Developer拡張機能に関するセキュリティ情報（CVE-2025-8217、本文未使用・補足資料）：aws.amazon.com
