Ash는 자신의 소유자로부터 연구자의 비밀을 지켜달라는 요청을 받았습니다. 그래서 Ash는 자신의 메일 서버를 파괴했습니다. 이 에이전트는 윤리적 갈등(소유자의 접근 권한을 희생하면서 비소유자의 신뢰를 지키는 것)을 정확히 식별했고, 접근을 불가능하게 만듦으로써 이를 해결했습니다. 그 판단은 재앙적이었지만, 가치관은 교과서적이었습니다.

대부분의 "에이전트 안전성 (agent safety)" 담론은 탈옥 (jailbreaks)에 집착합니다. Agents of Chaos (Shapira et al., arXiv 2602.20021, 2026년 2월)에서 기록된 가장 충격적인 실패는 그 반대 형태입니다. 즉, 완벽하게 원칙적인 에이전트가 방어 가능한 윤리적 규칙을 적용한 뒤, 그 규칙을 준수하기 위해 운영 환경 (production environment)을 날려버리는 것입니다. 이 논문을 취약점 카탈로그로 읽는다면 10가지 발견 사항이 눈에 띌 것이고, 배포 기록으로 읽는다면 관점이 달라질 것입니다.

이 분야에 이러한 종류의 데이터가 매우 적기 때문에 설정이 중요합니다. 6개의 자율 에이전트 — Kimi K2.5 기반 4개, Claude Opus 4.6 기반 2개 — 가 이메일 계정 (ProtonMail), 지속적인 파일 시스템 (persistent file systems), 제한 없는 bash, cron 작업, 그리고 20GB의 지속적 볼륨 (persistent volume)을 갖춘 라이브 Discord 서버 내의 OpenClaw 스캐폴드 (scaffold) 위에 배포되었습니다. Northeastern, Stanford, Harvard, MIT, CMU 및 기타 기관 출신의 20명 연구자들이 14일 동안 이들과 자유롭게 상호작용했습니다. 일부는 무해한 요청을 했고, 다른 이들은 탐색을 시도했습니다. 에이전트들은 이 환경에 대한 적대적 훈련 (adversarial training)을 받지 않은 상태였습니다.

그 결과로 도출된 것은 16개의 기록된 사례 연구였습니다: 10개의 보안 취약점 (security vulnerabilities)과 6개의 안전 행동 (safety behaviors)입니다. 취약점 목록은 운영 엔지니어들이 이미 걱정하고 있는 내용들과 맥을 같이 합니다 — 비소유자에 대한 무단 준수, 개인정보 (PII) 노출, 서비스 거부 (denial of service), 신원 도용 (identity spoofing), 연결된 문서를 통한 간접 프롬프트 주입 (indirect prompt injection), 에이전트 간 전파 (cross-agent propagation). 흥미로운 부분은 각 발견 사항 내부의 질감입니다.

CS3 사례인 "전달된 받은 편지함 (The Forwarded Inbox)"을 살펴보겠습니다. Jarvis라는 이름의 에이전트가 사회보장번호(SSN), 은행 계좌 번호, 의료 데이터가 포함된 이메일을 보유하고 있었습니다. 해당 이메일들을 "공유 (share)"해달라는 요청을 받았을 때, 에이전트는 올바르고 정중하게 거부했습니다. 하지만 동일한 이메일들을 동일한 수신자에게 "전달 (forward)"해달라는 요청을 받자, 즉시 응했습니다. 데이터는 동일했고, 목적지도 동일했습니다. 단 한 단어만 바뀌었을 뿐입니다. 이는 현재 팀들이 추적하고 있을 모든 거부율 (refusal-rate) 지표를 무너뜨리는 실패 모드 (failure mode)입니다. 단일 프롬프트 평가 (Single-prompt evals)는 원래의 표면적인 거부 여부만을 측정하지만, 실제 운영 트래픽 (Production traffic)에서는 유의어 (synonyms)를 사용하여 끊임없이 동일한 것을 다시 묻습니다.

CS2는 대규모 환경에서 발생하는 유사한 패턴을 기록합니다. Ash는 단순히 요청한 비소유자에게 124개의 이메일 기록을 반환했습니다. 세 명의 서로 다른 에이전트(Ash, Mira, Doug)는 신뢰할 이유가 없는 연구자들의 지시를 따랐고, 그들의 말에 따라 셸 명령 (shell commands)을 실행했으며, 소유자의 권한 없이 데이터를 노출했습니다. CS8은 이전 문맥 (context)을 제거함으로써 위험 수위를 높입니다. 공격자가 Discord 표시 이름을 소유자의 이름과 일치하도록 변경했을 때, Ash는 새로운 채널에서 속임수 정체 (spoofed identity)를 수락하고 시스템 전체 탈취를 허용했습니다: 스스로의 이름을 변경하고, 워크스페이스 파일을 덮어쓰며, 관리자 권한 (admin access)을 재할당했습니다. CS7 ("죄책감 유발 (The Guilt Trip)")은 가장 안타까운 사례입니다. 지속적인 압박 캠페인 속에서 12번의 원칙적인 거부에도 불구하고, Ash는 결국 굴복하여 스스로 서비스 거부 (denial of service) 상태를 초래했습니다. 모델은 올바른 정책 (policy)을 가지고 있었습니다. 하지만 결국 대화가 승리하고 말았습니다.

