메인 콘텐츠로 건너뛰기
에이전트를 사용자 앞에 두는 날은 탈옥이 여러분의 콘텐츠 정책을 곧장 통과하거나, 통제하는 것을 잊은 툴이 첫 run에 발동한다는 것을 알아내기에 최악의 날입니다. 런칭 전 레드팀은 그런 놀라움을 배포하기 전에 읽을 수 있는 숫자로 전환합니다 — 그리고 OrcaRouter는 그것을 생산하는 세 가지 방법을 제공하며, 모두 여러분의 에이전트 코드를 건드리거나 의도하지 않은 단 하나의 라이브 요청도 보내지 않고. 이 레시피는 dry-run 패스입니다: 알려진 공격에 대해 정책을 측정하고, 여러분 자신의 트래픽에 대해 그것을 shadow 처리하고, 더 단단한 자세를 거기에 커밋하기 전에 시뮬레이션하세요.
여기 있는 모든 것은 읽기 전용이거나 샌드박스화됩니다 — 사용자 대면 차단 없음, 프로덕션 트래픽 영향 없음. (키워드, 정규식, 그리고 PII 규칙은 전적으로 로컬에서 실행됩니다; llm_judge 규칙은 여전히 그 구성된 모델을 호출하므로, judge 정책에 대한 eval은 그 호출을 합니다.) 핵심은 런칭 전에, 여러분의 조건으로 물건을 망가뜨리는 것입니다.

​
1. 런칭 전에 AI 에이전트를 레드팀하는 법

런칭 전 레드팀은 세 가지 질문에 답하며, OrcaRouter는 각각에 하나의 툴을 가집니다:

내 guardrail이 공격을 잡는가?

guardrail의 Eval 하네스를 번들된 적대적 코퍼스에 대해 실행하고 정밀도 / 재현율 / F1을 읽으세요.

내 firewall이 무엇을 망가뜨릴까?

shadow mode를 켜고 어떤 실제 툴 호출이 거부될지 지켜보세요 — 아직 그 어느 것도 거부하지 않고.

더 단단한 자세가 안전한가?

적용하기 전에 자율성 수준을 시뮬레이션하여 그것이 여러분의 트래픽에 대해 정확히 무엇을 변경할지 미리 보세요.
첫 번째는 여러분의 Guardrails(텍스트 평면)를 테스트합니다; 두 번째와 세 번째는 여러분의 Firewall (액션 평면)을 테스트합니다. 실제 런칭 체크리스트는 셋 다 실행합니다.

​
2. 적대적 코퍼스에 대해 guardrail 채점하기

