メインコンテンツへスキップ
ほとんどのチームはエージェントセキュリティに遅すぎ、一度に 1 プレーンずつ手を伸ばし ます — ここでプロンプトに正規表現、そこでツール deny リスト。結果は穴のある姿勢です： shell.exec を決して見ないテキストスクリーニング、あるいはプロンプトで出ていく クレジットカード番号に決して気づかないツールファイアウォール。 完全なエージェントセキュリティベースラインへの最速の方法は、両プレーンを一度に 設定することです。OrcaRouter の自律性コントロール — Secure Agents ベースライン — がまさにそれを行います：ファイアウォールポリシーと ガードレールを一緒に、ひとつのトランザクションで、ワンクリックの 取り消しとともに書き込む単一のワークスペースレベルのスイッチです。保護されるために ルールを作成しません；レベルを選び、後でチューニングします。
2 つのプレーンは補完的であり、冗長ではありません。ガードレールはプロンプト/レスポンスの テキスト（PII、シークレット、jailbreak とインジェクション意図）をスクリーニングします； ファイアウォールはエージェントが取るアクション（どのツール、MCP 呼び出し、ホスト）を 統制します。どちらか一方だけでは、もう一方が閉じるギャップが残ります — ガードレール vs. ファイアウォールを参照。

​
1. なぜ 1 つのベースラインが 2 つの中途半端に勝るか

実際のエージェント実行は、単一のリクエストで両プレーンを横切ります。モデルがプロンプト （テキスト）を読み、db.query を呼ぶことを決め（アクション）、ツールの結果が次のターンに フィードバックされます（再びテキスト）。1 つのプレーンだけを保護すると、もう一方が 無防備になります：

ファイアウォールのみ

破壊的シェルを deny しますが、プロンプトは依然として顧客の SSN をモデルに直接 運びます — そしてツール引数は依然として API キーを漏らします。

ガードレールのみ

プロンプトの PII をマスクしますが、エージェントは依然として rm -rf を呼んだり、 クラウドメタデータエンドポイントに到達したり、暴走ツールでループしたりします。
自律性コントロールは選択を取り除きます。1 つのレベルが両プレーンにわたる一貫した姿勢を 設定するため、一方が設定され他方がされていない窓がありません。

​
2. エージェントセキュリティベースライン：3 つのレベル

各レベルは同じ 2 つのプレーンをカバーします。1 つを選びます；それがあなたの床であり、 後でルールで精度を加えます。
レベルファイアウォールガードレール観察モード
tightデフォルト deny；破壊的シェル + フェッチ形のツールを denyPII Shield + Secrets Blocker を強制オフ
balancedデフォルト audit；破壊的シェルを denyPII Shield は audit のみ（PII をフラグ）オフ
permissive強制ポリシーなしなしオン — すべての呼び出しをギャップとしてログ
各レベルが実際に何を捕捉するかを形作るため、固めておく価値のあるいくつかの具体：
tight はファイアウォールポリシーのデフォルト判定を deny に刻印し、それから 破壊的なコマンドを運ぶシェル/exec ツール名 — shell.*、bash、cmd、 powershell、exec — と、SSRF を運ぶフェッチ形のツール名 — http_fetch、 web_search、fetch_url、request（とそれらの <server>.* MCP 名前空間化 バリアント） — に対する deny ルールを重ねます。これらのツール名を deny します； CIDR やクラウドメタデータの egress ルールは出荷しません。169.254.169.254 や RFC-1918 範囲を宛先で deny したい場合は、独自の egress ルールを作成します — Egress 制御を参照。
PII Shield と Secrets Blocker ガードレールの両方がアクティブで強制して います。PII Shield はモデルに到達する前にリクエスト上の PII をマスクします； Secrets Blocker はリクエスト内の認証情報を捕捉します。ツール引数内のシークレットは、 リクエスト上でこのガードレールによって捕捉されます — ファイアウォールはデフォルトでは それらを剥がしません。
balanced はすべてを audit し（デフォルト判定 audit）、エージェントの実際の挙動を 見られるようにしつつ、最も破壊的な単一クラス — 破壊的シェル — を依然として deny します。PII Shield は audit のみのモードで実行されます（PII をフラグ、ブロックしない）。 予期しないブロックのリスクをほぼゼロにして完全な証跡を得て、それから当て推量ではなく 可視性から締めます。
permissive は何も強制しません — 偶発的なブロックのリスクゼロで真新しいエージェントを 観察するために存在します。観察モードはオンのままなので、すべてのツール呼び出しは 依然としてカバレッジギャップとしてログされます（Discovered Tools で可視）。エージェントの 形を学ぶために使い、それから balanced または tight に移ります。

