메인 콘텐츠로 건너뛰기
고객 대면 챗봇은 대중으로부터 신뢰할 수 없는 입력을 받아 모델로 보냅니다. 그래서 그것은 여러분이 운영하는 노출도가 가장 높은 표면입니다: 사용자는 업스트림에 저장하고 싶지 않은 PII를 붙여 넣고, 공격자는 여러분의 시스템 프롬프트를 무력화하려 시도하며, 모델은 시크릿이나 안전하지 않은 콘텐츠를 채팅 창에 다시 메아리칠 수 있습니다. 이 레시피는 AI 챗봇을 처음부터 끝까지 보호하는 네 가지 컨트롤을 연결합니다 — 요청에 대한 PII guardrail, 프롬프트 인젝션 스크리닝, 출력 안전성, 그리고 단단히 범위가 지정된 키 하나 — 모두 콘솔에서, 챗봇 코드 변경은 전혀 없이.
여기 있는 모든 것은 여러분의 워크스페이스에 바인딩되며 콘솔에서 구성됩니다. 여러분의 챗봇은 동일한 sk-orca-... 키로 https://api.orcarouter.ai/v1/chat/completions를 계속 호출합니다 — 게이트웨이의 정책만 바뀝니다. 구성 작업은 각 단계에서 명시한 역할을 요구합니다; 릴레이 호출은 범위 지정 키를 사용합니다.

​
1. 공개 챗봇의 위협 모델

무엇을 작성하기 전에, 무엇으로부터 방어하는지를 알아두세요. 챗봇의 공격 표면은 완전한 에이전트보다 좁습니다 — 하지만 고빈도 위험은 구체적입니다:

들어온 PII, 로깅된 PII

사용자가 이메일, 카드 번호, SSN을 채팅에 붙여 넣고 — 여러분은 그것을 업스트림과 로그로 전달합니다.

프롬프트 인젝션

“이전 지시사항을 무시하고 …” — 여러분의 시스템 프롬프트를 무력화하고 봇의 동작을 바꾸려는 시도.

탈옥

봇을 정책 밖으로 끌어내려는 DAN / 역할극 프레이밍.

안전하지 않은 출력

유출된 시크릿, 시스템 프롬프트 보일러플레이트, 또는 인젝션이 섞인 콘텐츠를 모델이 채팅으로 다시 메아리치는 것.
순수 챗봇에는 툴 호출이 없으므로, 이 레시피는 Firewall보다는 텍스트 평면인 Guardrails에 의존합니다. 만약 여러분의 봇이 툴을 호출한다면, 그 위에 Firewall을 얹으세요 (§6 참조).

​
2. 하나의 guardrail, 네 가지 역할

네 개의 별도 정책 대신, 각 위험을 커버하는 순서가 있는 규칙을 가진 하나의 워크스페이스 guardrail을 작성하세요. guardrail은 이름이 지정된, 순서가 있는 규칙 목록입니다; 각 규칙은 무엇을 찾을지, 어디서(input, output, 또는 both), 그리고 무엇을 할지(block, mask, 또는 flag)를 말합니다. 콘솔에서 Guardrails → New guardrail을 열고, chatbot-shield로 이름을 붙이고, 아래 규칙을 추가하세요. guardrail 작성 — 그리고 Test 샌드박스 실행 — 은 Developer 역할을 요구합니다; guardrail 보기는 모든 멤버에게 열려 있습니다.

​
a. 요청에 대한 PII

