メインコンテンツへスキップ
長時間稼働する自律エージェントは、セキュアにするのが最も難しいものです。それは自分で 何時間もループし、自分でツールを選び、自分で URL を取得し、その間ずっとあなたのお金を 使います。失敗モードはひとつの悪いプロンプトではありません — それは一晩で $400 を 燃やすリトライループ、一度もレビューしなかったツール呼び出し、1 週間の実験のために 発行したのに 6 か月後もまだ動くキーです。 このレシピは、まさにその形のエージェントに 4 つのコントロールを配線します。そのすべてを コンソール（または REST API）で設定します — エージェントは以前と全く同様に https://api.orcarouter.ai/v1/... を呼び続けます。
ここは初めてですか？ まず balanced ベースラインを 適用し、あなたのエージェントが何をするかを 1 日 観察してください。このページは次のステップです：あなたがお守りできないエージェントの ために、観察を強制へと変えます。

​
1. セキュアな自律エージェントのレシピ

セキュアな自律エージェントは、チャットボットが必要としない 4 つのものを必要と します：

ハードなコスト上限

cap_cost ルールは、run の累積支出があなたの上限を超えたら run を deny します — 止まらないループのためのサーキットブレーカーです。

スパイク検出

異常検出はエージェントの通常の曜日内時間の形を学習し、静的ルールをすり抜ける レートとコストのスパイクをフラグします。

危険な呼び出しへの承認

pending_approval 判定は、エージェントが慎重であることを信頼する代わりに、 破壊的または不可逆なツール呼び出しを人間のために保留します。

期限切れするキー

エージェントのキーを期限とクレジット上限にスコープし、忘れられた実験が永遠に 実行 — あるいは支出 — できないようにします。
それぞれが 1 つの ファイアウォールポリシーまたは キーフィールドにマッピング されます。どれもあなたのエージェントコードに触れません。

​
2. すべての run のコストに上限をかける

暴走ループがまず吹き飛ばすのはあなたの予算です。cap_cost ルールは厳格な事前 チェックのコスト上限です：マッチすると、ゲートウェイはリクエストのコストを見積もり、 run の累積支出が上限を超えるならディスパッチ前に deny します — つまり予算超過の 呼び出しが決してプロバイダに到達しません。 上限は run スコープです。ゲートウェイはエージェント run 全体にわたる過去の支出を 合計するため、既に予算の大部分を燃やした長い run は、次の個別の呼び出しが安くても deny されます。これが、リクエストごとの制限ではなくサーキットブレーカーにしている ものです。 ファイアウォールポリシーにワイルドカードルールを 1 つ追加します： 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
これは run を $10 に上限します（cap_cost_cents は USD セント単位）。判定は予算内なら allow に、見積もりが超えるなら deny に解決されます。ほとんどの組み込みファイア ウォールテンプレート（Coding、Support、RAG、Data、DevOps、Browser）は、まさに これと同様の run ごとのコスト上限を出荷しています — ひとつを適用して上限を編集します。
run スコープの累積には、ワークスペースに対してリクエストログのキャプチャが有効である 必要があります。それがオフだと、過去支出のロールアップはゼロを読み、上限はリクエスト ごとのみに劣化します — 依然として安全ですが、緩やかな 500 呼び出しのドリップは 捕捉しません。 デニアル・オブ・ウォレットを参照。

​
3. 学習されたベースラインに対してスパイクを検出する

上限は破局を止めます；異常検出は、それが破局になる前に奇妙さを捕捉します。 ファイアウォールは各ワークスペースの通常のツール使用の形を学習し — 曜日内時間で バケット化された 14 日間の移動平均なので、火曜 14:00 のトラフィックは平坦な日次平均 ではなく火曜 14:00 の履歴と比較されます — 逸脱をビューア可読のフィードに表面化します：
学習されたベースラインに対してスコアリングされたツールごとの呼び出し量。 「ベースライン 8 に対して 1 時間に 143 回の db.query 呼び出し」は、各個別の 呼び出しが許可される場合でも表面化します。
同じベースラインを、カウントではなく支出に適用 — この時間に通常よりはるかに多く 燃やしている run。
同じ壊れた呼び出しをリトライして詰まっている自律エージェントの兆候。 過剰なエージェンシーを参照。
このワークスペースが一度も行ったことのないツール間のホップ — どこか新しい場所へ 向かうエージェントの形。
フィードはツール名、リダクトされたトークン id、そしてカウントを報告します — 生の引数は 決して報告しません。読み取りは任意の Member に開放されています；Developer+ は 調査中にフィードを最大 7 日間スヌーズできます。フィードを cap_cost ルールと 組み合わせて、予算超過でもあるスパイクが単に気づかれるだけでなく止められるように します。

