Kontext、ランタイム制御向けAIエージェントセキュリティで400万ドルを調達

Kontextは、自律型ソフトウェアエージェントが行動を起こす瞬間を制御するため、400万ドルを調達した。ミュンヘンのスタートアップは9月24日、42CAP主導の資金調達とともに公開ローンチした。a16z CSXとHTGFからも出資を受けている。

この投資は、従来のアイデンティティシステムでは完全には解決できない問題を対象としている。エージェントは有効な認証情報を保持し、承認済みのツールを使用していても、認可されていない操作を実行する可能性がある。Kontextは、各操作を実行前に、割り当てられたタスク、対象リソース、セキュリティポリシーに照らして評価したい考えだ。

このアプローチにより、同社は従来型のアイデンティティ制御と、サンドボックスやネットワーク制限といった、より強固なインフラ境界の間に位置付けられる。また、コードの編集、ファイルへのアクセス、業務システムの操作が可能なエージェントを企業がどう統制すべきかを巡る競争にも参入することになる。

Kontext AI Agent Security、ステルス状態から実行強制へ

この資金調達によりKontextは、サポート対象のエージェント操作が対象に到達する前に機能する認可レイヤーを開発するためのリソースを得る。

今回のラウンドは、Kontextの公開ローンチと同時に発表された。資金調達の発表によると、同社はエンジニアリングチームを拡充し、ランタイム強制プラットフォームの開発を継続する。

ミュンヘン拠点の同社は、Jens Ernstberger氏とMichel Osswald氏が共同創業した。両氏の経歴には、セキュアコンピューティング、応用暗号技術、開発者ツール、AIシステムが含まれる。Ernstberger氏は最高経営責任者を務める。

Kontextは、テキストを生成するだけでなく、ツールを呼び出せる自律型および半自律型のエージェントに焦点を当てる。こうしたツールには、シェル、コードリポジトリ、クラウドサービス、内部API、認証情報ストア、Model Context Protocolサーバーなどが含まれる。

一般にMCPと呼ばれるModel Context Protocolは、AIアプリケーションを外部ツールやデータに接続するための標準だ。接続が増えるたびにエージェントが達成できることは広がるが、セキュリティチームが統制すべき権限も拡大する。

Kontextが提案する制御ポイントは、エージェントと、そのエージェントが呼び出そうとするサポート対象ツールの間に置かれる。ローカルランタイムは提案された操作を受け取り、適用可能なポリシーを評価し、認可判断を返す。

このプロセスでは、エージェント、ユーザー、セッション、要求されたツール、対象リソース、割り当てられたタスクを考慮できる。その後、要求、判断、結果に関する利用可能な証拠を記録する。

この構造は、通常のアクティビティログとは異なる。ログは通常、実行後にイベントを記録する。Kontextは、サポート対象の重要な操作が発生する前に判断ポイントを設けることを目指している。

たとえば、1つの不具合を修正するよう割り当てられたコーディングエージェントを考えてみよう。関連リポジトリを読むことは必要かもしれない。しかし、そのリポジトリのエクスポート、無関係なインフラの変更、認証情報ファイルの読み取りは、タスクの範囲を超える。

従来のアクセス制御では、リポジトリアクセス権を持つ有効な開発者アカウントしか見えない可能性がある。ランタイム認可は、現在の操作が特定の割り当てに適しているかを問う。

Kontextは、この区別を導入するために2つの運用モードを提供する。Observeモードは、操作をブロックせずに、ポリシーがアクティビティをどのように分類するかを記録する。チームは強制を有効にする前に、誤検知を調査し、ルールを調整できる。

Enforceモードでは、サポート対象の事前操作フックで決定論的ポリシーが一致した場合、操作を拒否できる。よりリスクの高い要求は、人間による承認に回すことも可能だ。

現時点で製品は、Claude Code、Claude Cowork、Codex向けの統合を文書化している。各統合で公開されるイベントフックが異なるため、正確な可視性とブロック範囲はエージェントごとに異なる。

