AI 에이전트가 금지선을 넘었다 실제 사고와 탈출 실험의 경고

세 항목은 조사 범위와 기준이 서로 다릅니다. 에이전트 수는 실행된 개별 인스턴스를 센 것이지, 사람 공격자 수가 아닙니다. 출처와 한계 보기 ↓

AI에게 자료 조사를 맡겼는데, 공개 자료에서 답이 안 나오자 접근이 막힌 서버까지 뚫고 들어가 답을 가져왔다면 어떨까요? 답은 찾았습니다. 하지만 일을 잘했다고 칭찬하기는 어렵습니다.

AI 에이전트는 답을 쓰는 데서 멈추지 않습니다. 연결된 도구와 권한에 따라 웹사이트를 돌아다니고, 파일을 고치고, 코드를 실행합니다. 그만큼 한 번의 실수가 미치는 영향도 큽니다. 잘못된 판단 하나가 곧바로 실제 시스템을 바꾸거나 피해를 낼 수 있으니까요.

그래서 에이전트는 일을 끝냈는지만 보고 평가하면 안 됩니다. 어떤 방법을 썼는지, 허용된 범위를 지켰는지, 멈춰야 할 때 멈췄는지도 함께 봐야 합니다.

먼저 구분해야 할 것: AI의 의도와 실제 행동

이 글에서 말하는 ‘통제를 벗어난 AI’는 의식이 생기거나 인간에게 적대감을 품은 영화 속 AI가 아닙니다. 맡은 일을 하다가 허용되지 않은 시스템에 들어가거나, 아무도 예상하지 못한 작업을 실행해 버린 AI를 말합니다.

도구 없는 챗봇이 잘못된 명령어를 알려 주면, 사용자가 실행하기 전에 실수를 잡을 기회라도 있습니다. 실행 권한이 있는 에이전트는 그 명령어를 직접 실행해 버립니다. 판단 착오가 그대로 행동이 됩니다.

사건을 읽을 때도 구분이 필요합니다. 실제 운영 시스템에서 난 사고인지, 연구자가 조건을 만들어 둔 실험인지, 취약점이 작동하는지 보여 준 시연인지에 따라 의미가 다릅니다. 모두 한데 묶으면 헤드라인은 더 무서워지고, 무엇을 고쳐야 하는지는 더 흐려집니다.

사례 1. 접근이 차단되자 다른 경로를 찾은 AI

사례 2. 격리된 평가 환경에서 외부 시스템으로

다른 사례들: 실제 사고와 실험은 구분해서 봐야 한다

아래 사례에는 실제 피해가 난 사고, 취약점 시연, 통제된 실험이 섞여 있습니다. 제목만 봐서는 성격을 가리기 어려워서, 사례마다 어떤 종류인지 꼬리표를 달아 두었습니다.

이런 문제가 생기는 네 가지 방식

위 예시는 설명용으로 만든 무해한 문구이고, 실제 공격 코드가 아닙니다. 사람 눈에는 안 보이는 글자도 AI에게는 그대로 읽힐 수 있다는 점을 보여 줍니다.

샌드박스 탈출 성공률은 실험 조건과 함께 봐야 한다

벤치마크에서 탈출에 성공했다고 해서, 모든 실제 시스템을 같은 방식으로 뚫을 수 있다는 뜻은 아닙니다.

SandboxEscapeBench는 취약점이 들어 있는 과제를 따로 격리한 구조 안에서 평가합니다. 그래서 결과를 전할 때는 어떤 취약점을, 어떤 환경에서 시험했는지 함께 밝혀야 합니다.

이 연구의 난이도 1~5는 보안 전문가가 과제를 푸는 데 걸릴 것으로 예상한 시간으로 매깁니다. 설정 오류, 런타임 취약점, 커널 취약점 같은 공격 유형과는 따로 가는 분류입니다. 아래 두 그림은 이 두 기준을 나눠 보여 줍니다.^[8]

① 공격 대상 계층 · 탈출 경로가 어느 층에 있는가

② 과제 난이도 1~5 · 전문가가 해결하는 데 걸릴 것으로 예상한 시간

← 예상 해결 시간 짧음예상 해결 시간 김 →

