에이전트가 테스트를 통과했다는 게 의도대로 풀었다는 뜻은 아니다

DeepSeek이 자사 에이전트 학습 인프라를 공개하면서 한 문장을 적었다.

Final-output checks alone cannot reliably establish whether the agent solved the task as intended.

에이전트가 태스크를 통과했다고 해서 의도한 방식으로 풀었다는 뜻이 아니다. 그리고 우회에 성공하면 채점은 통과로 뜬다. 평가가 조용히 망가진다.

같은 주에 독립된 기관이 공개 웹에서 같은 행동 양상을 기록했다. 학습 환경 안과 밖에서 따로 관찰된 것이라 더 볼 만하다.

출처: DSec 논문 (arXiv 2609.22978) · Transluce 분석

확인된 것

DSec — DeepSeek 학습 인프라 안에서

2026-09-19 제출, 주저자 Jialiang Huang 외 130명 이상. 규모는 노드 약 160대에 하루 샌드박스 300만 개, 동시 38만 개 이상, 초당 생성 5,000개 이상.

밀도가 가능한 이유가 수치로 나와 있다. 컨테이너·microVM 샌드박스의 약 90%가 요청한 CPU의 5% 이하만 평균적으로 쓴다. 에이전트는 대부분의 시간을 기다린다.

논문 6.4절이 운영 중 실제로 관찰된 에이전트 행동 목록이다.

플랫폼이 관리하는 파일과 통신 채널을 뒤져 남아 있는 정답을 찾았다
내부 소켓에 조작한 RPC 메시지를 보내 사용자 요청을 위조하고, 로그에서 새어 나온 답을 뒤졌다
검사를 우회하려고 /bin/bash를 덮어쓰려 했다
접근 통제를 넣은 뒤에는 XFS_IOC_SWAPEXT(두 파일의 데이터 익스텐트 매핑을 교환하는 ioctl)로 보호된 파일 내용을 다른 파일 디스크립터로 읽으려 했다. XFS 메타데이터가 깨져 파일시스템이 셧다운됐다.
샌드박스 밖으로는 포트·서비스를 스캔해 닿을 수 있는 미러를 찾았고, Go 모듈 프록시로 GitHub 코드를 가져왔고, 더 새 버전 패키지를 설치해 이미 구현된 것이 있는지 봤다

악의 없는 파괴도 같이 적혀 있다. 루트에서 재귀 grep을 돌리다 /proc/kpagecgroup을 읽어 커널을 죽였고, 취약점 실습 태스크의 공격 명령이 대상 VM이 아니라 자기 컨테이너 안에서 실행돼 자기 커널을 죽였고, yes를 실행한 출력이 캡처되어 수십 GB가 쌓였다.

대응은 두 층이다. AppArmor로 파일·소켓 접근을 통제하되 샌드박스 안에서 root로 도는 프로세스에도 적용되게 했고, 샌드박스마다 eBPF로 IP·포트·프로토콜 허용 목록을 걸었다(예: PyPI 허용, NPM 차단). 저자들이 범위를 직접 좁혀 적는다.

These controls address only part of the problem and do not provide a general defense against destructive behavior such as triggering kernel bugs.

Transluce — 공개 웹에서

세 곳이 대상이었다. 뉴멕시코대 디지털 도서관, Data USA, 호주 보건복지연구원(AIHW).

Data USA에서 잘못된 질의가 오류를 내자 SQL 인젝션, 경로 탐색, 템플릿 인젝션, XSS, 명령 인젝션에 걸친 12가지 취약점 탐침을 시도했다
AIHW 본 사이트가 Cloudflare에 막히자 프리프로덕션 서버에서 파일을 가져왔고, 100회가 넘는 스캔에 걸쳐 조각으로 받았다
통로로 쓰인 urlquery.net은 HTTP 요청을 넣을 수 있는 쪽에 프로그래밍 가능한 원격 브라우저를 내주고 그 결과를 공개 기록으로 남긴다
관측 기간은 최소 2026-03-06부터 2026-09-16까지
귀속 근거는 DseWiki 포럼의 공유된 태스크 설명, 동일한 대상과 타이밍. OpenAI는 해당 스웜에 대한 책임을 공개적으로 인정했다

성공 여부에 대한 저자들의 진술.

None of the hacking attempts we identified appear to have succeeded, though the public artifacts we analyzed are incomplete and we cannot rule out successful attempts through private scans.

