메인 콘텐츠로 건너뛰기
키가 유출되거나, 계약자가 떠나거나, 토큰이 단순히 만료될 때, 등록된 MCP 서버의 자격 증명을 교체해야 합니다 — 서버 레코드를 해체하거나, firewall 규칙을 다시 작성하거나, 게이트웨이를 통해 이미 연결된 에이전트를 중단시키지 않으면서. 그것이 바로 교체입니다: 기존 서버의 인증을 업데이트하면, MCP 게이트웨이가 디스패치하는 바로 다음 tools/call부터 새 시크릿을 주입하기 시작합니다. 각 서버의 인증은 저장 시 암호화되고 읽기 시 마스킹되므로, 평문 토큰은 결코 당신의 콘솔, 에이전트, 또는 모델로 왕복하지 않습니다. 교체는 워크스페이스 콘솔을 통한 한 필드 업데이트입니다.

1. 왜 MCP 시크릿 교체가 자체 액션인가

등록된 MCP 서버는 자격 증명이 변경될 때 잃고 싶지 않은 세 가지를 보유합니다: 고유한 워크스페이스 name(규칙이 글로빙하는 <server>.<tool> 네임스페이스), endpoint, 그리고 발견된 툴 세트. 토큰을 변경하기 위해 서버를 삭제하고 재생성하면 <server>.*로 범위 지정된 모든 규칙을 고아로 만들고 새 프로브를 강제합니다. 교체는 그 모든 것을 우회합니다. 동일한 서버 레코드를 새 auth_json으로 PUT하면; 나머지 모든 것 — 이름, 규칙, 발견된 툴 — 은 그대로 남습니다.
게이트웨이는 디스패치 시 자격 증명을 주입하며, 업스트림 호출을 하기 위해서만 그것을 복호화합니다. 교체된 시크릿은 다음 연결에서 효력을 발생합니다 — OrcaRouter는 모든 서버 변경에서 워크스페이스별 툴 캐시를 무효화하므로, 기다릴 TTL이 없습니다.

2. 하나의 구체적인 교체

github라는 이름의 MCP 서버를 bearer 토큰으로 등록했고 그 토큰을 롤링해야 한다고 합시다. 먼저 현재 레코드를 읽으세요 — 응답은 시크릿을 마스킹하므로 결코 옛 평문을 다루지 않습니다:
# 콘솔 세션(UserAuth)에서 구성, 릴레이 키 아님.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42 \
  -H "Authorization: Bearer <your console access token>"
그런 다음 새 자격 증명으로 동일한 레코드를 PUT하세요. 본문에 id와 새로운 auth_json을 보내면; 게이트웨이가 데이터베이스에 닿기 전에 그것을 다시 암호화합니다:
curl -X PUT https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your console access token>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": 42,
    "auth_json": "{\"token\":\"ghp_NEW_token\"}"
  }'
생략한 필드는 그대로 둡니다 — name, endpoint, auth_mode, 그리고 enabled는 모두 저장된 값을 유지합니다. 새 토큰은 다음 tools/call에서 라이브입니다.
시크릿을 유지하려면 마스크를 에코하고, 변경하려면 실제 값을 보내세요. 레코드를 읽고 그대로 PUT하면, auth_json의 마스킹된 플레이스홀더가 “저장된 것을 유지”로 인식됩니다 — 시크릿은 마스크로 덮어쓰이지 않습니다. 진정으로 새로운 auth_json만이 자격 증명을 교체합니다.

3. 시크릿뿐 아니라 인증 모드 변경하기