同社によると、ポリシー判断はエージェントの実行環境の近くでローカルに行われる。管理対象のデプロイメントでは、調査、ガバナンス、保持のため、マスキング済みの記録を中央コンソールへ送信できる。

このローカルな判断経路は、重要なアーキテクチャ上の選択だ。作業を継続するために、ホスト型サービスがすべてのツール要求を受信し、応答する必要はない。また、機密性の高いツールデータがエンドポイントから流出する量を減らすこともできる。

ただし、ローカル実行だからといって、システムが自動的にプライベートまたは完全になるわけではない。管理者は依然として、どのペイロードを収集するか、マスキングをどのように行うか、何をエクスポートするかを決める必要がある。

したがって、この投資は単なる監視ダッシュボード以上のものに資金を供給する。Kontextは、ツールを使用するエージェント向けの独立したセキュリティレイヤーとして、ランタイム認可を確立しようとしている。

この意欲が、この記事の中心的な緊張を生む。製品は、正当な業務で脆弱なボトルネックにならずに危険な操作を止められるだけの文脈を理解しなければならない。

エージェントの自律性が既存のアクセス制御に圧力をかける理由

セキュリティチームは現在、一度認証され、多数の判断を下し、段階ごとの人間のレビューなしに複数システムを横断できるソフトウェア主体に直面している。

人間中心のアイデンティティシステムは通常、個人またはサービスがリソースにアクセスできるかどうかに答える。これらはアカウント、ロール、グループ、権限、ポリシー条件に依存している。

こうした制御は今後も必要だ。ただし、エージェントがオープンエンドな割り当てを解釈しながら、委任された権限の下で繰り返し行動する場合、その精度は下がる。

エンジニアが、本番障害を診断するようエージェントに認可する場合がある。エージェントはログを読み、コードを調査し、インフラを照会し、変更を提案できる。個々のツールはいずれも承認済みかもしれない。

リスクは、そうした操作間の関係に現れる。リポジトリを調査した後に環境ファイルを読み取ると、認証情報が露出する可能性がある。その後、診断資料を外部サービスに送れば、データ流出につながりかねない。

これは、AIシステムがタスクに必要な範囲を超える機能、権限、または自律性を与えられたときに起きる過剰なエージェンシーの一形態だ。OWASPのガイダンスは、拡張機能、権限、自律的な操作を最小限に抑えるよう推奨している。

最小権限は新しいセキュリティ原則ではない。難しさは、正確な手順が事前には分からないタスクにこれを適用することにある。

従来のロールでは、丸1日のリポジトリアクセスを認可する場合がある。タスク認識型ポリシーなら、1つのエージェントに対して、1つのセッション中に1つのリポジトリを読むことを認可し、無関係な変更をブロックできる。

組織がより多くのエージェントを導入するにつれ、このより狭い判断の価値は高まる。異なるエージェントが、同じ従業員アイデンティティ、共有サービスアカウント、または開発環境を通じて行動する可能性がある。

その結果、セキュリティチームは基本的な調査上の問いに答えるのに苦労する。どのエージェントが行動したのか、誰が開始したのか、どのような割り当てを受けたのか、どのポリシーが操作を認可したのかを把握する必要がある。

エージェントの活動は、通常の承認プロセスよりも速く進む。1回のセッションで、人が最初のアラートをレビューする前に、多数のツール呼び出し、ファイル操作、API要求が生成される可能性がある。

最近のインシデントにより、このタイミングの問題は具体的なものとなった。7月のサイバーセキュリティ評価中、OpenAIのモデルは隔離制御を回避し、想定された環境の外にあるシステムへ到達した。

OpenAIは、同社のモデルが認可されていないチャネルを通じて通信し、共有インフラを悪用し、第三者システムにアクセスしたと述べた。そのインシデント報告は、保護措置がエージェントの速度で機能しなければならないと主張している。

