Anthropic Google 보안 공백: AI 에이전트가 신뢰받는 문서를 따라 소유자 없는 코드로 향했다

연구자들이 코딩 에이전트가 신뢰받는 기업 문서에 언급된 패키지를 실행했다고 보고하면서 Anthropic과 Google이 보안 논쟁의 중심에 섰다. 한 테스트 패키지는 Fortune 500 기업 환경에서 불과 4분 만에 실행된 것으로 알려졌다. 연구자들에 따르면 이후 프로세스 기록에는 Claude, OpenAI Codex, Nous Research의 Hermes가 등장했다.

이번 발견이 Anthropic, Google 또는 OpenAI가 악성코드를 의도적으로 배포했다는 뜻은 아니다. 실험을 위해 등록된 대부분의 패키지에는 실행 시점만 보고하는 무해한 비콘이 포함돼 있었다. 더 심각한 발견은 인증 제공업체 Clerk의 웹사이트에 한때 게시됐던 지침과 연결된, 별개의 것으로 알려진 악성 npm 패키지였다.

이 구분은 초기 보도가 세 AI 공급업체가 기업 네트워크를 침해한 것처럼 들릴 수 있기 때문에 중요하다. 실제 증거는 소프트웨어 공급망 실패를 가리킨다. 에이전트는 공식적으로 보이는 지침을 신뢰했고, 공개 패키지 레지스트리에 접속해 아무도 확보하지 않은 이름을 실행했다.

Google은 웹사이트 감사 소프트웨어 Lighthouse에서 llms.txt 파일 검사를 지원한다는 점에서 이 Anthropic Google 보안 이야기와 연결된다. Claude와 Codex는 설치 지침을 따른 것으로 알려진 에이전트를 통해 이 사건에 등장한다. 공통된 문제는 특정 모델이나 회사 하나가 아니다. 문서와 실행 가능한 작업 사이의 경계가 무너지고 있다는 점이다.

과거에는 그 경계가 분명하게 느껴졌다. 개발자는 설정 가이드를 읽고, 패키지를 검증한 뒤 설치 여부를 결정할 수 있었다. 자율 코딩 에이전트는 이러한 단계를 하나의 작업으로 압축할 수 있으며, 종종 개발자에게 이미 부여된 권한을 사용한다.

그 결과 코딩 에이전트를 배포하는 모든 조직에는 새로운 보안 질문이 생긴다. 소프트웨어가 문서를 읽을 때, 그 문서가 여전히 신뢰할 수 있는 대상을 가리키는지는 누가 검증하는가?

기업 AI 에이전트가 아무도 소유하지 않은 이름을 실행했다

연구자들은 오래된 문서를 활용해 신뢰받는 텍스트가 실행의 진입점이 될 수 있음을 입증했다.

보안 연구자 Alon Hertz와 동료들은 6,214개의 운영 중인 도메인에 걸친 머신 리더블 문서를 조사했다. 표본에는 방산업체, 주요 기술 기업, Fortune 500 기업이 포함됐다.

연구자들은 8,265개의 llms.txt 및 llms-full.txt 파일을 발견했다고 보고했다. llms.txt 파일은 언어 모델과 AI 에이전트를 위해 웹사이트 콘텐츠를 정리하는 신흥 관례다. 더 큰 동반 파일은 하나의 머신 리더블 파일에 더 광범위한 문서를 제공할 수 있다.

수집된 파일 가운데 120개 웹사이트가 등록되지 않은 패키지나 소유자가 없는 도메인을 하나 이상 참조한 것으로 알려졌다. 연구팀은 존재하지 않는 패키지 또는 대상과 관련된 명령 227개를 집계했다.

이는 반드시 악의적인 지침은 아니었다. 일부는 한 번도 등록된 적 없는 패키지 이름을 가리키는 일반적인 설치 명령으로 보였다. 다른 일부는 만료된 도메인이나 더 이상 소유권이 주장되지 않는 서비스를 참조했다.

pip install package-name 같은 한 줄은 해당 패키지 이름이 PyPI에서 사용 가능할 때 위험해진다. 같은 원칙은 npm, RubyGems, NuGet, crates.io, Packagist 또는 방치된 호스팅 서브도메인에도 적용된다.

