메인 콘텐츠로 건너뛰기
원격 MCP 서버는 당신의 에이전트가 툴을 호출하는 HTTP 엔드포인트일 뿐이며 — 그리고 대부분은 토큰, OAuth 클라이언트, 또는 basic auth 뒤에 있습니다. 그 서버를 Firewall의 MCP 게이트웨이 뒤에 등록하면, OrcaRouter에 자격 증명을 한 번 넘겨주고, 어떻게 인증할지 고르면, 게이트웨이가 디스패치 시 그것을 주입합니다. 시크릿은 저장 시 암호화되며 결코 모델이나 당신의 에이전트 코드로 이동하지 않습니다. 이 페이지는 서버 등록의 인증 측면을 다룹니다: 네 가지 auth_mode 형태와 당신의 자격 증명에 무슨 일이 일어나는지. 연결이 수립된 후 게이트웨이가 각 tools/call에 대해 하는 모든 것 — 호출별 정책, 네임스페이싱, SSRF 보호 — 은 MCP 게이트웨이 레퍼런스를 참조하세요.

​
1. 왜 게이트웨이에서 인증하는가

게이트웨이가 없으면, MCP 서버와 대화하는 모든 에이전트가 그 서버 토큰의 자체 복사본을 운반하며, 구성과 프롬프트 전반에 흩어집니다. 대신 서버를 OrcaRouter를 통해 라우팅하면 자격 증명이 정확히 한 곳에 존재합니다:
  • 서버당 하나의 저장된 시크릿. 워크스페이스 레코드에 자격 증명을 한 번 등록합니다. 에이전트는 OrcaRouter 키로 게이트웨이에 연결합니다 — 그들은 결코 업스트림 서버의 토큰을 보지 않습니다.
  • 저장 시 암호화, 읽기 시 마스킹. 자격 증명은 저장될 때 암호화됩니다. 콘솔이나 SDK를 통해 서버를 다시 읽을 때마다, 시크릿은 마스킹되어 돌아옵니다 — 그것을 평문으로 반환하는 API는 없습니다.
  • 디스패치 시 주입. 게이트웨이는 tools/call을 실제 서버로 전달하는 바로 그 순간에만 자격 증명을 복호화한 다음, 그것을 그 아웃바운드 요청에 첨부합니다. 그것은 결코 모델이나 클라이언트에 에코되지 않습니다.
다시 읽을 수 없는 자격 증명은 결함이 아니라 기능입니다. 읽기가 항상 마스킹되므로, 유출된 콘솔 세션이나 SDK 토큰은 당신의 MCP 서버 시크릿을 유출할 수 없습니다 — 그것은 그것들을 다시 가리키거나 교체할 수만 있습니다.

​
2. auth_mode 고르기

모든 서버 등록은 auth_mode를 담습니다. 그것은 네 가지 값의 닫힌 집합이며, auth_json에 공급하는 자격 증명의 형태를 결정합니다:
서버가 개방되어 있거나(또는 네트워크로 게이트웨이를 신뢰). auth_json을 비워 두세요. 이것은 auth_mode를 설정하지 않을 때의 기본값입니다.
호스팅된 MCP 서버의 가장 흔한 경우. 하나의 토큰을 공급하면; 게이트웨이가 각 호출에 bearer 자격 증명으로 전송합니다.
{ "token": "ghp_…" }
OAuth로 보호되는 서버용. 이미 발급한 access_token을 공급하면; 게이트웨이가 bearer와 정확히 똑같이 bearer 자격 증명으로 전송합니다. 자동 client-credentials 교환(client_id/client_secret을 새 토큰과 맞바꾸기)은 아직 사용할 수 없습니다 — access_token이 없는 oauth 등록은 거부됩니다.
{ "access_token": "…" }
HTTP basic auth.
{ "username": "…", "password": "…" }
auth_json은 auth_mode가 none이 아닌 무엇이든일 때마다 필수입니다. 빈 자격 증명으로 bearer/oauth/basic 서버를 등록하는 것은 거부됩니다 — 게이트웨이는 절반만 구성된 연결을 영속화하지 않습니다.

