1. 게이트웨이가 올바른 검사 지점인 이유
대부분의 보안 제어는 애플리케이션에 존재합니다: 라이브러리 래퍼, 에이전트 프레임워크 훅, 프로바이더별 SDK. 이러한 제어에는 치명적인 구조적 결함이 있습니다 — 두 번째 프로바이더를 추가하거나, 프레임워크를 바꾸거나, 에이전트가 새 스킬을 자기 설치하도록 허용하면 즉시 깨집니다. 게이트웨이에는 그런 이음새가 없습니다. 에이전트가 발행하는 모든 호출은, 모델, 프로바이더, 또는 툴 기능이 어떻게 도달했든, 업스트림에 도달하기 전에 단 하나의 지점을 통과합니다. 그것이 보장할 수 있는 유일한 레이어입니다: 그것이 일어났다면, 게이트웨이가 봤다. OrcaRouter는 두 가지 별개의 강제 패스를 위해 그 위치를 사용합니다:- Guardrails는 텍스트를 검사합니다 — 에이전트가 보내는 프롬프트와
모델이 반환하는 응답. guardrail 차단은 **HTTP 400
guardrail_blocked**를 반환하고 쿼터를 소모하지 않습니다. - Firewall은 액션을 판단합니다 — 에이전트가 호출하는 툴, 접근하는 MCP
서버, 보고하는 네트워크 목적지. firewall 거부는 inbound 표면에서 **HTTP
400
firewall_blocked**를, 또는 MCP 표면에서 툴 오류를 반환하므로, 모델이 거부를 보고 이에 대해 추론할 수 있습니다.
https://api.orcarouter.ai/v1을 계속 호출합니다.
2. 네 가지 강제 표면
Firewall은 정확히 하나의 표면 — 게이트웨이가 그것을 볼 호출 수명 주기의 지점 — 에 대해 모든 툴 호출을 평가합니다.| 표면 | 게이트웨이가 보는 것 |
|---|---|
inbound | 에이전트가 요청에서 모델에게 광고하는 툴 — 툴 정의. 여기서 차단하면 모델이 위험한 툴을 선택하는 것 자체를 막을 수 있습니다. |
response | 모델이 응답에서 발행하는 tool_calls — 디스패치되기 전의 모델이 선택한 액션. |
mcp | Firewall MCP 게이트웨이를 통해 디스패치되거나 SDK 훅을 통해 평가된 tools/call — 디스패치 순간의 호출. |
egress | 툴이 보고하는 아웃바운드 네트워크 목적지 (호스트 / IP / CIDR) — SSRF와 데이터 유출 표면. |
input (요청 프롬프트와 메시지)와 output (모델의 응답 텍스트). 단일
요청이 그 모두를 통과할 수 있습니다.
3. 최초 사용 시 탐지
탐지는 게이트웨이에서, 최초 사용 시 일어납니다 — 설치 시점이 아닌.
에이전트가 자기 설치한 툴, MCP 서버, 또는 스킬은 호출이 처음 게이트웨이를
통과할 때 포착됩니다. 이것은 의도적입니다: 게이트웨이는 기능이 어떻게
도달했든 모든 프로바이더, 모든 에이전트, 모든 호출을 보는 단 하나의
초크 포인트입니다. 설치 시점 탐지를 기다리면 런타임에 로드된 기능을 놓칩니다.
4. 게이트웨이가 볼 수 없는 것
검사 보장은 게이트웨이를 통과하는 호출을 다룹니다. 에이전트가 완전히 자체 프로세스 내부에서 실행하는 툴 — 로컬 파일을 읽거나, 라이브러리 함수를 호출하거나, 게이트웨이에 메시지를 전혀 보내지 않고 서브프로세스를 실행하는 — 에는 적용되지 않습니다. 이것은 정직한 경계이지, 설계 결함이 아닙니다. 설계 목표는 게이트웨이를 중요한 호출 — 실제 세계에 결과를 미치는 것들 — 의 감사된 경로로 만드는 것입니다:| 실행 위치 | 게이트웨이가 봅니까? | 갭을 닫는 방법 |
|---|---|---|
모델 매개 툴 호출 (모델이 tool_calls를 발행) | 예 — response 표면 | 조치 불필요; 이미 관리됩니다. |
| Firewall MCP 게이트웨이를 통한 MCP 디스패치 | 예 — mcp 표면 | 조치 불필요; 이미 관리됩니다. |
에이전트가 디스패치 전에 POST /api/v1/firewall/evaluate를 호출 | 예 — 인라인으로 평가됨 | evaluate 훅을 통해 이미 관리됩니다. |
| 툴이 프로세스 내부에서 실행되고, 게이트웨이 접촉 없음 | 아니요 | 에이전트 프로세스에서 직접 호출하는 대신 MCP 디스패치와 네트워크 호출 툴을 게이트웨이를 통해 라우팅하세요. |
5. 검사 데이터에 대한 역할 게이팅
검사 표면에 대한 접근은 워크스페이스 내에서 역할로 범위가 지정됩니다:| 기능 | 최소 역할 |
|---|---|
| Guardrail 매치, firewall 정책 & 발견된 툴 읽기 | Member |
| Firewall Events & Runs 피드 읽기 | Developer |
| Guardrails, firewall 정책, 규칙 생성 또는 변경 | Developer |
컴플라이언스 내보내기, firewall-gateway-scoped 키 평문, is_firewall_gateway 키 플래그 | Admin |
firewall-gateway-scoped 토큰 (
/api/v1/firewall/evaluate와 MCP 게이트웨이를
호출하는 데 사용되는 키)은 생성에 Admin 역할이 필요합니다. 일반 API 키는
그 라우트들에서 403을 받습니다.6. 다음 단계
제어 스택
전체 요청 경로 — 키, guardrails, 모델, firewall, 감사 —
하나의 다이어그램으로.
공유 책임
게이트웨이가 보호하는 것과 애플리케이션에 남는 것.
Agent Firewall
정책 작성, 표면 구성, 툴 호출 심층 관리.