메인 콘텐츠로 건너뛰기
네트워크에 도달할 수 있는 에이전트는 데이터 파이프로 바뀔 수 있습니다. 주입된 지시사항은 그것에게 이미 가진 툴로 시크릿, 행, 또는 PII를 수집하여 공격자 호스트로 POST하라고 — 또는 내부 서비스를 탐색하라고(SSRF) — 말합니다. 에이전트는 결코 유출하기로 “결정”하지 않습니다; 그것에게는 정당한 지시처럼 보이는 것을 실행합니다. 이 레시피는 루프를 처음부터 끝까지 닫는 세 가지 컨트롤을 연결합니다 — 아웃바운드 호출이 갈 수 있는 곳을 잠그는 egress 허용 목록, 자격 증명이 모델에 도달하기 전에 멈추는 Secrets Blocker guardrail, 그리고 모델이 실제로 내보내는 툴 호출에서 시크릿을 벗겨내는 인자 새니타이저. 그 모든 것이 게이트웨이에 존재하므로, 여러분의 에이전트 코드 변경 없이 콘솔에서 한 번 구성합니다. 전체 공격 해부는 네트워크를 통한 데이터 유출을 읽으세요; 이 페이지는 구축 단계입니다.
여기 있는 모든 것은 여러분의 워크스페이스에 바인딩되며 콘솔에서 구성됩니다. 여러분의 에이전트는 동일한 sk-orca-... 키로 https://api.orcarouter.ai/v1/...을 계속 호출합니다 — 게이트웨이의 정책만 바뀝니다. 구성 작업은 각 단계에서 명시한 역할을 요구합니다; 릴레이 호출은 범위 지정 키를 사용합니다. firewall은 게이트웨이를 통해 라우팅되는 목적지(MCP 디스패치 경로 또는 evaluate 훅)에 대해서만 egress를 봅니다 — 네트워크 바운드 툴 호출을 그것을 통해 라우팅하면 통제됩니다.

​
1. AI 데이터 유출을 방지하는 세 레이어

각 레이어는 요청 수명 주기의 서로 다른 지점에서 공격을 잡습니다. 셋 다 쌓으세요 — 그것들은 독립적이고 상호 보완적입니다.

프롬프트 내 자격 증명

요청에 붙여 넣어진(또는 끌어들여진) 시크릿은 입력 단계에서 Secrets Blocker guardrail에 의해 잡힙니다 — 어떤 모델이 보기도 전에.

툴 인자 내 시크릿

자격 증명을 운반하는 툴 호출을 내보내는 모델은 매치된 인자를 가리는 sanitize firewall 규칙에 의해 정리됩니다.

아웃바운드 목적지

실제 네트워크 단계는 egress 허용 목록으로 제한됩니다 — 열거된 호스트만 통과; 나머지 모든 것은 거부됩니다.
이 레시피는 두 평면을 모두 사용합니다: 요청 내 텍스트를 위한 Guardrails, 그리고 액션과 네트워크를 위한 Firewall. 선이 어디에 있는지는 guardrails vs firewall을 참조하세요.

​
2. 프롬프트에서 자격 증명 멈추기 — Secrets Blocker guardrail

