AIエージェントの操作をエンドポイントでブロック

ポリシー適用

ほかの製品は監視するだけ。

ZYBEは実行前に操作を拒否します。

AIエージェントがこれから行うツール呼び出しは、エンドポイント上で、エージェント自身の実行前チェックのタイミングに、あなたのルールに照らして判定されます。ルールが拒否すれば、コマンドは起動せず、ファイルは開かれず、サーバーは応答しません。モデルには理由が伝えられ、別の方法を試さないよう指示されます。プロキシもゲートウェイも、検査すべきトラフィックもありません。判断を適用するのはエージェント自身です。だからこそ、オフラインでも、すべてのノートPCで同時に効果を発揮します。

仕組みを図で見る

各エージェントでの適用状況

止めるもの

12種類の操作を、エンドポイント上で拒否

それぞれが1つのルールです。プロファイルごと、エンドポイントのグループごと、エージェントごとに、Report、Ask、Blockを設定できます。

適用範囲

12のエージェントをルールで管理し、それ以外は全面的に拒否

実行前フックを持つエージェントでは、ZYBEのフックが動作します。フックのないアプリはMCPサーバーを通じて動作し、それらはZYBEのシムを経由して実行されます。コンソールでは、実際に届いた呼び出しにもとづき、エージェントとエンドポイントごとに4つの状態のいずれかを表示します。Blocking、Recording、Seen、Silent、そして会社が拒否した製品にはNot allowedと表示されます。

エージェント

拒否の届け方

フック（管理設定内）

フック

フック（マシン全体へのインストール時は管理設定）

フックと管理ポリシー

フック（共有のGeminiフックファイル内）

設定内のシェルフック

ゲートウェイ内のZYBEプラグイン

MCPサーバーをZYBEのシム経由で実行

MCPサーバーをシム経由で実行

全面的に拒否：エンドポイントが実行権限を取り上げます

最後の行はフックがないため、ルールで呼び出しを1つずつ判定することはできません。その製品をそもそも許可するかどうかを会社が決め、エンドポイントがそれを適用します。ファイルが配置されているというだけで、コンソールがエージェントをブロック済みと数えることはありません。

エージェント自身の言葉で

拒否されるとこうなります

実際のセッションで、実際のエージェントに、ワークスペースで封じ込め済みのパッケージをインストールするよう依頼しました。どのエージェントも停止し、理由を引用し、再試行しませんでした。

コンソールで開いた脅威。注入された出力、その後のコマンド、概要、修正策

コンソールに表示された一連の流れ。取得したページに指示が届き、そのセッションで次のコマンドが続き、対処法が示されています。

4つ目の状態

Not allowed：入口がなければ、エンドポイントがアプリを拒否

ベンダーのクラウドやWeb上で動作し、ノートPC上にフックを置く場所がないアプリもあります。そうしたアプリについては、そもそも許可するかどうかを会社が決め、エンドポイントがその判断を適用します。アプリの実行権限を取り上げ、起動中であれば終了させ、会社が再び許可した時点で権限を戻します。Rulesで製品名を一度入力すれば、1分以内にすべてのエンドポイントがそのアプリを拒否します。インストールされていても拒否され、すべてのエンドポイントでNot allowedとして表示されます。エンドポイント上でこれができるのはZYBEだけです。

外部送信なし

判定は他社のクラウドではなく、マシン上で

コマンド、パス、ページ、プロンプトはエンドポイント上で読み取られ、送信されることはありません。コンソールに届くのは、一致したルール、判定結果、エージェント、ハッシュだけです。そこが、トラフィックを検査するゲートウェイとの違いです。ZYBEはエージェントの行動を見ており、会話の内容はあなたのものとして守られます。

1台のマシンにインストール

マシンから送信されるもの