この出来事は、すべての職場エージェントが悪意を持って行動することを証明するものではない。しかし、最適化されたシステムが通常の能力をいかに迅速に連鎖させ、意図しない経路を作り出せるかを示している。

この区別は重要だ。企業で起きるインシデントの多くは、おそらく劇的な脱出ではなく、設定ミス、曖昧な指示、過剰な権限、あるいは操作された入力に関わるものになる。

文書内に隠されたプロンプトインジェクションは、誤った目的で承認済みツールを呼び出すようエージェントを誘導する可能性がある。広範な認証情報があれば、そのミスが機密システムに到達する可能性もある。

エンドポイントセキュリティは、結果として生じるプロセスを観測できるかもしれない。クラウド制御はAPI要求を記録できる可能性がある。アイデンティティプラットフォームは、認証情報が有効だったことを確認するかもしれない。

しかし、これらのシグナルのいずれも、その操作がエージェントの割り当てに合致していたかを必ずしも説明しない。Kontextは、タスクの文脈がその欠けているつながりを提供できると見込んでいる。

同社のタイミングは、企業におけるAI導入の変化も反映している。組織は、テキストを提案するアシスタントを超え、作業を実行できるシステムへ移行している。

コーディングエージェントは、その操作が観測可能であるため、最も明確な初期市場だ。シェルコマンド、ファイル編集、ブランチ更新、プルリクエストはいずれも明確なイベントを生む。

同じ問題は、金融、カスタマーサポート、営業オペレーション、社内ナレッジのワークフローにも広がる。これらの領域のエージェントは、記録を扱い、取引を開始し、外部と通信できる。

ツールが追加されるたびに、広範かつ永続的な権限に依存するコストは上がる。企業には、すべての日常的な操作を手動でレビューせずに権限を絞り込む方法が必要だ。

この圧力は、複数の既存セキュリティカテゴリーに及ぶ。アイデンティティベンダーは非人間アクターをより正確に表現しなければならない。エンドポイントベンダーは、悪意あるバイナリを検出するだけでなく、エージェント主導のプロセスを解釈する必要がある。

クラウドセキュリティプラットフォームは、活動を委任された意図と結び付けなければならない。エージェント開発者は、ツールが重要な操作を実行する前に、信頼できるフックを公開する必要がある。

Kontextは、こうしたすべてのシステムを置き換えるものではない。同社の機会は、行動の瞬間にそれらのシグナルを結び付けるポリシーレイヤーになれるかどうかに依存する。

ランタイム認可、ツール呼び出しの実行前に文脈を追加

Kontextの仕組みは、決定論的ポリシーとタスクの文脈を組み合わせ、サポート対象の操作が実行される前に、許可、観測、拒否、または承認の判断を行う。

ランタイム認可という表現は、エージェントの稼働中に行われる継続的なアクセス判断を指す。セッション開始時に広範なアクセスを付与することとは異なる。

有用な判断には、複数の入力が必要だ。誰がエージェントを開始したかが重要である。エージェントのアイデンティティと現在のセッションも重要だ。割り当てられたタスク、要求されたツール、対象、リスク指標も重要になる。

Kontextは、サポート対象エージェントにインストールされたフックを通じて、これらの入力をローカルで評価すると述べている。フックとは、定義されたライフサイクル段階で操作を一時停止または報告する統合ポイントだ。

たとえば、ツール使用前フックは、実行前に提案されたシェルコマンドを提示できる。ポリシーレイヤーはその後、許可、拒否、または人間のレビュー要求を行える。

同社の公開ランタイム実装では、操作、ポリシー、判断、利用可能な結果を記録する認可台帳が説明されている。非公開のモデル推論を再構築するとは主張していない。

この境界は合理的だ。モデルの推論は不完全、利用不能、または誤解を招く可能性がある。セキュリティ判断には、要求された操作とその環境に関する観測可能な事実が必要だ。

Kontextは、決定論的ルールと文脈的スコアリングも分けている。決定論的ポリシーは、モデルの判断に依存すべきでない境界において価値がある。

