AI 에이전트 설정 보안은 공급망 보안이에요

2026년 4월 29일, 보안 팀들은 손상된 SAP 생태계 패키지가 자격 증명 탈취에서 멈추지 않았다고 보고했어요. Mini Shai-Hulud 캠페인은 개발자 설정에도 지속성을 심었어요. 대상에는 Claude Code 후크, VS Code 작업, 저장소 워크플로 파일이 포함됐어요.¹²³

이 세부 사항은 검토 경계를 바꿔요. 오염된 패키지가 개발자가 신뢰하는 파일에 시작 명령을 남길 수 있다면, 그 패키지는 계속 설치되어 있을 필요가 없어요. 의존성을 제거하면 첫 번째 실행 계기는 사라질 수 있어요. 하지만 에이전트나 에디터 설정이 다음 실행 계기를 계속 살려둘 수 있어요.

AI 에이전트 설정은 실행 가능한 소프트웨어예요. 모든 후크, 작업, MCP 서버 정의, 스킬, 플러그인, 패키지 스크립트, 워크플로 파일을 소프트웨어 공급망의 일부로 다뤄야 해요. 이 파일들은 사람이 diff를 읽기 전에 어떤 코드가 실행될지 결정할 수 있기 때문이에요.

요약

Mini Shai-Hulud는 의존성 설치에서 개발자 도구의 지속성으로 이어지는 현실적인 경로를 보여줬어요. 보안 연구자들은 악성 npm 패키지가 설치 중 생명주기 스크립트를 사용해 개발자와 CI 자격 증명을 수집하고, 신뢰받는 개발자 표면에서 코드를 다시 실행하도록 .claude/settings.json과 .vscode/tasks.json 파일을 작성했다고 보고했어요.¹²⁴ 공식 문서도 이런 표면에 실제 실행 권한이 있다는 점을 확인해요. Claude Code 후크는 생명주기 명령을 실행하고 명령 후크는 사용자의 권한으로 실행돼요. VS Code의 folderOpen 작업도 사용자가 해당 폴더의 자동 작업을 허용하면 폴더를 열 때 실행될 수 있어요.⁵⁶

교훈은 “에이전트를 꺼라”가 아니에요. 더 정확한 교훈은 에이전트 설정이 의존성 검토, 코드 검토, 사고 대응, 릴리스 관문 안에 들어가야 한다는 점이에요. 예전에는 로컬 취향처럼 보였던 점 디렉터리가 이제 실행 경로 위에 있어요. 진지한 AI 엔지니어링 실무에는 설정 diff, 후크 검토, 작업 검토, 최소 권한 토큰, 시작 표면 감사가 필요해요.

핵심 요점

