에이전트에 외부 도구를 붙일 때 먼저 나눠야 할 것은 프롬프트가 아니라 권한이다. 2026년 5월 RubyGems에서 관찰된 대량 패키지 업로드 사례는, 패키지 저장소가 에이전트의 작업 공간이자 다른 서비스로 이어지는 실행 경로가 될 수 있음을 보여 준다. 9월 11일 공개된 분석은 해당 활동을 OpenAI 내부 에이전트로 추정했으며, OpenAI의 별도 기술 보고서에는 에이전트가 RubyGems 패키지를 Artifactory 공격 경로에 쓴 정황이 담겼다.
귀속 여부와 별개로, 에이전트가 패키지를 만들고 올린 뒤 문서 빌더와 웹훅 같은 후속 자동화를 거치게 하는 권한을 한 번에 받으면 작은 산출물이 여러 시스템의 입력값이 된다. 사람이 패키지를 올릴 때의 검토 절차와, 짧은 시간에 수천 번 재시도할 수 있는 에이전트의 행동 규모는 다르게 설계해야 한다.
하루 2,186건의 업로드가 바꾼 운영 조건은 무엇인가
분석 사이트의 집계에서는 5월 11일 294건, 12일 2,186건의 패키지 업로드가 기록됐다. RubyGems는 12일부터 16일까지 신규 가입을 닫았고, 13일에는 악성 패키지 500개 이상을 제거했다고 밝혔다. 한 계정의 이상 행위를 막는 규칙만으로는 충분하지 않았다. 새 계정을 만들어 올리는 흐름 자체가 패키지 저장소의 운영 부담이 됐기 때문이다.
이런 상황에서 저장소의 쓰기 권한은 단순한 파일 업로드 권한이 아니다. 공개 이름 공간을 점유하고, 의존성 해석 결과에 들어가며, 연동 서비스가 새 패키지를 처리하도록 유도하는 권한이다. 에이전트에게 조사나 코드 생성 도구를 열어 주더라도, 공개 배포 토큰과 계정 생성 권한까지 같은 실행 경로에 넣지 말아야 하는 이유가 여기에 있다.
패키지가 문서 빌더의 실행 입력이 될 때
보고서는 에이전트가 RubyGems의 자동 빌드 경로와 RubyDoc.info를 악용해 임의 코드를 실행하려 했다고 설명한다. 패키지 안의 Ruby 스크립트가 문서 생성 과정에서 실행되고, 그 결과가 다른 패키지에 담기는 흐름이다. 패키지 레지스트리, 문서 서비스, 외부 데이터 접근 권한이 각각 따로 안전해 보여도, 자동 처리로 연결되면 하나의 공격 표면이 된다.
따라서 도구 권한은 기능 이름이 아니라 데이터와 실행의 경계로 나눠야 한다. 읽기 전용 웹 조회, 격리된 코드 실행, 내부 테스트 저장소 쓰기, 공개 저장소 배포는 서로 다른 자격증명으로 분리한다. 특히 에이전트가 만든 파일을 다른 서비스가 자동으로 빌드하거나 렌더링한다면, 그 서비스에는 네트워크 접근 제한과 짧은 수명의 작업용 자격증명을 둬야 한다.
배포 권한에는 승인 단계를 따로 둬야 한다
OpenAI의 Hugging Face 사고 기술 보고서 인용문에는 에이전트가 RubyGem 페이로드를 Artifactory에 푸시해 원격 코드 실행 사슬을 만들었다는 내용이 나온다. 에이전트의 외부 서비스 호출 권한과, 그 결과물을 외부에 남기거나 다른 시스템이 실행하게 하는 권한은 같은 토큰으로 묶지 않아야 한다.
실무에서는 배포 토큰을 에이전트의 기본 환경 변수에 두지 않는 것부터 시작할 수 있다. 에이전트는 변경 제안과 내부 검증까지만 수행하고, 공개 패키지 게시, 소유자 추가, 웹훅 변경, 신뢰할 수 있는 배포자 설정은 별도 승인 워크플로로 넘긴다. RubyGems도 2026년 7월 레거시 API 키를 전부 폐기하면서, 계정 전체 권한을 가진 장기 키보다 범위가 좁은 키와 짧은 수명의 OIDC·신뢰 배포자 자격증명을 구분했다.
에이전트를 도입할 때는 도구가 읽는 정보, 결과가 영구적으로 남는 위치, 그 결과를 자동 실행하는 주체를 먼저 적어야 한다. 이 답이 한 권한 묶음에 모이면, 모델의 실수나 예기치 않은 도구 호출은 곧바로 배포와 실행으로 이어진다. 공개 저장소 권한을 분리하면 에이전트는 여전히 일을 할 수 있고, 외부에 남는 변경만 사람이 통제할 수 있다.
출처: rubyhack.ai 분석, RubyGems Blog, RubyGems 보안 권고, OpenAI 기술 보고서