workload의 code trust, network access, credential, lifetime, filesystem, state, resource bound를 기준으로 agent compute를 선택하세요. 범위가 제한된 API call에는 sandbox가 필요하지 않습니다. 신뢰할 수 없는 생성 코드는 일반 application process나 container configuration이 제공하지 못할 수 있는 isolation이 필요합니다.
escalation ladder는 단순한 database read에 filesystem과 shell이 주어지는 것을 막고, 위험한 코드는 수명이 긴 application credential에서 분리합니다.
task를 만족하는 가장 낮은 tier를 사용하세요
flowchart TD
A[Scoped API call] -->|needs application logic| B[In-process function]
B -->|needs async or longer work| C[Background job]
C -->|needs package or process isolation| D[Isolated process or container]
D -->|runs untrusted code| E[Hardened sandbox]
E -->|needs full machine control or long-lived isolation| F[Dedicated VM]
escalation은 capability와 운영 작업을 늘립니다. 자동으로 안전해지는 것은 아닙니다. network access가 제한되지 않고 production credential을 가진 sandbox는 범위가 좁은 server-side API보다 더 위험할 수 있습니다.
Tier 0: scoped API call
task를 database query, object read, email send, deployment request로 이미 표현할 수 있다면 typed backend operation을 사용하세요. agent는 범위가 제한된 argument를 제공하고, server가 credential, authorization, validation, audit를 소유합니다.
이 tier에는 일반 code execution이 없습니다. 보통의 product action에 적합한 기본값이며 semantic tool design과도 일치합니다.
Tier 1: in-process function
request lifecycle 안에서 끝나는 짧고 신뢰할 수 있는 transformation과 orchestration에는 application code를 사용하세요. 사용 가능한 module을 제한하고 provider secret은 model-visible input 바깥에 두세요.
이 tier에서 생성 코드를 eval, shell, dynamic import로 실행하지 마세요. timeout은 request의 대기를 끝내지만 모든 child process나 외부 effect를 확실히 중단하지는 못합니다.
Tier 2: background job
request timeout보다 오래 걸릴 수 있거나, scheduled retry가 필요하거나, rate를 독립적으로 제어해야 하는 작업은 queue로 옮기세요. queue가 여러 번 전달할 수 있으므로 operation record를 저장하고 job을 idempotent하게 만드세요.
job worker는 durable scheduling이지 security boundary가 아닙니다. 대개 service와 비슷한 접근 권한으로 신뢰할 수 있는 application code를 실행합니다. durable execution 가이드는 checkpoint와 unknown outcome을 다룹니다.
Tier 3: isolated process 또는 container
package, filesystem, 다른 CPU 및 memory limit가 필요한 신뢰할 수 있는 코드는 별도의 process나 container에서 실행하세요. privilege를 제거하고, 가능하다면 read-only base filesystem을 사용하고, 필요한 file만 mount하고, outbound network access를 제한하세요.
platform이 더 강한 경계를 추가하지 않으면 container는 host kernel을 공유합니다. workload packaging과 process isolation 수단으로 취급한 뒤 runtime configuration이 threat model에 맞는지 평가하세요.
Tier 4: hardened sandbox
신뢰할 수 없거나 model이 생성한 코드에는 sandbox를 사용하세요. 각 실행에 ephemeral filesystem, 엄격한 CPU, memory, process, wall-clock limit, outbound network allowlist를 적용하세요. task 범위의 credential만 주입하고 실행 후에는 revoke한 뒤 environment를 폐기합니다.
cleanup 전에 승인된 output을 object storage에 저장하세요. artifact를 scan하고 크기가 제한되지 않은 stdout이나 binary content를 model에 반환하지 마세요. sandboxing 가이드는 escape path와 test case를 다룹니다.
Tier 5: dedicated VM
자체 kernel boundary, privileged system behavior, 특수한 dependency, 장시간 유지되는 desktop, customer별 isolation이 필요한 task에는 dedicated virtual machine을 사용하세요. image를 harden하고, metadata-service access를 통제하고, patch를 적용하고, teardown을 정의하세요.
agent가 한 번 사용했다는 이유만으로 VM을 영구 유지해서는 안 됩니다. 장시간 유지되는 machine에는 credential, file, package, network trust가 쌓입니다. persistence가 필요하지 않다면 알려진 image에서 다시 만드세요.
tier를 선택하기 전에 여섯 가지 요구 사항을 분류하세요
- Code trust: 모든 instruction과 dependency를 팀에서 통제하는가, 아니면 user나 model이 code를 제공할 수 있는가?
- Authority: workload가 어떤 credential과 resource에 접근해야 하는가?
- Network: network가 필요 없는가, 고정 allowlist나 public web 또는 private service가 필요한가?
- Lifetime and state: 몇 초 안에 끝나는가, 몇 시간 기다리는가, persistent machine이 필요한가?
- Runtime surface: shell, browser, package install, writable filesystem, kernel feature, GPU가 필요한가?
- Resource bounds: runaway work를 막을 CPU, memory, process, output, spend limit는 얼마인가?
Cloudflare의 Project Think는 agent workload를 위한 비슷한 tier 설계를 설명합니다. 정확한 product mapping은 provider마다 다르지만, 요구 사항이 필요로 할 때만 범위가 좁은 operation에서 isolated compute로 올라간다는 개념은 어디서나 적용됩니다.
label이 아니라 boundary를 테스트하세요
filesystem mount, network egress, secret visibility, process limit, termination, artifact export, cleanup을 검증하세요. isolated environment에서 허용되지 않은 host와 다른 tenant의 resource에 접근해 보세요. 어떤 image, policy, identity, operation이 실행을 만들었는지 platform이 기록하는지 확인합니다.
아래 프롬프트는 인프라를 제안하기 전에 현재 workload를 분류합니다. shell 자체가 필요 없는 task를 찾아내는 경우가 많은데, container 이름을 sandbox로 바꾸는 것보다 훨씬 명확한 보안 개선입니다.