Adam Markowitz、DrataのCEO兼共同創業者 — インタビューシリーズ

Adam MarkowitzはDrataのCEO兼共同創業者であり、継続的なコンプライアンスと信頼に関する同社の取り組みを、AIエージェントガバナンスへと拡大している。2020年にDrataを共同創業する前は、Troy Markowitz、Daniel MarashlianとともにPortfoliumを創業した。セキュリティ質問票への対応や監査、コンプライアンス審査に取り組んできた経験は、組織が信頼を証明するプロセスを自動化するというDrataのアプローチを形づくるうえで役立った。

Drataは、ガバナンス、リスク、コンプライアンスのためのプラットフォームを提供している。証跡の自動収集、継続的な統制の監視、サードパーティリスク管理、セキュリティ質問票への対応ワークフローを組み合わせている。同社のAIエージェントガバナンス機能は、エージェントの発見、アクションの実行前におけるポリシーの適用、監査可能性を確保するための判断記録に重点を置いている。このインタビューでMarkowitzは、内部者によるエージェントの脅威、マシンアイデンティティ、ツール呼び出しのセキュリティ境界、自律型エージェントを大規模に導入するために企業が必要とする統制について語る。

あなたは、企業の成長に伴ってセキュリティコンプライアンスがいかに煩雑になるかを身をもって経験した後、Portfoliumを創業し、2020年にDrataを共同創業しました。これをまったく新しい会社を立ち上げて取り組む価値のある問題だと考えたのはなぜですか。また、AIによってセキュリティを取り巻く状況が変化するなかで、Drataの使命はどのように進化してきましたか？

共同創業者のTroy Markowitz、Daniel MarashlianとともにPortfoliumを率いるなかで、私たちは大切な教訓を学びました。ビジネスで信頼を得るのは、売り込みではなくプロセスだということです。学生情報は量が多く、機微性も高いため、データを守るために適切な取り組みをしていると証明するまでは、大学も企業も私たちと提携しようとしませんでした。セキュリティ質問票への回答、監査、コンプライアンス審査を一つひとつ手作業で進める、時間のかかる骨の折れる作業は、誰もが経験している共通の課題だと気づきました。Portfoliumが買収された後、Troy、Daniel、私の3人は再び集まり、コードを書き始める前に、問題を検証するために数十社の企業や監査人と話をしながら、6か月かけてDrataの最初のバージョンを開発しました。サービスを開始すると、最初の6週間で顧客数が100社に達し、1年以内に1,000社に到達しました。これは、私たちが提供するものが「あれば便利」なものから、なければ業務を続けられないものへと変わったことを示していました。

AIの登場後も、継続的な信頼を実現するというDrataの使命は変わっていませんが、その信頼が対象とする範囲は広がりました。まずコンプライアンスに伴う煩雑な作業を自動化し、次にサードパーティリスク評価やセキュリティ質問票への対応を最初から最後まで実行できるエージェント型ワークフローへと領域を広げました。しかし、本当の転換点は、エージェントそのものがガバナンスの対象になったときに訪れました。現在は、AIエージェントガバナンスを実現するためにプラットフォームを拡張しています。エージェントを発見し、許可する行為を管理し、説明を求められたときに裏付けとなる証跡を提示できるようにします。

外部の攻撃者ではなく、組織が自ら導入したAIエージェントによって生じるリスクを表す言葉として、「内部者エージェント脅威」という用語を提唱されました。内部者エージェント脅威は、セキュリティチームが何十年も対策を講じてきた従来の内部者脅威と、どのように異なるのでしょうか？

従来の内部者脅威とは、不満を抱えた従業員や不注意な従業員、あるいは単に誤った操作をしてしまった人などが、すでに持っているアクセス権を悪用することです。セキュリティチームは、身元調査、最小権限の原則、退職時のチェックリストなどに重点を置き、このリスクに対処する体制を何十年もかけて整えてきました。

