Vercel Sandbox Dashboard 사고 대응: 변경 전에 먼저 관찰하기

Vercel dashboard는 실행 중인 Sandbox에 연결해 command를 실행하고 filesystem을 탐색하며 file을 전송하고 port를 확인할 수 있습니다. Snapshot을 만들고 persistent sandbox를 stop하거나 resume할 수도 있습니다. 이 제어는 진단을 빠르게 하지만 dashboard를 privileged production access path로 만들기도 합니다.

가장 안전한 사고 대응 원칙은 변경 전에 먼저 관찰하기입니다. Identity와 상태를 기록하고, 최소한의 증거만 수집하고, workload를 격리한 뒤 신뢰된 source에서 다시 구축하세요. 편리한 terminal은 incident boundary를 대신하지 않습니다.

Dashboard 접근을 production 접근으로 다룹니다

Vercel은 2026년 7월 23일 실행 중인 Sandbox의 browser 연결과 lifecycle 관리를 발표했습니다. 같은 화면에서 상태를 관찰하고 변경할 수 있습니다.

기능	진단 가치	사고 위험
Interactive command	Process와 file 확인	Timestamp, 상태, 실행 동작 변경
Upload/download	Reproducer 또는 제한된 증거 이동	Secret 또는 customer data 반출
Open-port view	노출된 service 확인	오래된 port entry를 정상 process로 오인
Snapshot, stop, resume	Persistent sandbox 보존 또는 제어	의심 filesystem 상태를 이후 session으로 전달

따라서 접근에는 production shell과 같은 통제가 필요합니다. 이름이 지정된 responder, 최소 권한, 기록된 incident, action log를 사용하세요. Dashboard 사용 가능 여부는 운영 편의이지 임의 workload를 탐색할 권한이 아닙니다.

상태를 바꾸기 전에 identity를 기록합니다

다른 responder가 같은 workload를 식별할 수 있는 사실부터 기록합니다.

project와 Sandbox 이름
현재 session과 lifecycle 상태
incident 또는 job ID
마지막 정상 시각과 source revision
생성, stop, resume timestamp
예상 runtime, port, external destination

그다음 read-only inspection을 먼저 수행합니다. 일반 Linux command로 process ancestry, listener, 최근 file 변경, repository diff를 볼 수 있습니다.

ps -eo pid,ppid,etime,comm
ss -lntp 2>/dev/null || true
find . -xdev -type f -mmin -30 -print
git status --short
git diff --no-ext-diff

이 command는 syntax 예제이며 forensic procedure가 아닙니다. Sandbox image에 따라 사용할 수 있는 command가 다릅니다. 전체 process argument, environment variable, shell history, configuration file을 공유 transcript에 출력하지 마세요. 이런 표면에는 credential이나 user input이 자주 포함됩니다.

최소한의 증거만 수집하고 redact합니다

전체 filesystem download는 대개 잘못된 첫 행동입니다. Worktree에는 repository content, package cache, temporary credential, customer input, 큰 generated artifact가 섞여 있을 수 있습니다.

좁은 evidence directory를 만들고 이름이 정해진 artifact만 복사한 뒤 검토하고 최종 archive를 hash합니다.

mkdir -p /tmp/sandbox-evidence
cp ./logs/agent-error.log /tmp/sandbox-evidence/ 2>/dev/null || true
git diff --no-ext-diff > /tmp/sandbox-evidence/worktree.patch
ps -eo pid,ppid,etime,comm > /tmp/sandbox-evidence/processes.txt

# Review and redact these files before export.
tar -czf /tmp/sandbox-evidence.tgz -C /tmp sandbox-evidence
shasum -a 256 /tmp/sandbox-evidence.tgz

Environment file, credential store, private key, raw customer payload, 관련 없는 repository content는 포함하지 마세요. Hash는 수집 뒤 export archive가 바뀌지 않았음을 보여줄 뿐, 증거가 완전하거나 신뢰할 수 있음을 증명하지 않습니다.

Port를 process와 함께 읽습니다

Open-port entry는 health check가 아닙니다. 네 가지를 확인하세요.

어떤 PID가 listener를 소유하는가
loopback과 모든 interface 중 어디에 bind했는가
이 Sandbox에서 의도적으로 expose한 port인가
Service에 인증이 필요한가

