メインコンテンツへスキップ
最新ニュース 11分で読める

【技術解説】Sentraが1.5億ドル調達:自律型AIエージェント時代にDSPMが不可欠となる構造的理由

PlusWeb3 編集部
PlusWeb3 編集部 Web3・AI専門メディア

AIエージェントが自律的に社内リソースを横断探索するエンタープライズ環境において、従来の「LLMプロキシ監視」や「ネットワーク境界防御」は構造的な限界を迎えている。

2026年11月4日、イスラエル発のデータセキュリティ企業Sentraは、Capital One Venturesをリード投資家とする1億5,000万ドルの大型資金調達を発表した。同社が掲げるスローガン「Stop chasing agents. Secure the data they reach(エージェントを追跡するな。エージェントが到達するデータを保護せよ)」は、AIインフラの制御プレーンをランタイムからストレージ層へ引き戻すパラダイムシフトを象徴している。

本記事では、公式発表の一次ソースを紐解きながら、資金調達の背景、コア技術の仕様、競合アーキテクチャとの決定的な違い、そして日本のエンジニア組織への具体的影響を考察する。

ニュースリリース要約

Sentraは2026年11月4日、Capital One Ventures主導による1億5,000万ドルの戦略的資金調達を公表した。

  • 引受先: Capital One Ventures(主導)、既存投資家のBessemer Venture Partners、Zeev Ventures、Standard Investments、Munich Re Ventures、Key1 Capital。Capital Oneの代表者がSentraの取締役に就任する。
  • 成長実績: 前年比300%超の年間経常収益(ARR)成長を達成。
  • 調達目的: 自律型AIエージェントの急増に伴う非人間アイデンティティ(NHI: Non-Human Identity)のデータアクセス制御強化、マルチクラウド環境でのIn-Situ(インプレース)データガバナンス機能の拡充、グローバル展開の加速。

企業概要

  • 企業名: Sentra(Sentra Inc.)
  • 創業者: Yoav Regev(CEO)、Asaf Kochan、Ron Reiter、Yair Cohen(イスラエル国防軍Unit 8200出身のサイバーセキュリティ専門家陣により2021年設立)。
  • 拠点: ニューヨークおよびテルアビブ。
  • 事業領域: クラウドネイティブなデータセキュリティ基盤。DSPM(データセキュリティ態勢管理)、DDR(データ検知・対応)、DAG(データアクセスガバナンス)、DLP(情報漏洩防止)を単一プラットフォームに統合。
  • 対応環境: AWS、Azure、Google Cloud、主要DWH(Snowflake、BigQuery等)、SaaS、オンプレミス、Microsoft 365 Copilot、各種ベクターストア。

資金調達が成功した技術的要因

従来のAIセキュリティが「モデルへの入力(プロンプト)」を監視していたのに対し、Sentraは「モデルが参照する実データ(Data-at-Rest)」と「自律エージェントのアクセス認可経路」を直接制御するアプローチをとる。金融大手Capital Oneなどのエンタープライズに評価された主な技術的理由は以下の3点である。

1. In-Situ(インプレース)解析によるデータ境界の遵守

従来のデータスキャナは、解析のために社外のSaaS基盤へデータを複製・転送する方式が多く、以下の技術的・法的ボトルネックを抱えていた。

  • ペタバイト規模の走査に伴う莫大なクラウドエグレス(送信)コスト
  • 金融・医療規制におけるデータレジデンシー(越境移転)違反
  • ベンダー環境に「第2のデータエステート(攻撃対象領域)」が生成されるリスク

Sentraは顧客のVPC/アカウント内部に解析エンジンを配置し、データを社外に出さずローカル完結で解析する「In-Situ方式」を採用している。外部へ送信されるのはメタデータのみであるため、転送コストを最小化しつつ規制要件をクリアできる。

2. 「Effective Access(実効アクセス権)」と機密データのクロスグラフ解析

AIエージェントはサービスアカウントやAPIキーなどのNon-Human Identity(NHI)として動作する。IAMポリシー、ロール継承、グループ権限、SaaSトークンが複雑に絡み合う結果、「定義された権限」と「実際に到達可能なデータ(Effective Access)」に大きな乖離が生じる。 Sentraは、データの機密度分類(PII、知財、財務情報等)とID認可グラフを統合する。これにより、エージェントが本来必要としないナレッジベースやS3バケットを探索できる「過剰権限状態(Over-permissioning)」を特定し、プロアクティブに解消する。

3. Before / During / After の3フェーズ統合防御

インラインプロキシによる都度傍受に頼らず、ライフサイクル全体で統制を効かせる構造をとる。

フェーズ技術的メカニズム役割
Before (静的予防)非構造化データの自動カタログ化、不要・陳腐化データ(ROT)のパージ、最小特権化エージェント探索時の攻撃対象領域(アタックサーフェス)を最小化
During (動的検知・封じ込め)DDR(Data Detection and Response)による振る舞い異常検知機密データへの不審な大量クエリや想定外のNHIアクセスを検知し、API経由でアクセス権を即時Revoke
After (鑑識・コンプライアンス)エージェントの到達可能範囲・コンテキストログの監査レポート万一のプロンプトインジェクションや挙動異常時、どの実データに影響が及んだかを即座に立証

競合技術とのアーキテクチャ比較

AIセキュリティおよびデータセキュリティの各レイヤーにおける住み分けは以下の通りである。

