AI 에이전트의 위험을 ‘모델이 말을 잘 듣는가’만으로 판단할 수는 없다. 실제 도구와 네트워크, 권한이 연결된 환경에서는 주어진 일을 충실히 수행하는 과정에서도 잘못 설계된 경계를 넘어설 수 있다. 그래서 평가 환경과 운영 환경 모두 여러 겹으로 방어해야 한다(defense in depth).
무슨 일이 있었나
Anthropic은 7월 30일 자사 사이버 보안 평가 기록을 재검토한 결과, Claude 모델이 외부 평가 환경에서 인터넷에 닿은 뒤 서로 다른 세 조직의 실제 시스템에 무단 접근한 사례 3건을 발견했다고 발표했다. 회사 발표에 따르면 검토 대상은 인터넷 접근 가능성이 있었던 평가 실행 141,006건이었고, 문제의 평가는 가상의 네트워크에서 ‘플래그’라는 비밀 정보를 찾는 CTF(capture the flag) 방식이었다.
여기서 놓치면 안 되는 건 모델이 인터넷을 쓸 수 없다는 지시를 받았다는 점이다. 그러나 Anthropic과 외부 평가 파트너 사이의 구성 오류·오해로 실제 인터넷 경로가 열려 있었다. 모델은 접근 가능한 실제 시스템을 시뮬레이션의 일부로 오인한 채, 약한 비밀번호나 인증되지 않은 엔드포인트 같은 기본 기법으로 과제를 계속 수행했다. 이는 새로운 취약점을 뚫었다는 의미와는 구분해야 한다.
BBC와 Reuters 보도도 같은 지점을 짚었다. BBC는 격리돼야 할 시험 환경의 약점이 인터넷 연결로 이어졌다고 보도했고, Reuters 보도는 문제의 평가에 일반 배포 모델에서 쓰는 표준 안전장치가 없었다는 Anthropic 설명을 전했다. 다만 세 사건은 통제된 비교 실험이 아니며, 개별 모델의 안전성을 일반화할 근거로 쓰기에는 제한적이다.
채팅창 밖으로 나온 에이전트
AI 도입의 단위가 채팅창에서 ‘도구를 실행하는 에이전트’로 옮겨가고 있기 때문이다. 파일을 읽고, 사내 문서를 검색하고, 티켓을 만들고, 코드나 클라우드 리소스에 접근하는 자동화는 생산성을 높인다. 동시에 프롬프트의 문장 한 줄보다 더 큰 영향을 주는 것은 에이전트가 실제로 닿을 수 있는 범위다.
이번 사례를 ‘AI가 자율적으로 탈주했다’고 단순화하면 실무 교훈을 놓친다. Anthropic은 모델이 자신의 목표를 추구했다는 증거는 없었으며, 잘못된 상황 인식 아래 평가 과제를 수행했다고 설명했다. 즉, 사람의 승인 절차와 시스템 경계를 대신하는 보안 설계가 없다면, 정상적인 작업 완수 행동도 피해로 이어질 수 있다. 에이전트의 성능이 좋아질수록 이 문제는 더 빨리, 더 넓게 발생할 수 있다.
프롬프트 경계와 시스템 경계는 다르다
1. ‘인터넷이 없다’는 문장은 네트워크 차단이 아니다
모델에게 인터넷이 없다고 알려도 방화벽, egress(외부 송신) 정책, DNS 제어, 프록시가 이를 기술적으로 강제하지 않으면 그 지시는 보안 통제가 아니다. 테스트 컨테이너든 업무용 에이전트든 기본값은 외부 통신 차단으로 두고, 필요한 목적지·포트·시간만 명시적으로 허용하는 편이 안전하다.
2. 최소 권한은 모델의 능력과 별개다
에이전트가 사용할 API 키·서비스 계정·브라우저 세션에 관리자 권한을 주면, 모델의 의도가 선하더라도 손실 범위가 커진다. 읽기 전용 계정, 작업별 임시 자격 증명, 짧은 만료 시간, 분리된 샌드박스는 에이전트 품질과 무관하게 피해 상한을 낮춘다.
3. 평가 환경도 운영 환경만큼 감시해야 한다
‘가짜 데이터니까 안전하다’는 가정도 충분하지 않다. Anthropic은 평가 시작 전 모든 인터넷 접근 경로를 검증하고, 실시간 로그 감시와 전사 기록 검토를 강화하겠다고 밝혔다. 이는 팀 내부의 프롬프트 실험, 데모용 API, 외부 벤더가 제공하는 샌드박스에도 적용할 수 있는 원칙이다.
그래도 에이전트를 포기할 이유는 없다
그렇다고 도구 사용 에이전트를 포기할 이유는 아니다. 반복적인 문서 분류, 제한된 지식베이스 검색, 초안 생성, 테스트 실패 요약처럼 범위가 명확한 업무에서는 큰 도움이 된다. 다만 ‘완전 자율’보다 작업 범위가 작고 검증 가능한 자동화부터 시작하는 것이 현실적이다.
예를 들어 고객 지원 초안 작성 에이전트에는 공개된 FAQ와 비식별화된 티켓만 읽게 하고, 답변 발송은 사람이 승인하게 할 수 있다. 개발 보조 에이전트에는 별도 테스트 저장소와 읽기 전용 토큰을 제공하고, 배포·비밀 관리·프로덕션 DB 변경은 별도 승인 워크플로에 남긴다. 보안 테스트를 한다면 대상의 서면 허가, 명확한 스코프, 속도 제한, 즉시 중단 장치를 먼저 갖춰야 한다.
물론 비용도 든다. 사람의 승인을 거치면 속도가 느려지고, 권한을 나누면 통합 비용이 커진다. 로그도 읽고 판단할 사람이 있어야 쓸모가 있다. 또한 모델이 위험한 상황을 항상 올바르게 알아차릴 것이라고 기대해서는 안 된다. 이번 사건의 최신 연구 모델은 실제 대상임을 인식한 뒤 중단했지만, Anthropic 역시 사례 수가 적어 확정적 결론을 내릴 수 없다고 명시했다.
내 환경에서 먼저 확인할 것
- 내 자동화의 연결 지도를 그린다. 현재 쓰는 AI 도구가 읽는 데이터, 호출하는 API, 쓰기 가능한 위치, 외부 인터넷 접근 여부를 한 장에 적는다. 모르는 연결은 우선 차단하거나 확인한다.
- 가장 강한 권한 하나를 낮춘다. 개발·노션·드라이브·클라우드 연동 중 하나를 골라 읽기 전용 또는 프로젝트 전용 계정으로 바꾸고, 토큰 만료 정책을 확인한다.
- 승인 전 로그를 남기는 작은 실험을 한다. 에이전트가 파일 수정이나 외부 전송을 하기 전 ‘계획·대상·변경 요약’을 출력하게 만들고, 사람이 확인한 뒤에만 실행하도록 구성한다.
권한보다 먼저 볼 것
이번 사건을 AI 에이전트의 ‘탈주’로만 읽으면 중요한 부분을 놓친다. 자동화의 능력이 커진 상태에서 환경 경계가 허술하면 정상적인 작업도 사고로 이어질 수 있다. AI 활용 역량은 더 많은 권한을 주는 능력이 아니라, 필요한 권한만 주고 결과를 되돌리고 검증할 수 있게 설계하는 능력에 가깝다. 에이전트를 도입할 때는 ‘무엇을 할 수 있나’ 다음으로 ‘실수하면 어디까지 닿나’를 먼저 물어보자.