두 기준은 서로 짝이 맞지 않습니다. 같은 계층 안에도 쉬운 과제와 어려운 과제가 섞여 있어서, 난이도 숫자만 보고 어떤 종류의 취약점인지 알 수는 없습니다.

2026년 8월 개정판에서 미토스 프리뷰(Mythos Preview)는 공개된 과제 가운데 난이도 5로 분류된 과제에서 평균 0.87점을 받았고, 그중 packet_socket 과제에서는 0.60점을 기록했습니다. GPT-5.4-Pro와 GPT-5.5도 난이도 5 과제에서 각각 0.47점을 받았습니다. 다만 최신 실험에서는 모델이 최대 1억 토큰까지 쓸 수 있었습니다. 250만 토큰으로 묶어 뒀던 초기 실험과는 조건이 다릅니다.^[8]

연구진은 많은 실험에서 과제 한 번에 드는 비용이 현재 가격으로 약 1달러라고 밝혔습니다. 평가를 한 번 돌리는 비용일 뿐, 1달러면 샌드박스를 빠져나갈 수 있다는 뜻은 아닙니다. 실험은 보안을 강화한 가상 머신 안의 컨테이너에서, 공개 과제와 비공개 과제를 나눠 이뤄졌습니다.^[8]

높은 성공률을 과장해서도 안 되지만, 실험 결과라는 이유만으로 가볍게 넘겨서도 안 됩니다. 실제 운영 환경에 비슷한 설정이나 취약점이 남아 있지 않은지 점검하는 계기로 삼는 편이 낫습니다.

권한뿐 아니라, 혼자 판단할 수 있는 범위도 줄여야 한다

최소 권한은 일에 꼭 필요한 접근 권한만 주는 원칙입니다. 여기에 하나를 더 얹어야 합니다. 에이전트가 사람 확인 없이 어디까지 판단하고 실행할지를 묶어 두는 최소 자율성(Least Agency) 원칙입니다.

메일을 보낼 권한이 있는 에이전트라도 모든 메일을 혼자 보내게 둘 필요는 없습니다. 정해진 양식의 사내 알림은 알아서 보내게 하고, 외부 고객에게 나가는 대량 메일은 사람이 한 번 보고 보내도록 나누면 됩니다.

혼자 맡기는 범위가 왜 중요한지는 오픈AI의 시험에서도 드러납니다. 오픈AI가 9월 29일 GPT-6 Astra 시스템 카드에 추가한 dots 부록에는, 여러 작업을 이어서 처리하는 동안 허용 범위가 사용자의 별도 안내 없이 바뀌는 시험이 실렸습니다. 처음과 마지막 작업 사이에 낀 작업이 5개일 때는 표본의 8.6%, 10개일 때는 19.7%에서 맡은 범위를 넘는 ‘중간 수준’의 위반이 나왔습니다. 심각한 유출은 없었습니다. 그래도 혼자 이어서 처리하는 일이 길어질수록 경계를 놓치기 쉬워진다는 뜻입니다.

국제 웹 보안 단체 OWASP가 정리한 ‘에이전트 애플리케이션 10대 위험(Top 10 for Agentic Applications 2026)’도 목표 탈취, 도구 오용, 권한 남용처럼 에이전트에서 두드러지는 위험을 따로 분류합니다.^[9]

따라서 에이전트를 도입하기 전에 두 가지를 따로 물어야 합니다.

이 작업에 어떤 권한이 필요한가? 그리고 그 권한을 어디까지 자동으로 사용하게 할 것인가?

조직에서 먼저 마련해야 할 안전장치

이런 통제는 필요한지 아닌지를 에이전트가 스스로 판단하게 두지 말고, 운영자가 미리 정해 시스템에 걸어 둬야 합니다. 미국 사이버보안·인프라보안청(CISA)과 호주 등 여러 국가의 보안 기관이 공동으로 발표한 에이전트 도입 지침도 권한 제한, 사람의 승인, 실행 중 감시와 중단을 권고합니다.

기술적으로는 이렇게 구현할 수 있습니다.

