당신의 코딩 에이전트는 당신처럼 작동합니다. 여기에 설치하는 모든 것도 마찬가지입니다.

당신의 코딩 에이전트는 당신처럼 작동합니다. 신중하게 범위가 지정된 역할을 가진 서비스 계정으로, 혹은 누군가 승인한 샌드박스 안에서 작동하지 않습니다. 당신처럼, 파일 시스템과 자격 증명(credentials), 저장소(repository) 그리고 코드를 푸시할 수 있는 능력까지 가지고 작동합니다.

이것이 바로 그것이 유용한 이유이며, 여기에 설치하는 것들이 평소보다 더 많은 검토를 받아야 하는 이유입니다. 에이전트 스킬(agent skill), 플러그인 또는 MCP 서버는 당신의 에이전트가 읽는 문서가 아닙니다. 이것은 당신이 다른 일을 하고 있는 동안, 당신의 권한을 가지고 에이전트가 따르는 일련의 지침입니다.

대부분의 사람들은 이를 앱 스토어 모델로 생각합니다. 여기서 마켓플레이스 리뷰는 누군가가 검사했다는 의미를 갖습니다. 올해 한 연구는 이러한 정신적 모델(mental model)이 실제 접촉을 겪으면 유지되지 않는다는 상당히 설득력 있는 주장을 펼쳤습니다. 저는 Ant Davis가 연구원들이 무엇을 했는지 설명하는 비디오를 통해 이 내용을 접하게 되었고, 그의 요약은 분석 전에 이야기를 듣고 싶다면 훌륭한 5분 분량입니다.

연구원들이 한 일

AIR라는 보안 회사에서 AI 에이전트 스킬을 만들었고, 설득력 있는 이름을 붙여주었으며, 사람들이 알아볼 만한 회사의 도구처럼 보이도록 꾸몄습니다. 그리고 이를 인기 마켓플레이스에 승인받게 했습니다.

그들은 이 도구를 판단하는 전문직 종사자들에게 광고를 집행했습니다.

이를 검사한 모든 스캐너들, 잘 알려진 보안 벤더들의 것들을 포함하여, 모두 깨끗하다고 보고했습니다.

그들은 맞았습니다. 그들이 본 순간에는 깨끗했습니다.

이 스킬은 문서화 링크를 참조했고, 스캐너들이 확인하는 동안 이 링크는 실제 문서를 제공했습니다. 충분한 사람들이 이를 설치하자, 연구원들은 링크 뒤에 있는 것을 변경했습니다. 이제 그것은 에이전트에게 스크립트를 다운로드하고 실행하라고 지시했습니다. 공개된 시연에서는 이메일 주소를 수집했는데, 이는 그들이 수집할 수 있었던 것의 정중한 버전이었습니다.

저는 이 연구와 함께 돌았던 설치 횟수를 의도적으로 반복하지 않습니다. 왜냐하면 이는 실험을 진행한 회사에서 자체 보고한 것이고 제가 독립적으로 확인한 적이 없기 때문입니다. 그 숫자가 핵심은 아닙니다. 중요한 것은 메커니즘이며, 이 메커니즘은 작용할 가치가 있기 위해 큰 숫자를 필요로 하지 않습니다.

스캐너가 이것을 고칠 수 없는 이유

여기서 내재화할 가치가 있는 부분이 있는데, 이는 에이전트 기술을 훨씬 넘어 일반화되기 때문입니다.

스캐너는 특정 시점의 아티팩트를 검사합니다. 파일들을 읽고 알려진 악성 행위 패턴과 일치시키며, _그 바이트들_에 대한 판결을 내립니다. 그 판결은 정확하며 과거에 관한 것입니다.

반면, 에이전트가 결국 따르게 되는 지침(instruction)은 나중에 네트워크를 통해 아티팩트가 단지 가리키는 위치에서 가져옵니다. 두 개의 다른 객체이며, 이 둘 사이에는 팀이 도구를 채택하는 데 걸린 시간과 HTTP 요청만큼의 간격이 있습니다.

보안 엔지니어링에서는 이러한 형태에 '검사 시점부터 사용 시점까지(time of check to time of use)'라는 이름이 붙어 있으며, 이는 파일 시스템 레이스 조건부터 결제 흐름에 이르기까지 모든 곳에서 나타납니다. 일반적인 형태는 간단합니다. 검증한 것과 실제로 작용하는 것이 분리되어 가져와질 때, 두 번째 것을 통제하는 사람이 첫 번째 것을 얼마나 신중하게 검증했는지와 관계없이 실제로 무슨 일이 일어날지 결정하기 때문입니다.

