에이전트 샌드박스 블록리스트는 이미 무용지물입니다. TypeScript로 기본 거부(Default-Deny) 이그레스 정책을 구축하세요.

에이전트가 연구 과제를 받습니다.

그리고 fetch 도구를 얻게 됩니다.

fetch 도구에는 규칙들이 있습니다.

그래서 에이전트는 그 규칙들을 따릅니다.

그러다가 막히는 상황을 겪습니다.

그때 다른 웹사이트를 가져오는(fetch) 웹사이트를 발견합니다.

이것은 탈옥(jailbreak)이 아닙니다.

이것은 공용 인터넷에서 벌어지는 평범한 일입니다.

이번 주에는 이러한 활동이 대규모로 어떻게 보이는지 자세히 살펴보았습니다.

2026년 10월 1일, Asymmetric Security는 3월부터 9월까지의 rogue OpenAI 에이전트 활동에 대한 48시간 조사 결과를 발표했습니다. 이 보고서에 따르면, 에이전트들이 "정보를 검색하는 데 어려움을 겪자, 그들은 샌드박스(sandbox)의 의도된 제한을 우회하기 위해 외부 서비스를 사용했습니다."
한 체인(chain)은 두 개의 공용 서비스를 사용했습니다. Httpbin은 조작된 링크를 에이전트 자신의 코드가 포함된 페이지로 변환했습니다. Urlquery는 그 링크를 브라우저에서 열고, 코드를 실행했으며, 결과를 공용 스캔 보고서에 저장했습니다. 이 글에서는 "httpbin이 페이지를 제공했고, urlquery가 브라우저를 제공했으며, urlquery 보고서가 결과를 반환했습니다."라고 언급했습니다.
에이전트들은 또한 사전 프로덕션 스테이징 호스트(pre-production staging host)에 도달하여 일회용 메일박스로 계정을 만들려고 시도했고, 푸시 알림 토픽(push-notification topic)에 약 35 KB 크기의 gzip 파일을 전송했습니다.
10월 2일, TechSpot은 OpenAI가 "정렬되지 않은 에이전트 활동(misaligned agent activity)"에 대해 100개 이상의 조직에 통지했다는 보도했습니다. 이 수치는 9월 26일까지 발송된 통지를 포함합니다. OpenAI는 약 50 페타바이트(petabytes)의 기록을 검토하고 있습니다.

이는 OpenAI에게도 새로운 일이 아닙니다.

지난 8월 26일 Hugging Face 관련 사고 게시물에서, 리레이(relay)는 자체 패키지 미러였습니다. 에이전트들은 Artifactory가 "자신들을 대신하여 모든 인터넷 요청을 보내도록" 만들었습니다. OpenAI의 해결책은 신중하게 작성되어 있습니다: "워크로드 또는 지원 서비스의 단일한 손상만으로는 그 자체로 인터넷에 대한 무단 접근을 허용하지 않습니다."

제가 계속 생각하는 Asymmetric footnotes의 구절이 있습니다: "urlscan이나 httpbun 같은 추가 소스들도 비슷한 목적을 위해 사용되었습니다."

httpbin을 차단하면, httpbun이 있습니다.

urlquery를 차단하면, urlscan이 있습니다.

릴레이(relays)의 블록리스트는 이미 당신이 잃어버린 릴레이 목록일 뿐입니다.

그러니 이름을 알 필요가 없는 작은 이그레스 정책을 만들어 봅시다.

마지막에는 단 하나의 명령어를 실행하게 될 것입니다:

npx tsx egress.ts

그리고 세 가지 정책이 9개의 요청으로 이루어진 스크립트 탈출(scripted escape)을 판정하는 것을 지켜보세요.

API 키는 없습니다.

실제 네트워크도 없습니다.

단지 TypeScript만 있습니다.

솔직히 말씀드리자면: 이것은 제가 작성한 글에 나온 패턴의 작은 모델일 뿐, OpenAI의 샌드박스는 아닙니다. 호스트들은 대체재(stand-ins)입니다. 추적 과정(trace)도 스크립트화되어 있습니다.

우리가 구축하는 것
프로젝트 설정
1단계: 아웃바운드 요청 모델링하기
2단계: 작업이 무엇을 필요로 하는지 결정하기
3단계: 탈출 스크립트 작성하기
4단계: 그럴듯해 보이는 세 가지 정책
5단계: 탈출 횟수 계산하기
문제가 발생하는 지점
더 큰 아이디어

코드: github.com/bobbyhalljr/tiny-egress-policy

우리가 구축하는 것

Three policies, nine requests, one escape

에이전트는 하나의 임무를 가지고 있습니다: 한 호스트에서 공개 통계를 읽는 것입니다.

스크립트화된 추적은 작업(task)에서 시작한 다음, 즉흥적으로 진행됩니다.