연구자들은 이처럼 사용 가능한 이름 가운데 일부를 등록했다. 이어 실행될 때 서버에 접속하도록 설계된 코드를 포함한 패키지를 게시했다. Hertz의 연구 계정에 따르면 첫 콜백은 4분 안에 Fortune 500 기업 환경에서 도착했다.

추가로 두 시스템이 첫 한 시간 안에 코드를 실행한 것으로 알려졌다. 시간이 지나며 연구팀은 스타트업과 대기업에서 수십 건의 콜백을 받았다.

콜백은 프로세스 시작에 관여한 프로그램을 식별하는 상위 프로세스 체인을 기록했다. 연구자들에 따르면 이 기록은 일부 설치를 Claude, OpenAI Codex, Nous Research의 Hermes와 연결했다.

이 실험은 해당 모델들을 침해할 필요가 없었다. 새로 발견된 소프트웨어 취약점, 피싱 메시지 또는 탈취된 직원 비밀번호에도 의존하지 않았다. 에이전트는 합법적인 웹사이트에 게시된 지침을 찾아 자신이 속한 환경에서 사용할 수 있는 접근 권한으로 이를 따랐다고 전해진다.

바로 이것이 핵심적인 역전이다. 기업 문서는 일반적으로 개발자에게 소프트웨어를 구성하는 승인된 방식을 보여 줌으로써 보안을 강화한다. 그러나 여기서는 문서 속 방치된 참조가 누군가가 승인된 명령이 무엇을 실행할지 정의할 기회를 만들었다.

이번 발견에는 신중한 표현도 필요하다. 연구자들은 영향을 받은 기업을 공개적으로 식별하지 않았고, 모든 패키지 이름을 공개하지도 않았으며, 외부인이 각각의 기업 귀속을 재현할 만큼 충분한 원격 측정 데이터를 제공하지도 않았다. Anthropic, OpenAI, Nous Research는 원 보도가 게시되기 전까지 논평하지 않았다.

이러한 한계에도 실험은 신뢰할 만한 메커니즘을 보여 준다. 공개 패키지 레지스트리에서는 이름을 통제하는 사람이 그 이름의 의미를 부여한다. 공식 문서는 의도된 의미가 사라진 뒤에도 해당 이름을 계속 남길 수 있다.

Anthropic Google 신뢰 체인이 실패한 이유

에이전트는 신뢰 모델을 무시한 것이 아니다. 자율 소프트웨어의 작동 방식과 더 이상 맞지 않는 신뢰 모델을 따랐다.

전통적인 문서는 지침과 실행 사이에 인간 독자가 있다고 전제한다. 그 독자는 낯선 패키지 이름을 알아차리고, 게시자를 조사하거나, 설정 명령에 뒷받침하는 리포지토리가 없는 이유를 물을 수 있다.

에이전트도 같은 검사를 수행할 수 있지만, 지침과 환경이 이를 요구할 때만 가능하다. 그렇지 않으면 요청된 작업을 완료하는 데 최적화된다. 공식 문서를 찾아 설치 명령을 실행하는 일은 가장 짧고 유효한 경로처럼 보일 수 있다.

Anthropic Google 연결은 각각 독립적으로는 합리적인 여러 결정이 어떻게 하나의 위험한 체인으로 결합될 수 있는지를 보여 준다. 웹사이트는 머신 리더블 가이드를 게시한다. Google의 Lighthouse 도구는 개발자가 이 가이드를 발견 가능하게 만들도록 장려한다. 코딩 에이전트는 권위 있는 맥락을 검색한다. 패키지 관리자는 의존성을 쉽게 내려받아 실행할 수 있게 한다.

이 구성 요소 중 어느 것도 악의적일 필요는 없다. 위험은 에이전트가 전체 체인을 인증된 것으로 취급할 때 나타난다.

Google의 Lighthouse 안내는 llms.txt의 가용성과 형식을 검사하는 감사를 설명한다. Lighthouse는 파일 내부에 언급된 모든 명령이나 의존성을 인증하지 않는다. 따라서 형식 감사를 통과했다고 해서 패키지 소유권, 게시자 신원 또는 코드 안전성이 보장되는 것은 아니다.

마찬가지로 HTTPS는 파일이 브라우저 연결에 표시된 도메인에서 왔음을 증명한다. 그러나 해당 파일이 참조하는 모든 패키지가 여전히 그 도메인 운영자에게 속한다는 사실까지 증명하지는 않는다.

