AI 코딩 에이전트의 보안 위험은 잘못된 코드를 만드는 데서 끝나지 않는다. 에이전트가 개발자와 같은 사용자 권한으로 실행되면 개발자가 읽을 수 있는 파일과 이미 인증된 도구에도 접근할 수 있다. 악성 패키지는 이 권한을 빌려 별도의 취약점 공격이나 권한 상승 없이 에이전트를 자격 증명 검색 도구로 이용할 수 있다.

Docker Blog가 소개한 사건은 2025년 8월 26일 npm에 배포된 악성 Nx 빌드 패키지에서 시작됐다. 감염된 릴리스에는 설치 직후 telemetry.js를 실행하는 post-install 훅이 들어 있었다. 사용자가 파일을 열거나 변경 내용을 검토하지 않아도 패키지를 받은 컴퓨터에서 코드가 실행되는 구조였다. CI 러너와 당시 Nx Console 확장 기능으로 버전 업데이트를 확인한 환경도 같은 위험에 놓였다. 해당 패키지는 출처 증명 없이 npm에 직접 배포됐다.

설치된 AI CLI를 검색 도구로 이용했다

일반적인 자격 증명 탈취 프로그램은 자체 검색기로 알려진 경로와 파일 이름을 조사한다. 이 사건의 스크립트는 컴퓨터에 이미 설치되고 인증된 AI 코딩 CLI를 찾아 검색 작업을 맡겼다. 에이전트가 개발자의 홈 디렉터리를 읽을 수 있다면 공격자는 새로운 권한을 얻지 않고도 그 접근 범위를 그대로 이용할 수 있기 때문이다.

스크립트는 Claude Code, Gemini CLI, Amazon Q 가운데 실행 가능한 도구를 확인했다. 이어 사용자 승인을 건너뛰는 옵션을 붙여 발견한 도구를 실행했다. Docker가 공개한 코드에는 Claude Code의 –dangerously-skip-permissions, Gemini CLI의 –yolo, Amazon Q의 –trust-all-tools가 등장한다. 신뢰한 작업의 반복 승인을 줄이기 위한 옵션이지만, 악성 스크립트가 이를 직접 설정하면서 중요한 확인 절차가 사라졌다.

에이전트에 전달된 지시는 홈 디렉터리 등을 깊이 8까지 탐색하고 .env, id_rsa, 키 저장소와 여러 지갑 관련 형식에 해당하는 파일을 찾아 절대 경로를 /tmp/inventory.txt에 기록하라는 내용이었다. sudo를 사용하지 말라는 지시도 포함됐다. Docker Blog는 이를 비밀번호 입력 창으로 사용자의 주의를 끌지 않으려는 행동으로 해석한다.

역할은 명확히 나뉘었다. 코딩 에이전트는 자연어 지시를 해석해 파일을 찾았고, 악성 코드는 그 결과를 이용했다. 에이전트 자체를 침해하거나 샌드박스를 탈출한 사건이 아니었다. 이미 설치되고 인증됐으며 개발자의 파일을 읽을 수 있는 도구를 승인 생략 모드로 호출한 것이다. 따라서 알려진 에이전트 취약점이 없다는 사실만으로는 이런 공격을 막을 수 없다.

‘2,900만 개’ 통계가 말하는 것

Docker Blog 원문의 ‘2,900만’은 GitGuardian의 2026년 비밀 정보 확산 보고서가 집계한 수치를 반올림한 표현이다. Docker가 인용한 결과에 따르면 2025년 공개 GitHub에 새로 올라온 하드코딩된 비밀 정보는 약 2,865만 개였고 전년보다 34% 증가했다. 같은 인용에는 AI 지원 코드의 비밀 정보 유출률이 GitHub 전체 기준선의 약 두 배라는 내용도 포함됐다.

이 통계가 모든 AI 코딩 도구와 모든 사용자에게 동일한 위험도를 뜻하는 것은 아니다. 다만 에이전트가 API 연동을 위해 프로젝트의 .env 파일을 읽으면 실제 자격 증명이 작업 문맥에 들어갈 수 있고, 이후 생성된 설정이나 테스트 fixture, 커밋에 자리표시자 대신 실제 값이 포함될 가능성이 생긴다는 점은 사건의 구조와 맞닿아 있다. 우발적 유출과 공급망 공격은 원인이 다르지만, 에이전트가 개발자의 권한으로 비밀 정보에 접근한다는 조건을 공유한다.

