격리된 샌드박스에서의 MCP 서버: 파일시스템, 시크릿, 네트워크 트레이드오프

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 서버도 여전히 제어가 필요할 수 있습니다. 읽기 전용 공개 문서 검색 서버는 요청당 microVM이 필요하지 않을 수 있지만, 허용 목록에 포함된 네트워크 경로, 로그, 속도 제한은 여전히 있어야 합니다. 격리는 "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 서버가 샌드박스에서 실행되어야 하나요?

아니요. 코드를 실행하거나, 파일을 읽거나 쓰거나, 시크릿을 사용하거나, 비공개 서비스를 호출하거나, 브라우저를 실행하거나, 패키지를 설치하거나, 외부 상태를 변경하는 서버를 우선시하세요. 위험도가 낮은 읽기 전용 서버는 여전히 인증, 로깅, 네트워크 제어가 필요할 수 있지만, 요청당 전용 샌드박스가 필요하지 않을 수 있습니다.

stdio가 MCP 서버에 HTTP보다 더 안전한가요?

자동으로 그렇지는 않습니다. Stdio는 로컬 서버에 단순할 수 있지만, 서버가 로컬 파일시스템, 환경, 네트워크 접근을 상속할 수 있습니다. HTTP 기반 서버는 더 강력한 인증 및 노출 제어가 필요합니다. 더 안전한 선택은 프로세스가 실행되는 위치와 어떤 런타임 권한을 받는지에 따라 달라집니다.

MCP 루트가 파일시스템 샌드박싱을 대체할 수 있나요?

아니요. 루트는 클라이언트와 서버 간에 의도된 작업 공간 위치를 전달하는 데 도움이 되지만, 완전한 런타임 경계는 아닙니다. 경로 검증 및 샌드박스 수준 파일시스템 제어를 사용하여 서버를 의도된 작업 공간 내에 유지하세요.

샌드박스 처리된 MCP 도구의 시크릿은 어디에 저장되어야 하나요?

도구가 필요로 하는 자격 증명만 주입하세요. 가능하면 수명이 짧은 환경 변수 또는 범위가 지정된 런타임 시크릿으로 주입하세요. 광범위한 개발자 자격 증명 폴더를 마운트하거나 프롬프트를 통해 시크릿을 전달하지 마세요. 로그와 도구 응답에서 편집하세요.

MCP 도구는 언제 인간 승인이 필요해야 하나요?

프로덕션 배포, 고객 대상 메시지, 결제 또는 접근 제어 변경, 대규모 데이터 내보내기, 인프라 쓰기, 그리고 일반 작업 공간 정책 외부의 모든 명령 또는 네트워크 작업에 대해 승인을 요구하세요.

추천 문서

• Novita Sandbox와 mcp-use 라이브러리로 원격 코드 실행 MCP 서버 구축하기
• Novita의 Agent Sandbox로 코딩 에이전트 구축하기
• 에이전트 샌드박스가 안전하고 확장 가능한 AI 혁신을 지원하는 방법