메인 콘텐츠로 건너뛰기
등록된 MCP 서버는 원하는 어떤 툴이든 광고합니다 — 그리고 에이전트는 그 중 무엇이든 기꺼이 호출합니다. 안전한 자세는 그 반대입니다: 실제로 필요한 짧은 툴 목록을 정하고, 정확히 그것들만 허용하고, 나머지는 거부합니다. 그것이 **허용 목록(allow-list)**이며, OrcaRouter에서는 mcp 표면에서 평가되는 tool_name_glob 규칙으로 그것을 구축합니다. MCP 게이트웨이를 가로지르는 모든 tools/call은 실제 서버에 도달하기 전에 당신의 firewall 정책을 통해 실행됩니다. 따라서 허용 목록은 권고가 아닙니다 — 허용하지 않은 툴로의 호출은 결코 디스패치되지 않습니다.
정책 편집은 콘솔 액션입니다. /api/workspace/firewall/* 라우트는 릴레이 sk-orca-… 키가 아니라 세션/액세스 토큰으로 인증합니다. 규칙 쓰기는 Developer+ 역할이 필요합니다; 어떤 워크스페이스 멤버(Viewer까지)도 정책과 발견된 툴 피드를 읽을 수 있습니다.

​
1. 왜 보안 mcp 툴을 위한 기본 거부 허용 목록인가

거부 목록 — “위험한 툴을 차단” — 은 서버가 새 툴을 추가하거나, 하나의 이름을 바꾸거나, 두 번째 서버를 연결하는 순간 실패합니다. 위험한 툴의 집합은 무한정입니다; 당신이 사용하려던 집합은 작고 알려져 있습니다. 허용 목록은 기본값을 뒤집어 알려지지 않은 것이 허용이 아니라 거부되게 합니다:
  • 새 툴은 기본적으로 거부됩니다. 연결 후 delete_repo 툴이 자라난 서버는 그것을 허용 목록에 추가할 때까지 호출될 수 없습니다.
  • 범위는 서버별입니다. <server>.<tool> 네임스페이스는 github.* 아래 나머지 모두를 거부하면서 github.create_issue를 허용할 수 있게 합니다.
  • 하나의 초크 포인트. 동일한 정책이 번들 서버와 게이트웨이 뒤의 모든 BYO 서버를 관리하므로, 허용 목록을 읽을 한 곳이 있습니다.
허용 목록은 observe 모드와 자연스럽게 짝지어집니다: 먼저 그것을 켜고, 실제 트래픽이 Discovered Tools 피드를 채우게 한 다음, 당신이 보는 툴을 명시적 allow 규칙으로 승격하고 기본값을 deny로 전환하세요.

​
2. 두 조각

허용 목록은 default_verdict 더하기 정렬된 규칙 세트입니다.

default_verdict: deny

어떤 규칙도 매칭하지 않는 tools/call에 대한 정책의 폴백. 그것을 deny로 설정하면 명시적으로 허용하지 않은 모든 것이 차단됩니다. (그것은 allow와 audit도 받습니다 — audit가 기본값입니다.)

allow 규칙

툴당(또는 글로브당) 하나의 규칙. 각각은 tool_name_glob과 allow 판정을 담습니다. 글로브에 매칭하는 tools/call은 allow로 해결되어 디스패치됩니다; 나머지 모두는 deny 기본값으로 떨어집니다.
글로브는 네임스페이스 처리된 툴 이름에 대해 매칭됩니다 — github.create_issue, shell.exec. *는 어떤 툴이든 매칭합니다(아껴 쓰세요; *가 있는 allow 규칙은 전체 허용 목록을 무효화합니다). 선행 <server>.는 글로브를 한 서버로 범위 지정합니다.

​
3. 하나의 구체적인 예

github 서버를 연결했고 에이전트가 읽고 이슈를 열도록만 하고 싶습니다 — 결코 삭제하거나 관리하지 않게. 콘솔에서, Firewall → Policies를 열고, 정책의 기본 판정을 deny로 설정하고, 두 개의 allow 규칙을 추가하세요:
순서tool_name_glob판정
1github.create_issueallow
2github.list_issuesallow
그것이 전체 허용 목록입니다. 기본값이 deny일 때:
  • github.create_issue → 규칙 1 매칭 → allow, 디스패치됨.
  • github.delete_repo → 아무것도 매칭 안 됨 → 기본적으로 deny.
거부된 MCP 호출은 모델에 툴 오류(firewall deny: …)로 돌아옵니다 — 실패하는 어떤 툴이든 반환하는 것과 동일한 형태 — 그래서 에이전트가 크래시하는 대신 적응할 수 있습니다. (inbound 표면에서는 deny가 대신 에러 코드 firewall_blocked의 HTTP 400입니다.)
규칙은 정렬되어 위에서 아래로 평가됩니다. 광범위한 tool_name_glob: github.* allow를 특정 deny 규칙 위에 두지 마세요 — 첫 매칭이 이기며 와일드카드가 당신이 제외하려던 바로 그 툴을 허용할 것입니다. 의심스러울 때는 허용 목록을 좁게 유지하고 와일드카드보다 deny 기본값에 기대세요.

​
4. 인자로 좁히기

허용 목록의 툴 이름도 여전히 나쁜 인자로 호출될 수 있습니다. 규칙에 args_match 절(JSONPath + eq, contains, regex, in, 또는 cidr_match 같은 연산자)을 추가하거나, 특정 인자 형태에 대해 allow 위에 deny 규칙을 계층화하여 더 좁히세요 — 예를 들어, github.create_issue를 허용하되 대상 repo가 승인된 목록에 없을 때 deny. 전체 연산자 세트는 firewall 규칙 레퍼런스를 참조하세요.
sanitize는 전달 전에 툴 호출의 인자를 편집합니다 — 그것은 툴이 반환하는 것에 결코 손대지 않습니다. 반환된 콘텐츠를 다듬는 것은 다른 통제입니다; 툴 출력 정화를 참조하세요.

​
5. 안전하게 롤아웃하기

프로덕션에서 전체 서버 기본 거부를 전환하면 잊은 툴에 조용히 의존하던 에이전트를 깨뜨릴 위험이 있습니다. 두 설정이 그것을 디리스크합니다:
강제 판정을 audit로 다운그레이드하는 정책별 플래그. 당신의 deny 기본값과 deny 규칙이 차단하는 대신 [shadow] would deny …를 로깅하므로, 그것이 물기 전에 실제 트래픽에 대해 허용 목록을 검증할 수 있습니다. 강제 모드에서 더 읽으세요.
모든 커버되지 않은 호출을 Discovered Tools 피드의 갭으로 로깅하는 워크스페이스 설정. 허용 목록을 작성하기 전에 그것을 실행하여 에이전트가 호출하는 툴을 정확히 파악한 다음, 각각을 명시적 allow 규칙으로 승격하세요.
shadow 로그가 깨끗해지면 — 정당한 호출이 거부되지 않았을 — shadow_mode를 지우면 허용 목록이 강제됩니다.

​
6. 작동 검증하기

강제한 후, 거부된 툴이 실제로 거부되는지 확인하세요:
  • Dry-run 으로 정책에 대해 tools/call을 실행(Developer+)하여 판정과 어떤 규칙 — 또는 기본값 — 이 그것을 생성했는지 실제 트래픽을 보내지 않고 보세요. 툴 이름, 표면, 그리고 샘플 인자를 전달하면; 엔진이 그것들을 평가하고 이벤트를 기록하지 않고 판정 트레이스를 반환합니다.
  • 이벤트를 관찰하세요. 각 차단된 호출은 **Developer+**가 콘솔에서 읽을 수 있는 firewall 이벤트를 기록합니다; 감사 이벤트 페이지가 피드와 그 필드를 다룹니다.
각 규칙을 손으로 작성하지 않으시겠어요? tight 자율성 프리셋이 당신을 위해 기본 거부 정책(파괴적 셸 툴과 fetch 형태 툴 이름에 대한 deny 규칙 더하기)을 작성한 다음, 필요한 특정 툴을 다시 추가하면 됩니다. 각 자율성 수준이 설치하는 것은 강제 모드를 참조하세요.

​
관련

MCP 서버 연결하기

툴을 허용 목록에 넣기 전에 서버를 등록합니다.

Firewall: MCP 서버

게이트웨이의 런타임 동작과 호출별 판정.

Firewall 규칙 레퍼런스

전체 규칙 DSL — 글로브, args_match, egress, sanitize.

위험한 툴 호출

허용 목록이 봉쇄하도록 만들어진 위협.

Egress 한도

허용된 툴이 도달할 수 있는 곳을 관리합니다.

Guardrails vs. firewall

콘텐츠 정책 vs. 툴 정책을 언제 사용할지.