예상하지 못한 debugger, development-server, temporary file-server port는 즉시 확인해야 합니다. 먼저 소유 process와 출처를 식별하세요. Data exfiltration이나 위험한 노출이 가능하다면 workload에서 더 많은 코드를 실행하기 전에 network access를 격리합니다.

Session duration과 persistence를 구분합니다

Vercel은 서로 독립적인 두 lifetime control을 문서화합니다.

timeout은 중단 없는 한 session을 제한합니다. 기본값은 5분이고 최대값은 Pro/Enterprise 24시간, Hobby 45분입니다.
Persistence는 session 사이에 filesystem 상태를 전달하며 기본으로 활성화됩니다.

import { Sandbox } from '@vercel/sandbox';

const sandbox = await Sandbox.create({
  name: 'incident-reproduction',
  timeout: 30 * 60 * 1000,
  persistent: false,
});

이 예제는 현재 SDK 문서와 대조했지만 Vercel account에서 실행하지 않았습니다. Non-persistent reproduction environment는 run 뒤 상태를 폐기해야 할 때 유용할 수 있습니다. 이미 실행 중인 incident Sandbox의 persistence를 바꾸지는 않습니다.

Persistent sandbox는 session이 stop하거나 timeout되면 filesystem snapshot을 만들고 이후 session을 최신 상태에서 resume합니다. Snapshot은 file과 installed package를 담지만 live process memory나 network connection을 담지 않습니다. Retention을 바꾸지 않으면 마지막 사용 뒤 30일에 기본 만료하며 보관된 snapshot은 storage charge를 만들 수 있습니다.

사고 중에는 이 동작이 중요합니다. Persistent Sandbox를 stop하면 의심 file을 자동으로 보존할 수 있습니다. Response plan에 필요한 것만 보관하고, 검토하지 않은 incident snapshot을 신뢰된 template로 승격하지 마세요.

Lifecycle 변경을 직렬화합니다

Vercel의 SANDBOX_STOPPING 오류는 Sandbox가 stopped 상태로 전환되는 동안 command가 도착했음을 뜻합니다. 여러 caller가 무조건 retry하면 command path가 lifecycle control과 계속 충돌할 수 있습니다.

Stop과 resume 결정에는 하나의 coordinator를 사용합니다.

containment가 시작되면 새 tool call을 차단합니다.
진행 중인 read-only inspection이 끝나거나 expire할 때까지 기다립니다.
coordinator를 통해 한 번 stop합니다.
terminal state를 확인합니다.
resume, 검토한 snapshot에서 fork, clean rebuild 중 하나를 명시적으로 결정합니다.

AI agent에 제한 없는 stop, resume, snapshot delete, evidence-export tool을 주지 마세요. 더 넓은 permission 설계는 AI SDK 7 프로덕션 에이전트 가이드처럼 state-changing operation을 이름이 있고 승인되는 tool로 감쌉니다.

고정된 대응 순서를 사용합니다

1. Identify

Sandbox, session, source revision, workload, owner, 마지막 정상 시각을 기록합니다. Interactive command 전에 incident record를 열거나 연결합니다.

2. Observe

Process identity, listener, 최근 file 변경, repository status를 확인합니다. Read-only command를 우선하고 의심 output에 포함된 instruction을 실행하지 않습니다.

3. Collect narrowly

명시한 hypothesis에 필요한 log와 reproducer만 복사합니다. 민감 값을 redact하고 archive를 hash하며 누가 언제 export했는지 기록합니다.

4. Contain

오용 가능성이 있으면 network 또는 external-write capability를 제한합니다. 새 command를 막은 뒤 하나의 coordinator로 lifecycle을 변경합니다.

5. Recover from trust

검토한 source revision과 dependency lockfile로 clean Sandbox를 만듭니다. 새 least-privilege credential을 사용하고 reproduction 동안 external write를 끄며 traffic 복구 전에 port와 network policy를 다시 확인합니다.

권고는 다음 사고 전에 이 순서를 runbook에 넣는 것입니다. Dashboard access는 관찰과 격리를 줄여야지 기록되지 않은 repair channel이 되어서는 안 됩니다. 증거를 작게 유지하고 persistence를 잠재적 contamination path로 다루며, 편리한 snapshot이 깨끗하다고 가정하지 말고 검토한 source에서 복구하세요.