메인 콘텐츠로 건너뛰기
장시간 실행되는 자율 에이전트는 보안하기 가장 어려운 것입니다. 몇 시간 동안 스스로 루프하고, 자신의 툴을 고르고, 자신의 URL을 가져오고, 그 내내 여러분의 돈을 씁니다. 실패 모드는 단일한 나쁜 프롬프트가 아닙니다 — 하룻밤에 $400을 태우는 retry 루프, 여러분이 한 번도 검토하지 않은 툴 호출, 일주일짜리 실험을 위해 발급했는데 6개월 후에도 여전히 작동하는 키입니다. 이 레시피는 정확히 그런 형태의 에이전트 주위에 네 가지 컨트롤을 연결합니다. 여러분은 그 모든 것을 콘솔(또는 REST API)에서 구성합니다 — 에이전트는 이전과 정확히 동일하게 https://api.orcarouter.ai/v1/...을 계속 호출합니다.
여기가 처음이신가요? 먼저 balanced 기준선을 적용하고 하루 동안 에이전트가 무엇을 하는지 지켜보세요. 이 페이지는 다음 단계입니다: 베이비시팅할 수 없는 에이전트를 위해 관찰을 강제로 전환하기.

​
1. 안전한 자율 에이전트 레시피

안전한 자율 에이전트는 챗봇이 필요로 하지 않는 네 가지가 필요합니다:

단단한 비용 상한

cap_cost 규칙은 run의 누적 지출이 여러분의 상한을 넘으면 run을 거부합니다 — 멈추지 않는 루프를 위한 회로 차단기.

급증 탐지

이상 탐지는 에이전트의 정상적인 주중 시간대 형태를 학습하고 정적 규칙을 빠져나가는 속도 및 비용 급증을 플래그합니다.

위험한 호출에 대한 승인

pending_approval 판정은 에이전트가 신중하리라 신뢰하는 대신, 파괴적이거나 되돌릴 수 없는 툴 호출을 사람을 위해 보류합니다.

만료되는 키

잊힌 실험이 영원히 실행되거나 — 또는 지출하거나 — 할 수 없도록 에이전트의 키를 만료와 크레딧 상한으로 범위 지정하세요.
각각은 하나의 Firewall 정책 또는 키 필드에 매핑됩니다. 그 어느 것도 여러분의 에이전트 코드를 건드리지 않습니다.

​
2. 모든 run의 비용 상한 처리하기

폭주 루프가 가장 먼저 날리는 것은 여러분의 예산입니다. cap_cost 규칙은 엄격한 사전 검사 비용 상한입니다: 매치하면 게이트웨이가 요청의 비용을 추정하고 run의 누적 지출이 상한을 초과하게 될 때 디스패치 전에 거부합니다 — 그래서 예산 초과 호출은 결코 프로바이더에 도달하지 않습니다. 상한은 run 범위입니다. 게이트웨이는 전체 에이전트 run에 걸친 이전 지출을 합산하므로, 이미 예산의 대부분을 태운 긴 run은 다음 개별 호출이 저렴하더라도 거부됩니다. 그것이 그것을 요청별 한도가 아니라 회로 차단기로 만드는 것입니다. firewall 정책에 와일드카드 규칙 하나를 추가하세요: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
이는 run을 $10로 상한 처리합니다(cap_cost_cents는 USD 센트 단위). 판정은 예산 내일 때 allow로, 추정이 그것을 넘게 될 때 deny로 해석됩니다. 대부분의 내장 firewall 템플릿(Coding, Support, RAG, Data, DevOps, Browser)은 정확히 이와 같은 run별 비용 상한을 제공합니다 — 하나를 적용하고 상한을 편집하세요.
run 범위 누적은 워크스페이스에 대한 요청 로그 캡처가 활성화되어야 합니다. 그것이 꺼져 있으면, 이전 지출 롤업은 0을 읽고 상한은 요청별로만 저하됩니다 — 여전히 안전하지만, 느린 500-호출 누수는 잡지 못합니다. denial-of-wallet를 참조하세요.

