
kontext-cli v1.8.1
AIエージェントのランタイムセキュリティ:エージェントを検出し、その権限をマッピングし、実行可能な操作を強制します。
Website | Documentation | Dashboard | Discord
リスクのある AI エージェントの操作を実行前に停止する
AI エージェントはコードを提案するだけではありません。シェルコマンドを実行し、ファイルを読み取り、サービスを呼び出し、インフラストラクチャを変更し、本番システムとやり取りします。
Kontext は AI エージェントと呼び出されるツールの間にローカルポリシーを配置します。 サポート対象の操作を監視し、重要な操作が実行される前にポリシーを評価し、その決定と結果を認可台帳に記録します。
まずは監視モードから始めてください。ポリシーが何を停止するかを確認できます。準備ができたら、サポート対象の境界を強制モードに移行してください。
ポリシー評価エラーは、強制モードであってもツール呼び出しを許可し、アクティビティ記録に失敗として表示され続けます。完了したポリシー拒否と利用できない必須承認は引き続きブロックします。このエラーフォールバックは、デーモンが利用できない場合や強制に使用可能なポリシーがない場合の動作を変更しません。
- ローカルでの決定: ポリシー評価はエージェントと並行して行われます。
- 操作前の強制: 一致する操作は、サポート対象の同期フックで拒否できます。
- ラッパーコマンド不要: Kontext を一度インストールすれば、通常どおりエージェントを使い続けられます。
- 帰属可能な証拠: エージェント、セッション、操作、ポリシー決定、結果を保持します。
- 管理されたロールアウト: 組織全体でポリシーを配布し、編集済み記録をレビューできます。
Kontext は現在 Claude Code、Claude Cowork、Codex をサポートしています。正確なイベントおよび強制のカバレッジはエージェントによって異なります—エージェントサポートマトリックスを参照してください。
管理された Claude フックは、完全または短縮されたセッションディレクトリ名のいずれかで Cowork セッションを認識し、アクティビティ記録にその Cowork アイデンティティを保持します。
クイックスタート
Kontext のインストール
brew install kontext-security/tap/kontext
この Mac を接続する
Kontext ダッシュボードでインストールトークンを作成し、次を実行します:
kontext setup
オプションのローカルリスクモデルには llama.cpp が必要です: brew install llama.cpp を実行してから、kontext setup --with-local-llm を実行してください。
セットアップでは:
- インストールトークンを macOS ログインキーチェーンに保存します;
- サポート対象エージェントのフックをインストールします;
- ローカル Kontext デーモンを起動します;
- インストールを Kontext 組織に接続します。
インストールを確認します:
kontext doctor
その後は Claude Code または Codex を通常どおり使い続けてください。エージェントを別のラッパー経由で起動する必要はありません。
セルフサービスセットアップは現在 macOS をサポートしています。管理環境およびクラウド環境では、サポート対象のフック契約、ストレージ、デーモンライフサイクルが提供されていれば、同じローカルランタイムを実行できます。
セットアップ後、何が変わるのか?
操作前のポリシーがなければ、エージェントの操作はセキュリティチームがログをレビューする前に実行されます:
agent requests an action
|
v
action executes
|
v
activity appears in a log
Kontext を使用すると:
agent requests an action
|
v
Kontext receives it through a supported hook
|
v
local policy evaluates the action
|
+---- allow ----------> action continues
|
+---- would deny -----> action continues and evidence is recorded
| (observe mode)
|
+---- deny -----------> action is stopped before execution
(enforce mode)
|
v
decision and outcome enter the authorization ledger
これにより、操作の後に記録されるだけでなく、操作の前に決定ポイントが生まれます。
まず監視。準備ができたら強制。
初日にすべての不慣れな操作をブロックするとノイズが生じ、開発者の作業を中断させます。すべての操作を無期限に許可すると、ポリシーは受動的な監視のままになります。
Kontext はロールアウトを 2 つのモードに分離します:
監視モード
監視モードは、エージェントを中断せずにポリシー決定を記録します。
次の問いに答えるために使用します:
- エージェントはどのツールを呼び出しているか?
- 現在のポリシーはどの操作を拒否するか?
- どのリポジトリ、ファイル、システムが関与しているか?
- 強制はどこで正当な作業を中断するか?
- どのイベントサーフェスが実際に操作を停止できるか?
強制モード
強制モードは、サポート対象の同期操作前フックで決定論的ポリシーが一致したときに、実際の拒否を返します。
ポリシーは次のような操作の境界を定義できます:
- 破壊的なコマンド;
- 機密ファイルへのアクセス;
- 本番システムの操作;
- 認証情報へのアクセス;
- データのエクスポート。
強制は、エージェントが続行する前に Kontext を待つイベントサーフェスに意図的に限定されています。Kontext は、イベントを受信することがそのエージェントからのすべての操作を停止できることを意味するとは主張しません。
何が起きたか—そしてその理由を知る
Kontext に到達するすべてのサポート対象イベントは、ローカル認可台帳に証拠を提供できます。
記録には次のものを含めることができます:
- エージェントとセッション;
- ライフサイクルまたはツールイベント;
- ツール名と利用可能な入力;
- ローカルポリシー決定;
- その決定の原因となったポリシー;
- 利用可能な操作結果;
- 後でレビューするための編集済み証拠。
Kontext はツールアクティビティと決定証拠を記録します。モデルの推論をキャプチャしたり、完全な会話履歴を再構築したりすることはありません。
管理されたデプロイメントは、組織全体のレビュー、保持、調査のために、編集済み記録を Kontext ダッシュボードにエクスポートできます。
台帳のエクスポートとアイドルハートビートは、実行中のデーモンの CLI リリースを device.cli_version として報告し、device.deployment_version のパッケージマーカー(またはそのセルフサービスフォールバック)とは別に扱います。パッケージマーカーの更新は、新しいバイナリを実行しているデーモンがテレメトリを送信するまで、報告される CLI リリースを変更しません。
エージェントが実行される場所でのポリシー
決定パスはローカルに留まります:
Claude Code / Cowork / Codex
|
v
supported hook
|
v
local Kontext runtime
|
+-----+------+
| |
v v
policy decision local ledger
|
v
allow / would deny / deny
ホストされたサービスがすべてのツール呼び出しに応答する必要はありません。
管理されたデプロイメントは、組織構成、ポリシーロールアウト、記録エクスポート、アイデンティティ、保持を追加します。同期決定パスをエージェント環境の外に移動させることはありません。
サポート対象エージェント
「サポート対象」とは、イベントを受け入れるだけではありません。Kontext は、受信するイベント、ブロックできるイベント、各統合のインストール方法を文書化しています。
| Agent | Kontext が記録するもの | 操作前のブロック | インストール |
|---|---|---|---|
| Claude Code | セッションライフサイクル、ツール使用前、ツール使用後の成功と失敗 | ツール使用前 | kontext setup によりインストール |
| Codex | セッション開始、ツール使用前、ツール使用後、プロンプト送信、停止 | ツール使用前 | kontext setup によりインストール; フックは Codex で信頼される必要があります |
| Claude Cowork | Claude Code 互換のセッションおよびツールイベント | ツール使用前 | Cowork 環境内でフックを構成 |
正確な動作、デプロイメントスコープ、既知のギャップについてはエージェントサポートマトリックスを参照してください。これは強制カバレッジの権威ある情報源です。
Kontext とサンドボックスは異なる問題を解決する
プロセスサンドボックスは次のように問います:
このプロセスはどのファイル、ネットワーク宛先、認証情報、オペレーティングシステムリソースにアクセスできるか?
Kontext は次のように問います:
どのエージェントがどの操作を試みているか、どのポリシーが適用されるか、操作を続行すべきか、そしてその決定を証明する証拠は何か?
カーネルサンドボックスは強力な封じ込め境界です。Kontext はサポート対象のエージェントおよびツールフックで意味論的ポリシーと帰属を提供します。
これらは補完的です:
Kontext
decides whether the action is authorized
|
v
sandbox
constrains what the process can physically access
Kontext はカーネルレベルの分離を主張しません。脅威モデルがプロセス、ファイルシステム、またはネットワークの封じ込めを必要とする場合は、適切なサンドボックスを使用してください。
単にエージェントログを収集するだけではだめな理由
ログは、イベントの後にエージェントが報告した内容を伝えます。
Kontext は、サポート対象の重要な操作が実行される前に認可決定を作成し、その決定を利用可能な結果にリンクします。
この区別は次の場面で重要です:
- ポリシーロールアウト;
- インシデント調査;
- 本番アクセスレビュー;
- 開発者の例外処理;
- コンプライアンスおよび監査レビュー。
結果は単に「エージェントがツールを呼び出した」だけではありません。何が要求され、どのポリシーが適用され、許可されたかどうか、そして次に何が起きたかの証拠です。
組織全体で Kontext を実行する
管理されたデプロイメントは次を追加します:
- 集中管理された決定論的ポリシー;
- エンタープライズアイデンティティと組織コントロール;
- 監視から強制へのロールアウト;
- 管理されたエージェントおよびクラウドデプロイメントのサポート;
- 編集済み証拠のエクスポート;
- 監査保持;
- デプロイメントの健全性とバックログの監視;
- セキュリティおよびプラットフォームチームのオンボーディング。
デプロイメント計画と組織のオンボーディングについては、[email protected] に連絡するか、会話を予約してください。
インストールの診断
kontext doctor
doctor は次をチェックします:
- インストールされたエージェントフック;
- デーモンの健全性とバージョン;
- 管理されたエクスポートの健全性;
- 保留中のエクスポートバックログ。
構成されたインストールが異常な場合、非ゼロで終了します。
Claude フックの検証は、同等のシェルクォートを許容しつつ、期待される実行可能ファイル、引数、イベント設定を依然として要求します。Codex フック診断はシステムファイルとユーザーファイルの両方をチェックします: 一方が完全なインストールを含んでいれば、他方が存在しないか空であっても有効です。不正な形式または不完全な非空ファイル、および競合するインストールは依然として異常なセットアップを報告します。
所有された Claude ドロップインが現在のバージョンで必要なイベントのみを欠いている場合、doctor は欠落しているイベントとスコープ固有の hooks install コマンドを通知します。セルフサービス修復は Claude のシステムファイルを更新するためだけに sudo を要求します; 組織の修復には --scope system を伴う sudo が必要です。doctor --fix はフックを再インストールしません。
セルフサービスデーモンが古い場合:
kontext doctor --fix
セットアップを再度実行してインストールトークンをローテーションします:
kontext setup
セルフサービスインストールを削除します:
kontext setup --uninstall
データの取り扱い
- ポリシー決定はローカルで行われます。
- ツールアクティビティと決定証拠はローカルに保存されます。
- 機密値はローカル保存および管理されたエクスポートの前に編集されます。
- Kontext はモデルの推論や完全な会話履歴を保存しません。
- 管理されたデプロイメントは、編集済み記録を組織ダッシュボードにエクスポートできます。