MCP 서버는 범위가 지정된 파일 시스템 마운트, 최소 권한 비밀, 명시적 네트워크 정책, 에이전트별 작업 공간 경계, 그리고 로그를 사용하여 실행되어야 합니다. 그래야 도구 접근이 에이전트의 신뢰 경계를 조용히 확장하지 않습니다. 샌드박스는 MCP 서버가 파일을 읽거나, 하위 프로세스를 생성하거나, 패키지를 설치하거나, 내부 API를 호출하거나, 장기 실행 에이전트 세션의 상태를 유지할 수 있을 때 유용합니다. 어려운 점은 MCP에 격리가 필요하다는 것을 결정하는 것이 아니라, 각 도구에 어떤 경계가 속하는지, 어떤 데이터가 그 경계를 넘는지, 어떤 작업에 여전히 인간의 검토가 필요한지를 결정하는 것입니다.
MCP가 에이전트 신뢰 경계를 변경하는 이유
Model Context Protocol은 AI 애플리케이션이 모델을 도구, 프롬프트, 리소스에 연결하는 일반적인 방법을 제공합니다. 이는 통합을 더 깔끔하게 만들지만, 각 MCP 서버를 정책 경계로 만듭니다. 서버가 read_file, run_command, query_database 또는 deploy_preview를 노출하면, 에이전트는 이제 모델 컨텍스트 창을 넘어서는 작업을 요청할 수 있습니다.
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 도구에는 하위 프로세스가 필요합니다. 코딩 에이전트는 테스트를 실행합니다. 데이터 에이전트는 라이브러리를 설치합니다. 브라우저 에이전트는 브라우저를 실행합니다. 빌드 에이전트는 컴파일러를 호출합니다. 하위 프로세스 지원 자체는 문제가 아닙니다. 보이지 않는 하위 프로세스 지원이 문제입니다.
패키지 설치 또는 셸 실행을 허용하기 전에 다음을 정의하십시오:
- 허용, 거부 또는 승인 게이트가 필요한 명령.
- 패키지 관리자가 공개 인터넷에 도달할 수 있는지 여부.
- 종속성 버전을 고정하거나 lockfile 기반으로 해야 하는지 여부.
- 빌드 캐시 및 설치된 패키지가 있는 위치.
- 백그라운드 프로세스가 실행될 수 있는 시간.
- 정리 후 보존되는 출력 파일.
- 에이전트가 네트워크 리스너를 시작할 수 있는지 여부.
장기 실행 MCP 서버는 두 번째 문제인 상태 표류를 도입합니다. 몇 시간 동안 지속되는 서버는 파일, 자격 증명, 브라우저 쿠키, 셸 기록, 종속성 변경 및 백그라운드 작업을 축적할 수 있습니다. 이러한 상태는 다단계 워크플로우에 유용할 수 있지만, 올바른 에이전트, 사용자 및 작업에 속해야 합니다.
수명 주기 제어를 사용하십시오:
| 제어 | 중요한 이유 |
|---|---|
| 에이전트별 샌드박스 ID | 한 에이전트의 도구 상태가 다른 에이전트의 컨텍스트가 되는 것을 방지 |
| 유휴 시간 제한 | 중단된 도구 세션 정리 |
| 일시 중지 및 재개 정책 | 불필요한 컴퓨팅을 활성 상태로 유지하지 않고 장기 작업 지원 |
| 스냅샷 또는 템플릿 정책 | 알려진 기준선에서 반복 가능한 환경 시작 |
| 명시적 해체 | 작업 후 파일 제거, 프로세스 종료 및 자격 증명 해제 |
도구가 내구성 있는 아티팩트를 생성하는 경우, 해당 아티팩트만 샌드박스 밖으로 복사하십시오. 제품이 명시적으로 전체 세션 재생을 필요로 하지 않는 한, 전체 작업 공간을 보존하지 마십시오.
로깅, 정리 및 인간 검토
MCP 도구 로그는 새로운 비밀 저장소가 되지 않으면서 보안 및 디버깅 질문에 답해야 합니다. 유용한 로그에는 도구 이름, 호출자 ID, 샌드박스 ID, 작업 공간 ID, 명령 범주, 읽거나 쓴 파일, 접촉한 외부 도메인, 설치된 패키지 이름, 종료 상태 및 아티팩트 경로가 포함됩니다.
기본적으로 원시 프롬프트, 원시 고객 데이터, 토큰, 전체 파일 내용 또는 완전한 명령 출력을 기록하지 마십시오. 민감한 추적은 더 엄격한 접근 제어 및 보존 정책 뒤에 보관하십시오.
일부 MCP 작업은 샌드박스 내에서도 인간의 검토를 받아야 합니다:
- 프로덕션에 게시 또는 배포.
- 이메일, 채팅, 티켓, 청구서 또는 고객 대상 메시지 전송.
- 접근 제어, 청구, 사용자 데이터 또는 인프라 구성 수정.
- 대용량 파일, 비공개 리포지토리, 데이터베이스 내보내기 또는 자격 증명과 유사한 문자열 유출.
- 작업 공간 정책 외부의 명령 실행.
- 쓰기 권한이 있는 내부 API 호출.
샌드박스는 폭발 반경을 줄여야 합니다. 민감한 비즈니스 작업에서 검토를 제거하는 이유가 되어서는 안 됩니다.
Novita Agent Sandbox의 적합성
Novita Agent Sandbox는 코드 실행, 파일, 프로세스, 브라우저 스타일 워크플로우 및 장기 실행 세션을 위한 격리된 런타임이 필요한 에이전트 워크로드를 위해 설계되었습니다. 도구 서버가 개발자 노트북, 프로덕션 호스트 또는 공유 CI 머신에 대한 직접 접근 대신 일회용 작업 공간이 필요한 MCP 아키텍처에 적합합니다.
다음이 필요한 서버의 런타임 경계로 사용하십시오:
- 생성된 코드 또는 명령 실행.
- 임시 파일 및 생성된 아티팩트 작업.
- 다단계 작업 전반에 걸쳐 에이전트별 작업 공간 상태 유지.
- 에이전트가 나중에 확인할 수 있는 백그라운드 작업 실행.
- 에이전트 실험과 애플리케이션 호스트 분리.
제품 경계를 명확히 유지하십시오: MCP 서버는 여전히 애플리케이션 코드입니다. 도구 권한, 자격 증명 범위, 네트워크 정책, 승인 흐름, 로깅 스키마 및 정리 동작을 여전히 설계합니다. 샌드박스는 이러한 결정이 적용되는 격리된 환경을 제공합니다.
제품별 설정은 이전 튜토리얼에서 오래된 스니펫을 복사하는 대신 현재 Novita 문서를 사용하십시오. 개념적으로 모양은 다음과 같습니다:
각 에이전트 작업에 대해:
승인된 템플릿에서 샌드박스 생성
작업 작업 공간만 마운트
도구별 비밀만 주입
샌드박스 내에서 MCP 서버 시작 또는 샌드박스 기반 도구 API에 연결
승인 및 정책 검사를 통해 도구 호출 라우팅
로그 및 승인된 아티팩트 수집
작업 수명 주기에 따라 샌드박스 중지, 재설정 또는 일시 중지
이것은 기사 수준의 지침을 안정적으로 유지하면서 정확한 SDK 호출은 최신 문서와 플랫폼 코드에 맡깁니다.
구현 체크리스트
자율 또는 반자율 에이전트에 MCP 서버를 연결하기 전에 이 체크리스트를 사용하십시오:
| 영역 | 답변해야 할 질문 |
|---|---|
| 도구 범위 | 서버가 노출하는 도구는 무엇이며, 외부 상태를 변경하는 도구는 무엇인가요? |
| 배치 | 서버가 에이전트 샌드박스, 별도 샌드박스 또는 좁은 API 뒤의 샌드박스 외부에서 실행되어야 하나요? |
| 파일 시스템 | 어떤 디렉토리가 마운트되어 있으며, 읽기 전용인가요 읽기-쓰기인가요? 경로 탈출은 어떻게 차단되나요? |
| 비밀 | 어떤 자격 증명이 주입되며, 어떻게 범위가 지정되고, 로그나 출력에 나타날 수 있는 위치는 어디인가요? |
| 네트워크 | 이그레스가 기본 거부, 프록시 라우팅 또는 도메인, 레지스트리, 내부 API별로 허용 목록에 있나요? |
| 하위 프로세스 | 어떤 명령, 패키지 관리자, 백그라운드 작업 및 리스너가 허용되나요? |
| 상태 | 에이전트별 작업 공간, 스냅샷, 유휴 시간 제한, 일시 중지/재개 동작 및 정리는 어떻게 처리되나요? |
| 로그 | 비밀을 저장하지 않고 도구 호출, 파일 변경, 외부 도메인 및 아티팩트를 재구성할 수 있나요? |
| 인간 검토 | 실행, 내보내기, 배포 또는 고객 대상 작업 전에 어떤 도구 호출이 승인을 필요로 하나요? |
| 테스트 | 프롬프트 인젝션, 심볼릭 링크/경로 탐색, 대용량 출력, 실패한 정리 및 거부된 이그레스 경로를 테스트했나요? |
MCP는 도구 통합을 더 쉽게 만듭니다. 샌드박싱은 그 통합이 모델 권한의 조용한 확장이 되는 것을 방지합니다. 올바른 설계는 일반적으로 혼합입니다: 일부 서버는 동일한 에이전트 작업 공간에, 일부는 별도 샌드박스에, 일부는 엄격한 권한 부여가 있는 API 뒤의 샌드박스 외부에 있습니다. 도구의 데이터, 비밀, 하위 프로세스 및 네트워크 요구 사항과 일치하는 배치를 선택하십시오.
FAQ
모든 MCP 서버가 샌드박스에서 실행되어야 하나요?
아니요. 코드를 실행하거나, 파일을 읽거나 쓰거나, 비밀을 사용하거나, 개인 서비스를 호출하거나, 브라우저를 실행하거나, 패키지를 설치하거나, 외부 상태를 변경하는 서버를 우선시하십시오. 위험이 낮은 읽기 전용 서버는 여전히 인증, 로깅 및 네트워크 제어가 필요할 수 있지만, 요청당 전용 샌드박스가 필요하지 않을 수 있습니다.
MCP 서버에 대해 stdio가 HTTP보다 더 안전한가요?
자동으로 그렇지 않습니다. Stdio는 로컬 서버에 간단할 수 있지만, 서버가 로컬 파일 시스템, 환경 및 네트워크 접근을 상속할 수 있습니다. HTTP 기반 서버는 더 강력한 인증 및 노출 제어가 필요합니다. 더 안전한 선택은 프로세스가 실행되는 위치와 수신하는 런타임 권한에 따라 달라집니다.
MCP 루트가 파일 시스템 샌드박싱을 대체할 수 있나요?
아니요. 루트는 클라이언트와 서버 간에 의도된 작업 공간 위치를 전달하는 데 도움이 되지만, 완전한 런타임 경계는 아닙니다. 서버가 의도된 작업 공간 내에 유지되도록 경로 유효성 검사 및 샌드박스 수준 파일 시스템 제어를 사용하십시오.
샌드박스 MCP 도구의 비밀은 어디에 저장해야 하나요?
도구에 필요한 자격 증명만 주입하십시오. 이상적으로는 단기 환경 변수 또는 범위 지정 런타임 비밀로 주입하십시오. 광범위한 개발자 자격 증명 폴더를 마운트하거나 프롬프트를 통해 비밀을 전달하지 마십시오. 로그 및 도구 응답에서 비밀을 편집하십시오.
MCP 도구는 언제 인간의 승인이 필요해야 하나요?
프로덕션 배포, 고객 대상 메시지, 청구 또는 접근 제어 변경, 대용량 데이터 내보내기, 인프라 쓰기 및 일반 작업 공간 정책 외부의 모든 명령 또는 네트워크 작업에 대해 승인이 필요합니다.