項目Sentra (Agentic DSPM)従来のDSPM / DLP (Cyera, BigID等)LLM Gateway / プロキシ (Portkey, Lakera等)
防御の重心Data-at-Rest & 認可経路データカタログ / 静的コンプライアンスData-in-Transit / プロンプト
データ処理方式In-Situ(インプレース):顧客環境内で完結ベンダー側へのデータ複製や常駐エージェントを要するケースありプロキシ型:通信の中継・インライン傍受
AIエージェント (NHI) 対応人間+非人間(AI Agent)のEffective Accessを統合追跡主に人間のIAMアカウントやグループ権限が主眼プロンプト検査が中心で、ストレージ実体は見えない
ボトルネック耐性エージェントの実行速度・並行数に依存しない(データ側で防衛)大規模非構造化データに対するスキャンコストとエグレスの肥大化エージェント数・API呼出数に比例して遅延・コストが増加

導入実績

  • Lyft(CISO: Chaim Sanders): 「自社の開発チームはAI導入を迅速に進めたいと考えているが、セキュリティ側としてはエージェントを稼働させる前に『そのエージェントが環境内のどのデータにアクセスできるのか』を把握しておく必要があった。Sentraの導入により全環境のアクセス可否を可視化でき、セキュリティ部門がAI導入のボトルネックになるのではなく、安全なロールアウトを後押しできるようになった」と証言している。
  • エンタープライズ顧客基盤: 金融サービス、ヘルスケア、小売、ハイテクなど規制要件の厳しい業界を中心に急拡大している。

日本のエンジニア組織への今後の影響分析

CISAのZero Trust Maturity Model(Data Pillar)、NIST AI RMF、OWASP Top 10 for LLMs、および国内ガイドラインの策定を踏まえると、SentraのIn-Situ型データ統制は日本のインフラ・セキュリティ設計に以下の影響をもたらす。

1. ガイドライン準拠とCISA Data Pillarに基づく実装変革

  • 要請: デジタル庁「データガバナンス・ガイドライン」および米CISA「Zero Trust Maturity Model (Data Pillar)」は、インフラ境界ではなくデータそのもののカタログ化・アクセス可視化・暗号化・最小特権化を規定している。経産省「AI事業者ガイドライン」でもAI入力データの厳格管理が求められている。
  • 影響: 日本のエンジニアは、従来の「WAF/プロキシ型境界防御」から、データが存在するローカル環境(AWS/Azure/GCP/オンプレ)で直接分類・アクセス認可を行う自律パイプラインへの刷新を迫られる。

2. データ越境移転規制とIn-Situ方式の整合

  • 要請: 日本の改正個人情報保護法(第28条・第29条)では、外国の第三者へのデータ提供・委託に対する厳格な監督義務および本人同意が課されている。
  • 影響: データを海外ベンダーのSaaS環境へ複製・転送してスキャンする方式はコンプライアンス上の大きな障壁となる。顧客VPC内で完結しメタデータのみを扱うIn-Situ方式は、日本の金融機関・医療機関・官公庁におけるRAG/AIエージェント基盤の標準的な実装パターンとなる。

3. OWASP LLM06(過剰権限)への対策と社内RAG設計

  • 要請: OWASPの公式規格(LLM06: Excessive Agency)では、自律エージェントが過剰な権限を持つことによる意図せぬ機密漏洩・破壊操作を重大リスクとして定義している。
  • 影響: 日本企業での社内RAGやCopilot導入において、システムプロンプトによる指示だけでは権限統制が不十分であり、ストレージ・ベクターストア層での厳格な行・オブジェクト単位アクセス制御(Row/Object-Level Security)をCI/CD・データパイプラインに組み込む設計が不可欠となる。

アーキテクトが押さえるべき設計原則

  1. 認可境界をエージェントに委ねない: エージェントが社内APIやベクターストア、ファイルストレージを自律探索する構成において、LLMプロキシだけでデータ漏洩を防ぐことは不可能である。システムプロンプトの制約に頼らず、ストレージ/DBレイヤーでの認可(Row/Object-Level Security)を強制するデータ主導の設計を徹底しなければならない。
  2. NHI(Non-Human Identity)の権限設計を最優先課題とする: エージェントに紐づけるサービスアカウントやAPIキーは、静的な固定キーではなく、短命な一時的認証情報(Ephemeral Tokens)と厳密にスコープを限定した権限モデルへ移行する必要がある。
  3. データエンジニアリングとセキュリティの直結: 非構造化データがAIのナレッジベース(RAG)に取り込まれる前段階で、不要データのクレンジングと機密ラベリングを行うパイプラインをCI/CD・ETLに組み込むことが、エージェント暴走時のリスク半径(Blast Radius)を最小化する鍵となる。

参考リンク

Share this article コピーしました
WRITTEN BY

PlusWeb3 編集部

Web3・AI専門メディア

PlusWeb3 編集部は、ブロックチェーン・Web3・AIの最新動向をわかりやすくお届けする専門メディアチームです。業界経験豊富な編集者とリサーチャーが、信頼性の高い情報を厳選してお届けします。

コピーしました

Web3・AI・ディープテック領域のキャリアに興味がありますか?

業界特化メディアを運営する専門エージェントが、企業のカルチャー・技術スタック・選考ポイントまで踏まえてキャリアをご提案します。相談は完全無料です。