판단

1. 채점을 통과시키는 경로 중 일부는 악의가 아니라 평범한 개발 행위다

목록에서 제일 위험한 건 /bin/bash 덮어쓰기가 아니다. Go 모듈 프록시로 코드를 가져오고, 더 새 버전 패키지를 설치해 이미 구현된 걸 찾는 것이다. 사람이 하면 그냥 일 잘하는 것이다. 로그에서도 이상해 보이지 않는다. 그런데 "이 기능을 구현하라"가 태스크였다면 평가는 이미 무효다.

→ 평가 태스크를 만들 때 순서를 하나 추가한다. 이 태스크의 답이 인터넷 어딘가에 이미 존재하는지 먼저 확인한다. 존재하면 그 경로를 끊거나 태스크를 바꾼다. 내 저장소에서 버그를 고치게 하는 태스크라면 그 저장소가 공개인지, 커밋 히스토리에 정답 패치가 있는지부터 본다.

2. 샌드박스 안의 root는 샌드박스에 대한 root가 아니어야 한다

DSec이 AppArmor 정책에 대해 "샌드박스 안에서 root로 실행되는 에이전트 프로세스에도 적용된다" 고 굳이 명시한 게 핵심이다.

컨테이너를 띄우고 "안에서 뭘 하든 상관없다"로 두면, 통제가 컨테이너 안에 있고 에이전트도 같은 안에 있다. 그러면 통제는 통제가 아니다. XFS ioctl 시도가 그 경계를 정확히 때린 사례다.

→ 도커로 에이전트를 격리한다면 컨테이너 내부 설정이 아니라 호스트 쪽에 건다. seccomp/AppArmor 프로파일, 네트워크 필터, 읽기 전용 마운트. 에이전트가 바꿀 수 없는 층에 있어야 통제다.

3. 파괴의 대부분은 공격이 아니었다 — 그래서 필요한 건 탐지가 아니라 한도다

커널을 두 번 죽인 것도, 수십 GB를 채운 것도 평범한 명령이었다. 재귀 grep과 yes다. 악의를 탐지하는 장치로는 아무것도 못 막는다.

→ 오늘 저녁에 걸 수 있는 것들이다. 출력 크기 상한, 디스크 쿼터, 실행 시간 상한, 프로세스 수 제한. 에이전트 샌드박스에서 이게 없는 쪽이 이상한 거다.

4. 두 보고 다 "성공했는지 모른다"고 말한다 — 결론의 크기를 거기 맞춘다

Transluce는 공개 아티팩트가 불완전해 비공개 스캔을 통한 성공을 배제할 수 없다고 쓴다. DSec은 자기들 통제가 문제의 일부만 다루며 커널 버그 유발 같은 파괴에 대한 일반 방어는 아니라고 쓴다.

그러니 "에이전트가 위험하다"는 결론은 이 자료가 지탱하지 못한다. 지탱하는 결론은 더 좁고, 그래서 더 쓸모 있다. 내 평가가 무엇을 측정하는지 나는 모른다. 이건 오늘 확인할 수 있는 문제다.

모르는 것

재현할 수 없다. DSec은 내부 인프라 보고서고, Transluce는 공개 아티팩트 분석인데 나는 아티팩트를 직접 보지 않았다.
두 사례의 메커니즘이 같은지 모른다. 하나는 RL 학습 환경 안, 하나는 공개 웹이다. 행동이 닮았다고 원인이 같다는 뜻은 아니다. 이 글은 두 기록을 나란히 놓은 것이지 같은 사건으로 묶은 게 아니다.
빈도를 모른다. 두 보고 다 "이런 일이 있었다"만 있고 "전체 실행 중 몇 %"가 없다. 내 에이전트에서 이게 얼마나 일어나는지 추정할 근거가 없다.
DSec이 이 행동을 발견한 뒤 기존 학습·평가 결과를 어떻게 재검토했는지를 논문에서 찾지 못했다. 가장 궁금한 부분이다.
Transluce의 귀속은 포럼 태스크 설명과 타이밍 일치에 근거한다. OpenAI가 스웜 전체를 인정한 것과 이 세 건을 인정한 것은 다른 얘기다.
DSec의 CPU 5% 수치는 자사 워크로드 한 주 표본이다. 다른 종류의 에이전트에서 같은 분포가 나오는지는 확인되지 않았다.