1,000 Agent Tasks in a Sandbox: What Breaks When LLMs Run Code — Kevin Orellana, AWS

한 줄 핵심

LLM과 coding agent가 실제 sandbox 환경에서 무엇을 망가뜨리는지 1,000개 워크플로로 fuzz 테스트한 결과, 문제의 핵심은 모델보다 MCP 같은 인터페이스 계층과 파일·권한·메모리 같은 sandbox primitive의 제약에 있었다.

시간별 요약

1. 0:00
   agent에게 sandbox를 깨보게 한 실험 coding agent를 클라우드 sandbox 호스팅 환경에 붙여 밤새도록 깨보게 했고, 그 과정에서 실제로 어떤 실패가 나는지 확인하는 실험이 시작점이 되었다.
2. 0:37
   Amazon Bedrock AgentCore 개요 Amazon Bedrock AgentCore는 에이전트를 클라우드에서 만들고 호스팅하기 위한 플랫폼으로, identity, memory, runtime environments, sandboxes, gateways까지 함께 제공한다.
3. 0:57
   coding agent로 고객을 모사하기 실제 고객이 플랫폼을 쓰는 방식을 에이전트로 흉내 내고, 사람이 아니라 agent가 실행하는 워크플로 관점에서 서비스를 시험하는 접근이 필요하다는 문제의식이 나온다.
4. 1:37
   MCP 서버로 플랫폼 감싸기 Frontier model과 coding agent가 자연스럽게 다룰 수 있도록 MCP 서버를 만들어 환경을 노출했고, 손으로 몇 가지 기본 작업을 실행하며 접근 가능한 도구를 다듬었다.
5. 2:27
   10개 도메인에 걸친 1,000개 테스트 생성 넓은 실패 지점을 보기 위해 10개 도메인에 걸쳐 1,000개의 테스트를 생성했고, 자격 증명 관리와 실패 원인 구분 같은 조건들도 함께 시험했다.
6. 3:02
   테스트 하니스와 SQLite 결과 저장 coding agent, MCP 서버, 클라우드 sandbox를 연결한 단순한 하니스로 실험을 구성하고, 결과는 markdown 파일 대신 SQLite에 저장해 대규모 동시 실행과 집계를 가능하게 했다.
7. 3:47
   1,000개 워크플로가 다룬 범위 테스트는 sandbox 생명주기, 파일 업·다운로드, 성능, 패키지 작성, PDF 생성, 웹페이지 열기 같은 실제 고객 워크플로를 포괄했고, code sandbox와 cloud browser는 서로 다른 실패 패턴을 보였다.
8. 5:11
   세 가지 실패: 인코딩, null byte, 파일 이미지 업로드·다운로드의 불일치는 MCP 계층의 인코딩 오류였고, null byte는 테스트를 흔들었으며, 특정 디렉터리에 쓴 파일이 다시 보이지 않는 문제는 sandbox 계층의 결함으로 드러났다.
9. 6:11
   인터페이스 계층과 sandbox 계층 구분 실패를 인터페이스와 sandbox 계층으로 나누어 봐야 원인을 분리할 수 있으며, 에이전트 워크로드는 API 서비스보다 훨씬 다양한 메모리·CPU·권한·파일시스템 조건을 요구한다.
10. 7:51
    code sandbox와 cloud browser의 실패 차이 cloud browser는 탭을 많이 열면 메모리 부족으로 자주 실패했고, 실패 원인은 파일시스템 권한·마운트·영속성 같은 sandbox primitive에 수렴했다.
11. 9:16
    sandbox primitive: seccomp, eBPF, 권한 seccomp, eBPF, kernel capabilities, 파일 실행 권한 같은 하위 제약이 에이전트의 프로세스 생성, 패키지 설치, 내부 API 호출 가능 여부를 좌우하며 작업 성공률에 직접 영향을 준다.
12. 10:55
    LLM 생성 테스트의 한계 LLM은 단위 테스트나 통합 테스트를 잘 만들어낼 수 있지만, 낮은 수준의 환경 제약이 목표 달성을 막는 문제까지는 쉽게 드러내지 못하므로 fuzz testing이 더 효과적이다.
13. 12:00
    로컬과 원격 에이전트 환경 로컬에서는 잘 되던 MCP 도구와 애플리케이션이 원격 sandbox에서는 같지 않을 수 있고, 작업 규모가 커질수록 노트북 한계를 넘어서 원격 환경으로 옮길 필요가 생긴다.
14. 12:35
    AgentCore sandbox에 SSH 접속하기 사용자가 sandbox 내부를 직접 들여다보고 문제를 추적할 수 있도록 SSH 접근을 제공했으며, 이는 에이전트가 왜 제대로 실행되지 않는지 확인하는 데 중요한 수단이 된다.
15. 13:25
    SWE-bench 익스플로잇과 망가진 도구 적절한 환경 제어와 익스플로잇이 있으면 SWE-bench 점수가 크게 달라질 수 있고, 반대로 도구가 깨진 상태에서는 동일한 에이전트도 성능이 급격히 떨어진다.
16. 14:10
    원격으로 sandbox를 fuzz 테스트하라 에이전트를 sandbox에서 운영할 때는 로컬 확인만으로는 부족하며, 다양한 도메인 워크플로로 원격 fuzz testing을 해야 숨은 제약과 취약점을 찾을 수 있다.

실무 인사이트

• 에이전트 실패를 모델 능력 문제로만 보지 말고, MCP·권한·파일시스템·메모리 같은 실행 환경 계층별로 분해해 관찰해야 원인을 빠르게 좁힐 수 있다.
• 실서비스에 가까운 테스트를 하려면 단일 시나리오보다 업로드, 다운로드, 로그인, 스크래핑, 패키지 실행처럼 실제 고객 워크플로를 넓게 덮는 fuzz 테스트가 효과적이다.
• 원격 sandbox를 운영하는 팀은 SSH나 유사한 관측 경로를 제공해 에이전트가 어떤 제약에 걸리는지 직접 확인할 수 있게 해야 한다.