メインコンテンツへスキップ
エージェントが十数個の MCP ツールにわたって自由に動き回るとき、事後に重要な問いは 決して「この 1 つのツールは安全か」ではありません — それは「エージェントが実際に 何を呼び出したか、ファイアウォールが何を決定したか、そしてどのルールがその呼び出しを した」かです。OrcaRouter はそれにひとつの場所から答えます:mcp 監査ログです。 MCP ゲートウェイmcp サーフェス上で評価する すべての tools/call は、ファイアウォールイベント — 判定、ツール、マッチしたルール、 それを発行したエージェントラン — として記録されるため、セッションをライブで監視したり、 後で再構築したりできます。 このページはそのトレイルを読むことに焦点を当てた手順です。ゲートウェイ自体、判定の 語彙、ルール DSL についてはファイアウォールファイアウォール:MCP サーバーを参照してください。
ここでのすべての読み取りはコンソール(またはセッション/アクセストークン — UserAuth — を使った REST API)から設定され、ロールゲートされています。sk-orca-... 形式のキーを持つのは /v1/* リレー呼び出しとファイアウォールゲートウェイルート だけです。

1. mcp 監査ログが記録するもの

各 MCP ツール呼び出しは、mcp サーフェス上にひとつのファイアウォールイベントを 生成します。イベントは「誰が何を呼び、ポリシーは何をしたか」に答えるのに必要なものを 運びます — そして運ぶべきでないものは運びません(ツール引数はリダクトされます、 §4を参照)。
verdictallow / audit / deny / sanitize / pending_approval / observe)、surface(ここでは mcp)、policy_namerule_label、そして 人間が読める reasonquarantine フラグは、所有元スキル が隔離モードにあるために保留された呼び出しをマークします。
tool_name(名前空間化された <server>.<tool>)、呼び出しが登録済みスキルに 帰属できるときの skill_namemodel_name、そして token_name
agent_run_idconversation_idrequest_id — セッションの呼び出しを グループ化したり、ひとつのリクエストからそれがファンアウトしたすべての呼び出しに ドリルダウンしたりするために使うキーです。
gap フラグは、アタッチされたポリシーが見たがどのルールにもマッチしなかった observe モードの呼び出しをマークします — 発見されたツールビューが、ポリシーが まだカバーしていないツールを表面化するために使うシグナルです。

2. フィードを読む

コンソールの Events タブが主要なビューです。同じデータをプログラム的に取得するには、 あなたのアクセストークンでイベントを一覧し、mcp サーフェスにフィルターします:
# Console route (UserAuth). Reading events requires Developer+.
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
verdict フィルターは単一の値またはカンマ区切りのセット(上の「拒否 + 保留」 プリセット)を受け付けます。サンプルイベント:
{
  "created_at": 1700000000,
  "surface": "mcp",
  "tool_name": "github.create_issue",
  "verdict": "deny",
  "policy_name": "Coding agent",
  "rule_label": "no writes to prod org",
  "reason": "rule matched: no writes to prod org",
  "agent_run_id": "run_8f3a",
  "model_name": "claude-sonnet-4-5",
  "token_name": "ci-agent"
}
ひとつのリクエストの完全なファンアウト — ひとつのリレーリクエストの下でモデルが呼び 出したすべてのツール — を再構築するには、request id でドリルインします:
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
生の行ではなくセッションレベルのロールアップが欲しいときは、 GET /api/workspace/firewall/events/aggregate?group_by=run(または group_by=session)を叩いてください — エージェントランごとに 1 行で、判定ごとの 内訳、個別のツール、初回/最終確認を伴います。トレースエンドポイント (/trace/runs/trace/by-run)はランの呼び出しツリーを再構築します。

3. サーバー統制の監査行

呼び出しごとのイベントは、エージェントがしたことを教えます。第 2 の、より小さな トレイルは、サーバーの統制に対してあなたがしたことを教えます — そしてそれが ラグプルのストーリーが存在する場所です。プローブが登録済みサーバーの アドバタイズされたツールセットがドリフトしたことを見つけ、管理者が再ベースライン化 または隔離すると、その決定はワークスペース監査ログに書き込まれます:
監査アクション書き込まれるとき
firewall_mcp_schema_changedプローブがライブツールセットが承認されたものからドリフトしたことを見つけたとき。
firewall_mcp_schema_approved管理者が新しいツールセットに再ベースライン化したとき。
firewall_mcp_schema_quarantined管理者がドリフトしたサーバーを隔離(および無効化)したとき。
各行はサーバー id、名前、ツール数を運びます — ツール引数やクレデンシャルは決して 運びません。これはラグプル防御の背後にある フォレンジックトレイルです:月曜に承認したサーバーは、ここに行を残さずに金曜に shell.exec ツールを静かに生やすことはできません。
ファイアウォールのポリシールール設定の変更は、これらと並んで独自の 監査行を書き込みます。プラットフォーム管理者が変更を行ったときは、それは中央の 管理者監査ログ(GET /api/admin/audit-logs、管理者専用)にも記録されます;通常の メンバーの編集はワークスペーストレイルに留まります。

4. 引数はデフォルトでリダクトされる

イベントストリームは、シークレットを漏らさずにチームが読めるように作られています。 ツール呼び出しの引数は決して逐語的に保存されません — イベントは多くてもキャップされ リダクトされた args_summary を運び、異常グルーピングに使われる生の引数ハッシュは 決してサーバーを離れません。
イベントがそのサニタイズされた引数スナップショットを運ぶため、events、aggregate、 trace エンドポイントは Developer+ にゲートされています — Viewer ロールのメンバーは ポリシーと発見されたツールを読めますが、別のメンバーの ツール呼び出しの来歴は読めません。それに応じてロールを計画してください。

5. ライブ監視:異常

事後に読むことは半分です;もう半分は、それが起きている間に知らされることです。 異常フィードは、MCP(とその他すべてのサーフェス)を、ワークスペースの学習された ベースラインから外れる挙動 — 週の時間帯プロファイルに対する頻度とコストのスパイク、 リトライループ、新規のツールパス — について監視し、ルールをひとつも書かずにそれらを 表面化します。
# Anomaly feed is open to any Member.
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
ノイジーなシグナルは、永久に黙らせることなくフィードを混雑させなくするために スヌーズ(最大 7 日)できます。異常の読み取りは Member に開放されています — イベントストリームより広い — なぜなら、それは引数ではなくシグナルを運ぶからです。
フィードをシャドウモードとペアにしてください:厳格化した ポリシーを audit-only でロールアウトし、イベントストリーム(reason[shadow] would … がプレフィックスされる)で would-be な拒否を監視し、フィードが 静かになったら昇格させます。

6. 保持と消去

ファイアウォールイベントは自動的に期限切れになります — それらは永久ストアではなく、 ローリングする監視ウィンドウです。ワークスペース監査行 (§3のサーバー統制トレイル)は最大 180 日保持されます。 そしてユーザーが削除されると、grace-then-scrub サイクルがファイアウォールイベントと マッチをカスケードするため、離脱したユーザーのツール呼び出しトレイルが残ることは ありません。
データレジデンシーと保持の制御はコンプライアンス プレーンにあります。mcp 監査ログはワークスペースの保持姿勢を継承します;サーバー ごとには設定しません。

7. 次のステップ

MCP セキュリティ概要

MCP 統制サーフェス全体 — ゲートウェイ、判定、スキル、egress。

ラグプル防御

§3 のドリフトイベント、端から端まで:検出、再ベースライン化、隔離。

MCP ツールの許可リスト化

監査ログが示すものをデフォルト拒否ポリシーに変えます。

ファイアウォール:MCP サーバー

完全なフィールドとルートのリファレンス。
このモデルが初めてですか? イベントが評価パスのどこで発せられるかについては OrcaRouter の検査方法を、クリーンな 監査トレイルが早期に捕捉する助けとなる脅威については 過剰なエージェンシーを参照してください。