stage input, action mask의 PII 규칙을 추가하세요. 내장 엔티티 세트는 닫혀 있습니다 — 챗봇이 실제로 보는 것을 고르세요: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
mask는 각 매치를 타입이 지정된 태그로 대체합니다 — jane@acme.com은 [EMAIL]이 되므로, 업스트림 모델은 그 주소를 결코 보지 못합니다. entity_actions 오버라이드는 카드 번호나 SSN에서는 요청을 완전히 차단하면서 더 낮은 심각도의 엔티티는 마스킹합니다. 이것이 바로 엔티티별 오버라이드로 확장된 PII Shield 프리셋입니다 — 템플릿 라이브러리에서 프리셋을 적용하고 거기서부터 편집하세요.
입력 단계 PII 마스킹은 오늘 라이브입니다 — 모델이 보기 전에 요청을 다시 씁니다. 스트리밍 응답의 라이브 마스킹은 로드맵에 있습니다. 봇이 다시 말하는 내용에서 PII를 가리려면, 출력 block 규칙을 사용하거나(스트리밍 및 비스트리밍에서 강제됨) 출력 마스킹이 적용되는 비스트리밍으로 봇을 실행하세요. 먼저 Test 탭에서 정확한 stage/stream 조합을 증명하세요.

​
b. 프롬프트 인젝션 스크리닝

OrcaRouter는 이것을 Prompt-Injection Basics 안전 프리셋(“이전 지시사항을 무시하라” 및 *“시스템 프롬프트를 드러내라”*와 같은 문구에 대한 키워드 차단 목록; DAN / 역할극 프레이밍의 더 엄격한 정규식 커버리지를 위해서는 Jailbreak / Role-Play Blocker 프리셋을 추가)으로, 그리고 어떤 패턴도 잡지 못하는 의미적 의도를 위해 llm_judge 규칙으로 제공합니다. 프리셋을 추가한 다음, 인젝션/무력화 시도를 플래그하는 루브릭과 함께 input 단계의 judge 규칙을 추가하세요. judge는 여러분 워크스페이스의 모델에 대해 실행되고, judge_timeout_ms로 제한되며, 기본적으로 페일 오픈합니다(judge 오류가 로깅되고 요청은 계속됨) — 페일 클로즈하려면 judge_fail_open: false로 설정하세요.
인젝션 규칙을 **flag**로 시작하고, 실제 트래픽에 대해 하루 동안 Matches 피드를 지켜본 다음, 공격에는 발동하고 정당한 질문에는 발동하지 않음을 확인한 후 block으로 격상하세요. 강제 모드를 참조하세요.

​
c. 출력 안전성

채팅 창에 결코 도달해서는 안 되는 콘텐츠 — 유출된 시크릿, 채팅 템플릿 제어 토큰, 시스템 프롬프트 보일러플레이트 — 를 위한 output 단계 block 규칙(정규식 또는 키워드)을 추가하세요. Secrets & API-Key Blocker와 시스템 프롬프트 유출 안전 프리셋이 흔한 경우를 커버합니다; 그것들을 적용하고 관련 규칙을 output 단계에 고정하세요. 출력 block은 스트리밍에서도 강제됩니다 — 스캐너가 차단된 콘텐츠가 사용자에게 도달하기 전에 스트림을 중간에 끊고 대체 메시지를 내보냅니다.

​
3. 배포하기 전에 테스트하기

모든 guardrail 에디터에는 Test 탭이 있습니다. 샘플을 붙여 넣고, stage를 고르고, 현재 정책을 로컬에서 실행하세요 — 업스트림 호출 없음, 쿼터 소모 없음.
이것을 붙여 넣기Stage기대
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block (선택)
카드 4111 1111 1111 1111inputguardrail_blocked(오버라이드에 따라)
적대적 커버리지를 위해, Eval 탭은 번들된 레드팀 코퍼스(또는 여러분 자신의 JSONL)에 대해 정책을 실행하고 어떻게 채점되었는지 보고합니다 — judge 루브릭을 튜닝하여 알려진 공격을 잡으면서 무해한 채팅을 플래그하지 않도록 하세요.

​
4. 봇을 위한 범위 지정 키 하나 발급하기