​
3. 보안 MCP 서버 등록하기 — 하나의 예

MCP 서버 등록은 콘솔 액션입니다: 그것은 /api/workspace/firewall/mcp_servers에 대해 세션/액세스 토큰으로 실행되며, 서버를 쓰는 것은 Developer+ 역할이 필요합니다. (이것은 /v1/* 모델 호출에 사용하는 sk-orca-… 릴레이 키와 다릅니다 — 그 키는 결코 워크스페이스 구성을 관리하지 않습니다.) firewall 콘솔에서, 또는 세션 토큰으로 직접 bearer-auth 서버를 등록하세요: 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
name은 워크스페이스당 고유하며(중복은 HTTP 409를 반환), .을 담을 수 없습니다 — 그 문자는 툴을 <server>.<tool>로 네임스페이스 처리합니다. 들어오는 길에 OrcaRouter는 auth_json을 암호화하고 암호문만 저장합니다. 서버를 다시 읽으면, 마스킹된 형태를 얻습니다.
저장된 시크릿을 변경하지 않으려면 업데이트 시 마스킹된 값을 그대로 돌려보내세요 — 실제로 교체하려는 경우에만 진짜 auth_json을 보내세요. 교체 흐름은 자격 증명 교체를 참조하세요.

​
4. 연결이 작동함을 증명하기

게이트웨이가 당신이 저장한 자격 증명으로 실제로 서버에 도달할 수 있을 때까지 인증은 끝나지 않습니다. 그것을 Probe하세요: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"
게이트웨이는 복호화된 자격 증명을 사용하여 엔드포인트에 연결하고, 서버의 툴을 나열하며, 도달 가능성 status를 기록합니다:
status의미
ok도달 및 인증됨; 툴 발견됨.
degraded도달 가능하지만 완전히 건강하지는 않음.
down연결 또는 인증할 수 없음.
등록 직후의 down 결과는 거의 항상 잘못된 자격 증명이나 잘못된 auth_mode를 의미합니다 — auth_json을 고치고 다시 프로빙하세요. 프로빙은 Developer+ 액션입니다; 번들 인프로세스 서버는 엔드포인트가 없어 프로빙 불가합니다.
비활성화된 서버는 깔끔한 오프 스위치입니다: 그 툴은 게이트웨이에서 사라지고 그 자격 증명은 결코 복호화되지 않습니다. 인증을 정리하는 동안 서버를 비활성화한 다음, 프로브가 ok로 돌아오면 다시 활성화하세요.

​
5. 에이전트에서 서버 읽기

당신의 에이전트는 자격 증명을 읽지 않습니다. SDK 프록시가 런타임 레지스트리가 필요하면 firewall-gateway-scoped 키로 GET /api/v1/firewall/mcp_servers를 호출합니다 — 전용 키이며, 당신의 릴레이 키도 세션도 아닙니다. 그 경로는 활성화된 서버만 제공하며, 게이트웨이는 여전히 자격 증명 주입을 처음부터 끝까지 소유합니다. 에이전트를 통합 MCP 엔드포인트에 연결하는 것은 게이트웨이 레퍼런스에 다뤄집니다.

​
6. 다음 단계

첫 서버 연결하기

빈 워크스페이스에서 라이브 툴까지의 전체 등록 워크스루.

자격 증명 교체

연결을 끊지 않고 유출되거나 만료되는 시크릿을 교체합니다.

MCP 툴 허용 목록

서버의 어떤 툴을 에이전트가 실제로 호출할 수 있는지 결정합니다.

Egress 제한

서버의 툴이 네트워크에서 도달할 수 있는 곳을 제약합니다.
이것 뒤의 개념 — 게이트웨이가 요청 경로에 어떻게 위치하는지와 자격 증명이 결코 모델에 닿지 않는 이유 — 은 OrcaRouter가 검사하는 방식과 AI 에이전트 보안 강화를 참조하세요. 이것이 닫는 위협은 MCP 툴 포이즈닝과 데이터 유출을 참조하세요.