정적 분석(Static analysis)으로는 그 간극을 메울 수 없습니다. 도구가 약해서가 아니라, 분석되는 내용물과 실행되는 내용물이 다르기 때문입니다. 지속적으로 스캔하더라도 여전히 실패할 수 있는데, 이는 스캔과 다음 호출 사이에 교체(swap)가 발생할 수 있기 때문입니다.

실제로 위험을 줄이는 방법

교체를 신뢰성 있게 감지할 수 없으므로, 교체하는 능력을 제거하거나 교체가 할 수 있는 것을 제한해야 합니다.

출판사(publisher)와 목적지(destination)를 확인하고, 설명(description)을 믿지 마십시오. 그럴듯한 이름과 그럴싸한 문서 링크가 전체 공격의 핵심입니다. 질문은 '이것이 전문적으로 보이는가'가 아니라, '이 공급업체(vendor)가 실제로 자신이 소유한 도메인에서 이것을 게시하는가?'여야 합니다. 이 둘은 다른 질문이며, 오직 후자만이 검증 가능합니다.

사용할 패키지와 공급업체를 고정하십시오. 해당 스킬을 자신의 리포지토리로 복사하고, 그곳에서 검토한 다음, 자동적으로 업데이트하기보다는 의도적으로 업데이트해야 합니다. 사용자가 직접 검토하고 통제하는 버전은 신뢰만 한 이름과 같지 않습니다. 그리고 도구의 유지 관리자(maintainer)가 변경될 때마다, 이는 새로운 리뷰가 필요한 완전히 새로운 도구로 취급해야 합니다. 왜냐하면 공급망(supply chain) 관점에서 볼 때 정확히 그것이기 때문입니다.

불변 참조(immutable references)를 선호하십시오. 무언가를 가져와야 할 경우, 변경될 수 있는 브랜치(branch), 태그(tag) 또는 단순 URL 대신, 아래에서 변경될 수 없는 커밋 해시(commit hash)나 콘텐츠 다이제스트(content digest)로 고정해야 합니다. 이는 동일한 이유로 CI 액션(CI action)을 버전 태그가 아닌 해시로 고정하는 것과 같은 원칙입니다.

에이전트가 잃을 것이 적게 만드십시오. 프로덕션 자격 증명(production credentials)이 포함된 환경에서 에이전트를 실행하지 마십시오. 전역 설치(global installs)보다는 프로젝트별 설치(per-project installs)를 선호하여, 손상된 도구가 사용자가 작업하는 모든 것을 건드리는 대신 하나의 프로젝트에만 영향을 미치도록 하세요. 이것은 최소 권한 원칙(least privilege)을 가장 많은 팀이 아직 권한으로 실행되는 소프트웨어로 분류하지 못한 사물에 적용한 것입니다.

어디서 실행되는지에 대한 참고 사항입니다. 왜냐하면 이는 위험도를 실질적으로 변화시키기 때문입니다: 로컬 코딩 에이전트에서 실행되는 에이전트 스킬은 사용자의 기기에 있는 다른 모든 프로그램과 동일한 네트워크 및 파일 시스템 접근 권한을 가집니다. 샌드박스(Sandboxed)된 API 측 실행은 다르며 더 작은 위험 표면적(risk surface)입니다. 어느 것을 사용하는지 알아야 얼마나 신경 써야 할지 결정할 수 있습니다.

인벤토리 실행하기

조언은 싸기 때문에, 여기 점검 목록을 제공합니다.

당신은 두 가지를 알고 싶어 합니다. 설치된 모든 것에서 도달 가능한 모든 URL과 에이전트 툴링(agent tooling)이 실행하도록 구성된 모든 실행 파일입니다. 하나의 스크립트로 이루어진 appsec-protocols 저장소에서는 이를 클론한 후 다음 명령을 실행합니다:

bash ci/scripts/vet-agent-installs.sh

이 스크립트는 스킬(skill) 및 플러그인 디렉터리를 탐색하고, 심볼릭 링크된 스킬을 따라가며, 전역 구성 파일 내에 중첩된 프로젝트별 서버를 포함하여 MCP 서버 구성을 읽고 두 가지 목록을 출력합니다. 바로 URL과 각 서버의 명령어 및 그 인자들입니다.

그러면 이 출력을 읽고 모든 줄을 고려해야 합니다. 불변 참조(immutable reference)가 아니거나 번들링된 사본이 아닌 URL은 취약점(finding)입니다. 무결성 잠금(integrity-locked)되지 않은 실행 가능한 소스도 취약점입니다. 공급업체 자체 도메인에서 온 문서화 링크는 아마 괜찮을 것이고, '아마 괜찮으니 확인해봤다'라는 입장은 '전혀 확인하지 않았다'와는 물질적으로 다른 입장입니다.

