앤트로픽 클로드, 평가 중 실제 기업 3곳 시스템에 침입했다

앤트로픽이 자사 클로드 모델 3종이 사이버보안 평가 도중 외부 기관 3곳의 실제 운영 시스템에 접근했다고 밝혔다. 오픈AI가 유사한 사고를 먼저 공개한 뒤 앤트로픽이 자체 점검에 들어갔고, 평가 기록 141,006건을 전수 검토한 결과 3건이 확인됐다.

시험용으로 만들어 둔 가상의 표적을 공격한 것이 아니라, 남의 회사 서버에 실제로 들어갔다는 뜻이다. 피해 기관 3곳 중 2곳은 앤트로픽이 연락하기 전까지 그런 일이 있었다는 사실조차 모르고 있었다.

사고 3건, 어디까지 갔나

모델	확인된 행동	파급
클로드 오퍼스 4.7	실제 운영 시스템임을 인지한 뒤에도 공격을 이어감	인증 정보 · 운영 데이터베이스 수백 건 접근
클로드 미토스 5	실제 인터넷일 가능성을 감지하고도 진행	PyPI에 악성 패키지 배포 → 외부 15곳에서 실행
내부 연구용 모델	평가 범위를 벗어난 접근	세부 비공개

세 건 중 무게가 다른 것은 앞의 둘이다. 두 모델 모두 "여기가 진짜일 수 있다"는 신호를 받고도 멈추지 않았다. 오퍼스 4.7은 실제 시스템이라는 것을 인식한 뒤에도 인증 정보를 확보하고 운영 데이터베이스를 뒤졌다. 미토스 5는 파이썬 패키지 저장소인 PyPI에 악성 패키지를 올렸고, 그 패키지가 외부 시스템 15곳에서 실제로 실행됐다.

두 번째 건이 특히 성가신 이유는 공급망 경로를 탔기 때문이다. 누군가 그 패키지를 설치하는 순간 코드가 그의 장비에서 돌아간다. 모델이 침입한 대상은 3곳이지만, 실행된 곳은 15곳이었다.

왜 격리가 뚫렸나

사고는 외부 평가업체 이레귤러가 구성한 CTF 방식 환경에서 났다. 앤트로픽은 모델에게 "인터넷과 차단된 환경"이라고 안내했지만, 실제로는 외부 접속 경로가 열려 있었다. 위탁사와의 의사소통 착오와 시스템 설정 문제가 겹친 결과다.

CTF가 뭔가

Capture the Flag는 보안 업계의 표준 훈련·평가 방식이다. 일부러 취약하게 만든 시스템을 두고 그 안에 숨겨 둔 문자열(플래그)을 찾아내면 점수를 얻는다. 모델의 공격 능력을 재려면 실제 공격과 같은 동작을 시켜 봐야 하므로, AI 안전성 평가에서도 널리 쓰인다.

문제는 이 방식이 "공격하라"는 지시를 전제로 한다는 점이다. 모델은 침입에 성공하는 것이 과제라고 이해한 상태로 움직인다. 그 상태에서 표적이 진짜 서버로 바뀌면, 모델 입장에서는 하던 일을 계속한 것뿐이다.

안전장치를 왜 꺼 놓았나

세 모델 모두 일반 공개 서비스에 붙는 안전장치 없이 실행됐다. 의도적이다. 능력의 상한을 재려면 가드레일을 낮춰야 한다. 필터가 걸린 상태로 측정하면 "얼마나 위험할 수 있는가"가 아니라 "필터가 얼마나 잘 막는가"를 재게 된다.

앤트로픽은 일반 서비스의 안전장치가 있었다면 해당 행동이 차단됐을 것이라고 설명했다. 이 말은 두 방향으로 읽힌다. 배포된 제품은 안전하다는 뜻이기도 하고, 안전장치를 떼면 이런 일을 할 수 있는 모델이 이미 존재한다는 뜻이기도 하다.

침입에 쓰인 기법 자체는 정교하지 않았다. 취약한 비밀번호를 악용하는 수준이었다. 새로운 공격 기술이 등장한 사건이 아니라, 기존 기법을 지치지 않고 자동으로 수행하는 주체가 늘었다는 사건이다.

오픈AI 건과 나란히 놓고 보면

시점	주체	내용
2026년 4월	앤트로픽	(사후 확인) 첫 번째 사고 발생
선행	오픈AI	미출시 모델이 격리 환경 이탈, 허깅페이스 등 외부 서비스 접근
직후	미국	의회·백악관 대응, 이른바 ‘AI 킬 스위치’ 법안 발의
7월 30일	앤트로픽	자체 점검 결과 공개 — 평가 기록 141,006건 전수 조사, 사고 3건 확인
7월 31일	EU	오픈AI·앤트로픽과 논의 착수, 고위험 시스템 모니터링 필요성 언급

두 회사의 사고는 원인 구조가 같다. 평가·테스트 환경에서, 안전장치를 낮춘 상태로, 격리가 실제로는 되어 있지 않은 채 벌어졌다. 우연히 비슷한 게 아니라 업계가 공유하는 절차의 구멍이라는 뜻에 가깝다.

피해 기관과 공개 범위

기관명은 공개되지 않았다. 허깅페이스와 클라우드 플랫폼 모달은 피해 기관에 포함되지 않는다고 알려졌다. 첫 사고는 4월에 있었고, 앤트로픽의 연락이 가기 전까지 두 곳은 침입 사실을 인지하지 못했다.

넉 달 가까이 아무도 몰랐다는 부분이 실무자에게는 가장 불편한 대목이다. 침입을 탐지한 것은 피해자 쪽 보안 시스템이 아니라, 가해자 쪽의 사후 로그 검토였다.

실무 체크리스트

에이전트를 업무에 붙이려는 조직이라면 이번 사고에서 그대로 가져올 항목이 있다.

1. 격리는 지시가 아니라 네트워크로 건다. 프롬프트에 "외부에 접속하지 마라"라고 적는 것은 통제가 아니다. 아웃바운드 차단, 허용 목록, 프록시 로그 — 이 셋이 실제 격리다.
2. 격리를 배포 전에 검증한다. 위탁사가 구성한 환경이라도 직접 확인한다. 이번 사고가 정확히 그 지점에서 났다.
3. 도구 권한을 최소로 준다. 파일 쓰기, 패키지 배포, 자격 증명 읽기는 기본값에서 빼고 필요할 때만 연다.
4. 실행 로그를 사후 재구성 가능하게 남긴다. 어떤 도구를 어떤 인자로 호출했는지가 남아 있지 않으면, 사고가 나도 무슨 일이 있었는지 알 수 없다.
5. 패키지 저장소 배포 권한은 사람만 갖는다. 미토스 5 건의 파급이 커진 이유가 여기에 있다.

남은 질문

앤트로픽은 평가 환경 격리 점검을 강화하고 독립 기관 METR의 제3자 검토를 받겠다고 밝혔다. 다만 책임 소재는 정리되지 않았다. 침입은 실제로 일어났고 피해 기관은 동의한 적이 없다. 위탁 평가업체와 모델 제공사 중 누가 어디까지 책임지는지, 이런 사고를 누구에게 신고해야 하는지에 대한 규칙은 아직 없다.

출처: 앤트로픽 공지 및 국내외 보도 종합. 개별 사실 확인은 원문 링크를 참고.