​
3. 학습된 베이스라인에 대한 급증 탐지하기

상한은 재앙을 멈춥니다; 이상 탐지는 그것이 재앙이 되기 전에 이상함을 잡습니다. Firewall은 각 워크스페이스의 정상적인 툴 사용 형태를 학습하고 — 주중 시간대로 버킷화된 14일 롤링 평균이라, 화요일 14:00 트래픽은 평평한 일일 평균이 아니라 화요일 14:00 이력에 대해 비교됩니다 — 뷰어 판독 가능한 피드에서 편차를 표면화합니다:
학습된 베이스라인에 대해 채점된 툴별 호출 볼륨. “베이스라인 8에 대해 한 시간에 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 서명 웹훅 콜백을 통해 해결합니다.
  3. 에이전트가 GET /api/v1/firewall/approvals/:id를 폴링합니다; 일단 승인되면 일회용 X-OrcaRouter-Firewall-Approval 헤더와 함께 원래 호출을 재제출하고, 게이트웨이는 그것을 그 한 번 통과시킵니다.
파괴적 표면에 쓰기를 보류하는 규칙: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
이것을 먼저 shadow mode로 롤아웃하세요 — pending_approval이 audit로 강등되므로, 실제로 에이전트를 차단하지 않고 어떤 호출이 보류될지 봅니다. 피드가 적절해 보이면 shadow를 끄세요.

​
5. 에이전트에게 만료되는 키 부여하기

모든 정책보다 오래 사는 컨트롤은 키 자체입니다. 자율 에이전트는 여러분의 기본 키가 아니라 범위 지정 키를 받아야 합니다. 발급할 때 다음 필드를 설정하세요(콘솔 → keys, 또는 token API):
필드무엇으로 설정이유
expired_timeUnix 타임스탬프실험이 끝나면; 키도 그것과 함께 죽습니다. -1은 절대 안 됨을 의미 — 여기서는 사용하지 마세요.
credit_limit_usd달러 상한run 상한과 독립적인 키의 지출 상한. 0은 무제한을 의미.
firewall_policy_id위의 여러분 정책cap_cost + 승인 규칙을 이 키에 바인딩.
allow_ips에이전트의 egress IP유출된 키는 다른 어디서도 쓸모없습니다.
environment 태그도 설정하여, 키 — 그리고 그것이 Events와 Matches에서 하는 모든 것 — 이 이 에이전트에 귀속되게 하세요. 만료되고, 크레딧 상한이 있고, IP가 고정된 키가 마지막 방어선입니다: 모든 정책이 어떻게든 우회되더라도, 폭발 반경은 시간과 달러로 제한됩니다.
키 구성은 콘솔 / token-API 작업이며 역할로 게이트됩니다. firewall-gateway 키의 평문을 읽으려면 **Admin+**가 필요합니다.

​
6. 종합하기

강화된 자율 에이전트는 결국 하나의 firewall 정책과 하나의 범위 지정 키로 귀결됩니다:
LayerControl잡는 것
예산cap_cost 규칙, run 범위폭주 루프, denial-of-wallet
동작이상 피드(rate / burn / retry / novel)이상하지만-허용된 것
신뢰파괴적 툴에 대한 pending_approval되돌릴 수 없는 액션
범위만료, 크레딧 상한, IP 고정 키잊히거나 유출된 키
예산과 승인 규칙을 함께 작성하고, firewall 규칙으로 run별 상한을 설정하고, 표면, 판정, 그리고 관측성에 대한 나머지 Firewall 레퍼런스를 읽으세요. 이 레시피가 방어하는 관련 위협은 과도한 에이전시, 위험한 툴 호출, 그리고 denial-of-wallet를 참조하세요.

​
7. 다음 단계

MCP 에이전트 강화

MCP 서버를 통해 툴에 도달하는 에이전트를 통제하세요.

유출 중지

자신의 URL을 가져오는 에이전트를 위한 egress 규칙.

강제 모드

Observe → shadow → enforce, 안전한 롤아웃.

Firewall 규칙

위의 모든 규칙 뒤의 매칭 언어.