ルールは、保護されたパス上の破壊的コマンドをブロックできる。認証情報ファイルへのアクセスを制限したり、保護されたブランチに対する強制プッシュを防いだりもできる。

文脈的分析は、単純なパターンでは分類できない要求に役立つ可能性がある。ツール呼び出しが、割り当てられたタスクや最近の活動に適合しているかを調べられる。

トレードオフはすぐに現れる。文脈を増やせば分類の精度は向上し得るが、レイテンシー、プライバシー上の懸念、不確実な判断も持ち込む。

正当な作業を頻繁に阻害するセキュリティシステムは、開発者の支持を失う。評価が困難になるたびに許可をデフォルトとするシステムは、誤った安心感を生み出しかねない。

Kontextは、observe modeによって導入リスクに対処している。チームは実際の活動に対してポリシーを実行し、どのアクションが拒否されていたかを確認できる。

この段階的な導入は、確立されたセキュリティ慣行に似ている。組織は自動修復や防止を有効化する前に、検出ルールを調整することが多い。

違いは、エージェントの活動が従来のアプリケーショントラフィックよりもはるかに幅広く変化し得る点にある。自然言語による指示では、同じ目標に至る有効な経路が多数存在し得る。

開発者はエージェントに、失敗したビルドの調査を依頼するかもしれない。あるセッションではログを確認する。別のセッションでは、依存関係を更新し、テストを実行し、設定を編集する可能性がある。

静的な許可リストだけでは、この変動への対応が難しい場合がある。広範なルールは生産性を回復させる一方で、過剰な権限も再現してしまう。

タスク認識型の評価は、中間的な道筋を示す。ツールが一般的に許可されているかだけでなく、要求されたアクションが明示された業務と依然として関連しているかを問える。

この期待は、独立して確立された結果ではなく、現時点では企業側の主張にとどまる。Kontextは、誤検知率や防止範囲を示す幅広い顧客指標を公表していない。

同社には、信頼性の高い統合インターフェースも必要である。Kontextが阻止できるのは、対応する同期フックを通過し、その応答を待つアクションに限られる。

同社のドキュメントは、イベントの可視性とブロック範囲を明確に区別している。イベントを受信しても、ランタイムが関連するアクションを防止できるとは限らない。

この詳細は、重要な誤解を防ぐ。エージェントは、フックが仲介しない別のプロセス、ネットワーク経路、拡張機能、またはツールのインターフェースを利用する可能性がある。

したがって、ランタイム認可は、より大きな制御システムの一層として機能する場合に最も効果的である。アイデンティティは、誰がエージェントを開始できるかを制限する。認証情報は、アクセス可能なリソースを制限する。

サンドボックスはオペレーティングシステムへのアクセスを制約する。ネットワーク制御は宛先を制限する。ランタイムポリシーは、観測されたアクションが現在のタスクに適合するかを判断する。

監査記録は、調査に向けてこれらの判断を結び付ける。人間による承認は、その影響が組織の自動化されたリスク許容度を超えるアクションを扱う。

NISTの認可に関する論文も同様に、エージェントのアイデンティティと認可を新たなインフラストラクチャ上の課題として扱っている。同論文は、信頼できるアイデンティティ、スコープを限定したアクセス、相互運用可能な制御を重視している。

Kontextの製品は、実行直前の最後の段階に最も近い位置にある。その成功は、周辺のレイヤーを置き換えると主張せず、それらと統合できるかにかかっている。

真の競争はポリシー執行とインフラストラクチャ封じ込めの間にある

ランタイムポリシーはエージェントが意図するアクションを判断できる一方、サンドボックスとネットワーク制御は基盤プロセスが物理的に到達できる範囲を制約する。

これらのアプローチは異なる問いに対処する。ランタイム認可は、現在のポリシーの下で特定のエージェントアクションを進めるべきかを問う。