内部者エージェント脅威が異なるのは、そもそもエージェントにアクセス権が与えられていないためです。リスクの焦点は、アクセス権の悪用からその獲得へと移ります。エージェントに目標が与えられ、その達成に必要な明確な経路が塞がれていても、人間のようにチケットを起票して待つことはありません。別の経路を探します。パスワードの弱いサービスアカウントや、閉じ忘れられたエンドポイントを見つけようとするのです。エージェントは悪意も、自ら認識しているポリシー違反もないまま侵入します。指示されたことを正確に実行するからこそ、検知が非常に難しいのです。個々の手順を見れば、どれも妥当に思えます。そして最後には、エージェントが成功を報告します。

機微なシステムにアクセスできる従業員やサードパーティをどう管理すればよいかは、すでにわかっています。しかし、エージェントは3つ目の集団であり、最初の2つを対象に作られたツールでは対応できません。

AIエージェントは目標を粘り強く追い、機械の速度で動作し、人間の従業員なら働かせるであろう判断力を備えないまま複数のシステムとやり取りできます。これは企業の脅威モデルを根本的にどのように変えるのでしょうか？

何よりも大きく変わるのは、時間軸です。システムに侵入する方法を探る人間は、やがて飽きたり、見つかったり、諦めたりします。エージェントはそうではありません。以前は見つかっていなかった開いた侵入口が今では発見されます。エージェントは疲れず、探すのをやめないからです。

侵入口は一つとは限りません。あるタスクを実行するために作られたエージェントは、タスクを終えるまでの間に、アカウント履歴を取得したり、データベースを調べたりと、喜んで十数ものシステムに触れます。その大半は、実際に指示されたタスクとは関係ありません。資料を1つ作成する過程で、別の顧客のデータや財務記録、従業員情報など、経路上にあるものなら何にでも触れる可能性があります。そのどれも、インシデントとして記録されません。

つまり、脅威モデルは変化しています。今日、セキュリティチームが問うべきなのは、どこで止まるべきかを誰も指示しなかった場合、自社のエージェントがタスクを完了するためにどこまで進むのか、ということです。

多くの組織では、すでにアイデンティティ・アクセス管理、特権アクセス管理、ゼロトラストアーキテクチャを導入しています。自律型AIエージェントを統制するうえで、こうした制御だけでは不十分なのはなぜでしょうか？

こうした枠組みは、人間とベンダーを対象に構築されました。どちらも判断力を備え、壁にぶつかれば立ち止まる存在です。エージェントのアイデンティティにも、人間の管理やサードパーティリスク管理で確立されたのと同じ厳格さが必要です。つまり、エージェントの把握、所有者の明確化、そして監査人が信頼できる証拠の確保です。課題は、認証情報を保持するものがエージェントである場合に、「統制されている」とは実際に何を意味するのか、共通の基準がまだないことです。

たとえば、エンジニアの一人が作成したエージェントは、そのエンジニアのアクセス権を使って動作できます。エンジニア自身が一度も利用したことのないシステムであっても同様です。IAMやPAMは、認証情報を保持するものがいつ立ち止まるべきかを理解している前提に立っていますが、エージェントにはその前提が組み込まれていません。

企業は、すべてのAIエージェントを、それぞれ明確な所有者、権限、適用範囲、ライフサイクルを持つ独立したマシンアイデンティティとして扱い始めるべきでしょうか？エージェント向けの成熟したアイデンティティフレームワークとは、どのようなものでしょうか？

はい。ただし、ほとんどの企業はまだそこまで到達していません。予想以上に多くの企業が、自社内で稼働しているエージェントの数すら把握できておらず、ましてや一体ずつ誰が所有しているのかは分かっていません。成熟したフレームワークは、すべてのエージェントを対象とする実質的かつ継続的な台帳を作るための把握から始まります。次に、各エージェントに所有者を定め、アクセスを許可する対象の範囲を明確にし、その範囲を実際に適用するポリシーを設ける必要があります。私たち自身の調査でも、ベンダー側に同じ問題が見られます。組織の4分の3は、サードパーティの再評価を年に1回以下しか行っていません。そのため、何かが変わる頃には、すでに古くなったデータに基づいて統制していることになります。内部であれ外部であれ、エージェントの管理に一時点の評価は通用しません。