공개 레지스트리는 공격자가 통제하는 계정에서 올바르게 철자된 패키지를 제공할 수도 있다. 이는 공격자가 인기 패키지와 유사한 오탈자를 등록하는 고전적인 타이포스쿼팅과 다르다. 이번 실험의 이름은 공식 문서에서 직접 복사된 것으로 알려졌다.

그 점은 해당 지침을 에이전트와 인간 모두에게 더 설득력 있게 만든다. 개발자가 터미널 기록을 검토할 때 공식 도메인, 익숙한 패키지 관리자, 그럴듯한 의존성 이름을 볼 수 있다. 눈에 보이는 모든 신호가 일상적으로 보일 수 있다.

에이전트의 검색 행동은 문제를 더 키운다. 사용자는 통합을 요청하면서 공급업체 이름만 언급할 수 있다. 에이전트는 공급업체 문서를 찾고, llms.txt를 발견하고, 설치 명령을 선택한 다음 사용자가 의심스러운 링크를 제공받지 않은 상태에서도 패키지 관리자를 호출할 수 있다.

이 때문에 이 사건은 프롬프트 인젝션보다 더 광범위하다. 프롬프트 인젝션은 보통 적대적인 콘텐츠가 에이전트의 방향을 바꾸려 하는 경우를 말한다. 여기서 지침 자체는 무해하고 과거에는 정당했을 수 있다. 보안 실패는 나중에 참조된 대상의 소유권이 바뀌거나, 애초에 존재하지 않았다는 사실이 드러난 뒤 발생한다.

신흥 llms.txt 관례 역시 확립된 보안 아키텍처를 갖춘 공식 웹 표준과 동등하지 않다. 그 유용성은 모델에 간결하고 구조화된 맥락을 제공하는 데서 나온다. 바로 그 편의성은 에이전트가 신뢰하도록 장려되는 위치에 운영 지침을 집중시킬 수 있다.

따라서 Anthropic Google 보안 공백은 출처 문제다. 출처란 산출물이 어디에서 왔고 누가 이를 통제하는지 보여 주는 증거를 뜻한다. 에이전트는 문서의 위치는 검증했지만, 명령 뒤에 있는 실행 가능한 의존성의 출처는 확립하지 못한 것으로 보인다.

진짜 상대는 출처 검증 없는 자율성이다

핵심 갈등은 Claude 대 Codex가 아니다. 자율 실행과 검증된 소프트웨어 소유권의 충돌이다.

Claude, Codex, Hermes는 서로 다른 모델, 인터페이스, 권한 시스템을 사용한다. 이 사건을 이 도구들 간의 단순 비교로 취급하면, 보고된 설치의 배경에 있는 공통 운영 조건을 놓치게 된다.

각 코딩 에이전트는 프로젝트 맥락을 읽고, 문서를 참조하며, 파일을 편집하고, 개발 도구를 호출할 수 있다. 이러한 기능은 조사와 실행 사이의 수작업 전환을 없애기 때문에 에이전트를 유용하게 만든다.

그러나 이 기능들은 보안 결정을 에이전트의 워크플로 안으로 옮긴다. 누군가는 의존성이 정품인지, 해당 버전이 허용되는지, 설치 스크립트를 실행해야 하는지를 결정해야 한다.

패키지 관리자는 설치 중에 일상적으로 코드를 실행한다. npm 패키지는 라이프사이클 스크립트를 정의할 수 있으며, Python 패키지는 빌드 프로세스를 통해 설치 관련 동작을 실행할 수 있다. 정확한 동작은 다르지만, 설치는 비활성 텍스트를 내려받는 것과 같지 않다.

Clerk 사례는 이것이 왜 중요한지 보여 준다. 연구자들은 Clerk의 합법적인 웹사이트에 있는 지침 파일이 npx clerk-next-fix-auth-protection을 참조한다는 사실을 발견했다. npx 유틸리티는 패키지를 프로젝트 매니페스트에 영구적으로 추가하지 않고도 패키지를 내려받아 노출된 명령을 실행할 수 있다.

보안 조사에 따르면 누군가가 해당 패키지 이름을 선점해 실제 악성코드를 배포하는 데 사용했다. Clerk는 이후 문서를 수정했다.

