이 소식은 무엇인가요?
배경부터 차근차근 살펴보기
최근 자율 AI 에이전트가 급속도로 발전하면서 선한 목적(자동 테스트, 코드 검토)의 활용 외에 악의적 사용의 위험도 실질화되고 있습니다. 2026년 9월 이를 보여주는 구체적 사건이 발생했습니다.
자율 해킹 에이전트 'Strix'가 머신러닝 플랫폼 Baseten을 공격해 자격증명이나 소스 코드 없이 약 25분 만에 프로덕션 환경의 GitHub 관리자 권한을 발견했습니다. 에이전트가 자동으로 접근 경로를 단계적으로 탐색해 최종 목표에 도달한 사례입니다.
Strix가 사용한 침입 지점은 공개된 Harbor 컨테이너 레지스트리였습니다. 인증 없이 내려받을 수 있는 이미지들로부터 내부 저장소의 접근 정보를 추출했고, 이를 발판으로 더 높은 권한으로 단계적으로 상승했습니다.
이 사건은 개발 인프라의 여러 계층(컨테이너 레지스트리, 내부 저장소, API 토큰, GitHub 권한)이 어떻게 연결되어 있으며 한 곳의 보안 설정 오류가 전체 시스템을 위험에 빠뜨릴 수 있는지를 보여줍니다. 클라우드 서비스 사용자나 자동화 도구 도입을 고려하는 일반 조직도 주목할 필요가 있습니다.
공식 발표에서 확인된 내용
구체적으로 무엇이 달라졌나
- 01
자율 에이전트는 초기 자격증명 없이 공개 자료(컨테이너 이미지)로부터 시스템 내부의 접근 경로를 자동으로 탐색할 수 있습니다.
- 02
25분이라는 시간은 단계적 침투를 자동으로 완료하는 에이전트의 속도를 보여줍니다. 각 단계를 수동으로 진행했다면 훨씬 오래 걸릴 과정입니다.
- 03
공개된 컨테이너 레지스트리가 침투의 시작점이 되었으며, 보안 설정 오류 하나가 더 높은 권한으로의 상승을 초래했습니다.
- 04
최종 목표인 GitHub 관리자 토큰은 향후 저장소 수정, 배포 자동화 설정 변경, 추가 시스템 침투 등 더 심각한 피해로 이어질 수 있습니다.
- 05
에이전트는 프로덕션 환경(실제 운영 중인 시스템)에 직접 접근했으므로 단순 테스트 환경의 침투가 아닙니다.
사용자에게 미치는 영향
누구에게 어떤 의미가 있나
클라우드 서비스 사용 개발팀과 운영팀
자신의 팀이 사용하는 클라우드 서비스의 컨테이너 레지스트리, API 토큰, GitHub 권한 설정을 종합적으로 검토해야 한다는 판단이 생깁니다. 공개되어도 되는 것과 반드시 보호해야 할 것을 명확히 구분하고 접근 권한을 최소화해야 합니다.
AI 자동화 도구 도입을 고려하는 조직
자동화 도구나 에이전트에 부여하는 권한의 범위를 신중하게 설정해야 한다는 인식이 생깁니다. 도구가 실제 필요한 작업만 수행하도록 권한을 제한하고 주기적으로 사용 로그를 검토하는 정책이 필수입니다.
개인 개발자
GitHub, AWS, Azure 등에서 발급한 개인 API 토큰과 액세스 키의 권한 범위를 점검해야 한다는 실감이 생깁니다. 필요 이상의 광범위한 권한을 가진 토큰은 삭제하거나 권한을 제한하는 것이 중요합니다.
실제 활용 장면
어디에 어떻게 써볼 수 있나
조직의 보안 담당자가 컨테이너 레지스트리 공개 상태 점검
Harbor, AWS ECR, Docker Hub 등의 컨테이너 레지스트리에서 인증 없이 접근할 수 있는 이미지가 있는지 확인하고 필요에 따라 접근 권한을 제한합니다.
- 예를 들면
- AWS ECR 콘솔 → 각 Repository 선택 → Permissions 탭에서 'Principal'이 '*'로 설정되어 있지 않은지 확인하거나, Harbor 관리자 페이지에서 Project의 공개 여부 확인
- 확인할 결과
- 공개되어서는 안 되는 내부 이미지를 발견하면 접근 권한을 'Private'으로 변경하고 필요한 팀원만 액세스할 수 있도록 설정
개발팀 리더가 팀 멤버의 API 토큰 권한 감시
팀 멤버에게 발급한 GitHub, AWS 액세스 토큰이 각각 어떤 권한을 가지고 있는지 검토하고 필요 이상의 권한은 제거합니다.
- 예를 들면
- GitHub Settings → Developer settings → Personal access tokens에서 각 토큰의 scopes를 확인 (예를 들어 특정 저장소만 수정 권한, 전체는 읽기만 가능 등으로 제한되어 있는지 확인)
- 확인할 결과
- 모든 저장소 수정 권한이나 조직 전체 관리 권한을 가진 토큰을 발견하면 해당 권한을 제거하거나 새로 발급해 필요한 권한만 부여
개인 개발자의 개인 API 키 정기 점검
개인이 사용하는 클라우드 서비스의 API 키와 액세스 토큰 목록을 정기적으로 검토하고 불필요한 것은 삭제합니다.
- 예를 들면
- AWS IAM 콘솔에서 과거 프로젝트용 Access Key를 찾아 더 이상 사용하지 않는 Key는 삭제하고, 현재 사용 중인 Key의 권한이 필요한 수준(예: 'AmazonS3ReadOnly')으로 제한되어 있는지 확인
- 확인할 결과
- 사용하지 않는 토큰/키를 제거하고 남은 토큰들이 각각 필요한 최소 권한만 가지도록 조정
직접 적용해 보기
처음부터 무리하지 말고, 이 순서로 확인하세요
1단계: 현재 권한 구조 이해하기
자신이나 팀이 사용하는 클라우드 서비스의 공식 문서에서 권한 관리 방식을 학습합니다. GitHub의 token scope, AWS의 IAM policy, Azure의 role-based access control 등 각 서비스별로 어떻게 권한을 설정하고 제한하는지 확인합니다.
확인: 각 서비스의 공식 보안 가이드에서 '최소 권한 원칙(Principle of Least Privilege)' 또는 '권한 최소화'를 찾아 읽었는가?
2단계: 현재 발급된 토큰/키 목록 만들기
GitHub, AWS, Azure, Docker Hub 등에서 발급한 모든 API 토큰과 액세스 키의 목록을 스프레드시트에 정리합니다. 각 항목마다 발급일, 마지막 사용일, 부여된 권한, 사용 용도를 기록합니다.
확인: 생각보다 많은 토큰이 발급되어 있지는 않은가? 사용하지 않는 오래된 토큰(1년 이상 미사용)이 있는가?
3단계: 권한 범위 검토 및 조정
목록의 각 토큰이 실제 필요한 권한만 가지고 있는지 확인합니다. 전체 저장소 접근, 조직 전체 관리, 계정 삭제 권한 등 과도한 권한을 찾아 해당 서비스에서 권한을 제한하거나 새로 발급합니다.
확인: 위험한 권한(조직 관리, 전체 저장소 접근, 계정 설정 변경 등)을 찾았는가? 현재 실제 업무에 필요한 최소 권한으로 변경했는가?
4단계: 불필요한 토큰 제거
더 이상 사용하지 않는 프로젝트나 인원을 위해 발급한 토큰을 각 서비스에서 삭제합니다. 삭제 전에 해당 토큰이 현재 작동 중인 자동화 파이프라인(CI/CD, 정기 배치 작업 등)에서 사용 중이지 않은지 최종 확인합니다.
확인: 삭제할 토큰이 현재 실제로 실행 중인 자동화 작업에 사용되고 있지는 않은가?
5단계: 정기 점검 일정 수립
이 과정을 분기마다(3개월마다) 반복하도록 달력에 일정을 등록합니다. 팀인 경우 보안 담당자가 주도하고 모든 팀원이 참여하는 방식으로 진행하며, 점검 결과와 조정 사항을 기록해 둡니다.
확인: 다음 분기 점검 날짜가 업무 달력에 입력되었는가? 반복되는 일정으로 설정했는가?
해석할 때 주의할 점
확인된 범위와 아직 모르는 내용을 구분하세요
공식 원문에서 확인되는 사실은 다음과 같습니다. 자율 해킹 에이전트 Strix가 Baseten을 공격했고, 자격증명이나 소스 코드 없이 약 25분 만에 GitHub 관리자 권한을 보유한 유효한 토큰을 발견했으며, Harbor 컨테이너 레지스트리의 공개 이미지로부터 접근했다는 점입니다. 아직 공개되지 않은 내용은 다음을 포함합니다. Baseten의 구체적인 보안 결함이 무엇인지, 기업이 취한 보안 대응 조치, 영향받은 고객 또는 데이터의 범위, 이 사건이 권한을 받은 침투 테스트였는지 무단 침투였는지의 법적 상황, 다른 클라우드 서비스의 유사 취약점 여부, Strix의 상용화 상태와 접근성입니다.
- Baseten이 이 사건의 기술 분석 자료나 보안 패치 내용을 공식 발표하지 않아 구체적인 시스템 결함이 무엇인지 알 수 없습니다. 따라서 다른 클라우드 서비스도 같은 방식으로 공격받을 수 있는지 불명확합니다.
- Strix의 구체적인 프롬프트, 추론 단계, 사용한 보안 우회 기법이 공개되지 않아 비슷한 공격을 예방하기 위한 구체적인 방어 대책을 수립하기 어렵습니다.
- 이 침투가 권한을 받은 보안 테스트(Red Team 테스트)였는지 무단 침투였는지 법적 상황이 명확하지 않아 사건의 전체 맥락을 정확히 파악할 수 없습니다.
- AWS, Google Cloud, Azure 등 다른 주요 클라우드 플랫폼도 유사한 공격에 취약한지는 아직 알려지지 않았습니다. Baseten이 특정 설정 오류를 가지고 있었던 것인지 일반적인 위험인지 구분이 필요합니다.
- Strix 같은 자율 해킹 에이전트가 실제로 상용 서비스로 이용 가능한지, 학술 연구 수준인지, 누구나 사용할 수 있는 수준인지 알 수 없어 이 위협의 즉각성을 판단하기 어렵습니다.
출처와 확인일
원문에서 다시 확인하기
이 글은 GeekNews의 공식 발표를 바탕으로 정리했습니다. 기능 범위와 제공 조건은 바뀔 수 있으므로 실제로 적용하기 전에는 원문을 다시 확인해 주세요.
- 마지막 확인
- 2026-09-15
- 다음 검토
- 2026-10-15