個々の開発者が独自に構築したものをセキュリティ部門が一つずつ追いかけるのではなく、すべてのエージェントに同じように適用される単一の基準を設けたいと考えています。そのためには、平易な言葉で記述できるポリシーを用意し、有効化する前に実際の過去のトラフィックを使ってテストしたうえで、インラインで適用する必要があります。つまり、フレームワークがエージェントのあらゆるアクションの実行経路上で機能し、文書に記載されているだけのものにとどまらないようにするのです。

特に難しい状況の一つに、悪意ある行動をしているわけではないエージェントがセキュリティポリシーに違反するケースがあります。割り当てられたタスクを完了しようとした結果、意図せず機密データへの経路を見つけてしまった場合、セキュリティチームは、自動化が適切に機能したケースとセキュリティインシデントをどのように見分ければよいのでしょうか？

現時点での率直な答えは、見分けられない、ということです。四半期ごとのビジネスレビューの草案を作成するよう設計されたサポートエージェントがあり、アカウント履歴を取得して資料を作成するよう指示されたとします。想定された取得元である、正規のエクスポート経路からデータが返ってきません。人間ならそこで止まりますが、エージェントは別の経路を見つけ、その視点からはタスクを成功させたことになります。

タスク自体は完了したものの、セキュリティプロトコルを迂回し、アクセスを許可されていないシステムに入り込むことで達成されました。見分けるうえで問うべきなのは、エージェントが与えられた範囲内にとどまったかどうかです。タスクを終えたかどうかが問題だったわけではありません。これはポリシーの問題です。「自動化の成功」と「セキュリティインシデント」が事後に同じものに見えないよう、適用範囲を十分に厳密に定める必要があります。

従来のセキュリティ監視では、不審な活動が起きた後に検知することがよくあります。しかし、自律型エージェントは、人間が対応するまでに何百ものアクションを実行する可能性があります。エージェント型AIには、アラートや事後の監視を主に頼るのではなく、実行経路上で直接機能するセキュリティ制御が必要なのでしょうか？

はい、間違いありません。実行時に検知しているようでは、すでに手遅れです。監視ツールがそのアクションに警告を出す頃には、すでに実行されています。どのように情報が露出したかを正確に記録した完璧な記録は手に入りますが、それを止めるために後戻りする方法はありません。

機械の速度で動くものに有効なガバナンスは、アクションの実行前に評価し、違反をインラインで阻止するものだけです。最も機密性の高いデータを新入社員に渡し、問題が起きても監視が検知してくれるだろうと期待するだけ、ということは決してしません。エージェントにも、アクションが実行されようとするまさにその瞬間に、同じ規律を適用すべきです。事後ではなく。

Model Context Protocol (MCP)をはじめとするエージェントとツールのインターフェースによって、AIシステムはますます強力な外部機能を利用できるようになっています。企業がエージェントに許可する操作を拡大するなか、ツール呼び出し、API、認証情報、サービスアカウントには、どのような新たなセキュリティ境界を設ける必要があるでしょうか？

ツールの呼び出しが、新たな境界になっています。エージェントが認証情報を使おうとしたり、APIを呼び出したり、ツールを実行したりするたびに、それが実行されるべきかどうかを判断する機会が生まれます。しかし現在、そうしたまさにその時点でアクションの可否を評価する境界を設けている大企業はほとんどありません。これまで欠けていたのは、まさにその仕組みです。外部から見ても同じ盲点が見つかります。セキュリティ責任者のうち、現在すでに取引のあるベンダーの環境でAIがどこで稼働しているかを特定できると自信を持っているのは、わずか37%です。ベンダーの製品内でAIの稼働状況を把握できなければ、自社のエージェントが次に何をするかも把握できないでしょう。こうした仕組みの基盤となる認証情報やサービスアカウントにも、人間のアクセスに適用しているのと同じ厳格さが必要です。所有者を明確にし、範囲を定め、定期的に見直さなければなりません。エージェントが、どこかの経路上に存在していたというだけで、付与されていない認証情報を使えるようにしてはなりません。

