메인 콘텐츠로 건너뛰기
시크릿은 있어서는 안 될 곳에 도달합니다. 개발자가 “디버깅 도움”을 위해 .env 파일을 프롬프트에 붙여넣습니다. 검색된 문서가 임베드된 API 키를 실어 나릅니다. “config를 보여줘”라는 요청을 받은 모델이 AWS 액세스 키를 클라이언트에게 곧장 되돌려 보냅니다. 에이전트가 라이브 토큰을 인자에 구워 넣은 툴 호출을 구성합니다. 이들 각각은 자격 증명이 탈출하는 경로입니다 — 업스트림 프로바이더의 로그로, 클라이언트 트랜스크립트로, 또는 서드파티 툴로. 이 페이지는 OrcaRouter의 Guardrails와 Agent Firewall이 llm 시크릿 유출을 방어하도록 어떻게 해주는지를 다룹니다 — 애플리케이션 코드를 변경하지 않고.
탐지는 게이트웨이에서, 연결된 모든 키 앞에서 일어납니다 — 따라서 단일 정책이 SDK 변경 없이 모든 프로바이더, 모든 모델, 모든 에이전트를 커버합니다.

​
1. 시크릿은 어디서 유출되는가

자격 증명은 요청의 세 가지 별개 지점에서 탈출할 수 있습니다:
자격 증명이 모델이 실행되기 전에 요청 안에 있습니다 — 붙여넣은 키, .env 스니펫, 검색된 RAG 청크 내부의 토큰. 확인되지 않은 채로 두면 업스트림 프로바이더에 도달하여 그들의 로그에 떨어질 수 있습니다. Secrets Blocker 입력 guardrail로 막으세요 (§2).
모델이 시크릿을 클라이언트로 되돌려 내보냅니다 — 컨텍스트의 키를 토해내거나, 자격 증명 형태의 문자열을 환각합니다. 출력 시크릿 규칙으로 포착하세요 (§3).
에이전트가 인자에 토큰을 담아 툴 호출을 구성합니다. Firewall의 sanitize 판정은 호출이 디스패치되기 전에 인자에서 매치된 부분 문자열을 편집합니다 (§4).
처음 둘은 콘텐츠 검사(Guardrails)이고; 세 번째는 액션 검사(Firewall)입니다. 심층 방어를 위해 셋 모두를 계층화하세요.

​
2. Secrets Blocker — 프롬프트의 자격 증명 차단

Secrets Blocker는 secrets 카테고리 아래의 guardrail 프리셋으로 input 스테이지에서 실행됩니다. 요청에서 자격 증명 형태 — AWS 액세스 키, OpenAI 스타일 키, GitHub 토큰 — 를 스캔하고 호출이 게이트웨이를 떠나기 전에 차단합니다. 자격 증명은 모델에 결코 도달하지 않습니다. 콘솔에서 한 번 작성하고, 키를 연결하면, 그 키를 통과하는 모든 요청이 검사됩니다:
1

guardrail 생성

콘솔에서 /console/guardrails를 열고, New guardrail을 클릭하고, secrets 카테고리에서 Secrets & API-Key Blocker 프리셋을 적용합니다. 이는 흔한 자격 증명 형태에 대한 입력 스테이지 차단 규칙으로 guardrail을 시드합니다 — 거기서 자유롭게 편집하세요.
2

키 연결

/console/token을 열고, API 키를 편집하고, Guardrail 드롭다운에서 guardrail을 고르세요 — 또는 워크스페이스 기본값으로 설정해 연결되지 않은 모든 키가 그것을 상속하게 하세요.
3

요청 전송

그 sk-orca-... 키로 평소와 똑같이 게이트웨이를 호출하세요:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "why is AKIAIOSFODNN7EXAMPLE rejected"}
    ]
  }'
AWS 키 형태가 guardrail을 발동시키고 요청은 HTTP 400 guardrail_blocked으로 거부됩니다. 키는 모델에 결코 도달하지 않습니다.
차단된 요청은 쿼터를 소모하지 않으며 — 입력 스테이지 차단은 미터링 전에 발동합니다 — skip-retry로 표시되므로, 동일한 프롬프트를 다시 실행해도 폴백 채널을 태우는 대신 그저 다시 차단됩니다.
더 넓은 커버리지가 필요한가요? secrets 카테고리는 PEM 개인 키, Slack과 Stripe 토큰, Google API 키, JWT를 차단하는 Private Keys & Cloud Tokens 프리셋도 제공합니다. 둘 다 적용하세요 — guardrail은 임의 개수의 규칙을 담을 수 있습니다. JWT와 자격 증명 형태를 타입이 지정된 엔티티로([JWT] / [AWS_ACCESS_KEY] 태그와 함께) 포착하려면, jwt, aws_access_key, api_key_openai를 커버하는 pii 규칙이 엔티티 기반 대안입니다; Guardrails 레퍼런스를 참조하세요.
Firewall의 tight 자율성 수준은 PII Shield 및 파괴적 셸 거부와 함께 자세의 일부로 Secrets Blocker guardrail을 켭니다. 규칙을 직접 작성하는 대신 스위치 하나를 원한다면, 그것이 빠른 경로입니다. 자격 증명 검사 자체는 항상 guardrail입니다 — firewall의 인자 스캐너가 아닙니다.

​
3. 모델 출력의 시크릿 차단

