メインコンテンツへスキップ
単一のツール呼び出しは完全に無害に見えることがあります。1 つの CRM レコードを読む： 許可。エクスポートツールを呼ぶ：許可。外部ホストに当たる：許可。実行の形 — 50 回の 読み取り、それからエクスポート、それから日曜午前 3 時に見たことのないホストへの egress — が攻撃です。呼び出しごとの判定は各呼び出しを 孤立して判断し、それを決して見ません。 このページは、1 回ずつではなく実行を時間をまたいで監視する 2 つのファイアウォール メカニズムをカバーします：シーケンスルール（あなたが作成する順序付けられた チェーン）と挙動異常検出（ワークスペースの学習された通常からの逸脱）。これらは 共に、単一の allow/deny ルールが捕捉できないエージェントの攻撃チェーン挙動を 検出する方法です。
ここのすべてはコンソール（Security → Firewall）で設定され、その管理ルートは セッション / アクセストークンを使い、リレーの sk-orca-… キーではありません。 エージェントの /v1/* 呼び出しは変わりません。

​
1. なぜ呼び出しごとのルールがチェーンを見逃すか

ファイアウォールのツールグロブと 引数句は、設計上ステートレスで決定論的 です — それらは 1 つの呼び出しを、高速に、ホットパス上で決定します。それが 「shell.exec rm -rf をブロック」に対してまさに欲しいものです。それは、すべての 個別の呼び出しが合法であるゆっくりと進む持ち出しに対してはまさに間違っています。 2 つの補完的なツールがギャップを埋めます：

シーケンスルール

時間ウィンドウ内の呼び出しの順序付けられたチェーンにマッチする、あなたが 作成するルール — 「バルク読み取り → エクスポート → egress」。あなたがパターンを 名指しします。

異常検出

ファイアウォールが各ワークスペースの通常のツール使用の形を学習し、逸脱を フラグします — リトライループ、見たことのないツールパス、ボリューム/コストの スパイク。作成するルールはありません。

​
2. シーケンスルール：攻撃チェーンを名指しする

sequence ルールは他のルールと同様にファイアウォール ポリシーの中に存在しますが、単一の tool_name_glob の代わりにステップの順序付けられたリストを運びます。各ステップは オプションの min_count とオプションの egress: true を持つツールグロブです； ステップは順序どおりに発生しなければならず（無関係な呼び出しと交互になるのは 問題ありません）、チェーン全体が window_seconds 内に完了しなければなりません。 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
これは、エージェントが 50 個以上の crm.* レコードを読み、それから任意の *.export ツールを呼び、それから任意の egress 呼び出しをする — すべて 10 分以内 — ときに発火 します。各呼び出しはそれ自体では通るでしょう；パターンがシグナルです。
シーケンスはそれを完了する呼び出しで評価されます。 インラインルールループは チェーンルールをスキップします（1 つの呼び出しがマルチステップチェーンを満たせません）； マッチは呼び出しがチェーンの最終ステップになりうるときに実行され、その時点で ファイアウォールはそのプリンシパルの最近のイベントを引き出してチェーンをテストします。 ルールに設定した verdict が、完了する呼び出しにその後起こることです：audit は それを記録して通し、pending_approval はそれを人間のレビューの ために保留し、deny はそれをブロックします。そのためチェーンはその最終呼び出しを リアルタイムで止めることができます — マッチさせる判定を選んでください。検出して アラートしたいだけのときは audit を使います；ハードな停止が必要なときは pending_approval または deny を使います（または呼び出しごとの deny / egress ルールと組み合わせます）。
完全な sequence フィールド構文 — 時間制限なしの window_seconds: 0、min_count のデフォルト、ステップ順序のセマンティクス — はルール スキーマにあります。シーケンスルールはコンソールの ルールエディタで作成します；保存は Developer+ のアクションです。

​
3. 異常検出：学習された通常からの逸脱

シーケンスルールが「この特定のパターンが起こったか」を問うのに対し、異常検出は 「この実行について何かがこのワークスペースにとって異常か」を問います。ルールは 不要です — ファイアウォールはあなた自身のトラフィックからベースラインを構築し、ライブ アクティビティをそれに対してスコアリングします。4 種類が表面化します：
（ツール, キー）ごとの呼び出しボリュームが、この曜日内時間の学習された ベースラインに対してスコアリングされます。カウントが絶対的な床をクリアかつ ベースラインに対して高く走るとき、またはその z スコアが統計的しきい値を超えるとき、 行が表面化します。そのため「日曜午前 3 時の 100 回の db.query 呼び出し」は、 火曜午後 2 時の同じサイズのバーストならそうでなくても際立ちます。
支出に適用された同じ考え：この曜日内時間の学習されたベースラインコストの数倍を 燃やすツール。denial-of-wallet の早期警告です — ハードな上限を強制するには cap_cost ルールと組み合わせます。
タイトなウィンドウで何度も繰り返す (conversation, tool, arguments) グループ — ゆっくりとした正当なポーリングではなく、同じ失敗するツールを同じ引数で何度も何度も 呼び続けるスタックしたエージェント。
このワークスペースがこれまで一度も行ったことのない tool_a → tool_b 遷移。 エージェントが初めて read_file から直接 http_fetch に行くとき、両方のツールが 個別には許可されていても、そのエッジが点灯します。

​
曜日内時間ベースライン

ベースラインは曜日内時間（weekday × 24 + hour）でバケット化された 14 日間の 移動平均です。そのため火曜 14:00 は、あなたの実際の日次・週次のリズムを洗い流す 平坦な全期間平均ではなく、特に過去の火曜 14:00 の履歴と比較されます。まだ学習された 通常のない真新しいワークスペースでも、絶対的な床を介して明白な洪水を捕捉するため、 初日から保護されます。
フィードはツール名、リダクトされたキー id、カウント、z スコアを報告します — 生のキー素材は決して報告しません。各異常は推奨される是正措置（rate_limit、review、 block_tool）を運ぶため、次のステップは推測ではなくワンクリックです。

​
4. 具体的なウォークスルー 1 つ

侵害されたプロンプトが、あなたのエージェントのひとつをタイトな失敗ループに駆り立て、 それから一度も触れたことのないエクスポートパスを探るとします。事前にルールを作成 しないで見るものはこうです：
1

エージェントが誤動作する

インジェクションされた指示がエージェントに、同一の引数で失敗する db.query を リトライさせ、それから report.export を呼び、続いてアウトバウンドフェッチを させます — このワークスペースが一度も実行したことのないパスです。
2

異常フィードを開く

Security → Firewall → Anomalies で、実行は db.query 上の retry_loop と report.export → http_fetch エッジ上の novel_path を表面化します。フィードの 読み取りは Member のアクションです — チームの誰でもトリアージできます。
3

events トレースで確認する

events ログと実行 分析へクリックスルーし、エージェント実行と会話に 相関付けられた正確な呼び出しシーケンスを見ます。異常フィードは Member 可読ですが、 events ログと実行トレースはツール呼び出しの来歴を運び、Developer+ です。
4

発見をルールに変換する

チェーンを見た今、それをエンコードします：危険なエクスポート上の deny、フェッチ上の egress 許可リスト、または次回パターン全体を audit するシーケンスルール。異常検出は未知を見つけます；ルールは既知を固定します。
チューニング中にフィードがノイジーな場合 — 例えば毎週日曜に本当にスパイクする正当な バッチジョブ — 調査中、異常フィードを最大 7 日間スヌーズします。スヌーズは Developer+ のアクションです；ウィンドウはサーバーでクランプされるため、検出は 常に自動で戻ってきます。

​
5. シーケンスルール vs. 異常検出

それらは隣接する問題を解決します — あなたが知っているものにマッチするものを選びます：
シーケンスルール異常検出
あなたが作成する正確なチェーン何も — 学習する
捕捉する既知のマルチステップパターン未知 / 異常
作用する完了する呼び出しにルールの判定を適用（audit / pending_approval / deny）フィードに表面化
成熟したワークスペースは両方を実行します：異常検出は予期しなかったチェーンを表面化 するレーダーです — 表面化のみで、決してブロックしません；シーケンスルールは持っている ものを成文化する方法で、ラベル付けされ、追跡され、（pending_approval または deny 判定で）完了する呼び出しをゲートできます。チェーンに関わらず単一の呼び出しをハードに 止めるには、呼び出しごとの判定に手を伸ばします。

​
6. RBAC とフィードの背後のルート

異常フィードとシーケンスルールはワークスペースファイアウォール管理ルートのもとに あります — セッション / アクセストークンで、決してリレーキーではありません：
メソッドとパスロール目的
GET /api/workspace/firewall/anomaliesMember異常フィードを読み取り（?window=）。
POST /api/workspace/firewall/anomalies/snoozeDeveloper+フィードをスヌーズ（{until}、7 日にクランプ）。
POST /api/workspace/firewall/rulesDeveloper+ポリシーのもとでシーケンス（または任意の）ルールを作成。
POST /api/workspace/firewall/testDeveloper+依存する前にサンプル呼び出しに対してポリシーをドライラン。
フィードの読み取りはチーム全体がトリアージできるようすべての Member に開放されて います；ルールの作成とフィードのスヌーズは Developer+ の書き込みで、 ファイアウォール RBAC モデルの 残りと一致しています。

​
次に進む場所

ルールスキーマ

完全な sequence フィールド — ステップ、min_count、window_seconds、そして 他のすべてのルールフィールド。

Events ログ

マッチしたシーケンスと異常が着地する場所 — 実行、サーフェス、判定でフィルタ。

コスト上限

burn_spike シグナルを実行ごとのハードな支出上限に変える。

Egress 制御

チェーンの最終持ち出しステップをネットワーク境界で止める。
これらのメカニズムが対抗する攻撃者のプレイブックについては、 連鎖攻撃、 データ持ち出し、 過剰なエージェンシーを参照してください。 詳細なファイアウォールリファレンスについては、 ファイアウォールルールを参照してください。