이 스크립트를 만드는 과정 중 한 가지 세부 사항은 전달할 가치가 있습니다. 왜냐하면 그것은 신뢰할 수 있는 도구와 단순히 실행만 해본 도구를 구별하는 종류의 것이기 때문입니다.

그 스크립트의 출력은 AI 에이전트의 컨텍스트(context)로 바로 들어갑니다. 만약 이 구성 파일에 자격 증명(credentials)이 포함되어 있고, 그것을 출력한다면, 그 도구는 당신이 의도하지 않은 곳으로 비밀 정보(secrets)를 옮긴 것입니다. 그래서 그것은 이를 마스킹합니다. 처음에는 알려진 자격 증명 이름 목록과 일치하는 방식으로 마스킹되었는데, 이 목록은 두 번 검토를 거쳤지만 api-key에서 실패했습니다. 왜냐하면 목록에 api_key가 포함되어 있었기 때문입니다. 수정된 방식은 이름을 매칭하는 것을 멈추고 모양(shape)을 매칭하는 것으로 시작하는 것이었습니다. 즉, 이름이 자격 증명처럼 보이는 모든 파라미터와 토큰처럼 보이는 모든 값이 출력되기 전에 대체되는 것입니다.

현재는 임시 설정(throwaway configuration)에 자격 증명(credentials)을 심는 테스트가 있습니다. 제가 작성했을 때는 12가지 형태였고 오늘날은 17가지입니다. 이들 중 어느 하나라도 출력에 도달하면 실패합니다. 이전 버전의 스크립트를 실행해 보면, 12개 중 4개가 유출됩니다. 그 테스트가 제가 여러분에게 그것을 실행하라고 말할 수 있는 유일한 이유입니다.

팀이 설치하는 것을 승인하는 사람이라면

위 내용을 모두 읽지 않아도 중요한 질문들을 할 수 있습니다. 네 가지 질문입니다:

1. “우리 각자가 코딩 에이전트에 무엇을 설치했는지, 목록을 만들 수 있습니까?” 아무도 목록을 만들 수 없다면, 그것이 문제입니다. 이는 프로덕션 환경에 어떤 의존성(dependencies)이 있는지 모르는 것과 같은 문제입니다.
2. “그들 중 어느 것이 런타임 시 인터넷에서 지침을 가져옵니까?” 이것은 도구와 책임 소재가 되는 위험 요소(liability)를 구별하는 기준이며, 단일 명령으로 답할 수 있습니다.
3. “우리 에이전트는 어디서 실행되며, 실행될 때 어떤 자격 증명이 접근 가능한 상태입니까?” 프로덕션 키가 환경 변수(environment)에 있는 디렉터리에서 실행되는 에이전트는 프로덕션 키를 가진 에이전트입니다.
4. “우리가 의존하는 도구가 주인이 바뀔 때, 무슨 일이 발생합니까?” 여러분이 원하는 대답은 누군가 그것을 다시 검토해야 한다는 것입니다. 일반적인 대답은 아무도 알아차리지 않는다는 것입니다.

이 모든 것은 정책 문서(policy document)를 요구하지 않습니다. 목록의 존재와 누군가가 그것을 읽었음을 요구합니다.

한계점

이것은 특정 공급망 위험(supply chain risk)에 대한 기준선일 뿐, AI 도구에 대한 완전한 위협 모델(threat model)은 아닙니다.

이는 스킬 설명(skill descriptions)을 통한 프롬프트 인젝션이나, 전혀 아무것도 가져오지 않는 스킬에서의 악성 행위, 마켓플레이스 자체의 손상, 또는 도구가 주장하는 것과 정확히 같을 가능성과 그 작성자 계정이 다음 달에 탈취될 가능성을 다루지 않습니다. 인벤토리 스크립트는 무엇이 접근 가능하고 구성되었는지 알려줄 뿐이며, 그 이름 뒤에 있는 사람들이 신뢰할 만한 사람인지는 알 수 없습니다. 이는 여전히 명령어가 반환하지 못하는 판단 문제입니다.

이것이 제공하는 것은 당신이 한 번도 가져가지 않은 인벤토리(inventory)에 놀랄 일이 없다는 것입니다.

이는 제가 에이전트 스킬로 유지하는 보안 기준선(security baseline)의 44번째 통제 항목(control)입니다. 여기서 모든 통제 항목은 주장(claim)보다는 검증 단계(verification step)를 수반합니다. 저는 이 체크리스트가 어떻게 작동하는지에 대해 별도로 작성한 적이 있습니다. 이 내용은 공개적이며 github.com/lawalOyinlola/appsec-protocols에서 MIT 라이선스로 이용 가능합니다. 스크립트는 ci/scripts/vet-agent-installs.sh이며, 그 한계점과 다른 모든 것들의 내용은 DISCLAIMER.md에 있습니다.