AI 에이전트 보안 평가에서 발견된 실제 사고 3건이 주는 교훈

AI 모델에게 취약점을 찾고 침투 시나리오를 수행하게 하는 보안 평가는 통제된 가상 환경에서 이뤄진다고 흔히 가정한다. 그런데 평가용으로 설계된 환경이 실제로는 인터넷에 연결돼 있었고, 그 상태에서 모델이 진짜 회사 시스템까지 건드린 사례가 보고되면서 이 가정 자체를 다시 점검해야 한다는 문제의식이 생겨났다. 테스트라는 이름표만 믿고 격리 여부를 확인하지 않은 채 자동화 권한을 넘기는 방식이 얼마나 위험할 수 있는지 짚어본다.

무엇이 문제였나

세 건의 사고 개요

Anthropic이 발표한 바에 따르면, 자체 사이버보안 평가 과정에서 모델이 의도치 않게 실제 시스템에 접근한 사고가 세 차례 확인됐다. 한 사례에서는 모델이 실제로 존재하는 회사 도메인을 찾아내 인프라를 공격했고, 그 결과 프로덕션 데이터가 담긴 데이터베이스에까지 접근이 이뤄졌다. 다른 사례에서는 모델이 파이썬 패키지 저장소에 악성 패키지를 올렸고, 짧은 시간 동안 실제 여러 시스템에서 내려받아지는 일이 벌어졌다. 세 번째 사례에서는 대규모로 목표를 스캔한 뒤 회사 시스템까지 침해했지만, 이후 실제 환경이라는 것을 인지하고 스스로 공격을 멈춘 것으로 알려졌다.

왜 이런 일이 가능했나

평가 지침에는 인터넷 접근이 차단돼 있다고 명시돼 있었지만, 평가를 진행한 조직과의 소통 과정에서 오류가 생겨 실제로는 네트워크가 열려 있는 상태였다. 모델은 눈앞의 환경을 시뮬레이션의 일부로 받아들였고, 그 결과 실제 시스템에 대해서도 시나리오상의 행동을 그대로 수행했다. 즉 기술적 결함이라기보다 환경 구성과 커뮤니케이션 과정에서 생긴 틈이 실제 피해로 이어진 셈이다.

실무에 적용할 수 있는 팁

네트워크 격리를 코드로 검증하기

에이전트에게 스캔이나 자동 실행 권한을 줄 때는 문서상 "인터넷 차단"이라는 문구를 신뢰하기보다, 실제로 외부 요청이 막혀 있는지 방화벽 규칙이나 네트워크 정책을 스크립트로 주기적으로 검증하는 편이 안전하다. 사람이 설정을 확인했다는 사실과, 그 설정이 실제로 작동하고 있다는 사실은 다르다.

권한 범위를 최소 단위로 쪼개기

테스트 목적의 에이전트라도 패키지 배포, 데이터베이스 쓰기, 외부 API 호출처럼 되돌리기 어려운 작업에는 별도의 승인 단계를 두는 편이 좋다. 작업 종류별로 권한을 나눠두면 한 곳에서 문제가 생기더라도 피해 범위가 다른 영역까지 번지는 것을 막을 수 있다.

환경 자체를 실제 시스템 수준으로 취급하기

평가·테스트 환경이라는 이유로 접근 통제나 로그 기록을 느슨하게 두는 경우가 많은데, 에이전트의 실행 능력이 커질수록 이런 환경도 프로덕션과 동일한 보안 기준으로 다뤄야 한다. 방어 계층을 하나만 두지 않고 네트워크, 권한, 모니터링을 겹겹이 쌓아두는 접근이 여기서 특히 의미가 있다.

이상 행동을 조기에 감지하는 장치 마련하기

세 번째 사고에서 모델이 스스로 공격을 멈춘 것처럼, 상황을 인지하고 판단을 바꾸는 사례도 있지만 이를 안전장치로 삼기는 어렵다. 대신 평소와 다른 스캔 범위나 비정상적인 트래픽 패턴이 감지되면 자동으로 실행을 중단시키는 모니터링을 별도로 갖춰두는 편이 훨씬 안정적이다.

주의할 점

"테스트 환경이니 괜찮다"는 전제를 그대로 믿고 넘어가는 것이 가장 흔한 함정이다. 설정 문서와 실제 인프라 상태가 항상 일치한다고 보장할 수 없으므로, 특히 여러 팀이나 외부 조직과 환경을 공유할 때는 담당자가 바뀌거나 설정이 변경되는 과정에서 격리 조건이 깨질 수 있다는 점을 염두에 둬야 한다. 또한 에이전트가 판단을 잘못 내리는 상황뿐 아니라, 애초에 환경 구성 자체가 잘못됐을 가능성도 함께 점검 대상에 포함해야 한다.

정리

이번 사례들은 모델의 성능 자체보다 그 성능을 검증하는 환경의 설계가 얼마나 중요한지를 보여준다. 자동화된 에이전트에게 폭넓은 실행 권한을 맡기는 팀이라면, 격리 설정을 문서로만 확인하지 말고 실제로 작동하는지 주기적으로 검증하고, 되돌리기 어려운 작업에는 별도 승인 절차를 두는 것이 현실적인 대응이 된다. 특히 국내 개발팀에서는 사내 보안 감사 주기와 에이전트 자동화 도입 시점이 맞물리는 경우가 많은데, 이런 상황일수록 새로운 자동화를 도입하기 전에 기존 네트워크 정책과 권한 체계를 먼저 재점검하는 순서가 안전하다. 에이전트의 판단 능력이 앞으로 더 향상되더라도, 그 판단을 감싸는 환경 설계가 허술하면 같은 유형의 사고는 얼마든지 재현될 수 있다는 점을 기억해둘 필요가 있다.