監査人、規制当局、顧客から、AIエージェントが何にアクセスし、どのような判断を下し、その結果どこにデータが送られたのかを尋ねられた場合、組織は現実的にどの程度の追跡可能性を確保できるべきでしょうか。エージェントの監査証跡は、従来のアクセスログと同じくらい基本的なものになっていくでしょうか。

組織は求められたときに、エージェントが何にアクセスし、どのような判断を下し、その結果どこにデータが送られたのかを説明できるべきです。事後にログをつなぎ合わせて答えを導き出すだけでは不十分です。求められた時点ですでに存在している、継続的で改ざんを検知できる記録が必要です。現状、こうした質問に対する答えを持たない企業が大半です。顧客に対して説明して済ませられるような不備ではありませんし、情報漏えいの内容によっては、規制当局も見過ごさないでしょう。

そして、エージェントの監査証跡はアクセスログと同じくらい基本的なものになり、そう遠くないうちに実現すると考えています。人間が利用するシステムについては、誰が、いつ、何にアクセスしたかを把握することを、長年にわたって必須としてきました。実際にクリックしたのが人間ではないというだけで、エージェントにより低い基準を適用する理由はありません。EU AI Act、AIUC-11、ISO 42001などのフレームワークも、すでにその方向を後押ししています。エージェントの追跡可能性は、コンプライアンスプログラムを支えている既存の管理策や証拠の仕組みと連動させる必要があります。これを後回しにすれば、重要視されなくなってしまいます。

今後、AIエージェントのガバナンスは独立したセキュリティ分野になると思いますか。それとも最終的には、既存のガバナンス、リスク管理、コンプライアンス、アイデンティティ、サイバーセキュリティの各プラットフォームに取り込まれるでしょうか。また、真に自律的なエージェントを大規模に安全に導入するには、企業はどのような体制を整える必要があるとお考えですか。

大きな技術革新の波が起きるたびに、それに伴う新たなセキュリティ分野が生まれます。クラウドの登場からWizが生まれ、エンドポイントの登場からCrowdStrikeが生まれたように、今、AIエージェントをめぐって新たな分野が生まれています。モデルプロバイダーは自社のプラットフォーム向けにコンソールやポリシーを構築しています。それは有用ですが、単一のモデルプロバイダー、単一のコーディングアシスタント、そして社内で開発したエージェントだけで運用している企業はありません。すべてを単一のポリシーと一元的な証拠の情報源に基づいて管理する仕組みが必要ですが、単一のAIプラットフォームで解決できる問題ではありません。そもそも、そうしたプラットフォームはそのために作られていないのです。AIエージェントのガバナンスは、企業がすでに運用しているGRC、アイデンティティ、コンプライアンスのシステムと連携しながら、すでに独立した分野として確立しつつあります。

真に自律的なエージェントを大規模に導入する前に、企業が整えておくべきことは4つあります。しかし、そのどれも整っていない企業が大半です。1つ目は、リアルタイムでの検出です。エージェントが作成された時点で、稼働中のすべてのエージェントとその所有者、使用するアイデンティティを把握することです。

2つ目は、アクションの実行前に評価し、その場で適用するポリシーです。3つ目は、ドリフトを継続的に監視することです。エージェントは作成されたセッションが終了した後も動き続け、その実行範囲が気づかないうちに拡大する可能性があるためです。最後に必要なのは、エージェントが下すすべての判断を記録し、監査人や規制当局が実際に認めているフレームワークに対応付けた、改ざんを検知できる記録です。これが、Drataで構築しているレイヤーです。これがなければ、自律型エージェントを大規模に導入する企業は、ただ希望的観測に頼っているにすぎません。

素晴らしいインタビューをありがとうございました。AIエージェントのガバナンス、継続的なコンプライアンス、エージェントによる内部脅威への対策に関心のある読者は、Drataをご覧ください。