가장 먼저 잠가야 할 것은 자격 증명 자체입니다. Secrets & API-Key Blocker guardrail은 입력 단계에서 실행되며 요청이 게이트웨이를 떠나기 전에 자격 증명 패턴 — AWS 스타일 액세스 키, OpenAI 키, JWT, 그리고 유사한 토큰 — 을 스캔합니다. 매치 시 요청이 차단됩니다: 자격 증명은 결코 모델에 도달하지 않고 결코 툴 호출에 들어가지 않습니다. 콘솔에서 Guardrails → New guardrail(Developer 역할; 읽기와 Test 샌드박스는 모든 멤버에게 개방)을 열고, exfil-shield로 이름을 붙이고, 템플릿 라이브러리(카테고리 secrets)에서 Secrets & API-Key Blocker 프리셋을 적용하세요. 프리셋은 자격 증명 형태당 하나씩 세 개의 input 단계 정규식 차단 규칙을 시드합니다 — AWS 액세스 키, OpenAI 스타일 키, 그리고 GitHub 토큰: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
커버리지를 확장하려면, 내장 엔티티에 대한 pii 규칙을 추가하세요 — 탐지기 세트는 email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, 그리고 bitcoin_address를 커버합니다. entity_actions를 통해 엔티티별로 mask([EMAIL] 같은 타입 지정 태그로 가림) 또는 block을 고르세요. 입력 단계 마스킹은 라이브입니다; 그것은 모델이 보기 전에 요청을 다시 씁니다.
차단된 요청은 HTTP 400 guardrail_blocked를 반환하고, 쿼터를 소모하지 않으며(입력 단계 block은 미터링 전에 발동함), skip-retry로 표시됩니다. 키를 연결하기 전에 Test 탭에서 증명하세요 — 샘플 AWS 키를 붙여 넣고, input 단계를 고르고, 판정을 확인하세요.

​
3. 툴 호출 인자에서 시크릿 정화하기

guardrail은 프롬프트를 스크리닝합니다; 그것은 모델이 내보내는 툴 호출을 보지 못합니다. 모델이 자격 증명을 인자에 담은 tool_call을 생산할 때, firewall sanitize 규칙이 그것을 잡습니다. Sanitize는 툴 호출 인자에서 매치된 부분 문자열을 가리고 정리된 호출을 전달합니다 — 툴은 실행되지만, 시크릿이 벗겨진 채로. Firewall → Policies → New policy(Developer 역할)에서, exfil-firewall로 이름을 붙이고 response 표면 — 모델이 응답에서 내보내는 tool_calls — 에 sanitize 규칙을 추가하세요: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize는 툴 호출 인자만 가립니다 — 툴이 반환하는 콘텐츠는 결코 아닙니다. 그것은 인바운드 툴 결과가 아니라 아웃바운드 호출 형태에 대한 방어입니다. inbound 표면(아직 호출 시점 인자가 없는 곳)에서는 sanitize 판정이 deny로 격상됩니다. 전체 매칭 언어는 Firewall 규칙을 참조하세요.

​
4. 아웃바운드 목적지 잠그기 — egress 허용 목록

가장 내구성 있는 방어는 네트워크 경계 자체입니다: 여러분의 에이전트가 정당하게 도달하도록 허용된 호스트를 열거하고 나머지 모든 것을 거부하세요. egress 규칙은 stage: egress와 egress 필드를 사용합니다; 판정이 극성을 설정합니다 — allow는 나열된 목적지를 통과시키고 더 낮은 우선순위의 deny 캐치올이 나머지를 차단합니다. 동일한 exfil-firewall 정책에 다음 규칙을 추가하세요: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": ["api.openai.com", "api.anthropic.com", "api.orcarouter.ai"]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
항목은 CIDR, IP 리터럴, 또는 대소문자 구분 없는 호스트명으로 매치됩니다. 명시적 허용 목록 없이 내부 서비스를 향한 SSRF를 멈추려면, 클라우드 메타데이터 엔드포인트(169.254.169.254)와 RFC-1918 사설 범위(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)를 나열하는 egress 거부 규칙을 직접 작성하세요. 거부된 호출은 HTTP 400 firewall_blocked를 반환합니다.
어떤 프리셋도 CIDR egress 규칙을 제공하지 않습니다 — host/CIDR 허용 및 거부 항목은 여러분이 직접 작성합니다. tight 자율성 수준은 인접한 빠른 경로입니다: 그것은 fetch 형태의 툴 이름(http_fetch, web_search, fetch_url, request)을 완전히 거부하여, 목적지가 평가되기도 전에 네트워크 기능을 제거합니다. 에이전트가 그 툴이 전혀 필요 없을 때 사용하세요.

​
5. 범위 지정 키 하나 연결하기