먼저 줄여야 할 접근 범위

  • 작업 디렉터리를 한정한다. 한 프로젝트를 처리하는 에이전트가 홈 디렉터리 전체와 다른 프로젝트의 .env, SSH 키, 클라우드 설정까지 읽을 필요는 없다.
  • 자동 승인 옵션을 제한한다. 신뢰하지 않은 저장소나 의존성 설치 과정에서는 승인 생략 옵션을 상시 적용하지 않는 편이 안전하다.
  • 실제 값과 예제를 분리한다. 저장소의 예제 환경 파일에는 실제 키 대신 빈 값이나 명확한 자리표시자를 사용한다.
  • 설치 훅을 확인한다. 예상하지 못한 lockfile 변경과 install 스크립트, 패키지 출처를 검토한다.
  • 키를 교체할 수 있게 운영한다. 노출이 의심되면 파일 삭제에 그치지 않고 해당 자격 증명을 폐기하거나 교체해야 한다.

CI 환경에서는 격리가 더 중요하다

CI는 사람이 화면을 지켜보지 않는 상태에서 의존성을 설치하고 명령을 실행하므로 post-install 훅과 비대화형 에이전트 실행이 결합되기 쉽다. 여러 작업이 러너의 홈 디렉터리나 파일 시스템을 공유하면 현재 빌드에 필요하지 않은 자격 증명도 검색 대상이 될 수 있다.

운영자는 작업마다 필요한 파일과 비밀 정보만 제공하고, 실행이 끝난 뒤 환경을 폐기할 수 있는지 확인해야 한다. 에이전트가 자동 승인 모드로 실행되는지도 점검해야 한다. 빌드에 배포 또는 관리자 권한이 필요하지 않다면 그런 자격 증명을 같은 환경에 두지 않는 것이 핵심이다. 설치 스크립트, 생성된 임시 파일, 에이전트 실행 기록을 확인할 수 있어야 사고 발생 시 영향 범위를 추적하기도 쉽다.

Docker Sandboxes를 볼 때의 핵심

Docker는 대응책으로 Docker Sandboxes를 제시하며 실행 계층에서 자격 증명을 에이전트의 접근 범위 밖에 두는 방향을 강조한다. 핵심은 에이전트에게 비밀 정보를 읽지 말라고 요청하는 데 그치지 않고, 필요한 소스와 명령만 제공되는 분리된 환경에서 실행하는 것이다. 모델의 판단이나 승인 화면에만 의존하지 않고 파일 시스템과 자격 증명의 경계를 좁히는 접근이다.

다만 제공된 자료만으로 Docker Sandboxes의 가격, 지원 운영체제, 계정 조건이나 구체적인 조직 관리 기능까지 확정할 수는 없다. 도입 전에는 호스트의 어떤 경로와 인증 정보가 전달되는지, 실제 비밀 정보가 샌드박스 안에 포함되는지 등을 공식 제품 문서에서 확인해야 한다. 제품 이름보다 에이전트가 작업 범위 밖의 자격 증명을 실제로 읽을 수 없는지가 중요한 판단 기준이다.

사고가 의심되면

문제가 된 패키지를 삭제하거나 저장소에서 값을 지우는 것만으로는 충분하지 않다. 이미 읽혔을 가능성이 있는 .env의 자격 증명, SSH 키, 클라우드 설정, npm·GitHub 토큰과 지갑 관련 키를 식별해 폐기하거나 교체해야 한다. 이어 패키지 설치 기록, CI 로그, 에이전트 실행 기록과 생성된 임시 파일을 확인하고, 같은 자격 증명이 다른 컴퓨터나 자동화 작업에도 복사돼 있는지 점검해야 한다.

이번 사건의 교훈은 특정 AI CLI 하나를 피하라는 것이 아니다. 개발자와 동일한 권한을 가진 에이전트, 승인을 생략하는 실행 옵션, 자동으로 실행되는 공급망 코드가 한 환경에 모일 때 위험이 커진다는 점이다. 가장 직접적인 방어는 필요한 프로젝트 파일만 에이전트에 제공하고 자격 증명을 실행 범위 밖에 두는 것이다.

출처와 검증

사건 날짜와 실행 흐름, 대상 AI CLI와 승인 생략 옵션, 검색 지시, 비밀 정보 통계 및 Docker의 격리 접근은 Docker Blog: Coding Agent Horror Stories: The 29 Million Secret Problem을 기준으로 정리했다. 제품의 현재 지원 범위와 조건은 실제 적용 시점의 공식 문서에서 다시 확인해야 한다.