​
4. 危険な呼び出しを人間のために保留する

自律エージェントが行うすべての呼び出しをレビューすることはできません — しかし、 重要な一握りの前に、それを止めて尋ねさせることはできます。pending_approval 判定は ツール呼び出しを帯域外で保留します：
  1. エージェントが、例えば payments.transfer 呼び出しを発行します。ルールがマッチし、 エンジンは承認 id とともに HTTP 400 firewall_approval_pending を返します — 呼び出しは決してツールに到達しません。
  2. レビュアーがコンソールからそれを解決する（Developer+）か、あなた自身の システムが POST /api/v1/firewall/approvals/:id/callback への HMAC 署名付き webhook コールバック経由で解決します。
  3. エージェントが GET /api/v1/firewall/approvals/:id をポーリングします；承認されると、 単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに元の呼び出しを再送信 し、ゲートウェイはその一度だけ通します。
破壊的なサーフェスへの書き込みを保留するルール： 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
まずこれをシャドウモードでロールアウト します — pending_approval は audit に格下げされるため、エージェントを実際に ブロックすることなく、どの呼び出しが保留されるかを見られます。フィードが正しく 見えたらシャドウをオフにします。

​
5. エージェントに期限切れするキーを与える

すべてのポリシーより長生きするコントロールは、キーそのものです。自律エージェントは、 あなたのデフォルトのキーではなく、スコープされたキーを得るべきです。発行時に次の フィールドを設定します（コンソール → keys、またはトークン API）：
フィールド設定値理由
expired_timeUnix タイムスタンプ実験が終わる；キーもそれとともに死ぬ。-1 は無期限 — ここでは使わない。
credit_limit_usdドル上限run 上限とは独立したキーへの支出上限。0 は無制限。
firewall_policy_id上記のポリシーcap_cost + 承認ルールをこのキーにバインドする。
allow_ipsエージェントの egress IP漏洩したキーは他のどこからも役立たない。
environment タグも設定して、キー — そしてそれが Events と Matches で行うすべて — が このエージェントに帰属できるようにします。期限切れし、クレジット上限があり、IP 固定の キーが最後の防衛線です：たとえすべてのポリシーが何らかの形でバイパスされても、爆発 半径は時間とドルによって境界づけられます。
キー設定はコンソール / トークン API のアクションであり、ロールゲートされています。 ファイアウォールゲートウェイキーの平文を読むには Admin+ が必要です。

​
6. 組み合わせる

強化された自律エージェントは、1 つのファイアウォールポリシーと 1 つのスコープキーに 落ち着きます：
レイヤーコントロール捕捉するもの
予算cap_cost ルール、run スコープ暴走ループ、デニアル・オブ・ウォレット
振る舞い異常フィード（rate / burn / retry / novel）奇妙だが許可されたもの
信頼破壊的ツールへの pending_approval不可逆なアクション
スコープ期限切れ・クレジット上限・IP 固定のキー忘れられた、または漏洩したキー
予算ルールと承認ルールを一緒に作成し、ファイアウォールルールで run ごとの上限を設定し、サーフェス、判定、可観測性については ファイアウォールリファレンスの残りを読んでください。この レシピが防御する関連脅威については、 過剰なエージェンシー、 危険なツール呼び出し、 デニアル・オブ・ウォレットを参照してください。

​
7. 次のステップ

MCP エージェントを強化する

MCP サーバー経由でツールに到達するエージェントを統制します。

持ち出しを止める

自分で URL を取得するエージェントのための egress ルール。

強制モード

Observe → shadow → enforce、安全なロールアウト。

ファイアウォールルール

上記のすべてのルールの背後にあるマッチング言語。