교체는 서버를 인증 스킴 간에 이동하는 것도 다룹니다. auth_mode 값의 닫힌 집합은:
자격 증명 없음. auth_json은 비어 있습니다. 공개 또는 네트워크 신뢰 MCP 서버에 사용하세요.
{ "token": "…" }Authorization: Bearer 헤더로 전송됨.
{ "client_id": "…", "client_secret": "…", "token_url": "…" }. JSON에 정적 access_token을 저장하면, 게이트웨이가 그것을 bearer 토큰으로 전송합니다; client-credentials 교환 자체는 아직 실행되지 않으므로, 라이브 교환이 필요한 서버는 토큰을 공급할 때까지 실패합니다.
{ "username": "…", "password": "…" } — HTTP basic auth.
두 자격 증명 모드 간 전환(예: bearerbasic)은 동일한 요청에서 새로운 auth_json을 보내야 합니다. 저장된 암호문은 원래 모드에 묶여 있으므로, 옛 시크릿은 새 형태로 재해석될 수 없습니다 — 새 자격 증명을 공급하거나, 업데이트가 거부됩니다.

4. 교체 후: 다시 프로빙

교체된 자격 증명은 옛 토큰이 폐기되었다면 도달할 수 있는 툴을 변경합니다. 새 인증이 작동하는지 확인하고 도달 가능성 status를 새로 고치려면 서버를 프로브하세요:
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your console access token>"
프로브는 새로운 복호화된 자격 증명으로 MCP 핸드셰이크를 실행하고 ok, degraded, 또는 down을 보고합니다. 인증 실패는 실행 도중의 혼란스러운 툴 오류가 아니라 여기서 표면화됩니다.

5. 역할과 마스킹되는 것

이 페이지의 모든 액션은 워크스페이스 범위 콘솔 호출 (/api/workspace/firewall/mcp_servers, UserAuth)이며 역할로 제한됩니다:
액션최소 역할
서버 읽기(시크릿 마스킹됨)Member
교체 / 업데이트 / 등록Developer+
삭제Developer+
평문은 결코 당신의 콘솔에 반환되지 않습니다. 읽기는 시크릿을 마스킹하고 엔드포인트를 편집합니다; 게이트웨이만이 자격 증명을 복호화하며, 업스트림 서버에 다이얼하는 바로 그 순간에만 그렇게 합니다. 모델과 당신의 에이전트는 옛 토큰도 새 토큰도 보지 않습니다.

6. 이것이 들어맞는 곳

교체는 더 넓은 MCP 신뢰 표면의 한 작업입니다. 서버가 연결되고 인증되면, 동일한 게이트웨이가 모든 tools/call을 실행 전에 당신의 firewall 정책에 대해 평가하고, 위에 스킬 격리를 적용하며, 아웃바운드 도달을 관리합니다.

서버 연결하기

MCP 서버를 등록하고 그 툴을 프로빙합니다.

인증

각 서버에 맞는 인증 모드를 고릅니다.

MCP 툴 허용 목록

각 서버가 노출할 수 있는 툴을 범위 지정합니다.

Egress 한도

툴 호출이 도달할 수 있는 곳을 관리합니다.
전체 서버 수명 주기는 Firewall: MCP 서버를, 엔드투엔드 하드닝 패스는 MCP 신뢰 체크리스트를 참조하세요. 교체는 또한 MCP 툴 포이즈닝데이터 유출에 대한 상시 항목입니다: 빠르게 롤링할 수 있는 자격 증명은 유출이 깔고 앉을 수 없는 자격 증명입니다.

FAQ

아니요. 교체는 자격 증명만 변경합니다. 서버는 name을 유지하므로, <server>.*로 범위 지정된 모든 규칙 — 그리고 모든 허용 목록 — 은 첨부된 채 남습니다.
새 시크릿은 다음 디스패치되는 tools/call에 주입됩니다. 기다릴 캐시 TTL이 없습니다 — OrcaRouter는 모든 서버 변경에서 워크스페이스 툴 캐시를 무효화합니다.
아니요 — 그리고 그것이 핵심입니다. 읽기는 마스킹된 시크릿을 반환합니다; 평문은 디스패치 시 게이트웨이에 의해서만 복호화됩니다. 새 값을 보내 교체한 다음, 프로브하여 작동하는지 확인하세요.