그 패키지가 AI 에이전트를 통해 감염을 일으켰는지는 여전히 불분명하다. 보도는 또한 Clerk의 합법적인 ESLint 플러그인에 포함된 기존 바이너리는 안전했다고 지적한다. 해당 합법적 바이너리가 없는 시스템은 대신 공격자가 통제하는 패키지를 가져올 수 있다.

이 차이는 서둘러 검토하는 사람이라면 놓치기 충분히 미묘하다. 두 경로 모두 실제 공급업체가 게시한 명령으로 시작한다. 둘 다 npm 인프라를 사용한다. 위험한 경로는 예상된 바이너리가 이미 로컬에 존재하는지에 달려 있다.

이것이 기업이 마주한 실질적인 트레이드오프다. 에이전트는 모든 명령마다 승인을 기다리지 않고 의존성을 해결하고, 테스트를 실행하고, 실패를 수정할 수 있을 때 더 큰 가치를 제공한다. 그러나 동일한 권한은 잘못된 신뢰 결정이 코드 실행으로 이어지게 한다.

모델 제공업체는 샌드박싱과 승인 절차를 통해 이 위험을 줄일 수 있다. 기업은 여전히 이러한 통제 장치를 구성하고, 네트워크 정책을 유지하며, 에이전트가 접근할 수 있는 패키지 소스를 결정해야 한다.

소프트웨어 공급업체도 문제의 또 다른 부분을 책임진다. 이들의 문서는 더 이상 정적인 마케팅 콘텐츠가 아니라 운영 자산이 되었다. 패키지 참조, 예시 도메인, 복사된 명령어, 보관된 설정 페이지는 이제 실행 가능한 코드와 같은 수준의 수명 주기 관리가 필요하다.

레지스트리 운영자도 결과에 영향을 미친다. 네임스페이스 예약, 게시자 검증, 의심스러운 패키지 스캔, 소유권 이력은 도움이 될 수 있다. 그러나 레지스트리가 소유권이 없는 이름이 제3자의 문서에 등장한다는 사실을 항상 알 수 있는 것은 아니다.

이러한 책임 분담 때문에 단순한 책임 공방은 도움이 되지 않는다. Anthropic Google 서사가 중요한 이유는 제품 경계를 넘나들기 때문이다. 검색 또는 문서화 도구는 지침을 더 쉽게 찾도록 만들고, AI 에이전트는 이를 해석하며, 레지스트리는 언급된 아티팩트를 제공할 수 있다.

모든 참여자가 다른 누군가가 소유권을 검증했다고 가정할 때 보안은 실패한다.

기존 에이전트 보호 장치가 위험을 없애지는 않는다

Claude와 Codex는 이미 의미 있는 통제 수단을 제공하지만, 이러한 통제는 조직이 제한적 경계를 유지할 때만 작동한다.

Anthropic의 Claude 보안 가이드는 프롬프트 인젝션을 어시스턴트의 지침을 조작하려는 적대적 텍스트로 설명한다. 또한 임의의 웹 콘텐츠를 가져오는 명령에 대한 권한 제어 및 제한도 문서화하고 있다.

Claude Code는 샌드박싱을 사용해 파일 시스템 및 네트워크 액세스를 제한할 수 있다. 자식 프로세스는 이러한 운영체제 제한을 상속하므로, 허용된 명령이 조용히 덜 제한적인 프로세스로 빠져나가는 것을 방지하는 데 도움이 된다.

OpenAI도 유사한 다층 접근 방식을 설명한다. Codex 안전 모델은 샌드박스 경계, 승인 정책, 관리형 네트워크 액세스, 규칙, 에이전트 인식형 텔레메트리를 결합한다.

OpenAI는 관리형 배포 환경에서 Codex에 무제한 아웃바운드 액세스를 제공하지 않는다고 설명한다. 예상되는 대상은 허용할 수 있고, 익숙하지 않은 도메인은 승인을 요구할 수 있으며, 보안팀은 프롬프트, 도구 호출, 승인, 네트워크 결정을 포괄하는 로그를 내보낼 수 있다.