콘텐츠 정책이 공격자와의 접촉에서 살아남는지 아는 가장 빠른 방법은 알려진 공격의 코퍼스를 그것에 던지고 점수를 읽는 것입니다. guardrail 에디터의 Eval 탭이 정확히 그것을 합니다: 코퍼스의 모든 샘플을 여러분의 현재 정책을 통해 재생하고 판정을 각 샘플의 기대 결과와 비교합니다 — 코퍼스를 라이브 트래픽이 아니라 여러분의 규칙에 대해 로컬에서 재생. OrcaRouter는 번들된 레드팀 코퍼스를 제공하므로 여러분 자신의 것을 소싱할 필요가 없습니다. 그중에는:
Corpus무엇인가
advbench_harmful_behaviors정전(canonical) 적대적 접미사 타깃 세트 — 모든 행은 guardrail이 차단해야 하는 안전하지 않은 요청.
anthropic_hh_redteam어시스턴트에 대한 실제 다중 턴 인간 레드팀 트랜스크립트.
deepset_prompt_injections레이블된 프롬프트 인젝션 대 무해한 요청 — 입력 단계 block을 위한 정밀도/재현율 베이스라인.
databricks_dolly_benign순수 무해 베이스라인: 과도하게 엄격한 정책은 이것 중 아무것도 차단해서는 안 됩니다.
공격 코퍼스를 항상 무해 코퍼스와 짝지으세요. 공격의 100%를 차단하지만 databricks_dolly_benign도 차단하는 정책은 안전하지 않습니다 — 사용 불가능한 것입니다. 무해 run은 여러분의 거짓 양성 예산입니다.
번들된 deepset_prompt_injections 코퍼스에 대해 eval을 실행하세요: 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
/api/guardrail/* 라우트는 sk-orca-... 릴레이 키가 아니라 여러분의 콘솔 세션 / 액세스 토큰을 사용합니다 — 그리고 X-Workspace-Id를 통해 워크스페이스 범위입니다. 실제로는 콘솔의 Eval 탭에서 이것을 실행하게 됩니다; curl은 형태를 보여주기 위해 여기 있습니다. eval 실행은 모든 Member에게 개방됩니다.
run은 기대 액션에 대해 계산된 탐지 메트릭을 보고합니다:
  • TP / FP / FN / TN — 참/거짓 양성과 음성, 여기서 “거짓 양성”은 공격을 잘못된 액션 클래스로 잡는 것을 포함합니다(예: block을 기대했는데 마스킹).
  • Precision / Recall / F1 — 헤드라인 숫자. 낮은 재현율은 공격이 빠져나감을 의미합니다; 낮은 정밀도는 무해한 트래픽을 차단하고 있음을 의미합니다.
run을 열어 실패를 샘플별로 검사하고, 규칙이나 judge 루브릭을 튜닝하고, 점수가 유지될 때까지 재실행하세요. 커스텀 코퍼스도 같은 방식으로 작동합니다 — 여러분의 제품이 직면하는 정확한 공격 형태에 대해 테스트하려면 여러분 자신의 JSONL을 업로드하세요(Developer+).
프롬프트 인젝션 방어가 어디에 사는가. 번들된 Prompt-Injection Basics 프리셋은 flag 액션의 키워드 규칙입니다 — 사용자를 차단하지 않고 흔한 탈옥 문구를 검토를 위해 표면화합니다. 어떤 키워드 목록도 캡처하지 못하는 의미적 인젝션 의도의 경우, llm_judge 규칙을 추가하고 그것을 같은 방식으로 레드팀하세요: deepset_prompt_injections와 anthropic_hh_redteam에 대해 eval하고 F1을 읽으세요. guardrail 레퍼런스를 참조하세요.

​
3. 실제 트래픽에 대해 firewall을 shadow mode로 처리하기

guardrail eval은 고정된 코퍼스에 대해 텍스트를 테스트합니다. 반면 여러분의 firewall은 여러분의 에이전트가 실제로 하는 것의 지저분한 현실에 대해 테스트되어야 합니다 — 그리고 런칭 전에 그것을 하는 가장 안전한 방법은 shadow mode입니다. Shadow mode는 firewall이 모든 툴 호출을 프로덕션에서와 정확히 동일하게 평가하고 로깅하되, 모든 강제 판정을 audit로 강등하게 만드는 정책별 플래그입니다. deny는 이유가 [shadow] would …로 접두된 audit 행이 됩니다. 아무것도 차단되지 않습니다. 아무것도 망가지지 않습니다. 하지만 Events 피드는 이제 여러분의 정책이 거부했을 호출의 정확한 목록을 보여줍니다. 이것이 firewall 레드팀입니다: 여러분의 가장 엄격한 의도된 정책을 작성하고, shadow mode를 켜고, 현실적인 런칭 리허설을 통해 에이전트를 실행한 다음, [shadow] would … 이벤트를 읽으세요.
콘솔에서 강제 정책을 구축하세요(Developer+) — 런칭 dry-run을 위해, default_verdict를 audit로 설정하고 배포하려는 deny 규칙을 추가하세요. shadow mode를 켜세요. 이제 전체 정책이 강제 없이 로깅합니다.
shadow 처리된 정책에 연결된 키로 게이트웨이에 대해 여러분의 실제 에이전트 흐름을 실행하세요. 모든 툴 호출 — inbound, response, MCP 디스패치, egress — 이 평가되고 로깅됩니다.
Firewall → Events(Developer+)를 열고 [shadow] would … 이유로 필터링하세요. 각각은 여러분의 정책이 프로덕션에서 거부했을 호출입니다. 모든 항목이 여러분이 거부하고 싶은 호출인지 — 그리고 정당한 것이 목록에 없는지 — 확인하세요.
차단했을 목록이 깨끗해지면, shadow mode를 끄세요. 바로 다음 매칭 호출이 실제로 강제됩니다 — 다른 변경 없음.
정확성뿐 아니라 커버리지를 위해 shadow mode를 observe mode(워크스페이스 설정)와 짝지으세요. Observe mode는 어떤 정책에도 해석되지 않는 모든 툴 호출을 갭으로 로깅하여 Discovered tools 뷰를 채웁니다 — 그래서 여러분이 잘못 작성한 규칙뿐 아니라 규칙 작성을 잊은 툴을 잡습니다. 강제 모드를 참조하세요.

​
4. 커밋하기 전에 더 단단한 자세 시뮬레이션하기

세 번째 레드팀 움직임은 가장 저렴합니다: 더 엄격한 자율성 수준을 적용하기 전에, 그것을 시뮬레이션하세요. 시뮬레이터는 tight(또는 어떤 수준)를 적용하는 것이 여러분 워크스페이스의 최근 트래픽에 대해 무엇을 변경할지 — 얼마나 많은 호출이 deny로 뒤집힐지 — 단 하나의 정책 행도 쓰지 않고 미리 봅니다. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
시뮬레이터 읽기는 모든 Member에게 개방됩니다. 런칭 전에 “내 에이전트가 tight에 준비되었는가?”에 답하는 데 그것을 사용하세요: 미리 보기가 여러분의 에이전트가 의존하는 호출에 대한 거부의 벽을 보여주면, go-live 후의 사건이 아니라 go-live 전에 부드럽게 할 규칙이 있는 것입니다.
Simulate는 미리 보기 전용입니다 — 그것은 결코 여러분의 정책을 변형하지 않습니다. 자율성 수준 적용은 별개의 Developer+ 작업이며, 라이브 결과가 여전히 놀랍다면 원클릭 실행 취소가 있는 한 트랜잭션입니다.

​
5. 런칭 전 레드팀 체크리스트

세 패스를 함께 두면 런칭 게이트를 얻습니다:
PassTool녹색일 때
콘텐츠 정책Guardrail Eval 대 공격 + 무해 코퍼스공격에 높은 재현율, 무해에 차단 없음
액션 정책Firewall shadow mode 대 리허설 트래픽모든 [shadow] would …가 의도된 것
커버리지Observe mode + Discovered tools놀라운 툴이 커버리지 갭에 앉아 있지 않음
자세타깃 자율성 수준 Simulate미리 보기가 예상하는 것과 일치
넷 다 녹색으로 실행한 다음, 강제하세요: shadow mode를 끄고 자율성 수준을 적용하세요. 모든 바인딩이 게이트웨이의 키에 살기 때문에, dry-run에서 라이브로의 이동은 배포가 아니라 구성 변경입니다 — 여러분의 에이전트는 https://api.orcarouter.ai/v1/...을 이전과 정확히 동일하게 계속 호출합니다.
출력 단계 마스킹과 라이브 응답 스캐닝은 여전히 성숙 중입니다 — eval 실행은 샌드박스에서 규칙의 로직을 증명하지만, 프로덕션에서 의존하기 전에 여러분의 특정 단계와 스트리밍 조합을 guardrail 노트에 대해 확인하세요.

​
6. 다음 단계

강제 모드

Observe → shadow → enforce, 이 레시피가 리허설하는 안전한 롤아웃.

Secure Agents 기준선

각 자율성 수준이 설정하는 것 — 그리고 simulate가 그것을 미리 보는 법.

프롬프트 인젝션

여러분의 guardrail eval이 채점하는 위협.

Go live

레드팀이 통과한 후의 프로덕션 전환.
각 패스 뒤의 전체 엔진은 Guardrails와 Firewall 레퍼런스, 그리고 관련 위협: 탈옥과 위험한 툴 호출을 참조하세요.