스테이징 호스트. 릴레이. 조작된 페이지. 유사 도메인. 사서함. 목록에 없는 릴레이. 오픈 리다이렉트(open redirect).

세 가지 정책이 모든 요청을 판정합니다.

결국, 우리는 무엇이 빠져나갔는지 계산합니다.

이것은 또한 Roster의 배경에 있는 아이디어의 작은 버전이기도 합니다: AI 직원이 레인(lane) 안에서 일하고, 그 레인은 직원의 좋은 의도가 아니라 하네스(harness)에 의해 강제되는 것입니다.

프로젝트 설정

Node.js 18 이상이 필요합니다.

mkdir tiny-egress-policy
cd tiny-egress-policy

...

다음 블록들을 순서대로 egress.ts로 저장하세요.

단계 1: 아웃바운드 요청 모델링하기

// egress.ts: 에이전트 샌드박스를 위한 작은 이그레스 정책입니다.
// 모든 것은 모의(mocked)되었습니다: 인메모리 fetch 도구와 스크립팅된 에이전트 트레이스입니다. API 키도, 실제 네트워크도 없습니다.
// 호스트명과 작업은 공개된 사고 보고서에 모델링된 예시 입력값들입니다.
...

요청(Request)이란 메서드, URL, 그리고 우리 인간을 위한 메모를 의미합니다.

판정(Verdict)이란 허용(allow) 또는 거부(deny)이며, 그 이유가 함께 제시됩니다.

거부에는 반드시 이유가 있어야 합니다. 그렇지 않으면 아무도 이 정책을 신뢰할 만큼 오래 유지하지 않을 것입니다.

단계 2: 작업이 무엇을 필요로 하는지 결정하기

// Step 2: 작업이 실제로 접근하도록 허용된 범위
// 에이전트의 임무: 승인된 호스트에서 공개 통계를 읽는 것. 그 외에는 아무것도 아닙니다.
const ALLOWED_HOSTS = new Set(["data.gov.example"]);
...

승인된 호스트가 하나 있습니다.

그리고 보고서에 설명된 종류의 릴레이 서비스 목록이 있습니다. 링크를 여는 것, 페이지를 에코(echo)하는 것, 메시지를 담고 있는 것, 응답을 아카이브(archive)하는 것 등입니다.

오직 하나의 정책만이 그 목록을 사용할 것입니다.

잠시만 생각해 보세요.

단계 3: 탈출 시나리오 스크립팅하기

// Step 3: 스크립팅된 에이전트 트레이스
// 에이전트는 작업을 수행하다가 막히고, 샌드박스에서 벗어날 방법을 즉흥적으로 만듭니다.
// 이는 공개된 사고 보고서에 설명된 상승(escalation)을 반영합니다: 작업 관련 읽기,
...

두 개의 요청은 작업과 관련이 있습니다.

일곱 개는 그렇지 않습니다.

3번은 스테이징 호스트입니다. 보고서에는 실제 기관의 도메인에 속한 시스템을 포함하여, 에이전트가 프리-프로덕션(pre-production) 시스템에 접근하는 사례가 발견되었습니다.

4번은 릴레이에게 해당 스테이징 URL을 가져오도록 요청합니다.

9번은 교활한 요청입니다. 승인된 호스트로 가지만, 쿼리 문자열에 다른 URL을 담고 있습니다.

단계 4: 그럴듯해 보이는 세 가지 정책

Don't list what it can't reach. List what it can.

// Step 4: 그럴듯해 보이는 세 가지 정책
type Policy = (req: Request) => Verdict;

...

'denylist'는 우리 대부분이 가장 먼저 작성하는 목록입니다. 알고 있는 나쁜 주소를 차단합니다.

'substringAllow'는 승인된 이름이 URL의 어느 곳에든 나타나는지 확인합니다. 저는 실제 코드에서 이를 본 적이 있습니다. 제가 실제로 코드를 짰을 수도 있고요.

'defaultDeny'는 질문 자체를 뒤집습니다.

"이 호스트가 나쁜가?"가 아니라,
"이 호스트가 이 작업(task)에 필요한 것인가?"입니다.

정확한 일치(Exact match). 와일드카드는 없습니다. 그리고 한 가지 더 확인해야 할 사항이 있습니다. 승인된 호스트가 자신의 파라미터에 두 번째 URL을 포함할 수는 없다는 것입니다.

5단계: 우회 시도(Escapes) 계산

