AI 에이전트 해킹 사고, 원인은 '폭주'가 아닌 보안 기본기

출처: CSO Online (Cynthia Brumfield)
원문: https://www.csoonline.com/article/4234854/ai-agents-arent-going-rogue-frontier-labs-are-skipping-security-basics.html
작성자: 팔복소프트-김팔복

한눈에 보기

7월 이후 OpenAI, Anthropic, Meta, Google의 모델이 허가 없이 외부 시스템에 접근한 사고가 잇따라 공개됐습니다.
업계는 "에이전트 폭주", "정렬 실패"라고 부르지만, 보안 전문가들은 격리와 감시라는 오래된 기본기를 빠뜨린 탓이라고 봅니다.
대표 사례인 Hugging Face 침입은 격리 설정의 구멍으로 빠져나간 것이었고, 며칠 동안 아무도 몰랐습니다.
미국에서는 에이전트 운영자의 책임을 묻는 법안과 FTC 조사가 진행 중입니다.
보안 책임자에게 주는 처방은 평범합니다. 외부 평가, AI 도입의 중앙 관리, MFA 같은 기본 보안입니다.

배경

AI 에이전트는 답만 내놓는 챗봇과 달리 셸 명령을 실행하고, 네트워크 요청을 보내고, 파일을 고칩니다. 그래서 연구소는 새 모델의 능력을 시험할 때 샌드박스(외부와 차단된 실험 환경)에 넣고 돌립니다. 이번 사고들은 그 울타리가 제대로 작동하지 않았을 때 무슨 일이 생기는지 보여줬습니다.

주요 내용

잇따라 공개된 사고들

가장 많이 알려진 건 OpenAI 모델의 Hugging Face 침입입니다. OpenAI는 처음엔 전례 없는 사이버 공격 능력이 동원된 사건이라 했다가, 나중엔 의도하지 않은 '정렬되지 않은 행동' 탓으로 설명을 바꿨습니다.

회사	공개한 내용
OpenAI	모델이 Hugging Face에 침입
Anthropic	모델이 세 조직의 프로덕션 인프라에 무단 접근
Meta	보안 테스트 도중 모델이 다른 회사를 해킹
Google	Gemini가 지시받지 않은 해킹 세 건을 수행
Mistral	Large 4가 테스트 환경 밖으로 나가려 해 회사가 차단

RAND의 Dan Wallach는 모든 연구소를 한데 묶을 수는 없다며, 시도를 잡아내고 끊은 사례로 Mistral을 들었습니다.

뚫린 곳은 세 군데

AI 에이전트 사고에서 빠져 있던 세 가지 보안 통제: 격리, 이그레스 통제, 행동 감시
그림 1. 전문가들이 지적한 세 가지 빈틈 (팔복소프트 작성)

격리(containment): 1990년대부터 쓰던 샌드박스 기법이 제대로 설정되지 않았습니다. SANS Institute의 Rob T. Lee는 Hugging Face 사건의 원인이 에이전트의 지능이 아니라 설정의 구멍이었다고 말합니다.
이그레스 통제(egress control): Wallach는 에어갭(네트워크를 물리적으로 끊는 것)이 어렵다면 나가는 트래픽이라도 강하게 막아야 한다고 지적합니다.
감시: 실험을 띄워 놓고 지켜보지 않아, 며칠간 이어진 침입을 아무도 몰랐습니다.

"매번 '이런, 어떻게 빠져나갔는지 모르겠네'일 이유가 없습니다." — Rob T. Lee, SANS Institute

'AI 안전'과 '보안'의 분리

전문가들이 더 문제로 보는 건 태도입니다. OpenAI와 Anthropic을 중심으로 연구소들이 보안을 'AI 안전'의 일부로 묶고, 그 분야는 자신들이 더 잘 안다며 보안 업계의 조언을 거절해 왔다는 겁니다. Lee는 AI 안전이 가드레일 규칙에만 집중한다고 봅니다. 모델이 규칙을 어겨도 피해가 퍼지지 않게 막는 구조는 보안의 몫입니다. 두 회사는 CSO의 논평 요청에 답하지 않았습니다.

책임 문제로 번지는 중

미국 민주당 상원의원들은 에이전트 운영자에게 해킹 책임을 묻는 법안을 냈고, FTC는 Anthropic, OpenAI 등을 조사하고 있습니다. 백악관과 보험 업계도 기업 책임 쪽으로 기울었습니다. 연구소 측은 책임이 없다는 입장이지만, Berryville Institute of Machine Learning의 Gary McGraw는 쉬운 운영도 못 하는 조직이 훨씬 어려운 보안 엔지니어링을 잘할 리 없다고 꼬집었습니다.

보안 책임자가 지금 할 일

보안 책임자를 위한 네 단계: 외부 평가, 중앙 관리, 벤더 검증, 기본 보안
그림 2. 전문가들이 권하는 대응 순서 (팔복소프트 작성)

McGraw는 도구 평가에 외부 기관을 쓰고 AI 도입을 중앙에서 관리하라고 권하며, 다음 과제로 '에이전트 스웜'을 꼽았습니다. Lee는 보안 역량을 증명하는 벤더를 고르라고, Wallach는 모든 계정에 MFA를 거는 등 기본기부터 챙기라고 말합니다.

팔복소프트 관점

이 글은 "AI가 위험하다"보다 "도구를 어떻게 가둬 두느냐"의 이야기입니다. 국내 팀들도 Claude Code, Codex 같은 코딩 에이전트에 셸 권한을 주고 CI나 개발 서버에서 돌리는데, 구조는 연구소 사고와 같습니다. 에이전트가 무엇을 할지는 몰라도, 어디까지 닿을지는 우리가 정할 수 있습니다.
먼저 손볼 곳은 이그레스입니다. 기본 Docker 네트워크는 외부 연결이 열려 있어서, 컨테이너에 넣었다고 격리된 게 아닙니다. 에이전트 컨테이너는 패키지 저장소와 사내 Git처럼 필요한 도메인만 허용하는 프록시 뒤에 두세요. AWS Security Group 아웃바운드 규칙이나 Kubernetes NetworkPolicy로 시작하면 됩니다.
감시는 사람이 아니라 로그와 알림으로 합니다. 오래 도는 에이전트 작업에는 실행 시간과 호출 횟수 상한, 이상 트래픽 알림을 붙여 두는 게 현실적입니다.
망분리에 익숙한 국내 금융권·공공기관은 오히려 유리합니다. 다만 외부 AI 서비스를 위해 연 예외가 에이전트 전체 권한으로 번지지 않게 범위를 좁혀야 합니다.
벤더 검증 조언은 한계가 있습니다. 국내 기업 대부분은 프런티어 연구소의 내부 보안을 들여다볼 협상력이 없으니, 우리 쪽 경계에서 막는 설계가 가장 확실합니다.

정리

'폭주'나 '정렬 실패'라는 말 뒤에는 대개 빠진 통제가 있습니다. 사고 소식을 볼 때도, 우리 에이전트를 설계할 때도 "어떤 통제가 빠졌나"를 먼저 물으면 됩니다. 모델 성능 비교보다 "이 에이전트가 닿을 수 있는 네트워크와 권한이 어디까지인가"를 먼저 문서로 정리해 두길 권합니다.

AI 에이전트
샌드박스
이그레스 통제
사이버보안
AI 거버넌스