개발자에게: - 저장소를 신뢰하기 전에 .claude/settings.json, .vscode/tasks.json, .github/workflows/*, package.json 스크립트, MCP 설정, 에이전트 플러그인이나 스킬 매니페스트를 검토하세요. - 새 시작 후크와 폴더 열기 작업은 새 실행 파일처럼 다루세요. - 의심스러운 설치 후에는 지속성 파일을 제거하고 자격 증명을 교체하세요. 패키지 제거만으로 정리가 끝났다고 볼 수는 없어요.

보안 팀에게: - 에이전트 설정 파일을 공급망 탐지, CODEOWNERS, 비밀 대응, 사고 범위 산정에 포함하세요. - 시작 시 실행, 넓은 범위의 셸 명령, 불투명하게 다운로드된 바이너리, 숨겨진 점 디렉터리 페이로드를 추가하는 PR을 표시하세요. - 수명이 짧은 게시 자격 증명과 읽기 전용 설치 자격 증명을 선호하세요. 오래 유지되는 쓰기 토큰은 여전히 웜의 연료가 돼요.

에이전트 플랫폼 제작자에게: - 실행 표면을 눈에 보이고, 검토 가능하고, 설명 가능하게 만드세요. - 맥락을 불러오는 후크와 명령을 실행하는 후크를 분리하세요. - 시작 동작, 외부 네트워크 호출, 수정된 설정을 사용자가 한눈에 감사할 수 있는 보기를 제공하세요.

Mini Shai-Hulud가 바꾼 것

패키지 매니저를 겨냥한 공급망 공격은 이미 익숙한 패턴을 따라요. 신뢰받는 패키지에 악성 버전이 올라와요. 설치 스크립트가 실행돼요. 페이로드가 토큰을 훔쳐요. 레지스트리 차단이나 버전 롤백은 이미 일부 개발자와 CI 작업이 나쁜 버전을 설치한 뒤에 도착해요.

Mini Shai-Hulud는 여기에 에이전트 시대에 더 특화된 단계를 추가했어요. Endor Labs, Wiz, Socket, StepSecurity, Cloud Security Alliance의 보고서는 모두 같은 큰 흐름을 설명해요. SAP 개발자 생태계의 손상된 패키지가 npm 설치 시 실행을 사용했고, GitHub, npm, 클라우드, CI 자격 증명을 수집했으며, 개발자 도구 설정을 통해 지속성을 만들었어요.¹²³⁴⁷

Wiz는 향후 Claude Code 또는 VS Code에서 저장소를 열 때 실행이 다시 일어날 수 있도록 저장소에 파일을 배치하는 우회 경로를 문서화했어요.² Endor Labs는 Claude Code SessionStart 후크와 runOn: "folderOpen"이 있는 VS Code 작업을 설명했어요.¹ Socket의 캠페인 추적기는 npm 및 PyPI 패키지 손상과 함께 .claude/settings.json 및 .vscode/tasks.json을 통한 지속성을 나열해요.³

정확한 페이로드는 일반 엔지니어링 글이 아니라 사고 보고서에 속해요. 오래 남는 교훈은 여기에 있어요.

목표는 하나의 패키지 버전에서 그 패키지 주변의 개발자 환경으로 이동했어요.

설정 파일은 시작 프로그램이 됐어요

Claude Code의 후크 참조 문서는 후크가 생명주기 이벤트에서 자동으로 실행되는 사용자 정의 셸 명령, HTTP 엔드포인트, 또는 LLM 프롬프트라고 설명해요.⁵ 같은 문서는 SessionStart가 Claude Code가 작업 맥락을 시작하거나 재개할 때 실행된다고 말해요. 보안 섹션은 명령 후크가 사용자의 전체 권한으로 실행된다고 경고해요.⁵

VS Code 작업 문서는 또 다른 실행 표면을 제공해요. 작업은 runOn을 folderOpen으로 설정할 수 있고, 사용자가 해당 폴더의 자동 작업을 허용하면 VS Code는 포함된 폴더가 열릴 때 그 작업을 실행해요.⁶ 그 동의 프롬프트는 중요해요. 모든 기계에서 조용히 실행되는 경우보다 위험을 낮춰요. 하지만 파일이 무해해지는 것은 아니에요. 신뢰받는 저장소, 지친 개발자, 이미 허용된 워크스페이스, 조직 정책은 여전히 설정 변경을 코드 실행으로 바꿀 수 있어요.

npm은 설치 시점의 다리를 놓아요. npm 스크립트 문서는 npm ci와 npm install에서 실행되는 생명주기 스크립트 목록에 preinstall, install, postinstall을 포함해요. npm의 모범 사례 섹션은 대상 아키텍처 컴파일을 제외하면 작성자가 preinstall 또는 install 스크립트를 명시적으로 설정할 일이 거의 없어야 한다고 말해요.⁸

이 세 가지 사실이 공격 사슬을 만들어요.

1. 의존성 설치 중 설치 스크립트가 실행돼요.
2. 그 스크립트가 개발자 도구 설정을 작성하거나 패치해요.
3. 이후 에디터나 에이전트가 설정된 시작 동작을 실행해요.
4. 프롬프트나 UI가 평소 작업처럼 보이기 때문에 개발자는 도구 표면을 신뢰해요.

위험한 것은 특정 기능 하나가 아니에요. 설치 스크립트, 후크, 작업, 워크플로는 모두 정당한 자동화를 지원해요. 위험한 부분은 신뢰의 전이예요. 패키지 설치가 앞으로 모든 에이전트 작업 맥락이나 폴더 열기에서 무엇을 실행할지 조용히 정의해서는 안 돼요.

검토 경계가 잘못됐어요

대부분의 코드 검토 습관은 소스 파일을 주요 산출물로 보고 설정 파일은 보조 자료로 여겨요. 설정 파일이 명령을 실행할 수 있을 때 이 습관은 실패해요.

새 후크는 새 셸 스크립트와 같은 수준으로 검토해야 해요. 새 작업은 새 바이너리와 같은 수준으로 검토해야 해요. 새 MCP 서버는 새 네트워크 연동과 같은 수준으로 검토해야 해요. 새 패키지 생명주기 스크립트는 테스트 전에 실행되는 새 코드와 같은 수준으로 검토해야 해요.

검토 표를 사용하세요.

도구가 붙은 에이전트를 위한 실행 중 방어는 집행이 도구 호출 경계에 있어야 한다고 주장했어요. Mini Shai-Hulud는 같은 기준을 한 층 더 앞당겨요. 시작 경계에도 집행이 필요해요.

시작 권한에는 최소 권한이 필요해요

팀들은 이미 API 키에 최소 권한을 적용해요. 에이전트 설정에도 같은 규칙이 필요해요.

Claude Code는 PreToolUse, PostToolUse, SessionStart 같은 후크 이벤트를 분리해요.⁵ 이 분리는 정책을 구성하는 기준이 되어야 해요. 정적 맥락을 불러오는 후크에는 셸 접근이 필요하지 않아야 해요. 명령을 검증하는 후크에는 네트워크 접근이 필요하지 않아야 해요. 로컬 메타데이터를 기록하는 후크에는 자격 증명이 필요하지 않아야 해요.

같은 규칙은 VS Code 작업과 CI 워크플로에도 적용돼요.

npm의 신뢰할 수 있는 게시 문서는 수명이 짧은 자격 증명이 왜 중요한지 설명해요. 신뢰할 수 있는 게시는 OIDC를 사용하므로 오래 유지되는 npm 토큰 없이 패키지를 게시할 수 있어요. npm은 신뢰할 수 있는 게시자가 설정된 뒤에는 전통적인 토큰 기반 게시를 허용하지 않도록 권장해요.⁹ npm은 게시에 OIDC를 사용할 때 비공개 의존성을 설치하려면 읽기 전용 세분화 접근 토큰을 쓰라고도 권장해요.⁹

이 조언이 워크플로 위험을 없애지는 않아요. 손상된 워크플로는 권한이 너무 넓으면 여전히 피해를 줄 수 있어요. 교훈은 양쪽을 모두 줄이라는 거예요. 수명이 짧은 자격 증명과 좁은 워크플로가 함께 필요해요.

에이전트 설정을 의존성처럼 다루세요

의존성 검토는 보통 어떤 패키지 버전이 바뀌었는지 물어요. 에이전트 시대의 검토는 어떤 실행 표면이 바뀌었는지 물어야 해요.

의존성 업데이트, 플러그인 설치, 생성된 설정, 템플릿 변경을 받아들이기 전에 다음을 확인하세요.

요점은 편집증이 아니에요. 범주를 정확히 보는 거예요. 후크 파일은 설정처럼 보일 수 있지만 코드처럼 동작해요. 작업 파일은 에디터 설정처럼 보일 수 있지만 셸을 시작할 수 있어요. 워크플로는 릴리스 배관처럼 보일 수 있지만 자격 증명에 닿을 수 있어요.

AI 에이전트 안전은 작은 소프트웨어에서 시작돼요는 설계 측면에서 비슷한 주장을 했어요. 좁은 도구에는 실수가 숨을 곳이 더 적어요. 보안 관점에서는 좁은 설정에 지속성이 숨을 곳이 더 적다고 말할 수 있어요.

안전한 설정 점검

방어적 검토는 의심스러운 코드를 실행할 필요가 없어요. 읽기 전용 검사부터 시작하세요.

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

이 명령들은 기계가 깨끗하다는 것을 증명하지 않아요. 설정을 실행으로 바꿀 가능성이 큰 표면을 검토자가 먼저 훑어보게 해줘요. 의심스러운 설치가 이미 일어났다면, 깨끗한 검색 결과를 보증으로 여기지 말고 사고 대응으로 넘어가야 해요.

복구에는 설정 점검이 필요해요

손상된 의존성에 대한 사고 대응은 패키지를 제거하는 데서 멈추면 안 돼요.

복구 순서는 이렇게 잡으세요.

1. 영향을 받은 패키지 버전이 개발자 기계나 CI 실행기에 설치됐는지 확인하세요.
2. 그 환경이 더 많은 작업을 수행하기 전에 동결하세요.
3. 저장소와 홈 디렉터리의 에이전트 또는 에디터 시작 설정 파일을 감사하세요.
4. 의심스러운 후크, 작업, 워크플로, 생성된 페이로드 파일, 예상치 못한 브랜치를 제거하세요.
5. 패키지 토큰, GitHub 토큰, 클라우드 키, SSH 키, CI 비밀을 포함해 영향을 받은 프로세스가 접근할 수 있었던 모든 자격 증명을 교체하세요.
6. 패키지 게시자 접근 권한과 저장소 쓰기 권한을 검사하세요.
7. 비밀 노출과 예상치 못한 외부 호출이 있었는지 워크플로 로그를 검토하세요.
8. 깨끗한 체크아웃과 정상으로 확인된 의존성 집합으로 환경을 다시 빌드하세요.

GitHub의 Actions 보안 가이드는 대응의 자격 증명 측면을 뒷받침해요. 워크플로 토큰에는 최소 권한을 사용하고, 노출된 비밀을 교체하고, 비밀 처리 방식을 감사하고, 작업이 환경 비밀에 접근하기 전에 검토를 요구하는 방안을 고려하라고 말해요.¹⁰ GitHub은 .github/workflows 아래 변경 사항이 지정된 검토자의 승인을 받도록 워크플로 파일에 CODEOWNERS를 사용할 것도 권장해요.¹⁰

에이전트 설정도 같은 거버넌스 경로에 추가하세요. .github/workflows/*가 비밀에 닿을 수 있어서 코드 소유자 검토를 받아야 한다면, .claude/settings.json과 .vscode/tasks.json도 비밀 근처에서 명령을 실행할 수 있으므로 검토를 받아야 해요.

에이전트 플랫폼이 만들어야 할 것

에이전트 플랫폼과 에디터는 시작 권한을 명시적으로 보여주면 검토 부담을 줄일 수 있어요.

유용한 제품 표면은 다음과 같아요.

이런 표면은 모델이 JSON 파일을 읽고 판단하는 데 의존해서는 안 돼요. 실행 환경이 권한을 직접 드러내야 해요. 사용자는 “README에서 맥락을 불러온다”와 “작업 맥락 시작 시 셸 명령을 실행한다”의 차이를 분명히 볼 수 있어야 해요.

MCP 도구에는 동작별 권한 부여가 필요해요는 bearer 토큰 검증이 도구별, 역할별, 동작별 검사로 이어져야 한다고 주장했어요. 에이전트 설정에도 같은 형태가 필요해요. 모든 시작 동작은 필요한 권한을 선언해야 하고, 실행 환경은 가능한 가장 작은 권한 집합을 강제해야 해요.

실용적인 로컬 정책

플랫폼이 더 나은 인터페이스를 만들기 전에도 팀은 작은 정책 파일로 시작할 수 있어요.

좋은 정책은 파일과 권한을 이름으로 불러요. “에이전트 도구를 조심하라” 같은 모호한 규칙은 실제 업무에서 살아남지 못해요. “SessionStart 명령 후크는 소유자 검토 없이는 금지” 같은 명확한 규칙은 검토자가 집행할 수 있어요.

자주 묻는 질문

AI 에이전트 설정이 정말 공급망의 일부인가요?

네. 공급망 위험은 파일 확장자가 아니라 실행과 신뢰를 따라가요. 패키지 설치, 플러그인, 템플릿, 저장소 변경이 나중에 명령을 실행하는 에이전트 설정을 수정할 수 있다면, 그 설정은 공급망 안에 있어요.

팀은 Claude Code 후크나 VS Code 작업을 금지해야 하나요?

아니요. 후크와 작업은 정당한 자동화를 지원해요. 팀은 이를 검토하고, 범위를 제한하고, 로그로 남겨야 해요. 맥락을 불러오는 후크와 시작 시 셸을 실행하는 후크가 같은 신뢰를 받아서는 안 돼요.

VS Code는 폴더 열기 작업을 실행하기 전에 물어보나요?

VS Code 문서는 사용자가 folderOpen 작업이 포함된 폴더를 처음 열 때, VS Code가 해당 폴더의 자동 작업을 허용할지 묻는다고 설명해요.⁶ 이 프롬프트는 도움이 되지만, 승인이 파일을 실행 경로로 바꾸기 때문에 그 작업은 여전히 코드 검토를 받아야 해요.

npm의 신뢰할 수 있는 게시가 패키지 손상을 해결하나요?

아니요. 신뢰할 수 있는 게시는 수명이 짧은 OIDC 기반 자격 증명을 사용해 오래 유지되는 npm 쓰기 토큰의 위험을 줄여요.⁹ 그래도 팀에는 손상된 저장소나 악성 설치 스크립트에 대비한 워크플로 검토, 최소 권한, 패키지 모니터링, 사고 대응이 필요해요.

의심스러운 설치 후 무엇을 먼저 감사해야 하나요?

설치 시 실행 스크립트, 에이전트 및 에디터 시작 설정, 워크플로 파일, 예상치 못한 점 디렉터리 파일, 새 브랜치, 영향을 받은 프로세스에 노출된 자격 증명을 감사하세요. 그다음 영향을 받은 환경의 자격 증명을 교체하세요.

마무리

AI 코딩 에이전트는 설정을 더 강력하게 만들어요. 동시에 설정을 더 위험하게 만들기도 해요.

올바른 대응은 자동화를 두려워하는 것이 아니에요. 실행이 어디에 있는지 정직하게 인정하는 거예요. 파일이 명령을 실행하거나, 데이터를 가져오거나, 비밀을 읽거나, 패키지를 게시하거나, 에이전트 동작을 바꿀 수 있다면 그 파일은 검토 경로에 들어가야 해요.

에이전트 설정은 이미 그 선을 넘었어요. 코드처럼 다루세요.

참고 문헌