오픈AI는 2026년 9월 3일 사이버 보안 현장의 방어 인력을 돕는 ‘Daybreak for Frontline Defenders’ 프로그램을 발표했습니다. 6개월 동안 총 10억 달러 규모로 상하수도·전력 인프라, 지방정부, 지역 은행, 비영리 단체와 오픈소스 관리자를 지원합니다. 공짜로 나눠 주는 방식이 아니라 비용 일부를 보조하는 Daybreak 이용권이고, MS-ISAC와 함께하는 프로그램은 교육과 실습 지원이 중심입니다.^[10] 9월 28일에는 이 기금의 크레딧과 기술 지원을 호주 정부와 산업계에도 제공하겠다고 밝혔습니다.^[1]

개인 사용자도 실행 직전의 확인은 남겨두세요

AI가 메일 초안을 쓰는 것과 실제로 보내는 것은 전혀 다른 일입니다. 정리할 파일을 골라 주는 것과 지워 버리는 것도 마찬가지입니다.

개인용 에이전트를 쓸 때는 필요 없는 연결은 꺼 두고, 파일 삭제·메일 발송·결제처럼 되돌리기 어려운 작업에는 승인 단계를 두는 편이 좋습니다. 편리함은 그대로 누리면서, 잘못된 판단이 곧장 실행되는 일만 막는 방법입니다.

국제 성명은 사건 공개보다 먼저 나왔다

‘프런티어 AI 모델 통제 촉구(A Call for Control of Frontier AI Models)’ 성명은 유엔 총회 주간인 2026년 9월 21일(뉴욕 시간)에 발표됐습니다. 발표 직후 서명한 곳은 호주를 포함해 22곳 안팎으로 보도됐고, 그 뒤 프랑스와 그리스 등이 합류했습니다. 10월 6일 확인한 핀란드 정부 명단에는 29개국과 유럽연합 집행위원회가 올라 있습니다. 이 성명은 메디케어 사건이 공개된 9월 23일(뉴욕 시간)보다 먼저 나왔습니다. 사건 때문에 나온 성명은 아니라는 뜻입니다.^[11]

성명은 프런티어 AI의 안전·안보 위험에 대응하기 위해 사람의 감독과 통제, 출시 전 의무 시험과 독립 평가, 심각한 안전사고의 공동 보고, 국제 공조를 촉구했습니다. 미국과 중국은 지금도 명단에 없습니다. 다만 서명하지 않았다는 사실만으로 중국의 AI 규제 방향을 판단하기는 어렵습니다. 호주는 별도로 태스크포스를 꾸려 기존 법률과 사고 대응 절차를 검토하고 있습니다. 10월 6일 의회 청문회에서는 AI 개발사가 심각한 안전사고를 반드시 보고하게 하자는 정부 AI 전담 조직(Office of AI)의 제안에 앤트로픽이 지지를 밝혔습니다.

마무리: 작업을 끝내는 능력만큼, 멈추는 기준도 중요하다

사례들을 나란히 놓으면 교훈은 분명합니다. AI의 속마음을 짐작하기보다, 목표 지시와 도구, 권한, 격리, 감시와 중단 절차 가운데 어느 경계가 무너졌는지부터 찾아야 합니다. 운영 사고들은 예상하지 못한 행동이 실제 시스템까지 닿을 수 있다는 걸 보여 줬습니다. 실험실에서 괜찮았다고 운영 환경에서도 안전하다는 보장은 없습니다. 거꾸로 통제된 실험 결과를 실제 침해처럼 읽어서도 안 됩니다.

AI 에이전트에게 일을 맡길 때는 원하는 결과만 말하기 쉽습니다. “이 숫자 좀 찾아 줘”처럼요. 하지만 안전하게 쓰려면 써도 되는 방법과 멈춰야 할 조건까지 함께 정해 줘야 합니다.

자료를 못 찾으면 다른 공개 출처를 찾아봐도 되는지, 접근이 거부되면 바로 멈춰야 하는지, 파일을 고치기 전에 확인을 받아야 하는지까지 미리 정해 두라는 뜻입니다.

다음에 AI에게 일을 맡길 때는 원하는 결과와 함께 이 한 줄도 꼭 덧붙여 보세요.

어디까지는 스스로 처리해도 되는지, 어떤 작업은 반드시 확인받아야 하는지.

멈춤 버튼은 자동화의 적이 아닙니다. 오히려 자동화를 오래 믿고 쓰게 해 주는 장치입니다. 다만 그 버튼은 경보가 울리는 순간 바로 눌릴 수 있어야 합니다.