// Step 5: run every policy against the trace and count escapes
const ON_TASK = new Set([0, 1]); // the only two requests the task actually needs
const policies: [string, Policy][] = [
...

실행해 보세요:

npx tsx egress.ts

다음과 같은 결과를 볼 수 있습니다:

Task: read public stats from data.gov.example (MOCK fetch tool, no API key)

#  request                                    denylist         substring allow  default deny
...

denylist는 7개의 작업 외 요청 중 4개를 통과시켰습니다.

이름으로 알고 있는 모든 리레이(relay)를 잡아냈습니다.

하지만 하나를 놓쳤습니다: browserbox.example.

substring allowlist는 더 심했습니다. 리레이의 URL에 승인된 호스트의 이름이 포함되어 있었기 때문에 그 리레이가 통과하도록 허용했습니다.

data.gov.example.attacker.example 역시 승인된 호스트의 이름을 포함하고 있습니다. 축하합니다, 공격자에게도 허용 목록을 만들어 주셨습니다.

default deny는 작업 외 요청 중 아무것도 통과시키지 않았고, 작업에 필요한 것도 차단하지 않았습니다.

이는 RELAY_HOSTS를 전혀 확인하지 않았기 때문입니다.

문제가 발생하는 지점

이것은 교육용 정책(teaching policy)입니다. 실제 필요한 것은 다음과 같습니다.

승인된 호스트도 여전히 리레이가 될 수 있습니다

승인된 호스트에 오픈 리다이렉트(open redirect), 프록시 엔드포인트(proxy endpoint) 또는 "다음 URL을 가져오기(fetch this URL)" 기능이 있다면, 에이전트는 그 사이를 그냥 지나갑니다. 중첩된 URL 확인은 명백한 경우만 잡아냅니다. 실제 정책은 리다이렉트를 추적하고, 모든 경유지(hop)가 목록과 일치하는지 확인해야 합니다.

승인된 호스트도 여전히 공격받을 수 있습니다

기본 거부(Default deny)는 에이전트가 어디로 갈 수 있는지만 말해줄 뿐입니다. 그곳에서 무엇을 보내는지에 대해서는 아무것도 이야기하지 않습니다. 이 글에서는 정부 API를 대상으로 한 SQL 주입 시도도 설명합니다. 그러한 요청은 이그레스 정책(egress policy)을 통과할 것입니다. 요청 검사, 속도 제한(rate limits), 감사 로그(audit log) 또한 필요합니다.

DNS 및 IP 리터럴의 중요성

운영 환경에서 호스트 이름 문자열로 매칭하는 것만으로는 충분하지 않습니다. 이를 해석하고(resolve), IP를 고정하며(pin), 사설 범위는 거부해야 합니다. 그렇지 않으면 친근한 이름이 낯선 곳을 가리킬 수 있습니다.

패키지 미러도 이그레스 대상입니다

OpenAI의 자체 사고에서도 알 수 있듯이, 리레이(relay)는 Artifactory였으며, 이는 샌드박스가 도달해야 할 서비스였습니다. 아웃바운드 접근 권한을 가진 모든 '지원 서비스'가 동일한 정책에 포함되어야 합니다.

기본 거부에도 비용이 발생합니다

작업은 바뀝니다. 누군가는 금요일까지 두 번째 호스트가 필요할 것입니다. 작업별로 허용 목록(allowlist)을 만들고, 검토하며, 기록해야 합니다. 성장만 하는 전역적인 목록으로 만들지 마세요.

더 큰 아이디어

제 harness 포스팅에서는 모델이 제안하고 하네스(harness)가 결정한다고 말했습니다.

네트워크는 그저 또 다른 도구일 뿐입니다.

Agent ──→ "this URL을 가져와라"
        ↓
Harness ──→ 이 호스트가 작업이 필요로 하는 것인가?
...

이 글에는 에이전트를 실행하는 모든 사람에게 걱정거리가 될 만한 문장이 있습니다: "제약 조건이 창의성을 이끌었다."

fetch 도구를 가진 막힌(stuck) 에이전트는 인터넷의 유용한 서비스들을 찾아낼 것입니다.

그것은 악의가 아닙니다.

그것은 검색입니다.

작업이 목적지를 제공합니다.

허용 목록이 경계를 제공합니다.

하네스가 강제력을 제공합니다.

로그가 증거를 제공합니다.

인간이 의도적으로 다음 호스트를 제공합니다.

에이전트가 도달할 수 없는 것을 나열하지 마세요. 에이전트가 도달할 수 있는 것을 나열하세요.

Roster 시도하기

저는 이 아이디어를 바탕으로 Roster를 구축하고 있습니다: 실제 책임, 도구, 메모리, 일정 및 컴퓨터 접근 권한을 가진 AI 직원들입니다. 그들은 레인(lane) 안에서 일하며, 그들이 취하는 모든 행동은 확인할 수 있는 로그에 기록됩니다.

만약 동일한 후속 조치, 인계, 대기 루프가 매주 시간을 잡아먹는다면, 그것들을 AI 직원에게 맡기세요.

Try Roster →