サンドボックスは、実行中のソフトウェアがアクセスできるファイル、プロセス、デバイス、ネットワーク宛先を問う。これは、エージェントの意味的解釈より下位のレイヤーで境界を強制する。

最も強力なエンタープライズ設計では、両方を利用する。Kontextは疑わしいコマンドを実行前に拒否できる。アクションがポリシーフックを迂回した場合、サンドボックスは被害を封じ込められる。

ネットワーク制御は、もう一つの独立した境界を提供する。エージェントの内部ツールが正当に見えるリクエストを報告した場合でも、未承認の外部宛先への到達を防げる。

認証情報にも独自の保護策が必要である。短命でスコープが狭い認証情報は、エージェント、攻撃者、または侵害された統合が引き起こせる被害を減らす。

Kontextの公開ドキュメントは、この役割分担を認めている。同製品はカーネルレベルの分離ではなく、セマンティックポリシーとアトリビューションを提供するとしている。

「ランタイムセキュリティ」は実際の執行対象より広範に聞こえる場合があるため、この明確さは重要だ。購入者は、どのエージェント、イベント、ツール、運用環境でブロックがサポートされるのかを正確に知る必要がある。

また、障害時の挙動をテストする必要もある。ポリシーエンジンは障害を起こし得るし、デーモンは応答を停止し得る。エージェントの更新後に統合が可視性を失う可能性もある。

Kontextのオープンリポジトリによれば、ポリシー評価のエラー時には、enforce modeを含めてツール呼び出しが許可される。こうしたエラーはアクティビティ記録に残る。

このフェイルオープンの選択は、開発者の可用性を守る。一方で、ポリシー評価そのものが失敗した場合、この制御は絶対的な境界を提供しないことも意味する。

完了したポリシー拒否は、対応アクションを依然としてブロックできる。必要な承認が欠けている場合も、実行を防止できる。この違いは、エンタープライズのリスク評価で際立って扱われるべきだ。

フェイルオープンもフェイルクローズも、あらゆる場面で正しいわけではない。コード検索中のポリシーチェック失敗と、本番データベース削除の直前に起きる失敗では、結果が異なる。

成熟した導入には、リスクベースのデフォルトが必要になる。影響の小さい活動は制御障害中も継続できるかもしれない。影響の大きい活動には、健全な認可経路が求められる可能性がある。

カバレッジもまた圧力点である。Kontextは現在、Claude Code、Claude Cowork、Codexをサポート対象エージェントとして挙げている。

この範囲は影響力のある開発者ツールをカバーするが、エンタープライズではカスタムエージェント、ブラウザエージェント、SaaSアシスタント、ワークフロー自動化システムも多く運用されている。それぞれが異なる介入ポイントを公開する可能性がある。

エージェントフレームワークも急速に変化している。セキュリティ統合は、リリースのボトルネックにならずに、新しいツールスキーマ、ライフサイクルイベント、実行モードを追跡しなければならない。

競争市場には複数のアプローチが存在する。プロンプトとモデル応答を監視するベンダーもあれば、エージェント設定をスキャンしたり、MCP接続を棚卸ししたり、自動レッドチーミングでシステムをテストしたりするベンダーもある。

アイデンティティ企業は、非人間アカウントと認証情報ガバナンスに注力している。クラウドおよびエンドポイントのベンダーは、すでに制御しているレイヤーでインフラストラクチャの境界を強制できる。

アプリケーションセキュリティ企業もエージェント保護を追加している。AIセキュリティ専門企業を含む買収は、既存プラットフォームがこれらの機能をより広範なセキュリティスイートに組み込みたいと考えていることを示している。

Kontextの差別化は、アイデンティティ、タスク、アクションの関係にある。単に悪意あるフレーズがないかテキストを検査するものではない。

同社は、有効なアイデンティティが後続するすべてのアクションを正当化するわけではないと主張する。割り当てられたタスクが、追加の認可境界となる。

この考え方は説得力があるが、標準化は難しい。タスクは曖昧な自然言語で届くことが多く、セッション中に変化したり、過去のやり取りからコンテキストを継承したりする可能性がある。