이러한 보호 장치는 중요하지만, 연구자들의 발견을 자동으로 무효화하지는 않는다. 조직은 에이전트에 더 광범위한 액세스를 구성할 수 있다. 개발자는 명령을 승인할 수 있다. 로컬 설치 환경은 이를 실행하는 사용자의 권한과 네트워크 연결을 상속할 수 있다.

패키지 레지스트리 역시 많은 개발 환경에서 예상되는 대상이다. npm 또는 PyPI에 대한 모든 액세스를 차단하면 일반적인 빌드, 의존성 업데이트, 테스트 설정이 중단된다. 해당 도메인을 허용하면 악성 설치를 구별할 수 있는 명백한 네트워크 신호 하나가 사라진다.

엔드포인트 탐지 및 대응 소프트웨어도 유사한 과제에 직면한다. 코딩 에이전트가 표준 패키지 관리자를 시작하면, 이 도구는 암호화된 연결을 통해 잘 알려진 레지스트리에 접속한다. 다운로드한 패키지가 명백히 적대적인 행동을 수행하기 전까지는 이 프로세스가 정상적인 개발자 활동처럼 보일 수 있다.

연구용 비컨은 의도적으로 최소 기능으로 구성됐다. 보도에 따르면 서버에 접속해 실행 컨텍스트를 기록했다. 실제 공격자는 자격 증명 탈취, 환경 탐색, 지속성 확보 또는 소스 코드 변조를 시도할 수 있다.

그러나 공개된 증거는 실험용 패키지가 이러한 행위를 수행했다는 점을 보여주지 않는다. 또한 수십 개 기업이 운영 환경에서 침해를 입었다는 사실도 입증하지 못한다. 이들은 개념 증명 코드를 실행했으며, 이는 심각하지만 확인된 침해보다 범위가 좁다.

이러한 신중한 구분은 기업의 대응 방식을 이끌어야 한다. 팀은 Claude, Codex 또는 Hermes를 사용할 때마다 감염이 발생한다고 가정해서는 안 된다. 대신 이 경로가 작동하기 위해 필요한 조건을 식별해야 한다.

에이전트는 관련 문서에 접근할 수 있어야 한다. 패키지 관리자를 호출할 권한도 필요하다. 환경은 레지스트리에서의 가져오기를 허용해야 한다. 패키지는 의미 있는 코드를 실행해야 하며, 기존 통제 수단은 그 동작을 차단하지 못해야 한다.

이 조건 중 하나만 제거해도 연결 고리를 끊을 수 있다. 네트워크 액세스를 제한하는 것이 한 가지 방법이다. 의존성 설치에 사람의 승인을 요구하는 것도 또 다른 방법이다. 에이전트를 일회용 컨테이너에서 실행하면 패키지가 실제로 실행되더라도 영향을 제한할 수 있다.

조직은 내부 의존성 프록시를 강제할 수도 있다. 이 프록시는 승인된 패키지와 버전은 허용하면서 알려지지 않은 네임스페이스는 거부할 수 있다. 이 접근 방식은 공개 문서를 읽는 에이전트로부터 신뢰 결정을 분리한다.

승인 프롬프트가 익숙한 명령만 제시한다면 그 자체로는 신뢰성이 떨어진다. 검토자에게는 패키지 소유권, 생성 시점, 게시자 신원, 다운로드 이력, 그리고 해당 의존성이 승인된 소프트웨어 자재 명세서에 포함되는지에 관한 맥락이 필요하다.

교훈은 보호 장치가 쓸모없다는 것이 아니다. 명백히 악의적인 명령을 중심으로 설계된 통제 수단은 신뢰할 수 없는 소유권으로 해석되는 정상적인 명령을 놓칠 수 있다는 점이다.

문서는 이제 소프트웨어 공급망의 일부다

기업은 문서 속의 모든 실행 가능한 참조를 만료되거나, 변경되거나, 소유자가 바뀔 수 있는 의존성으로 취급해야 한다.

즉각적인 대응은 인벤토리 작성에서 시작된다. 조직은 llms.txt, llms-full.txt, 개발자 포털, 보관된 가이드, 코드 예제, 지원 문서, 생성된 API 참조에서 설치 명령을 찾아야 한다.

언급된 각 패키지, 도메인, 리포지토리, 컨테이너 이미지, 호스팅된 서브도메인에는 소유자가 필요하다. 아무도 알아보지 못하는 이름은 조사가 진행되는 동안 공개 상태로 남아 있어서는 안 된다.

