MCP 서버는 범위가 제한된 파일 시스템 마운트, 최소 권한 비밀값, 명시적인 네트워크 정책, 에이전트별 작업 공간 경계 및 로그를 통해 실행되어야 합니다. 그래야 도구 액세스가 에이전트의 신뢰 경계를 조용히 확장하지 않습니다. MCP 서버가 파일을 읽거나, 하위 프로세스를 생성하거나, 패키지를 설치하거나, 내부 API를 호출하거나, 장기 실행 에이전트 세션의 상태를 유지할 수 있는 경우 샌드박스가 유용합니다. 어려운 점은 MCP에 격리가 필요하다는 결정을 내리는 것이 아니라, 각 도구에 어떤 경계를 설정하고, 어떤 데이터가 해당 경계를 넘으며, 어떤 작업에 여전히 인간 검토가 필요한지 결정하는 것입니다.
MCP가 에이전트 신뢰 경계를 변경하는 이유
Model Context Protocol은 AI 애플리케이션이 모델을 도구, 프롬프트 및 리소스에 연결하는 일반적인 방법을 제공합니다. 이렇게 하면 통합이 더 깔끔해지지만, 각 MCP 서버가 정책 경계가 됩니다. 서버가 read_file, run_command, query_database 또는 deploy_preview를 노출하는 경우, 이제 에이전트는 모델 컨텍스트 창을 넘어서는 작업을 요청할 수 있습니다.
이러한 도구를 광범위한 워크플로에 연결하는 경우, AI로 작업을 자동화하는 방법부터 시작한 다음, 외부 루프에 코딩 에이전트가 필요한지 아니면 더 가벼운 인터프리터가 필요한지 결정하세요.
MCP 사양은 샌드박스 설계에 중요한 여러 보안 기대치를 설명합니다. 사용자는 노출된 도구를 이해하고 동의해야 하며, 호스트는 도구 호출 전에 동의를 요구해야 하며, 도구 설명은 검증되지 않은 경우 신뢰할 수 없으며, 민감한 데이터는 적절한 접근 제어로 보호되어야 합니다. 이러한 규칙은 애플리케이션 수준 제어입니다. 샌드박스는 그 아래에 런타임 제어를 추가하여, 에이전트, 도구 설명 또는 프롬프트 체인이 잘못된 요청을 하더라도 MCP 서버 프로세스가 접촉할 수 있는 대상을 제한합니다.
신뢰 경계를 세 가지 계층으로 생각해 보세요:
| 계층 | 제어 대상 | 일반적인 실패 모드 |
|---|---|---|
| 호스트 또는 MCP 클라이언트 | 연결된 서버와 승인된 도구 호출 | 광범위한 도구가 한 번 승인된 후 더 민감한 맥락에서 재사용됨 |
| MCP 서버 | 도구 구현, 인증, 입력 검증, 리소스 액세스 | 도구가 예상보다 더 많은 파일을 읽거나, 더 많은 데이터를 보내거나, 더 많은 명령을 실행함 |
| 샌드박스 런타임 | 파일 시스템, 프로세스, 네트워크, 비밀값, 수명 주기 및 로그 | 서버 프로세스가 프로덕션 리소스에 너무 가깝게 실행되어 호스트 액세스를 상속받음 |
목표는 모든 MCP 서버를 동일한 방식으로 신뢰할 수 없게 만드는 것이 아닙니다. 캘린더 조회 도구, 로컬 코드 실행 도구 및 배포 도구는 서로 다른 위험 프로필을 가집니다. 목표는 각 서버의 런타임 액세스 범위가 수행하는 작업보다 더 넓지 않도록 유지하는 것입니다.
먼저 격리할 대상
외부 상태를 변경하거나, 민감한 데이터를 다루거나, 코드를 실행할 수 있는 MCP 서버부터 시작하세요. 이러한 서버는 일반적인 프롬프트 실수를 더 광범위한 사고로 전환할 가능성이 가장 높습니다.
샌드박싱의 우선 순위가 높은 후보는 다음과 같습니다:
- 셸 명령, Python, Node.js, 컴파일러, 테스트 또는 노트북을 실행하는 코드 실행 도구.
- 저장소, 사용자 업로드, 마운트된 데이터셋, 자격 증명 파일 또는 생성된 아티팩트를 읽거나 쓰는 파이시스템 도구.
- 쿠키, 세션 상태, 다운로드된 파일 또는 스크린샷트를 보유한 브라우저 및 컴퓨터 사용 도구.
- 고객 기록, 분석 내보내기, 티켓 또는 개인 문서를 질의할 수 있는 데이터 커넥터.
- 브랜드 생성, 프리�우 게시, 컨피그 로테이션 또는 인프라 수정이 가능한 배포 및 CI 도구.
- 레지스트리, Git 리모트 또는 임의 URL에서 코드를 페치할 수 있는 패키지 및 종속성 도구.
위험도가 낮은 MCP 서버라도 여전히 제어가 필요할 수 있습니다. 읽기 전용 공개 문서 검색 서버는 요청당 마이크로VM이 필요하지 않을 수 있지만, 허용된 네트워크 경로, 로그 및 속도 제한이 있어야 합니다. 격리는 "MCP 서버"라벨이 아라 "도구의 실용적 파괴 반경"을 따라야 합니다.
MCP 서버가 실행되야 할 위치
세 가지 일반적인 배치 패턴이 있습니다. 어떤 것이 보편적으로 올바른 것은 아닙다.
| 배치 | 사용 시점 | 주의할점 |
|---|---|---|
| 에잰트 작얌 공간과 동일한 샌드박스 | 서버가 에잰트의 현재 파일, � 명령, 브라우저 세션 또는 생된 인공물과 밀접하게 결합됨 | 서버와 에잰트가 상태를 공유하므로, 마운트와 비밀이 범위 지정되지 않으면 손상된 도구가 동일한 작습니다 |
| MCP 서버 또는 도구 그룹당 별도 샌드박스 | 도구가 에잰트 작업 공간에서 더 강한 격리가 필요하거나, 다른 자격 증을 사용하거나, 더 높은 위험 실행을 수행함 | 교차 샌드박스 파일 전송 및 지연 시간이 제품 설계의 일부가 됨 |
| 샌드박스 외부, 범위가 제한된 API 뒤 | 도구가 자체 인증, 허가, 로깅 및 요율 제한을 갖춘 안정적인 프로덕션 서비스임 | API는 좁아야 합니다. 샌드박스 외부에 있다고 해서 광범위한 관리자 내부 표면을 노출하지 마십시오. |
동일한 샌드박스에서 서버를 실행하는 것은 코딍 에잰트에 편리합니다. MCP 서버는 저장소를 보거, 테스를 실행하거, 인공물을 조사거, 환겨을 이하자 않고 결를 반환할 수 잇니다. 이 방버은 작업 공간 자체가 이마 폐기 가능하며 에잰트가 사해야 하는 일만 포할 때 가장 잘 작동합나다.
별도의 샌드박스는 구가 다른 정책을 가야 할 때 더 좋습나다. 예를 들어, 패키지 분석 MCP 서버는 공용 레지스트리에 대한 인터넷 액세스가 필요할 수 있지만, 메인 코딩 에이전트는 그래서는 안 됩니다. 브라우저 MCP 서버는 테스트 계정을 위한 쿠키가 필요할 수 있지만, 코드 실행 서버는 그 쿠키를 절대 볼 수 없습니다.
외부 서비스는 실제로 "런타임 구"가 아닌 도구에 적합입니다. 청구 조회, 피처 플래그 읽기 또는 이슈 트래커 검색은 에잰트의 컴퓨팅 환겨에서 자유 형식 서버보다는 서버 측 권한 부여가 있는 일반 백엔드 API로 더 안전할 수 있습니다.
파시스템 마운트와 에잰트별 작얌 공간
파일 시스템 액세스는 MCP의 편리함이 종종 의도치 않은 권한 상승으로 이어지는 부분입니다. ./src를 읽어야 하는 서버가 개발자의 홈 디렉토리를 상속받아서는 안 됩니다. 생성된 차트를 쓰는 도구가 배포 구성을 덮어쓸 수 없어야 합니다.
명시적인 작업 공간 경계를 사용하십시오:
- 각 에이전트 실행에 자체 작업 디렉토리를 할당하십시오.
- 작업에 필요한 저장소, 업로드 폴더, 데이터셋 또는 아티팩트 디렉토리만 마운트하십시오.
- 소스 자료는 읽기 전용 마운트를, 출력물만 읽기-쓰기 마운트를 선호하십시오.
- 생성된 출력물과 신뢰되는 소스 파일을 분리하십시오.
.ssh, 클라우드 구성 디렉토리, 브라우저 프로필 또는 로컬 패키지 관리자 인증 파일과 같은 자격 증명 폴더를 마운트하지 마십시오.- 관련 없는 사용자, 테넌트 또는 작업 간에 작업 공간을 재설정하거나 스냅샷을 사용하십시오.
MCP 루트는 클라이언트가 서버가 작동해야 할 파일 시스템 위치를 전달하는 데 도움이 될 수 있지만, 루트만으로는 완전한 보안 경계가 아닙니다. 이를 클라이언트와 서버 간의 조정 메커니즘으로 취급하십시오. 런타임에는 여전히 파일 시스템 수준의 제한이 필요하며, 서버는 심볼릭 링크, 상대 경로 또는 아카이브 추출 트릭을 통해 요청이 의도된 작업 공간을 벗어나지 못하도록 경로를 검증해야 합니다.
실용적인 패턴은 역할별로 작업 영역 액세스를 분할하는 것입니다:
| 디렉토리 | 액세스 | 목적 |
|---|---|---|
/workspace/input |
읽기 전용 | 사용자 업로드, 시드 저장소, 벤치마크 픽스처 또는 테스트 데이터 |
/workspace/output |
읽기-쓰기 | 생성된 파일, 보고서, 패치, 차트 또는 스크린샷 |
/workspace/tmp |
읽기-쓰기, 일회용 | 빌드 캐시, 패키지 설치 캐시, 임시 파일 |
/workspace/secrets |
가능하면 파일 마운트 피함 | 불가피한 경우, 엄격한 수명과 편집 기능이 있는 하나의 범위가 지정된 비밀 파일 마운트 |
정확한 경로는 중요하지 않습니다. 원칙이 중요합니다.
비밀값과 환경 변수
비밀값은 일반적으로 환경 변수, 로그, 스택 추적, 패키지 스크립트, 셸 기록, 브라우저 세션 및 도구 응답을 통해 이동하기 때문에 파일보다 유출되기 쉽습니다. MCP 서버에 자격 증명이 필요한 경우, 도구 작업을 완료할 수 있는 가장 좁은 범위의 자격 증명을 제공하십시오.
별도의 MCP 서버에 대해 별도의 자격 증명을 사용하십시오. GitHub 이슈 검색 서버는 읽기 전용 이슈 액세스만 필요할 수 있습니다. PR 작성 서버는 브랜치 쓰기 액세스가 필요할 수 있습니다. 배포 서버는 권한 모델이 실제로 요구하지 않는 한 두 토큰을 공유해서는 안 됩니다.
MCP 서버를 위한 좋은 비밀값 처리는 다음과 같습니다:
- 프롬프트가 아닌 샌드박스 또는 프로세스 시작 시 비밀값을 주입하십시오.
- 제공자가 지원하는 경우 수명이 짧거나 철회 가능한 토큰을 사용하십시오.
- 도구, 테넌트, 환경 및 작업별로 자격 증명 범위를 지정하십시오.
- stdout, stderr, 구조화된 도구 응답 및 추적 로그에서 비밀값을 편집하십시오.
- 원시 환경 변수를 모델에 반환하지 마십시오.
- 에이전트가 로드할 비밀값을 결정하도록 허용하지 마십시오.
- 위험도가 높은 서버에서 사용되는 자격 증명을 정기적으로 교체하고 의심되는 프롬프트 인젝션 노출 후에도 교체하십시오.
일반적인 안티 패턴을 피하십시오: 모든 목적의 환경 파일 하나를 모든 에이전트 세션에 마운트하는 것입니다. 이렇게 하면 로컬 개발은 더 쉬워지고 프로덕션 검토는 더 어려워집니다. 도구에 비밀값이 필요하지 않다면, 그 비밀값을 읽을 수 없어야 합니다.
네트워크 이그레스 및 전송 선택
MCP는 로컬 및 원격 전송 패턴을 지원합니다. 사양은 로컬 프로세스 통신을 위한 stdio와 서버-클라이언트 HTTP 통신을 위한 Streamable HTTP를 설명합니다. 기존 SSE 기반 설계는 여전히 생태계에 나타나지만, 새로운 통합은 특정 전송에 의존하기 전에 현재 MCP 문서와 선택한 SDK를 확인해야 합니다.
전송 선택과 샌드박스 네트워크 정책은 다른 문제를 해결합니다:
| 질문 | 전송이 해결하는 것 | 네트워크 정책이 해결하는 것 |
|---|---|---|
| MCP 클라이언트가 서버와 어떻게 통신합니까? | stdio, HTTP 기반 전송 또는 기타 지원 패턴 | 해당 없음 |
| 서버가 호출할 수 있는 외부 호스트는 무엇입니까? | 그 자체로는 충분하지 않음 | 허용 목록, 거부 목록, 프록시, DNS 정책 또는 이그레스 없음 |
| 서버가 패키지나 웹 페이지를 가져올 수 있습니까? | 그 자체로는 충분하지 않음 | 레지스트리 허용 목록, URL 허용 목록, 캐싱 및 로깅 |
| 다른 프로세스가 서버에 도달할 수 있습니까? | 바인딩 및 인증 세부 정보 | 인바운드 방화벽 및 샌드박스 네트워크 경계 |
로컬 stdio 서버의 경우, 위험은 종종 상속된 호스트 액세스입니다. 서버는 호스트 애플리케이션의 자식 프로세스로 실행되어 로컬 파일, 환경 변수 및 네트워크 경로를 볼 수 있습니다. 해당 서버가 코드를 실행하거나 민감한 파일을 읽는 경우, 샌드박스 처리된 프로세스로 이동하거나 호스트-워커 쌍 전체를 일회용 작업 공간 내에서 실행하십시오.
HTTP 기반 MCP 서버의 경우, 위험은 인증, 네트워크 노출 및 교차 테넌트 분리 쪽으로 이됩됩니다. 서버 측 권한 부여, TLS, 관런 경오 체크, 및 클라언트별 자격 증을 사하십시오. 명확한 정책 없이 광범위한 내부 네트워크에서 원격 MCP 서버를 노출하지 마십시오. 누가 어떤 도구를 호출할 수 있는지 명확히 하십시오.
네트워크 이그레스의 경우, 기본 거부가 기본 허용보다 추론하기 쉽습니다. 도구에 패키지 설치가 필요한 경우 패키지 레지스트리 또는 풀스루 캐시를 허용하십시오. 웹 연구가 필요한 경우 요청된 도메인을 기록하고 내부 메타데이터 엔드포인트를 차단하는 프록시를 통해 라우팅하십시오. 내부 API가 필요한 경우 전체 사설 네트워크 대신 좁은 API를 노출하십시오.
패키지 설치, 하위 프로세스 및 장기 실행 상태
많은 유용한 MCP 도구에는 하위 프로세스가 필요합니다. 코딩 에이전트는 테스트를 실행합니다. 데이터 에이전트는 라이브러리를 설치합니다. 브라우저 에이전트는 브라우저를 시작합니다. 빌드 에이전트는 컴파일러를 호출합니다. 하위 프로세스 지원 자체는 문제가 아닙니다. 보이지 않는 하위 프로세스 지원이 문제입니다.
패키지 설치 또는 셸 실행을 허용하기 전에 다음을 정의하십시오:
- 어떤 명령이 허용, 거부 또는 승인 게이트인지.
- 패키지 관리자가 공용 인터넷에 도달할 수 있는지.
- 종속성 버전이 고정되거나 잠금 파일 기반이어야 하는지.
- 빌드 캐시와 설치된 패키지가 저장되는 위치.
- 백그라운드 프로세스가 실행될 수 있는 시간.
- 정리 후 어떤 출력 파일이 유지되는지.
- 에이전트가 네트워크 리스너를 시작할 수 있는지.
장기 실행 MCP 서버는 두 번째 문제를 발생시킵니다: 상태 드리프트입니다. 몇 시간 동안 지속되는 서버는 파일, 자격 증명, 브라우저 쿠키, 셸 기록, 종속성 변경 및 백그라운드 작업을 축적할 수 있습니다. 이 상태는 다단계 워크플로에 유용할 수 있지만, 올바른 에이전트, 사용자 및 작업에 속해야 합니다.
수명 주기 제어를 사용하십시오:
| 제어 | 왜 중한가 |
|---|---|
| 에이언트별 샌드박스 ID | 한 에이언트의 도구 상태가 다 에짘트의 문맥이 되는 것 방지 |
| 유휴 시아웃 | 버려진 도구 세션 정리 |
| 일시 중지 및 재개 정책 | 필요 없는 컴퓨팅 리소스를 활성 상태로 유지하지 않고 장기 작업 지원 |
| 스냅샷 또는 템플릿 정책 | 알려진 기준선에서 반복 가능한 환경 시작 |
| 명시적 해체 | 작업 후 파일 제거, 프로세스 종료 및 자격 증명 해제 |
도구가 내구성 있는 아티팩트를 생성하는 경우, 샌드박스 밖으로 해당 아티팩트만 복사하십시오. 제품이 전체 세션 재생을 명시적으로 요구하지 않는 한 전체 작업 공간을 보존하지 마십시오.
로깅, 정리 및 인간 검토
MCP 도구 로그는 보안 및 디버깅 질문에 답해야 하며, 새로운 비밀 저장소가 되어서는 안 됩니다. 유용한 로그에는 도구 이름, 호출자 ID, 샌드박스 ID, 작업 공간 ID, 명령 범주, 읽거나 쓴 파일, 접촉한 외부 도메인, 설치된 패키지 이름, 종료 상태 및 아티팩트 경로가 포함됩니다.
기본적으로 원시 프롬프트, 원시 고객 데이터, 토큰, 전체 파일 내용 또는 완전한 명령 출력을 기록하지 마십시오. 민감한 추적은 더 엄격한 액세스 제어 및 보존 정책 뒤에 두십시오.
일부 MCP 작업은 샌드박스 내부에서도 인간 검토를 받아야 합니다:
- 프로덕션 게시 또는 배포.
- 이메일, 채팅, 티켓, 청구서 또는 고객 대상 메시지 전송.
- 액세스 제어, 청구, 사용자 데이터 또는 인프라 구성 수정.
- 대용량 파일, 개인 저장소, 데이터베이스 내보내기 또는 자격 증명과 유사한 문자열 유출.
- 작업 공간 정책 외부의 명령 실행.
- 쓰기 권한이 있는 내부 API 호출.
샌드박스는 폭발 반경을 줄여야 합니다. 민감한 비즈니스 작업에서 검토를 제거하는 이유가 되어서는 안 됩니다.
Novita Agent Sandbox 작동 방식
Novita Agent Sandbox는 코드 실행, 파일, 프로세스, 브라우저 스타일 워크플로 및 장기 실행 세션을 위한 격리된 런타임이 필요한 에이전트 워크로드를 위해 설계되었습니다. 도구 서버가 개발자 노트북, 프로덕션 호스트 또는 공유 CI 시스템에 대한 직접 액세스 대신 일회용 작업 공간이 필요한 MCP 아키텍처에 적합합니다.
다음과 같은 작업이 필요한 서버의 런타임 경계로 사용하십시오:
- 생성된 코드 또는 명령 실행.
- 임시 파일 및 생성된 아티팩트 작업.
- 다단계 작업 전반에 걸쳐 에이전트별 작업 공간 상태 유지.
- 에이전트가 나중에 확인할 수 있는 백그라운드 작업 실행.
- 애플리케이션 호스트와 에이전트 실험 분리.
제품 경계를 명확히 유지하십시오: MCP 서버는 여전히 애플리케이션 코드입니다. 여전히 도구 권한, 자격 증명 범위, 네트워크 정책, 승인 흐름, 로깅 스키마 및 정리 동작을 설계합니다. 샌드박스는 이러한 결정이 시행되는 격리된 환경을 제공합니다.
제품별 설정에 대해서는 오래된 자습서의 복사본을 사용하는 대신 현재 Novita 문서를 사용하십시오. 개념적으로 형태는 다음과 같습니다:
for each agent task:
create sandbox from approved template
mount only the task workspace
inject only tool-specific secrets
start the MCP server inside the sandbox or connect to a sandbox-backed tool API
route tool calls through approval and policy checks
collect logs and approved artifacts
stop, reset, or pause the sandbox according to the task lifecycle
이렇게 하면 문서 수준의 지침이 안정적으로 유지되는 동시에 정확한 SD 호출은 최신 문서와 플폼 코드에 맡겨집니다.
구현 체크리스트
MCP 서버를 자동 또는 반자동 에이전에 연결하기 전에 이 체크리스를 사용하십시오:
| 영역 | 답변해야 할 질문 |
|---|---|
| 도구 범위 | 서버가 노출하는 도구는 무엇이며, 외부 상태를 변경하는 것은 무엇입니까? |
| 배치 | 서버가 에잰트 샌드박스, 별도의 샌드박스, 아는 샌드박스 외부 좁은 API 뒤에서 실행되어야 합니까? |
| 파일 시스템 | 어떤 디렉토리가 마운트되며, 읽기 전용인지 읽기-쓰기인지, 경로 탈출은 어떻게 차단됩니까? |
| 비밀값 | 어떤 자격 증이 주입되며, 어떻게 범위가 지정되며, 로그나 출에 어디에 나탈 수 있습니까? |
| 네트워크 | 이그레스가 기본 거부인지, 프록시 경유인지, 아는 도메인, 레지스트리 및 내부 API별로 허용 목룩입니까? |
| 하위 프세스 | 어떤 명령, 패키지 관리자, 백그라운드 잡업 및 리스너가 허용됩니까? |
| 상태 | 에이전트별 작업 공간, 스냅샷, 유휴 시간 초과, 일시 중지/재개 동작 및 정리는 어떻게 처리됩니까? |
| 로그 | 비밀값을 저장하지 않고 도구 호출, 파일 변동, 외부 도메인 및 아티팩트를 재구성할 수 있습니까? |
| 인간 검토 | 실행, 내보내기, 배포 또는 고객 대면 작업 전에 어떤 도구 호출이 승인이 필요합니까? |
| 테스트 | 프롬프트 인젝션, 심볼릭 링크/경로 탐색, 대용량 출력, 실패한 정리 및 거부된 이그레스 경로를 테스트했습니까? |
MCP는 도구 통합을 더 쉽게 만듭니다. 샌드박싱은 해당 통합이 모델의 권한을 조용히 확장하지 않도록 합니다. 올바른 설계는 대개 혼합입니다: 일부 서버는 동일한 에이전트 작업 공간에, 일부는 별도 샌드박스에, 일부는 엄격한 인증이 있는 API 뒤의 샌드박스 외부에 있습니다. 도구의 데이터, 비밀값, 하위 프로세스 및 네트워크 요구에 맞는 배치를 선탣하십시오.
FAQ
모든 MCP 서버가 샌드박스에서 실행되어야 합니까?
아니요. 코드를 실행하거나, 파일을 읽거나 쓰거나, 비밀값을 사용하거나, 비공개 서비스를 호출하거나, 브라우저를 시작하거나, 패키지를 설치하거나, 외부 상태를 변경하는 서버를 우선 순위로 삼으십시오. 위험도가 낮은 읽기 전용 서버는 여전히 인증, 로깅 및 네트워크 제어가 필요할 수 있지만, 요청당 전용 샌드박스가 필요하지 않을 수 있습니다.
MCP 서버에 대해 stdio가 HTTP보다 더 안전합니까?
자동으로 그렇지는 않습니다. Stdio는 로컬 서버에 간단할 수 있지만, 서버가 로컬 파일 시스템, 환경 및 네트워크 액세스를 상속받을 수 있습니다. HTTP 기반 서버는 더 강력한 인증 및 노출 제어가 필요합니다. 더 안전한 선택은 프로세스가 실행되는 위치와 수신하는 런타임 권한에 따라 다릅니다.
MCP 루트가 파일 시스템 샌드박싱을 대체할 수 있습니까?
아니요. 루트는 클라이언트와 서버 간에 의도된 작업 공간 위치를 전달하는 데 도움이 되지만, 완전한 런타임 경계는 아닙니다. 경로 검증 및 샌드박스 수준의 파일 시스템 제어를 사용하여 서버를 의도된 작업 공간 내에 유지하십시오.
샌드박스 처리된 MCP 도구의 비밀값은 어디에 저장해야 합니까?
도구에 필요한 자격 증명만 주입하십시오. 이상적으로는 수명이 짧은 환경 변수 또는 범위가 지정된 런타임 비밀값으로 주입하십시오. 광범위한 개발자 자격 증명 폴더를 마운트하거나 프롬프트를 통해 비밀값을 전달하지 마십시오. 로그 및 도구 응답에서 편집하십시오.
MCP 도구는 언제 인간 승인이 필요합니까?
프로덕션 배포, 고객 대상 메시지, 청구 또는 액세스 제어 변경, 대규모 데이터 내보내기, 인프라 쓰기 및 일반 작업 공간 정책을 벗어난 모든 명령 또는 네트워크 작업에 대해 승인이 필요합니다.