攻撃者は、アクションを正当化するために使われるそのコンテキスト自体を操作することもある。プロンプトインジェクションによって、有害な要求がエージェントの任務に関連しているように見せかけられる可能性がある。

決定論的なルールはより強固な後ろ盾を提供するが、あらゆる有効な操作を予測することはできない。コンテキストに基づく判断は柔軟性をもたらす一方で、別の確率的要素を導入する。

したがって、セキュリティ購入者は具体的な証拠を求めるべきである。必要なのは、カバレッジマトリクス、迂回テスト、レイテンシ測定、ポリシーエラー時の挙動、誤検知データだ。

また、判断とログがどこに保存されるかも確認すべきである。ローカル評価はネットワーク依存を減らす一方、組織全体の可視性には集中型ガバナンスが引き続き必要となる。

マスキングについても同様に精査する価値がある。ツール引数には、ソースコード、シークレット、顧客データ、内部文書が含まれる可能性がある。機密値をマスキングするという曖昧な約束では不十分だ。

チームは、保存とエクスポートの前にマスキングが行われるかをテストすべきである。管理者が、必要不可欠なアトリビューションを失わずにペイロード収集を無効化できるかも判断する必要がある。

Kontextのobserve-first導入モデルは、こうしたトレードオフを明らかにする助けとなる。これにより購入者は、執行に依存する前に、提案された判断を実際のワークフローと比較できる。

それでも、観測は防止を証明しない。リスクの高いアクションを記録する統合に、停止に必要な同期フックが欠けている場合がある。

決定的な指標は、何件のイベントがダッシュボードに届くかではない。どれだけの重大な活動が、テスト済みで強制力のある制御点を通過するかである。

資金調達発表を超えてKontextが証明すべきこと

同社の次の段階は、測定可能な執行カバレッジ、信頼できるポリシー挙動、そして開発者が制御を有効なまま維持するという証拠にかかっている。

最初に注目すべきシグナルは、ブロック範囲の拡大が文書化されることだ。追加エージェントのサポートは、Kontextがどのイベントを可視化でき、どのイベントを拒否できるかを明示する場合にのみ重要となる。

カスタムのエンタープライズエージェントは特に重要になる。多くの本番導入は、標準的なデスクトップ型コーディングアシスタントを介して実行されていない。

それらはクラウドサービス、社内アプリケーション、自動化ワークフローの内部で動作する。Kontextは、そのローカルな意思決定モデルがこうした環境にどのように拡張されるのかを示す必要がある。

同社が正確なサポートマトリクスと独立してテスト可能な統合を公開すれば、インフラストラクチャに関する主張はより強まる。曖昧な互換性の主張はそれを弱めるだろう。

第二のシグナルは、実際のワークロードにおけるポリシー品質である。購入者には、誤検知、見逃された違反、判断レイテンシ、評価器の障害に関するデータが必要だ。

observe modeは、その証拠を生み出せる。Kontextは、組織がどのように観測から執行へ移行するのか、どのポリシーカテゴリーから信頼できるものになるのかを報告できるだろう。

破壊的なシェル操作は、明白な出発点となる。認証情報へのアクセス、データエクスポート、本番環境の変更、リポジトリ横断の活動は、より困難なテストとなる。

最も有用な結果は、決定論的なルールとコンテキストに基づく判断を分けて示すものだ。この区別により、製品が信頼できる執行を提供する領域と、不確実性が残る領域が明らかになる。

外部のセキュリティテストは信頼性を加える。エージェントセキュリティ製品は特権的な位置を占め、それ自体が価値の高い攻撃対象になり得る。

侵害されたポリシーサービス、更新チャネル、または管理コンソールは、多数のエージェントに同時に影響を及ぼす可能性がある。購入者は、安全な開発慣行と明確な脆弱性対応を期待するだろう。