정책은 그것으로 해석되는 키에서만 강제됩니다. 에이전트에게 자신만의 키를, 그것이 필요한 최소한으로 범위 지정하여 주세요 — 결코 계정 전체 키가 아니라. API Keys → New key(Developer 역할)에서:
Guardrail 드롭다운에서 exfil-shield를 고르고(guardrail_id 설정) Firewall policy 드롭다운에서 exfil-firewall을 고르세요 (firewall_policy_id 설정). 두 바인딩 모두 게이트웨이의 키에 존재합니다. 명시적 guardrail 연결은 결코 조용히 폴백하지 않습니다 — 그것을 비활성화하는 것이 off 스위치입니다. 반면 비활성화된 firewall 정책은 워크스페이스 기본 정책으로 폴백합니다.
손상된 키가 쿼터를 고갈시킬 수 없도록 credit_limit_usd를 합리적인 상한으로 설정하고(0 = 무제한), 에이전트가 고정된 서버에서 호출하면 allow_ips를 백엔드의 egress IP로 설정하세요. 임시 키에는 expired_time을 설정하세요(-1 = 만료 안 됨).
키는 생성 후 표시 시 마스킹됩니다 — 한 번 복사하세요. 이제 여러분의 에이전트는 강제가 일어나고 있음을 인지하는 코드 없이 모든 요청을 exfil-shield를 통해, 모든 툴 호출을 exfil-firewall을 통해 실행합니다.

​
6. shadow mode로 롤아웃한 다음, 지켜보기

여러분의 에이전트가 정당하게 도달하는 모든 호스트를 아직 모른다면, 맹목적으로 강제하지 마세요 — 먼저 관찰하세요. 전체 observe → shadow → enforce 경로는 강제 모드를 참조하세요.
1

egress 규칙 shadow 처리

exfil-firewall에 shadow_mode: true를 설정하세요. 모든 강제 판정이 audit로 강등되고 목적지와 함께 [shadow] would deny로 로깅됩니다. shadow mode가 켜져 있는 동안 어떤 트래픽도 차단되지 않습니다.
2

피드 지켜보기

Firewall → Events / Runs(Developer+)는 여러분의 에이전트가 친 모든 툴 호출과 egress 목적지, 그리고 무엇이 거부되었을지를 보여줍니다. Guardrails → Matches(모든 Member)는 입력 guardrail이 잡은 모든 시크릿을 보여줍니다. 공격자가 도달 가능한 호스트만 거부되도록 egress allow 목록을 튜닝하세요.
3

강제

shadow_mode를 끄세요. 바로 다음 요청이 통제됩니다 — 프롬프트에서 자격 증명 차단, 툴 인자에서 시크릿 벗기기, 아웃바운드 호출을 여러분의 허용 목록으로 제한. 애플리케이션 변경 없음.
Matches 피드는 guardrail에 대해 Log raw content가 켜져 있을 때만 매치된 부분 문자열을 기록합니다(기본 꺼짐 — 프라이버시 보수적 자세). 정책을 튜닝하려면 거짓 양성을 표시하세요(Admin). 모든 guardrail 변경은 diff하고 revert할 수 있는 version-history 행을 씁니다; firewall 정책 변경은 감사 추적에 기록됩니다.

​
7. 한눈에 보는 커버리지

유출 단계그것을 멈추는 레이어
자격 증명이 요청에 들어옴Secrets Blocker guardrail(입력)
모델이 시크릿을 운반하는 툴 호출을 내보냄sanitize firewall 규칙(response 표면)
툴이 공격자 호스트를 다이얼함Egress allow / deny 규칙
에이전트가 클라우드 메타데이터나 RFC-1918에 도달함그 CIDR을 나열하는 Egress 거부 규칙
fetch 형태의 툴이 모델에 제공됨tight 자율성 수준(툴 이름 거부)

​
8. 다음으로 갈 곳

Firewall 규칙 레퍼런스

전체 매칭 언어 — egress 목록, CIDR, 새니타이저, 그리고 모든 판정.

데이터 유출 위협

이 레시피가 방어하는 공격 해부, 처음부터 끝까지.

MCP 에이전트 강화

에이전트가 MCP 서버를 통해 디스패치하는 모든 tools/call을 통제하세요.

PII 안전 로깅

민감한 데이터를 요청 로그와 Matches 피드에서 멀리 두세요.