​
3. 具体例 1 つ：balanced を適用し、両方のフィードを監視

レベルの適用は単一のコンソールアクション（Firewall → Posture）または 1 つの API 呼び出しです。ルートはセッション下で実行され、Developer+ を必要とします。 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
レスポンスは audit_id を運びます — それを保持してください；取り消しに渡すもの です。一度適用されると、ベースラインは次のツール呼び出しでライブになります。再デプロイ なし、エージェントのコード変更なし。今、両方のプレーンを一度に監視します：
  • Firewall → Events — すべてのツール呼び出しの判定（audit、deny された破壊的 シェル呼び出し）。Events ログを参照。
  • Guardrails → Matches — すべてのコンテンツポリシーのヒット（PII Shield フラグ）。
balanced は実在する編集可能なファイアウォールポリシーと実在するガードレール （それぞれレベルにちなんで命名）を書き込むため、後でどちらかを開いてチューニングでき ます — ベースラインは開始点であり、ロックされたプリセットではありません。
コミットする前にプレビューします。GET /api/workspace/firewall/simulate?level=tight （Member、読み取り専用）は、tight が現在の状態に対して何を変えるであろうかを 正確に示します — 何も適用されません。balanced で 1〜2 日後にそれを実行し、tight が 通常のトラフィックの一部である呼び出しを deny しないことを確認します。

​
4. 取り消しは 1 つの呼び出し

すべての自律性の変更は、その監査スナップショットから可逆であり、正確な直前の状態 — ポリシー、ルール、ガードレール、設定 — を復元します。汎用リセットではありません。 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
スナップショットが監査ログのサイズ制限を超える非常に大きなワークスペースでは、適用は 依然として成功しますが、その変更に対してワンクリックの取り消しが利用できません — 代わりに欲しいレベルを再適用します。これは稀ですが、忙しい本番ワークスペースを締める前に 知っておく価値があります。

​
5. 推奨されるパス

広く始め、監視し、それから可視性の位置から締めます：
1

balanced を適用

完全な監査証跡；破壊的シェルのみ deny；PII はフラグ。エージェントを 1〜2 日通常通り 実行します。
2

tight をシミュレート

GET /api/workspace/firewall/simulate?level=tight し、その deny を Events フィードが 実際に示したものと比較します。フェッチ形または破壊的シェルの呼び出しが通常のフローの 一部なら、まずエージェントを修正します。
3

tight を適用

シミュレートに驚きがなければ、tight に切り替えます。本番が壊れたら取り消しは 1 つの 呼び出しの先です。
4

ルールでチューニング

ベースラインはあなたの床です。それがカバーしない例外を切り出すか、コントロールを ファイアウォールルールと名前付き ガードレールで追加します。より細かいスコープのために、 特定のポリシーまたはガードレールを個別のキーにアタッチします。

​
6. 組み合わせベースラインのロール

自律性コントロールは両プレーンにまたがりますが、すべてのアクションはロールゲート されています。
アクション最小ロール
レベルをシミュレート / ガードレール Matches を表示 / Discovered Tools を表示Member
ファイアウォール Events & Runs を表示Developer+
自律性レベルを適用Developer+
自律性の変更を取り消しDeveloper+
すべての設定はセッション下のコンソールで実行されます（/api/workspace/firewall/* と /api/guardrail/*）。/v1/* リレー呼び出しのみが sk-orca-… キーを使います；ゲート ウェイキーのルートは別のスコープです。 スコープ：キー、ポリシー、ワークスペースを 参照。

​
7. ベースラインの後：各プレーンをどこでチューニングするか

ベースラインは最初の 30 分であなたを保護します。そこから、各プレーンには精度作業の ための独自のリファレンスがあります：

ファイアウォールの概要

判定、サーフェス、引数述語、承認 — アクションプレーン。

ガードレール

キーワード、正規表現、PII、llm_judge、グラウンディングルール — コンテンツプレーン。

シャドウモード

締めたファイアウォールポリシーを、強制する前に audit のみでロールアウト。

Secure Agents ベースライン

自律性コントロールとその取り消しセマンティクスのコンセプトページ。
ベースラインは両プレーンを一度に閉じる床です；ルールは天井を上げる方法です。レイヤーが どう合成されるかについてはAI エージェントのセキュリティと コントロールスタックを、このベースラインが最も 直接的に答える脅威については過剰なエージェンシーを 参照してください。