メインコンテンツへスキップ
コーディングエージェントはあなたのワークスペースで最もレバレッジが高く、最も 危険なものです。shell.exec を実行し、ファイルを編集し、URL を取得し、コミュニティ スキルをロードします — そのどれもが、ボリュームを rm -rf し、.env を読み、あるいは 攻撃者ホストへ持ち出す可能性があります。このレシピは、そのサーフェスを ファイアウォールでロックダウンします:破壊的シェルを deny し、 許可する呼び出しの引数を検証し、egress を囲い、本当にリスクのある操作を人間のために 保留します。そのどれもがあなたのエージェントのコードに触れません — ポリシーは ゲートウェイに存在し、次の呼び出しで強制されます。
以下はすべてコンソール(Firewall → Posture / Policies)で設定されます。それらの 管理ルートはリレーキーではなく、あなたのコンソールセッションを使います。sk-orca-… キーを運ぶのは、あなたのエージェントが行う /v1/* 呼び出しだけです。ポリシー編集には Developer ロールが必要です。

1. ブロックではなく監視から始める — セキュアコーディングエージェントのベースライン

ルールを盲目的に作成しないでください。エージェントに sk-orca-… キーを与え、それから Firewall → Posture を開いて balanced 自律性レベルを適用します。ひとつの トランザクションで、これはすべてのツール呼び出しを audit し、PII を flag し、そして 破壊的シェルを deny します — つまり、エージェントの残りの振る舞いを実トラフィックから 学ぶ間、最悪のアクションは既に囲い込まれています。 実行させてから、Firewall → Discovered tools を読みます:ワークスペースが見たすべての ツールが、covered(ルールが適用される)または gap(何も適用されない)と フラグされています。そのリストがあなたの許可リストの下書きです。フィードが正しく 見えたら、tight(デフォルト deny)に移るか、下記のターゲット化されたポリシーを 作成します。
balanced は推奨される開始姿勢です;permissive は何もブロックしませんが依然として すべてをログします;tight はデフォルト deny に加えて secrets と SSRF のプリセットです。 それぞれが正確に何を具現化するかは ベースラインを参照してください。

2. 破壊的シェルを deny する — 譲れない下限

コーディングエージェントにとって唯一最も重要なルールは破壊的シェルなしです。 balancedtight の自律性レベルは既にこれを Block destructive shell プリセットとして出荷しており、ワークスペース直接のツール名(shell.*bashcmd.*powershell.*exec.*)と、登録済みサーバーが公開する MCP 名前空間化された 形(*.shell.**.cmd.*、…)の両方をカバーする、実在の編集可能な deny ルールを 具現化します。 「すべてのシェルを deny」よりタイトにスコープしたい場合は、破壊的なコマンドのみを deny し、残りを audit する 1 つのルールを作成します。ルールはツール名グロブに加えて、 オプションの引数述語(呼び出しの引数に対する JSONPath)でマッチします:
Firewall → Policies で、デフォルトの上にルールを追加します:
  • Tool glob: shell.exec
  • Args match(JSONPath 句):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Verdict: deny
引数演算子はクローズドセットです — eqcontainsregexincidr_matchgtlt$.command が正規表現にマッチする呼び出しはブロックされます; それ以外はすべて次のルールへフォールスルーします。
inbound サーフェスで拒否された呼び出しは、エラーコード firewall_blocked と、 ツールと理由を示すメッセージとともに HTTP 400 を返します。MCP ゲートウェイ経由で ディスパッチされた呼び出しはツールエラーfirewall deny: …)として返ってくる ため、モデルはクラッシュする代わりに反応できます。inbound ブロックは アップストリームのモデル呼び出しの前に発火するため、モデルトークンを消費しません。
完全なマッチング言語(ツールグロブ、引数句、シーケンス、コスト上限)については ファイアウォールルールを参照してください。

3. 残すツールの引数を検証する

ツールを許可することは、それへのすべての引数を許可することと同じではありません。deny を スコープするのと同じ JSONPath 述語で、許可された呼び出しのを制約できます — つまり db.queryDROP を運べないようにし、file.write がディレクトリを脱出できない ようにします。

SQL DROP をブロックする

グロブ db.query、句 {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}、判定 deny

引数内のシークレットをリダクトする

判定 sanitize は、呼び出しが転送される前にツール呼び出しの引数から マッチした部分文字列をリダクトします。ツールが返すものには決して触れません; inbound サーフェス(まだ呼び出し時の引数がない)では block にエスカレートします。
ファイアウォールはツール呼び出しの引数をサニタイズするのであり、ツールの結果では ありません。そもそもシークレットがリクエストに入るのを止めるには、Secrets Blocker ガードレールをキーにアタッチします — これは モデルが見る前にプロンプトテキスト自体をスクリーニングします。2 つのプレーンは 構成されます:ガードレールはテキストをスクリーニングし、ファイアウォールはアクションを 統制します。

4. egress を制御する — エージェントが到達できる先を囲う

URL を取得できるコーディングエージェントは、SSRF(クラウドメタデータや内部の 10.x ホストへの到達)へ操られたり、持ち出しに使われたりし得ます。tight 自律性レベルは、 fetch 形のツール名http_fetchweb_searchfetch_urlrequest、および それらの <server>.* 形)を完全に deny する SSRF プリセットを出荷します。 宛先レベルの制御のために、egress ルールを作成します。egress ルールは host または CIDR で allow / deny エントリによってスコープし、egress サーフェスで評価されます:
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
これは、ツールが報告するアウトバウンド宛先のうち、プライベート範囲、クラウド メタデータ IP、あるいは内部ホスト名に着地するものに発火します — 公開宛先を通しつつ、 危険なものを囲います。
CIDR ベースの egress ルールを出荷するプリセットはありません — SSRF プリセットは fetch 形のツール名にマッチします。上記の host/CIDR 拒否リストは、あなた自身が作成する ものです。完全なパターンについては 持ち出しを止めるを参照してください。

5. リスクのある操作を人間のために保留する(HITL)

一部の操作は、自動許可も自動拒否もすべきでないものです — デプロイ、git push、 破壊的マイグレーション。それらには pending_approval 判定を使います。呼び出しは 保留され、エージェントは承認 id 付きの「保留中」レスポンスを受け取り、レビュアーが 帯域外でそれを解決します:
  1. ルールを作成します(例:グロブ deploy.*、判定 pending_approval)。
  2. 保留された呼び出しは、承認 id とともに HTTP 400 firewall_approval_pending を 返します。
  3. レビュアーがコンソールから(Developer+)、または HMAC 署名付き webhook コールバック経由でそれを承認します。
  4. エージェントが承認をポーリングし、単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに元の呼び出しを再送信します — ゲートウェイはその一度だけ通します。
新しいポリシーはまずシャドウモードでロールアウトします。ポリシーは本番と全く同様に 評価・ログを取りますが、すべての強制判定は [shadow] would … という理由とともに audit に格下げされます — つまり、ビルドを壊し得る前に、期待どおりに発火することを 証明できます。

6. ロードするスキルと MCP サーバーを統制する

コーディングエージェントは実行時にケイパビリティを取り込みます — コミュニティスキル、 BYO MCP サーバー。ファイアウォールはその両方をゲートウェイで統制します:
  • スキルは、強制モード(allow / quarantine / block)とともにリスクバンドへ スキャンされます。自動検出されたスキルは、レビュアーがクリアするまで quarantine されます — 承認のために保留されます。 スキルを参照。
  • 登録した MCP サーバーは、すべての tools/call をゲートウェイ経由でディスパッチ し、ゲートウェイはディスパッチ前に mcp サーフェスで各々を評価します。クレデンシャル は暗号化されて保存されます;ヘルスプローブは ok / degraded / down を報告します。 MCP サーバーMCP エージェントを強化するを参照。

7. 検証して観察する

ポリシーに依存する前に、ドライランします。Test タブは、現在のポリシーに対して サンプルのツール呼び出しを評価し、判定、マッチしたルール、理由を表示します — 何も ディスパッチされず、何も永続化されません。ライブになったら、Firewall → Events / Runs がすべての評価の記録であり、判定、サーフェス、ツール、run でフィルタ可能です。そして 異常フィードは、ワークスペースの学習されたベースラインに対するレート/コストの スパイク、retry_loop、そしてこれまで一度も見たことのないツールパスをフラグします。

まとめ

ファイアウォールリファレンス

完全なポリシープレーン — サーフェス、判定、解決、自律性。

ファイアウォールルール

マッチング言語:グロブ、引数句、egress、シーケンス。

危険なツール呼び出し

このレシピが防御する脅威。

過剰なエージェンシー

過剰に権限を与えられたエージェントがなぜ中核的なエージェントリスクなのか。

自律エージェントのレシピ

完全に自律的なエージェントループをエンドツーエンドでロックダウンします。

持ち出しを止める

egress と lethal-trifecta のパターンを深く。