AWS가 Claude Code·Cursor·Codex를 클라우드 계정에 직접 연결하는 공식 MCP 서버 플러그인을 출시했다. 설치는 Claude Code 기준 /plugin install aws-core@claude-plugins-official 한 줄이다. IAM 인증, CloudTrail 감사 로깅, 샌드박스 Python 실행—이 모든 게 하나의 엔드포인트로 묶인다. 편리함은 분명하다. 그런데 나는 이 소식을 보자마자 보안 설계 쪽으로 먼저 머리가 갔다.
왜 지금 이 타이밍이 중요한가
공교롭게도 같은 시기, npm 생태계에서 jscrambler 패키지를 통한 공급망 공격이 터졌다(SafeDep·StepSecurity 분석 참고). 공격 벡터는 preinstall 훅이었다. npm install을 치는 순간, 패키지가 디스크에 풀리기도 전에 Rust로 작성된 인포스틸러가 실행됐다. 브라우저 자격증명, 크립토 지갑, Bitwarden 볼트—개발자 머신에서 가장 가치 있는 것들을 정확하게 노렸다. Socket이 약 6분 만에 탐지했지만, 대부분의 CI 파이프라인과 AI 에이전트는 설치 로그를 실시간으로 읽지 않는다.
이 두 사건을 연결하면 하나의 문장이 나온다: 에이전트가 클라우드에 손을 뻗을수록, 에이전트 머신은 더 매력적인 공격 표면이 된다.
세 가지 리스크 레이어를 동시에 설계해야 한다
AWS MCP 플러그인 자체는 잘 설계됐다. IAM 기반 접근 제어, CloudTrail 로깅, 문서 검색은 인증 없이 허용하고 실제 API 호출만 자격증명을 요구하는 구조—권한 범위를 좁히는 방향으로 갔다. 문제는 플러그인 바깥, 에이전트가 실행되는 환경 전체다.
리스크 1: 공급망 오염
Claude Code나 Cursor가 npm install을 자동 실행하는 순간, 위에서 설명한 공격이 에이전트 머신에 그대로 적용된다. 에이전트는 설치 출력을 줄 단위로 읽지 않는다. 오류 없이 종료된 preinstall 훅은 로그에 흔적조차 남기지 않는다. 이걸 막으려면 CI 파이프라인에 Socket 같은 공급망 스캐너를 붙이고, npm ci --ignore-scripts를 기본값으로 설정하고, lockfile 무결성 검증을 자동화해야 한다. --ignore-scripts 하나로 완전히 막히지 않는다는 것도 알아야 한다—jscrambler 공격의 일부 버전은 require 시점에 실행되도록 바꿔서 이 플래그를 우회했다.
리스크 2: 시크릿 평문 노출
에이전트는 당신의 셸로 실행된다. 파일을 읽고, 빌드를 돌리고, 커밋을 푼다. dev.to의 시크릿 관리 가이드가 정확하게 짚은 것처럼, .npmrc나 dotfile에 평문으로 박혀 있는 토큰은 에이전트가 즉시 읽을 수 있다. AWS MCP 플러그인이 IAM 기반으로 인증을 처리한다 해도, 에이전트가 접근하는 나머지 시크릿—데이터베이스 접속 정보, 서드파티 API 키—은 별도로 격리해야 한다. OS 수준 암호화(Windows DPAPI, macOS Keychain, Linux libsecret)를 기반으로 한 자격증명 관리가 최소 기준이다.
리스크 3: 브라우저 세션 탈취 이 부분이 가장 간과되기 쉽다. Playwright나 CDP 기반 브라우저 자동화를 에이전트가 실행한다면, 에이전트 머신의 브라우저 프로파일에는 실제 로그인 세션이 존재한다. jscrambler 공격의 인포스틸러가 정확히 노린 게 이 SQLite 로그인 데이터베이스와 LevelDB 익스텐션 스토리지다. AWS 콘솔 세션이 거기 있다면, 그게 클라우드 계정 탈취로 이어진다.
팀이 지금 당장 해야 할 설계 체크리스트
이론을 길게 늘어놓는 것보다 내일 당장 팀에서 실행 가능한 항목을 정리하는 게 낫다.
- MCP 권한 범위를 최소화하라. AWS MCP 플러그인의 IAM 역할은 에이전트가 실제로 필요한 서비스로만 제한한다. CloudTrail이 모든 API 호출을 기록하지만, 권한 범위가 넓으면 로그는 사후 증거가 될 뿐이다.
- 에이전트 실행 환경을 격리하라. 에이전트가 로컬 개발 머신과 동일한 환경에서 실행된다면 폭발 반경이 너무 넓다. 별도의 컨테이너 또는 VM에서 실행하고, 브라우저 프로파일도 자동화 전용으로 분리한다.
- 공급망 스캐너를 CI에 붙여라. 에이전트가 의존성 설치를 자동 실행하는 파이프라인이라면 Socket이나 동급의 도구가 필수다. 6분 탐지 vs. 무방비—차이가 크다.
- 시크릿을 OS 암호화 스토리지로 이동하라. 평문 dotfile,
.env파일을 에이전트 접근 경로에서 제거한다. 코드가 실행 시점에 OS 자격증명 관리자를 호출하도록 바꾼다. - lockfile 무결성을 강제하라.
npm ci를 사용하고, lockfile 변경은 PR 리뷰를 거치도록 정책화한다. npm 아티팩트와 GitHub 저장소 커밋이 일치하지 않는 패키지는 즉시 차단한다.
전망: 공식화될수록 공격 표면도 넓어진다
AWS MCP 플러그인의 출시 방향은 옳다. 에이전트에게 무제한 셸 접근 대신 좁고 감사 가능한 클라우드 접근을 주는 것—이게 앞으로 모든 AI-First 팀이 가야 할 구조다. 하지만 공식 플러그인이 등장한다는 건 공격자에게도 명확한 표적이 생긴다는 의미다. 인기 있고 신뢰받는 패키지가 공급망 공격의 좋은 숙주가 되듯이, 공식 MCP 플러그인이 주요 표적이 될 가능성을 배제할 수 없다.
에이전트에게 클라우드에 손을 뻗을 권한을 주기 전에, 팀이 먼저 설계해야 할 건 MCP 서버 설정 파일이 아니다. 공급망 신뢰 체계, 시크릿 격리 모델, 에이전트 실행 환경 경계—이 세 레이어가 먼저 있어야 CloudTrail 로그가 실제 의미를 갖는다. 로그는 사후 증거다. 설계는 사전 방어다.