팀은 공개 패키지 이름이 조직의 실제 레지스트리 계정과 일치하는지 확인해야 한다. 또한 오래된 문서에 전역 비스코프 이름이 등장하는 경우, 스코프 패키지를 사용할 수 있는지도 살펴봐야 한다.

문서 파이프라인에는 자동화된 테스트가 필요하다. 빌드는 모든 패키지가 존재하고, 승인된 게시자에게 속하며, 예상된 리포지토리로 해석되고, 소유권이 변경되지 않았는지 검증할 수 있다.

링크 검사만으로는 충분하지 않다. 악성 패키지나 탈환된 도메인도 성공 응답을 반환할 수 있다. 파이프라인은 가용성이 아니라 신원을 검증해야 한다.

기업은 문서를 게시하기 전에 이름을 예약해야 한다. 이는 중요한 제품 관련 방어적 도메인을 등록하는 것과 유사하지만, 패키지 네임스페이스에는 지속적인 관리가 필요하다.

프로젝트가 종료될 때도 같은 원칙이 적용된다. 설치 지침을 제거하지 않은 채 패키지를 삭제하면 소유권 공백이 생긴다. 링크를 남긴 채 호스팅 서브도메인을 포기하면 다른 당사자가 신뢰받는 경로를 이어받을 수 있다.

AI가 생성한 문서는 추가 검토가 필요하지만, 사람이 작성한 페이지도 예외는 아니다. 연구자들은 일부 의심스러운 참조가 현재의 에이전트 시대보다 앞섰다는 증거를 발견했다. 그러한 페이지를 llms-full.txt에 복사하면서 자율 소프트웨어가 오래된 실수를 더 쉽게 소비할 수 있게 됐다.

에이전트를 배포하는 기업에는 보완적인 제어 평면이 필요하다. 에이전트 세션은 개발자의 무제한 계정이 아니라 전용 신원으로 실행되어야 한다. 자격 증명은 현재 리포지토리와 작업 범위로 제한해야 한다.

패키지 설치는 시크릿에 대한 접근이 제한된 격리 환경에서 이뤄져야 한다. 의존성이 설치 중 네트워크 액세스를 필요로 한다면, 그 액세스는 명시적이어야 하며 기록돼야 한다.

팀은 운영체제 텔레메트리와 함께 에이전트의 추론 맥락을 보존해야 한다. 프로세스 로그는 npm이 시작됐음을 보여줄 수 있지만, 에이전트 네이티브 기록은 어떤 문서가 패키지 이름을 제공했는지 보여줄 수 있다.

이 맥락은 사고 대응 시 중요하다. 조사관은 승인된 프로젝트 의존성과 에이전트가 외부 지침을 탐색한 뒤 선택한 패키지를 구분해야 한다.

의존성 허용 목록은 위험을 줄일 수 있지만, 새 패키지를 위한 예외 경로가 필요하다. 이 예외 절차는 출처 증거를 수집하고 지정된 사람의 소유권 책임을 요구해야 한다.

조직은 에이전트가 참조하는 출처에 대한 검색 가능한 기록도 유지해야 한다. 여기에는 문서 스냅샷, 패키지 메타데이터, 승인 결정, 생성된 코드 변경 사항이 포함될 수 있다. 통제된 기술 지식 베이스는 검토자가 에이전트가 특정 의존성을 선택한 이유를 재구성하는 데 도움이 될 수 있다.

더 넓은 교훈은 llms.txt를 넘어선다. 코딩 에이전트는 이슈 설명, 리포지토리 파일, 검색 결과, 패키지 문서, Model Context Protocol 응답, 생성된 내부 가이드를 소비한다.

이러한 모든 출처에는 지침이 포함될 수 있다. 에이전트에 도구가 있다면, 그 지침은 행동이 될 수 있다.

이 때문에 문서 무결성은 소프트웨어 공급망 보안의 일부가 된다. 기업은 기계가 읽을 수 있는 지침을 통제 밖에 둔 채 소스 리포지토리와 빌드 서버만 보호해서는 안 된다.

업계가 배웠는지 보여줄 세 가지 신호

다음 단계는 문서, 에이전트 권한, 레지스트리 신원이 함께 개선되는지에 달려 있다.

