インタビュー
Micha Rave、Hush Security の CEO 兼共同創業者 – インタビューシリーズ
Unite.AI を Google の優先ソースに追加
Micha Rave、Hush Security の CEO 兼共同創業者は、ソフトウェアエンジニアリング、プロダクトマネジメント、エンタープライズネットワーキング、クラウドセキュリティ、アイデンティティにまたがる経験を持つサイバーセキュリティとテクノロジーのエグゼクティブです。2024 年に Hush Security を共同設立する前は、Proofpoint で 5 年以上、クラウドセキュリティのプロダクトマネジメント上級ディレクターとして、Zero Trust Network Access (ZTNA) および Secure Web Gateway (SWG) 製品ラインを担当していました。以前は Meta Networks のプロダクトマネジメント副社長としてエンタープライズネットワーキングとセキュリティに注力し、HARMAN International、Redbend、SanDisk、Hola、Jungo、Elbit Systems でプロダクトおよびエンジニアリングのリーダーシップを務めました。彼のバックグラウンドは、ハンズオンのソフトウェア開発と、20 年以上にわたるセキュリティ、ネットワーキング、仮想化、組み込み技術製品の構築と商業化の経験を組み合わせたものです。
Hush Securityは、長期間有効なクレデンシャルや静的シークレットをアイデンティティベースでポリシー制御されたアクセスに置き換えることで、AI エージェントやその他の非人間アイデンティティを保護することに特化したサイバーセキュリティ企業です。同社のプラットフォームは、シャドウエージェントや社内開発エージェントを含む AI エージェントを検出し、検証可能なアイデンティティを割り当て、スコープ付きのジャストインタイム権限、集中ポリシー、監査可能なアクティビティ記録を用いてエンタープライズシステムとのやり取りを管理します。会社は、Proofpoint が 2019 年に買収した Meta Networks のチーム出身のセキュリティベテランによって設立されました。2026 年 7 月、Akamai Technologies が戦略的投資家として Battery Ventures、YL Ventures とともに参加し、30 万ドルのシリーズ A ラウンドで 3,000 万ドルを調達し、総資金は 4,100 万ドルとなり、エンタープライズ AI エージェントと非人間インフラのガバナンス技術を拡大しています。
Hush Security を設立する前、あなたは Proofpoint でのクラウドセキュリティを含むセキュリティ製品の構築とリーダーシップに何年も費やしました。市場で何を見て、Hush を立ち上げる必要があると確信したのですか？また、エージェント型 AI の急速な台頭に伴い、当初の仮説はどのように変化しましたか？
Proofpoint では、企業が人間のアイデンティティを解決する一方で、非人間的なものは依然として静的シークレットで動作しているのを目にしました。サービスアカウント、ワークロード、パイプラインは、誰も所有せず、期限切れもしないキーで認証しています。業界はより優れた金庫で応えました。それはより良い金庫であり、解決策ではありません。
創業時の仮説は、非人間的アクセスをシークレットからアイデンティティへ移行することでした。検証可能なワークロードアイデンティティ、必要に応じて発行される短命クレデンシャル、インラインでポリシーが適用されます。コードの書き換えは不要です。
エージェント型 AI がそれを緊急課題にしました。エージェントは実行時にどのツールを呼び出すかを判断し決定する NHI（非人間アイデンティティ）です。静的キーを渡すと、自治ソフトウェアに本番環境への常駐アクセスを与えることになり、エージェントは変更プロセス外で出荷されます。開発者が火曜日に MCP サーバーを配線すれば、金曜日までに顧客データに触れることになります。
仮説は変わりませんでした。範囲が変わっただけです。アイデンティティベースのアクセスはワークロードにとって正しい答えでした。エージェントにとっては唯一実行可能なものです：存在するすべてのエージェントを把握し、デフォルトで最小限のエージェンシーを付与し、すべての操作を監査します。人間は IdP を持ちました。エージェントにもそれが必要であり、それが Hush です。
Hush は、エンタープライズ AI エージェントは独自のアイデンティティと委任された権限を持つべきであり、人間が使用するアクセス権を単に継承すべきではないと主張しています。従来のアイデンティティとアクセス管理（IAM）システムが自律エージェントに苦戦する理由は何で、何が変わる必要があるのでしょうか？
明らかなケースは、エージェントがユーザーのために行動する場合です。より難しいケースは、ユーザーが全くいないエージェント、すなわちスケジュールされたジョブ、自律的な SOC レスポンダー、独自に判断し行動するパイプラインです。委任先がいないため、チームは広範な権限を持つ静的サービスアカウントと期限切れしないキーという唯一のツールに頼ります。これは、10 年間破綻し続けている共有シークレットモデルが、即興で動くソフトウェアに付随したものです。
対向システムが状況を悪化させます。ほとんどの内部 API、データベース、MCP サーバーは実際の認可を行いません。トークンが有効かどうかをチェックするだけで、何ができるかは確認しません。所有＝許可です。
必要な変化は次のとおりです：すべてのエージェントに、有人かどうかにかかわらず、暗号的に発行された独自のアイデンティティを付与します。アクセスはアクション単位で、短命かつスコープ限定で、インラインでポリシーが適用され、ターゲットシステムに信頼されません。ユーザーがいる場合、エージェントの権限はユーザーができることとそのタスクのためにエージェントが許可されていることの交差点になります。ユーザーがいない場合、エージェント自身のアイデンティティとポリシーが全てです。人間は最小権限を得ました。エージェントは最小エージェンシーが必要です。
AI セキュリティについて議論する際に「最小エージェンシー」の概念を使用しています。最小エージェンシーは従来のサイバーセキュリティ原則である最小権限とどのように異なり、組織は特定のタスクに対して AI エージェントに何を許可すべきか正確にどのように決定すべきでしょうか？
エージェントは固定された動作を持ちません。CRM の読み取り権限とメールの書き込み権限を与えると、2 つの権限を付与したことになるのではなく、それらの間のすべてのパスを許可したことになります。最小権限はエージェントが触れられる範囲を制限しますが、何をすべきかについては何も規定しません。
最小限のエージェンシーは欠けている次元を追加します：どのアクションを、どのタスクに対して、今すぐ行うか。チケットをトリアージするエージェントは読み取りとコメントが必要です。トークンが許可していても、クローズ、削除、請求へのアクセスは必要ありません。タスクが終了すれば、アクセスも終了します。
許可されることを決定する際は、推測ではなく観察から始めます。エージェントを実行し、実際に呼び出すものを観察し、それをベースラインとします。その後、3つの入力で絞り込みます：エージェントが存在するタスク、エージェントが代行するユーザー（ユーザーができる以上のことはしない）、各アクションの影響範囲です。コメントの投稿と支払いの実行が同じ承認経路を共有すべきではありません。
最小権限は誰が鍵を持つかを決定します。最小エージェンシーは内部に入った後に何ができるかを決定します。
私たちはしばしばエージェントに自分のアイデンティティを「貸し出す」ですが、エージェントに自分と同じレベルの権限を与えたくありません――これが最小エージェンシーの定義です。
Hushは最近、$30 百万 Series Aを調達し、総資金は$41 百万となりました。AkamaiはBattery VenturesおよびYL Venturesと共に戦略的投資家として参加しています。Akamaiの関与は資本以外に何をもたらし、パートナーシップがHushのエンタープライズAIエージェントセキュリティへの拡大にどのように影響すると考えますか？
Akamaiは世界中の多くの企業のトラフィック経路に位置しており、まさにエージェントセキュリティが存在すべき場所です。エージェントを事後にダッシュボードから管理するのではなく、ツールやAPIを呼び出す瞬間にインラインで管理します。Akamaiはそのモデルで事業を築いてきました。
資本以外に、彼らがもたらすものは3つあります。エージェントとMCPトラフィックの制御方法を既に問い合わせているCISOへの配信、エージェントアイデンティティが機能ではなく実在するカテゴリであることの検証、そしてグローバル規模で機械間トラフィックを保護してきた数十年の経験です。これがエージェントからツールへのトラフィックが今後なる姿です。
Model Context Protocol (MCP) は、AIエージェントとツール、エンタープライズデータを接続する重要なレイヤーとして急速に普及しています。セキュリティの観点から、MCPがもたらす新たなリスクは何か、そして組織はエージェント、MCPサーバー、基盤リソース間のアイデンティティと認可をどのように考えるべきでしょうか？
MCPはエージェントとツールの接続を簡単にしました。これがリスクです。開発者が設定ファイルにサーバーを追加すると、モデルはJiraを読み取ったり、データベースにクエリを投げたり、メールを送信したりできるようになります。レビューもインベントリもポリシーもありません。セキュリティは何かが壊れたときに初めて問題を認識します。
現在、3つの新たな問題があります：
- シャドウMCP – 何台のサーバーが稼働しているか、何にアクセスしているかは誰も把握していません。
- 認証情報の散在 – 多くのサーバーは静的トークンで認証し、全領域へのアクセス権を付与するため、エージェントはトークンができるすべてを取得します。
- 崩壊したチェーン – リソースはMCPサーバーの認証情報しか見えないため、どのエージェントがどのユーザーとして呼び出したかが分かりません。アイデンティティはすべてのやり取りの基礎に置かれ、アクセスは一時的でスコープ化され、エージェントとユーザーの権限に基づくべきです。
Hushは、静的シークレットと長期間有効な認証情報が機械アクセスの壊れた基盤であるという考えに基づいて構築されました。多くのエンタープライズインフラが依然としてAPIキー、トークン、その他のシークレットに大きく依存している中、企業はテクノロジースタック全体を再構築せずに、アイデンティティベースの短期アクセスへ現実的に移行できるでしょうか？
再構築は不要です。そう主張する者は、エンタープライズに直面したことがありません。私たちが保護している多くは「非人間アイデンティティ」という言葉が生まれる以前から存在し、書き換えられることはありません。
そのため、私たちはそれを要求しません。Hushはコード変更なしでデプロイされ、アクセス経路に配置されます。第一ステップはディスカバリーです：すべてのシークレット、使用者、到達先、実行時に実際に何を行うかを把握します。多くの企業はその全体像を見たことがありません。
次に、それは移行ではなく旅です。ディスカバリーにより、どのシークレットが不要、過剰スコープ、または最高リスクかが分かります。まずそれらを修正します。その後、静的キーをシステムごとに短期のアイデンティティ発行クレデンシャルに置き換えます。アプリは依然としてキーを使用していると認識しますが、キーは長期的でなくなり、ポリシーは私たちに移行します。
同じモデルは、15年前のJavaサービスと先週立ち上げたMCPサーバーの両方に適用できます。リスクがある箇所から始め、実証し、継続します。
AIエージェントはますます人間に代わって働き、多くの場合、タスクを他のエージェントに委任します。これらのマルチエージェントワークフローが複雑化する中、発生するすべてのアクションに対して、アイデンティティ、認可、所有権、責任の明確なチェーンをどのように維持しますか？
失敗モード：ユーザーがオーケストレータに依頼し、オーケストレータが第2エージェントに委任し、そのエージェントがMCPサーバー経由でツールを呼び出し、サービスアカウントでデータベースにアクセスします。4つのホップの後、ログには有効なトークンだけが表示されます。誰が依頼し、誰が決定し、誰が責任を負うかは不明です。
解決策は、どのホップでもアイデンティティが崩壊しないようにすることです。すべてのエージェントは独自の暗号化アイデンティティを持ちます。委任時にトークンを渡すのではなく、スコープ付き委任を発行します：このサブエージェント、このタスク、これらのアクションをこのユーザーの代わりに実行します。各ホップは完全なチェーンと独自の権限を保持します。
アカウンタビリティは、アクションのポイントでインラインに強制し、ログを記録することから生まれます。ゲートウェイは、許可された操作、呼び出された内容、そしてその背後にあるチェーンを記録します。
マルチエージェントシステムは、理解がますます難しくなります。各アクションのチェーン・オブ・カストディは必ずしも必要ではありません。
プロンプトインジェクションやその他の攻撃は、本来正当な AI エージェントを操作し、オペレーターが意図しない行動を取らせる可能性があります。基盤となる AI モデルが誤動作していても、アイデンティティベースのアクセス制御は、侵害または操作されたエージェントからの被害をどの程度まで抑制できるでしょうか？
プロンプトインジェクションをモデルレベルで止めることはできません。モデルは設計上、信頼できないコンテンツを読み取ります。エージェントが最終的に誤った指示を受け入れると想定してください。問題は、そうなったときにエージェントが何ができるかです。
アイデンティティベースのアクセスは、被害範囲を限定します。最小限の権限しか持たない操作されたエージェントは、そのタスクに付与されたアクションだけを悪用できます。チケットを読みコメントを投稿できても、インジェクションによって顧客データベースを流出させることはありません。トークンにはそのような範囲はありません。
ユーザー属性付与によりチェーンが保たれます：どのユーザー、どのエージェント、どのタスクかがすべての呼び出しで記録されます。エージェントはユーザーが可能な範囲を超えることはなく、すべてのアクションが遡って追跡可能です。
異常検知は、ポリシーで許可されているが意図されていない動作を捕捉します。通常は5件のレコードを読むエージェントが突然5千件を取得するのは、各呼び出しが許可されていても異常です。ゲートウェイがインラインで配置されベースラインを把握しているため、リアルタイムでフラグ付けやブロックが可能です。
モデルは時折誤りを犯します。スコープされたアイデンティティ、属性付与、行動ベースラインにより、誤りが許容可能になります。
Hush は主に AI のセキュリティに注力していますが、Hush 自体で AI をどのように活用していますか？非人間アイデンティティの検出、アクセスパターンの分析、リスクの優先順位付け、ポリシーの施行など、AI がセキュリティプラットフォームを実質的に向上させる領域はありますか？
それが価値を発揮する場所であれば、どこでも活用しています。
製品において難しいのはシークレットを見つけることではなく、それを理解することです。キーがトラフィックに現れます。ワークロードアイデンティティ、ベンダー統合、開発テストトークン、無効な認証情報？LLM はランタイムコンテキストと所有者シグナルを読み取り、信頼度スコアとともに回答を提案します。アイデンティティが実際に何を行うかを平易な人間の言葉で要約するため、ポリシーは人間が承認できるものになります。リスクは静的な重大度ではなく、実際の影響範囲と被害半径で評価されます。施行は決定論的に保たれます。AI はポリシー作成を支援しますが、実行時に投票権を持つわけではありません。
Hush 内部では、エージェントプログラミングが私たちのスピード感を変えました。スプリントで開発していた機能が数日で実装でき、Series A のチームでは到底実現できないペースで統合を提供しています。LLM はサポートチケットを一次分類し、根本原因をクラスタリングし、ロードマップ議論のための顧客要望を表面化させます。私たち独自の MCP ゲートウェイがすべての前に配置され、顧客が NHI とエージェントリスクを理解し活用できるよう支援しています。
Hush は、複数の Fortune 500 企業が同社の技術を使用していると述べており、Kyndryl は内部で Hush を導入し、エンタープライズ顧客への再販を開始しています。これら大規模導入から、AI エージェントが実験段階から本番環境へ移行した際に企業が直面する実際のガバナンス課題について、どのような学びがありますか？
自社が何を持っているかを把握している組織はほとんどいません。大規模導入はすべて同じ形で始まります：セキュリティは本番に数十のエージェントがあると考えているが、調査では数百が見つかり、すでに顧客データに触れています。ガバナンスの問題はポリシーではなく、まずインベントリの把握です。
認証情報の方がエージェントよりも問題です。ほぼすべての本番エージェントは、事前に作成された静的なサービスアカウント上で動作しており、他の目的のために何年もかけて蓄積された権限を持っています。スコープされたアクセスは与えられていません。
所有権が欠如しています。エージェントや NHI の責任者を尋ねても、最高でもチーム名しか得られず、退職した契約者や無回答になることが多いです。
購入者が変わりました。これはプラットフォームチームの問題でしたが、取締役会の要請で CISO が所有することになりました。その結果、パイロットからエンタープライズ展開へと移行し、Kyndryl が再販前に内部展開した理由でもあります。
エージェントが新たなガバナンス問題を生み出したわけではありません。企業が10年間無視してきたサービスアカウントに関する問題を取り込み、さらに深刻化させただけです。
素晴らしいインタビューをありがとうございました。詳しく知りたい読者は Hush Security をご覧ください。