guardrail은 그것으로 해석되는 키에서만 강제됩니다. 챗봇에게 자신만의 키를, 그것이 필요한 최소한으로 범위 지정하여 주세요 — 결코 계정 전체 키가 아니라. API Keys → New key에서 다음을 설정하세요:
Guardrail 드롭다운에서 chatbot-shield를 고르세요. 이는 키에 guardrail_id를 설정합니다. 명시적 연결은 off 스위치의 반대입니다: 설정되고 활성화되어 있으면, 항상 적용되며 결코 조용히 폴백하지 않습니다. (워크스페이스 is_default guardrail로 폴백하려면 설정하지 않은 채로 두세요.)
credit_limit_usd를 합리적인 상한으로 설정하세요(0 = 무제한). 공개 챗봇은 남용될 가능성이 가장 높은 키입니다 — 단단한 크레딧 상한이 여러분의 폭발 반경 한계입니다. denial-of-wallet를 참조하세요.
model_limits를 켜고 봇이 호출하도록 허용된 모델만 나열하세요. 그래서 유출된 키가 의도하지 않은 비싼 모델을 실행하는 데 사용될 수 없습니다.
봇이 고정된 서버에서 호출하면 allow_ips를 백엔드의 egress IP로 설정하고, 키가 임시라면 expired_time을 설정하세요(-1 = 만료 안 됨).
키는 생성 후 표시 시 마스킹됩니다 — 한 번 복사하세요. 이제 여러분의 챗봇 백엔드는 스크리닝이 일어나고 있음을 인지하는 코드 없이 모든 사용자 턴을 chatbot-shield를 통해 보냅니다.

​
5. 프로덕션에서 지켜보기

두 가지 읽기가 여러분을 정직하게 유지합니다, 둘 다 워크스페이스 범위입니다:
  • Guardrails → Matches(모든 Member) — 발동한 모든 규칙: 타입, 액션, 단계, 그리고 상세. 매치된 부분 문자열은 guardrail에 대해 Log raw content가 켜져 있을 때만 기록됩니다(기본 꺼짐 — 프라이버시 보수적 자세). 정책을 튜닝하려면 거짓 양성을 표시하세요 (Admin).
  • Version history — 모든 변경은 history 행을 씁니다; 두 버전을 diff하고 규칙이 너무 공격적이라고 판명되면 revert하세요. 차단된 요청은 HTTP 400 guardrail_blocked를 반환하고, 쿼터를 소모하지 않으며, skip-retry로 표시됩니다.
guardrail_blocked 응답은 의도적이고 사용자에게 보이는 400입니다. 원시 오류를 표면화하기보다는 친근한 메시지(“그것은 처리할 수 없습니다”)로 챗봇 UI에서 처리하세요 — 게이트웨이가 이미 여러분을 위해 안전하지 않은 턴을 멈췄습니다.

​
6. 봇이 툴을 호출한다면

여러분의 챗봇이 함수를 호출하거나, URL을 가져오거나, MCP 서버에 도달할 수 있게 되는 순간, 텍스트 스크리닝만으로는 충분하지 않습니다 — 액션 평면이 필요합니다. firewall_policy_id를 통해 동일한 키에 Firewall 정책을 연결하거나, balanced 자율성 수준을 적용하여 강화하기 전에 툴 호출을 감사하고 PII를 워크스페이스 전역으로 플래그하세요. 가장 빠른 경로는 제로 트러스트 퀵스타트입니다; 툴을 많이 호출하는 에이전트의 경우 자율 에이전트 보안을 참조하세요.

​
7. 더 깊이 들어가려면

Guardrails 레퍼런스

모든 규칙 타입, PII 엔티티, judge 필드, 그리고 eval 하네스를 전부.

Guardrails vs Firewall

텍스트 평면 vs 액션 평면 — 언제 무엇이 필요한가.

강제 모드

Observe → shadow → enforce: 봇을 망가뜨리지 않고 롤아웃하기.

범위 키, 정책, 워크스페이스

키 연결과 워크스페이스 기본값이 어떻게 해석되는가.