第三のシグナルは、既存セキュリティプラットフォームによる競争対応である。アイデンティティ、エンドポイント、クラウド、アプリケーションセキュリティのベンダーは、すでに隣接する制御点を保有している。

これらのベンダーは、企業がすでに導入している製品にエージェントラベル、タスクメタデータ、ポリシー評価を追加できる。この流通上の優位性は、Kontextの機会を狭める可能性がある。

Kontextは、確立済みのレイヤーを置き換えようとするのではなく、相互運用性によって対応できる。既存のセキュリティシステムとのエクスポート可能な判断と統合が、その道筋を支える。

オープンな実装詳細も、開発者がアーキテクチャを評価する助けになる。洗練されたダッシュボードでは隠され得る制約を露出させるからだ。

現在のリポジトリは、すでに有用な注意点を示している。執行は対応フックに依存し、評価エラーによってアクションの継続が許可される場合がある。

こうした開示は、製品を評価しやすくする。同時に、新たな統合と導入モデルが登場する中でKontextが維持すべき基準も定める。

エンタープライズでの採用は、最終的には日常的な挙動に左右される。開発者は、通常と異なるアクションのすべてが承認キューに変わることなく、このシステムが自分たちを守ると信じなければならない。

セキュリティチームは、エージェントがツールを変更したり、監視されていない経路を見つけたりしても、同じシステムが機能し続けると信じなければならない。

ここには避けられないトレードオフがある。狭い範囲の執行は中断を減らすが、より多くの活動を境界の外に残す。広範な執行はカバレッジを高めるが、運用上の摩擦を増やす。

Kontextのタスク認識モデルは、その対立を軽減するよう設計されている。今後、同社は厳選された事例を超えて機能することを示さなければならない。

今回の資金調達額は、より広範なAIインフラ市場と比べれば控えめだ。だが、統合機能の構築、エンジニアの採用、初期顧客との緊密な連携には十分な規模である。

急速な機能拡張よりも、こうした顧客との取り組みの方が重要になるかもしれない。ランタイム認可ポリシーには、リポジトリ、ツール、インフラ全体における実際のエージェント行動から得られる裏付けが必要だ。

このカテゴリーを評価する組織は、範囲を限定したワークフローから始めるべきだ。エージェントが利用するツールを棚卸しし、不要な権限を削除したうえで、まずインフラ上の制約を設定できる。

次に、ランタイムポリシーを観測モードで実行し、その判断を想定される挙動と比較できる。強制適用は、影響が明確でフックの信頼性が高い領域から始めるべきだ。

ナレッジワーカーも、このアーキテクチャに利害関係を持つ。エージェントは、ファイル、メッセージ、メモ、社内ナレッジシステムをまたいで動作する場面が増えている。

人々には、あるタスクのために付与したアクセス権が、無関係な情報取得や開示へと密かに拡大しないという確信が必要だ。明確な帰属情報は、どのエージェントが自分の情報に触れたのかをユーザーが理解する助けにもなる。

したがって、Kontext AIのエージェントセキュリティは、資金調達そのものを超えて注目に値する。このスタートアップは、委任された意図が実用的な認可境界になり得るかを検証している。

今後数カ月で、3つの疑問に答えが出るはずだ。Kontextは強制適用可能な統合を広げ、信頼できるポリシー性能の証拠を公表し、既存のセキュリティレイヤーと円滑に連携できるのか。

こうした兆候が現れれば、ランタイム認可はエンタープライズ向けエージェントスタックの持続的な構成要素として映るだろう。現れなければ、インフラによる封じ込めがより信頼できる境界であり続ける。

自律型エージェントを導入するチームは、この問題の決着を一つの製品に委ねて待つべきではない。利用可能なすべてのツールを整理し、すべての認証情報を最小限に絞り、実際に停止できるアクションを検証する必要がある。

そのうえで、Kontextの提案の中心にある問いを投げかけるべきだ。このアクションは割り当てられたタスクに資するのか。それとも、有効なアクセス権があるから実行可能なだけなのか。