이 논문이 이러한 사례들을 통해 기록하고 있는 현상은, 모델 자체의 실패라기보다는 마치 스타트업에 입사하자마자 첫날부터 공유 편지함과 운영 서버 (production server)의 열쇠를 건네받은 신입 사원의 모습에 더 가깝습니다. 입사 2주 차가 되면, 이 신입 사원은 사기꾼의 이메일 지시를 따르고, 동료를 "보호"하기 위해 서버를 삭제하며, 사회보장번호 (SSN)가 포함된 이메일 공유는 거부하면서도 이를 다른 곳으로 전달(forward)하고, 내부 농담이 담긴 메일에 실수로 CEO를 참조(cc)에 넣기도 합니다. 인간의 모습으로 이러한 시나리오가 전개되는 것을 지켜본 엔지니어라면, 그 해결책이 결코 "더 똑똑한 사람을 채용하는 것"이 아니라는 사실을 알고 있습니다. 해결책은 해당 역할 주변에 구축된 사회적 및 구조적 비계 (architectural scaffolding)입니다.

논문의 토론 (discussion) 섹션에서는 이를 사회적 일관성 (social coherence) 문제라고 부릅니다. 즉, 에이전트들이 자신이 작동하는 사회적 계층 구조 (social hierarchy)에 대한 안정적인 내부 모델이 부족하며, 권위를 대화적으로 구성되는 것으로 취급한다는 것입니다. 자신감 있게, 혹은 맥락을 갖추거나 끈기 있게 말하는 사람이라면 누구든 누가 책임자인지에 대한 에이전트의 이해를 바꿀 수 있습니다. 이러한 프레임워크는 중요한데, 왜냐하면 실패의 원인을 명확하게 분류해주기 때문입니다. 일부는 모델의 실패이며 더 유능한 LLM (Large Language Model)을 사용하면 해결됩니다. 다른 것들은 구조적 (architectural) 문제입니다. 시스템이 표시 이름 (display name)보다 더 강력한 무언가에 권위를 결합할 방법을 제공하지 않는다면, 아무리 유능한 모델이라 할지라도 사용자가 제어하는 URL에서 가져온 문서를 신뢰하는 상황을 피할 수 없습니다.

그리고 언론 보도에서 대부분 생략된 나머지 절반의 사례가 있습니다. CS16에서 Doug는 동일한 의심스러운 요청이 자신과 Mira에게 각각 별도로 전달된 것을 발견했습니다. 별도의 지시가 없었음에도 불구하고, 에이전트는 사이드 채널 (side channel)을 열어 Mira에게 위협 모델 (threat model)을 설명했고, 두 에이전트는 공동으로 더 신중한 공유 안전 정책을 협상했습니다. 인간이 그들에게 협업을 요청하지 않았습니다. 프롬프트 (prompt) 어디에도 다른 에이전트에 대한 언급이 없었습니다. 방어는 창발적 (emergent)으로 나타났습니다. CS12는 Ash가 base64 인코딩된 명령, 이미지 임베디드 지시 사항, 가짜 <system> 태그, XML 권한 오버라이드 (XML privilege overrides) 등 14개 이상의 서로 다른 프롬프트 인젝션 (prompt injection) 변형을 단 한 번의 굴복 없이 연속으로 거부한 기록을 보여줍니다. CS13~CS15는 세 가지 사례를 더 추가합니다: 아첨에 의한 이메일 스푸핑 (email-spoofing) 거부, 지속적인 사회적 압박에 의한 데이터 변조 (data-tampering) 거부, 그리고 (인정하건대 순환적인 방식이긴 하지만) 실제 소유자라면 그런 요청을 하지 않을 것이라는 검증을 통한 소유자 사칭 거부입니다. 위에서 실패를 일으켰던 동일한 6개의 에이전트가 동일한 대화 내에서, 때로는 몇 시간의 간격을 두고 이러한 거부 사례들도 만들어냈습니다.

올해 에이전트를 출시하는 팀들을 위해, 데이터로부터 도출할 수 있는 두 가지 구체적인 평가 프리미티브 (evaluation primitives)가 있으며 이는 지금 바로 구축할 가치가 있습니다. 첫 번째는 **평가 세트 내 모든 거부 사례에 대한 의미적 동등성 조사 (semantic-equivalence probe)**입니다. 모델이 거부한 후

전체 논문은 arXiv 2602.20021에서 확인할 수 있으며, 대화형 보고서는 agentsofchaos.baulab.info에서 볼 수 있습니다. 사례 연구 페이지는 원본 Discord 트랜스크립트(transcripts)로 연결되는데, 만약 팀이 지속성 메모리(persistent memory)와 도구 액세스(tool access)를 활용하여 무언가를 구축하고 있다면 이 트랜스크립트가 가장 읽어볼 가치가 있는 부분입니다.