시크릿은 응답으로도 떠날 수 있습니다 — 모델이 컨텍스트의 키를 반향하거나 자격 증명 형태의 문자열을 내보냅니다. output 스테이지에 규칙을 추가해 모델의 응답이 클라이언트로 돌아가기 전에 검사하세요. secrets 카테고리는 정확히 이를 위한 Code Secret in Output 프리셋을 제공합니다: PEM 개인 키, AWS 액세스 키, OpenAI 스타일 시크릿 토큰에 대한 출력 스테이지 차단 규칙. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
출력 block은 비스트리밍 및 스트리밍 응답 모두에서 강제됩니다 — 스트림에서는 차단된 콘텐츠가 클라이언트에 도달하기 전에 스캐너가 응답을 비행 중에 끊습니다. 출력 차단은 사전 소모된 쿼터를 환불합니다.
출력 마스킹(전체 응답을 거부하기보다 매치를 타입이 지정된 태그로 대체하는 것)은 현재 비스트리밍 응답에만 적용됩니다. 출력의 자격 증명에는 스트리밍 트래픽에서 block 액션이 신뢰할 수 있는 선택입니다. 의존하기 전에 guardrail Test 탭에서 여러분의 스테이지/스트림 조합을 증명하세요.

​
4. 툴 호출 인자에서 시크릿 정화

에이전트가 툴 호출을 구성할 때 자격 증명이 인자에 묻어 갈 수 있습니다. Firewall의 sanitize 판정은 툴 호출 인자에서 매치된 부분 문자열을 편집하고 정리된 호출을 전달합니다 — 재작성할 라이브 호출 시점 인자가 있는 response와 mcp 표면에서. sanitize 규칙은 sanitize_json 구성에서 어떤 탐지기를 편집할지를 지정합니다 — 내장 프리셋 세트와 선택적 커스텀 regex. 매치된 자료는 [redacted:<preset>]로 대체됩니다(커스텀 매치는 [redacted:custom]로): 
{
  "priority": 10,
  "label": "Redact AWS keys from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize_json": {
    "presets": ["aws_access_key", "aws_secret_key", "openai_key", "anthropic_key", "bearer_token"],
    "custom": []
  }
}
새니타이저가 사용할 수 있는 시크릿 형태 프리셋은 aws_access_key, aws_secret_key, openai_key, anthropic_key, bearer_token입니다(PII를 위한 email, ssn_us, credit_card 추가). sanitize 규칙은 적어도 하나의 프리셋이나 커스텀 패턴을 지정해야 합니다 — 빈 새니타이저는 저장 시 거부됩니다.
Sanitize는 결과가 아니라 인자를 편집합니다. 에이전트가 작성한 툴 호출의 인자를 정리합니다; 툴이 반환하는 콘텐츠는 스크럽하지 않습니다. 그리고 inbound 표면에서는 — 아직 호출 시점 인자가 없으므로 — sanitize가 deny로 격상됩니다. 매칭 언어는 firewall 규칙 레퍼런스를 참조하세요.
Secrets Blocker guardrail(§2)은 요청 본문의 자격 증명에 대한 여러분의 주된 방어로 남습니다 — firewall 새니타이저는 구체적으로 툴 호출 인자 내부에 나타나는 시크릿을 위한 액션 계층 보완입니다.

​
5. 세 가지 방어 계층화

시크릿이 있는 곳그것을 막는 계층액션
프롬프트에서Secrets Blocker (입력 guardrail)block
모델의 응답에서출력 시크릿 규칙 (출력 guardrail)block
툴 호출 인자에서Firewall 새니타이저sanitize
새 규칙은 먼저 shadow mode(firewall)나 flag 액션(guardrail)으로 롤아웃하세요. events / Matches 피드를 보고 실제 자격 증명에는 발동하고 무해한 유사물에는 발동하지 않음을 확인한 뒤, 강제 액션으로 전환하세요.

​
6. 무엇이 발동했는지 관찰

발동하는 모든 guardrail 규칙은 매치를 기록합니다 — 규칙 타입, 액션, 스테이지, 그리고 detail 문자열 — 워크스페이스 Matches 피드(GET /api/guardrail/match, Member)에. 매치된 부분 문자열은 “Log raw content”가 켜져 있을 때만 기록되며, 이는 기본적으로 꺼져 있습니다 — 프라이버시 보수적 자세로, Matches 피드 자체가 시크릿이 쌓이는 곳이 되지 않게 합니다. 분류를 위해 부분 문자열이 구체적으로 필요한 경우가 아니면 자격 증명 규칙에 대해서는 꺼두세요. Firewall sanitize 결정은 Firewall Events 피드(GET /api/workspace/firewall/events, Developer+)에 떨어지며, 시크릿과 규칙 blob은 결코 로깅되지 않습니다.

​
7. 다음으로 갈 곳

Guardrails 레퍼런스

규칙 타입, PII 엔티티, 프리셋, 테스트 샌드박스, 그리고 eval 하네스 전체.

Firewall 규칙 레퍼런스

매칭 언어 — 툴 glob, 인자 절, 그리고 새니타이저.

PII 노출

동기 콘텐츠 위협: 프롬프트와 응답의 개인 데이터.

데이터 유출

유출된 자격 증명이 아웃바운드 유출 호출의 페이로드가 될 때.

Guardrails vs Firewall

어느 평면이 어떤 유형의 유출을 막는지, 그리고 그것들이 어떻게 조합되는지.

에이전트 보안 기준선

이 방어들을 함께 켜는 시작 자세.