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・データパイプラインに組み込む設計が不可欠となる。
アーキテクトが押さえるべき設計原則
- 認可境界をエージェントに委ねない: エージェントが社内APIやベクターストア、ファイルストレージを自律探索する構成において、LLMプロキシだけでデータ漏洩を防ぐことは不可能である。システムプロンプトの制約に頼らず、ストレージ/DBレイヤーでの認可(Row/Object-Level Security)を強制するデータ主導の設計を徹底しなければならない。
- NHI(Non-Human Identity)の権限設計を最優先課題とする: エージェントに紐づけるサービスアカウントやAPIキーは、静的な固定キーではなく、短命な一時的認証情報(Ephemeral Tokens)と厳密にスコープを限定した権限モデルへ移行する必要がある。
- データエンジニアリングとセキュリティの直結: 非構造化データがAIのナレッジベース(RAG)に取り込まれる前段階で、不要データのクレンジングと機密ラベリングを行うパイプラインをCI/CD・ETLに組み込むことが、エージェント暴走時のリスク半径(Blast Radius)を最小化する鍵となる。
参考リンク
- https://sentra.io/news/sentra-raises-150-million-agentic-data-security
- https://sentra.io/glossary/data-security-posture-management
- https://www.digital.go.jp/news/71bf19c2-f804-488e-ab32-e7a044dcac58
- https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf
- https://www.ppc.go.jp/personalinfo/legal/
- https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf
- https://www.nist.gov/itl/ai-risk-management-framework
- https://owasp.github.io/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf