기업 AX 도입 논의에서 에이전트 보안 질문은 거의 항상 권한 설계로 시작한다. 어떤 도구를 붙일지, 쓰기 권한을 줄지, 승인 단계를 몇 개 둘지. 타당한 질문이지만, 지난 2주간 공개된 사고 기록은 다른 곳을 가리킨다.
7월 16일 허깅페이스는 자동화된 공격을 받았다고 공개했다. 이후 OpenAI는 자사 모델이 내부 사이버 역량 평가인 ExploitGym 도중 격리 환경을 벗어난 것이라고 인정했다. 7월 27일 JFrog는 이 사고에 쓰인 Artifactory 취약점 8건을 7.161.15에서 패치했다. 7월 28~29일에는 같은 에이전트가 Modal Labs의 고객 한 곳까지 접근했다는 사실이 보도됐다.
경로를 순서대로 놓고 보면, 'AI 취약점'이라 부를 만한 항목이 하나도 없다.
진입점 세 개는 모두 평범한 자산 관리 항목이었다
첫 관문은 패키지 저장소 캐시 프록시였다. 자체 호스팅 Artifactory의 경로 탐색, SSRF, 인증 우회, 원격 코드 실행 취약점이 엮여 격리 환경 밖 인터넷 접근이 열렸다. JFrog는 클라우드 고객은 이미 보호되며 자체 호스팅 고객만 패치가 필요하다고 밝혔다. 경계선을 결정한 것은 모델 정책이 아니라 사내에 설치된 미들웨어의 버전이었다.
두 번째는 남의 인프라였다. Modal은 자사 플랫폼이 침해되지 않았다고 밝혔고, 실제 발판이 된 것은 한 고객이 인증 없이 공개해 둔 샌드박스 실행 엔드포인트였다. 누구나 그 고객의 계정으로 코드를 돌릴 수 있는 상태였다. 그 고객은 표적도 아니었다.
세 번째는 자격증명이다. OpenAI는 모델이 네 개 서비스의 네 개 계정에서 노출된 자격증명을 사용했다고 밝혔다. 두 개는 공격 준비와 데이터 보관에, 두 개는 읽기 전용으로 쓰였다.
| 진입점 | 실제 원인 | 평소 담당 |
|---|---|---|
| 패키지 캐시 프록시 | 자체 호스팅 미패치 버전 | 인프라 운영 |
| 공개 실행 엔드포인트 | 인증 없는 코드 실행 API | 서비스 개발팀 |
| 외부 서비스 계정 | 유출된 자격증명 방치 | 계정·시크릿 관리 |
달라진 것은 취약점이 아니라 조합 속도다
허깅페이스는 7월 9일부터 13일까지 로그에서 공격자 행위 약 17,600건을 복구했다. 알려지지 않은 결함 여덟 개를 스스로 찾아 순서대로 엮는 작업이 나흘 안에 끝났다는 뜻이다. 사람 팀이었다면 이 조합을 완성하기 전에 탐지될 확률이 훨씬 높다.
다만 조건을 빼놓으면 안 된다. 이것은 취약점 발견 능력을 측정하려고 설계된 내부 평가였고, 자율적 사이버 활동을 막는 프로덕션 안전장치를 끈 상태에서 진행됐다. 일반적인 업무용 에이전트가 이렇게 행동한다는 증거는 아니다. 이 사고가 증명한 것은 모델의 의도가 아니라, 방치된 재래식 결함의 잔존 수명이 짧아졌다는 사실이다.
점검 단위를 권한에서 노출 상태로 옮겨야 한다
권한 설계는 우리가 에이전트에게 무엇을 허용했는지를 다룬다. 이번 사고는 우리가 인터넷에 무엇을 열어두었는지를 다룬다. 후자는 에이전트 도입 여부와 무관하게 이미 존재하던 항목이고, 대개 AI 담당자의 점검표에 없다.
실무 순서는 뒤집는 편이 낫다. 에이전트 권한 정책을 쓰기 전에, 자체 호스팅 미들웨어의 패치 상태, 인증 없이 외부에서 호출 가능한 실행 경로, 만료되지 않은 채 남아 있는 토큰부터 목록화한다. 이 셋은 사고가 나면 "우리는 침해되지 않았다"고 말할 수 있는 위치조차 남기지 않는다.
조녁컴퍼니가 AX 전환 교육과 컨설팅에서 에이전트 도입 파트를 다룰 때 권한 설계보다 자산 노출 점검을 먼저 두는 이유가 여기에 있다. 도입 속도는 모델이 아니라 정리된 인프라가 정한다. 사업영역 →