메인 콘텐츠로 건너뛰기
네트워크에 접근할 수 있는 에이전트는 데이터 파이프로 바뀔 수 있습니다. 공격자가 에이전트가 읽는 문서에 지시사항을 심어 — 웹 페이지, 검색된 청크, 툴 결과 — 그 지시사항이 에이전트를 공격자 제어 호스트에 민감한 데이터를 POST하거나, 내부 서비스를 탐색 (SSRF)하도록 유도합니다. 에이전트는 유출하기로 “결정”하지 않습니다; 그것은 자신에게 합법적인 지시사항처럼 보이는 것을 실행합니다. 이 페이지는 OrcaRouter의 Agent Firewall과 Guardrails 스택이 에이전트 코드를 변경하지 않고 AI 데이터 유출을 방어하는 방법을 다룹니다.
Firewall은 MCP 디스패치 경로나 evaluate 훅을 통해 게이트웨이를 통해 라우팅된 목적지에 대한 egress만 봅니다. 에이전트가 완전히 자체 프로세스 내부에서 실행하는 툴은 시야 밖입니다. 에이전트의 네트워크 바인딩 툴 호출을 게이트웨이를 통해 라우팅하면 관리됩니다.

​
1. 공격 작동 방식

에이전트를 통한 표준 경로는 세 단계로 실행됩니다:
  1. 인젝션 — 에이전트가 삽입된 지시사항을 담은 신뢰할 수 없는 콘텐츠를 읽습니다 (웹 페이지, 가져온 문서, CRM 메모).
  2. 수집 — 주입된 지시사항이 에이전트에게 이미 보유한 툴을 사용하여 민감한 자료를 수집하라고 지시합니다 — API 키, 데이터베이스 행, 사용자 PII.
  3. 유출 — 에이전트가 fetch 형태 툴을 통해 그 자료를 보내라는 지시를 받습니다: http_fetch, web_search, fetch_url, 또는 request. 목적지는 공격자 제어입니다.
SSRF는 내부로 리디렉션된 동일한 형태입니다: 외부 호스트 대신 에이전트가 169.254.169.254 (클라우드 메타데이터), 내부 Redis 포트, 또는 다른 비공개 서비스로 유도됩니다. 인젝션 단계는 프롬프트 인젝션을 참조하세요; 이 페이지는 네트워크 단계에 집중합니다.

​
2. Egress 허용 목록 — 아웃바운드 목적지 잠금

가장 내구성 있는 방어는 egress 허용 목록입니다: 에이전트가 합법적으로 접근하도록 허가된 호스트를 열거하고 그 외 모든 것을 거부합니다. Egress 규칙은 stage: egress와 egress 필드를 사용합니다. 판정이 극성을 제어합니다 — allow가 나열된 목적지를 통과시키고; 낮은 우선순위 deny 캐치-올이 나머지를 차단합니다: 
[
  {
    "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 리터럴, 또는 대소문자 구분 없는 호스트명으로 매칭됩니다. 호스트명은 최선의 노력으로 해석되고 IP/CIDR 항목에 대해 재확인됩니다. 따라서 DNS가 반환한 169.254.169.254 같은 목적지는 여전히 10.0.0.0/8 CIDR 거부 항목에 의해 잡힙니다. 차단된 호출은 오류 코드 firewall_blocked와 함께 HTTP 400을 반환합니다. 명시적 허용 목록 없이 알려진 나쁜 범위를 거부하려면, 클라우드 메타데이터 엔드포인트 (169.254.169.254)와 RFC-1918 비공개 범위 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)를 나열하는 대상 egress 거부 규칙을 작성하세요. 낮은 우선순위 번호에 허용 목록을 상단에 레이어하여 거부 규칙이 먼저 평가되게 하세요.

​
3. 이름 레이어에서 fetch 형태 툴 차단

Egress 목적지가 평가되기 전에, 기능 자체를 완전히 제거할 수 있습니다. tight 자율성 수준은 SSRF와 유출 백스톱으로 툴 이름 glob으로 http_fetch, web_search, fetch_url, request를 거부합니다. 에이전트가 이러한 툴이 필요하지 않다면, tight가 한 단계에서 공격 표면을 제거합니다: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
전체 tight 자세를 채택하지 않고 fetch 툴을 거부하려면, inbound 표면 거부 규칙을 작성하세요. inbound는 모델이 선택하기 전에 툴을 차단합니다 — 에이전트가 툴 목록에서 기능을 받지 못합니다: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
에이전트 스택이 사용하는 각 fetch 형태 툴 이름에 대해 반복하세요.

​
4. Secrets Blocker guardrail — 프롬프트에서 자격 증명 차단

Secrets Blocker guardrail은 입력 단계에서 실행되어 요청이 게이트웨이를 떠나기 전에 AWS 스타일 액세스 키, OpenAI 키, Anthropic 키, GitHub 토큰, 유사한 자격 증명 패턴에 대해 프롬프트를 스캔합니다. 시크릿이 탐지되면 요청이 차단됩니다 — 자격 증명이 모델에 도달하지 않고 툴 호출에 나타나지 않습니다. Guardrails 패널에서 또는 tight 자율성 수준의 일부로 활성화하세요. Firewall egress 규칙과 독립적입니다.
위협차단하는 레이어
프롬프트가 API 키를 담음Secrets Blocker (입력 guardrail)
에이전트가 공격자 호스트로 fetch 툴 호출Egress 허용/거부 규칙
모델에게 광고된 Fetch 형태 툴Inbound 거부 규칙 또는 tight 자율성
에이전트가 클라우드 메타데이터 또는 RFC-1918에 접근해당 CIDR을 나열하는 Egress 거부 규칙

​
5. Shadow mode로 롤아웃

오늘날 에이전트가 합법적으로 접근하는 호스트를 확신할 수 없다면, 강제하기 전에 shadow mode에서 시작하세요:
  1. 의도한 허용 목록으로 egress 규칙을 생성하고 정책에서 shadow_mode: true를 설정합니다.
  2. Events 피드를 관찰합니다 — 차단될 호출이 목적지와 함께 [shadow] would deny로 나타납니다.
  3. 공격자 접근 가능한 목적지만 거부될 때까지 allow 목록을 조정한 다음, shadow mode를 비활성화하여 강제를 시작합니다.
Shadow mode가 켜져 있는 동안 트래픽이 차단되지 않습니다.

​
6. 다음 단계

Firewall 규칙 레퍼런스

완전한 매칭 언어 — egress 목록, CIDR, 인자 절, 모든 판정.

Agent Firewall 개요

정책, 표면, 자율성 수준, 관측성.

프롬프트 인젝션

에이전트를 유출로 유도하는 인젝션 단계.

MCP 툴 포이즈닝

fetch 형태 기능을 등록하는 악의적인 MCP 툴.