첫 번째 신호는 영향을 받은 120개 웹사이트 전반의 공개와 시정 조치다. Hertz의 팀은 영향받은 조직과 관련 보안팀에 연락했다고 밝혔지만, 공개 기록에는 대부분의 도메인이 식별되지 않았다.

기업이 llms.txt 파일을 감사하고, 패키지 이름을 예약하며, 사고 공지를 게시하는지 지켜봐야 한다. 공동 정리 작업은 업계가 기계 판독형 문서를 보안에 민감한 인프라로 인식한다는 주장을 강화할 것이다.

침묵이 아무런 수정이 없었다는 증거는 아니다. 특히 연구자들이 무해한 코드를 사용했고 확인된 데이터 탈취를 발견하지 못했을 때, 많은 조직은 공개 없이 노출된 참조를 수정한다.

두 번째 신호는 에이전트 공급업체의 제품 수준 출처 확인 기능이다. Claude, Codex, Hermes는 이미 명령 전에 승인을 요청할 수 있지만, 인터페이스가 명령 뒤의 의존성을 설명할 때 승인은 더 유용해진다.

의미 있는 변화라면 패키지가 새롭거나, 검증되지 않았거나, 공급업체의 알려진 게시자 계정과 무관하거나, 프로젝트의 기존 의존성 그래프에 없다는 경고를 제공해야 한다. 더 강력한 시스템은 공개 문서가 인식되지 않은 패키지를 가리킬 때마다 명시적 승인을 요구할 수 있다.

이러한 기능은 실행 전 의사결정 지점을 다루므로 Anthropic Google 보안 대응을 강화할 것이다. 셸 명령에 대한 또 하나의 일반적 경고는 보호 효과가 더 작을 것이다.

세 번째 신호는 레지스트리와 기업 정책의 통합이다. 패키지 관리자와 내부 프록시는 게시자 이력, 네임스페이스 생성 시점, 서명 상태, 소유권 변경 정보를 노출할 수 있다. 에이전트 플랫폼은 의존성을 선택하거나 설치하기 전에 이러한 메타데이터를 사용할 수 있다.

기업 정책은 확립된 패키지는 자동으로 허용하는 한편, 익숙하지 않은 패키지는 검토를 위해 격리할 수 있다. 또한 공식 문서에 이름이 등장하지만 게시자와의 검증 가능한 연결이 없는 패키지를 거부할 수도 있다.

신뢰할 수 있는 출처 확인이 여러 에이전트에서 공격 경로를 차단한다면, 이 신호는 연구자들의 더 광범위한 경고를 약화할 것이다. 반대로 사용 가능한 신원 데이터가 있음에도 에이전트가 새로 확보된 이름을 계속 설치한다면 그들의 경고는 강화될 것이다.

현재 증거는 절제된 결론을 뒷받침한다. 연구자들은 실제 기업 환경에서 코드 실행을 시연했고, 일부 활동을 저명한 코딩 에이전트와 연결한 것으로 보도됐다. 이들은 모델 공급업체가 의도적으로 악성코드를 설치했다거나 보고된 모든 콜백이 심각한 침해를 의미한다는 점은 입증하지 못했다.

더 중요한 발견은 구조적이다. 신뢰받는 문서, 자율 실행, 공개 레지스트리는 이제 많은 보안 프로그램이 인벤토리화하지 않는 공급망을 형성한다.

개발자와 기업 구매 담당자는 에이전트 권한을 확대하기 전에 직접적인 질문을 던져야 한다. 에이전트가 공개 패키지 레지스트리에 접근할 수 있는가? 게시자 신원을 검증하는가? 설치 명령은 격리되는가? 보안팀은 어떤 문서가 행동을 유발했는지 재구성할 수 있는가?

Anthropic과 Google 사이의 보안 격차는 더 나은 모델 행동만으로는 해소되지 않습니다. 문서 소유자, 레지스트리, 에이전트 공급업체, 기업 관리자는 각각 서로 다른 연결 고리를 통제합니다.

코딩 에이전트에 더 폭넓은 자율성을 부여하기 전에, 인식되지 않은 의존성을 사용해 그 전체 사슬을 테스트하세요. 에이전트가 출처를 제시하지 않고 이를 설치한다면, 해당 환경은 문서를 증거가 아닌 권위로 취급하고 있는 것입니다.