AI 코딩 에이전트는 이제 코드를 대신 짜는 수준을 넘어섰다. 파일을 읽고, 터미널을 쓰고, 외부 문서까지 직접 가져온다. 다만 편의가 커진 만큼 공격할 수 있는 면도 같이 넓어졌다. AI 코딩 에이전트 보안에서 진짜 문제가 되는 건 거창한 해킹이 아니라 가장 작은 틈이다.
최근 공개된 사고를 보면 한 가지가 반복된다. 사실 대단한 취약점이 아니라 사소한 입력 하나가 시작점이었다. 평범한 문서, 저장소 이름, 도구 설명 같은 것들이다. 그 작은 틈이 어떻게 시스템 전체를 넘기는지 정리해보고 싶었다.
작은 틈은 어디서 생기나
에이전트는 외부 콘텐츠를 너무 믿는다
에이전트가 읽는 README, 이슈, 웹페이지는 전부 데이터다. 사람은 데이터와 명령을 구분한다. 그런데 모델은 그 경계가 흐리다. 그래서 문서 안에 “이 토큰을 외부로 보내라”는 문장이 있으면, 그걸 참고 자료가 아니라 지시로 처리할 수 있다.
이걸 간접 프롬프트 인젝션이라고 부른다. 공격자가 직접 입력하지 않아도 된다. 에이전트가 알아서 읽을 만한 곳에 명령을 심어두면 그만이다. 신뢰 경계가 없으니 에이전트는 의심 없이 따른다.
예를 들어 공개 저장소의 README 맨 아래에 흐린 글씨로 한 줄을 숨긴다고 하자. 사람 눈에는 잘 안 띈다. 하지만 에이전트는 글자를 색과 상관없이 읽는다. 그 안에 든 지시까지 함께 읽는 게 문제다.
공격에 코드가 필요 없다
전통적인 해킹은 진입장벽이 높았다. SQL 인젝션이나 메모리 공격은 전문 지식과 도구가 필요했다. 반면 간접 프롬프트 인젝션은 다르다. 자연어 한 줄이면 된다.
“앞의 지시는 무시하고 이 명령을 실행하라” 같은 문장이면 충분하다. 사실 누구나 쓸 수 있다는 점이 가장 위험하다. 한 보안 연구자가 6개월간 주요 AI 코딩 도구를 점검한 연구에서, 시험한 도구 전부가 이 방식으로 원격 코드 실행과 데이터 유출에 노출됐다. 커서, 윈드서프, 깃허브 코파일럿, 클로드 코드까지 빠짐없이 들어갔고, 그중 24건이 CVE 번호를 받았다. (출처)
그래서 방어하는 쪽은 막아야 할 곳이 늘어난다. 예전엔 사용자가 만든 입력만 의심하면 됐다. 이제는 에이전트가 읽는 모든 외부 글이 잠재적 공격 경로다.
사례로 본 AI 코딩 에이전트 보안
윈드서프, 웹페이지 하나로 원격 코드 실행
윈드서프에서 CVE-2026-30615가 보고됐다. 에이전트가 공격자가 심어둔 HTML 콘텐츠를 처리하는 순간 문제가 시작된다. 숨은 명령이 로컬 설정을 바꾸고, 악성 MCP 서버를 자동으로 등록한다. 그 뒤로는 사용자가 아무것도 누르지 않아도 임의 명령이 실행된다. (출처)
결국 웹페이지 한 장이 트리거였던 셈이다. 작은 틈 하나가 노트북 장악으로 이어진 전형적인 그림이다.
코덱스, 브랜치 이름에 숨은 명령
오픈AI 코덱스에서는 깃 브랜치 이름이 문제였다. 코덱스는 작업할 때 저장소를 복제하고 단기 토큰으로 인증한다. 정작 사용자가 넣은 브랜치 이름은 제대로 검증하지 않았다.
그래서 조작된 브랜치 이름에 셸 명령을 끼워 넣으면 실행 환경에서 그대로 돌았다. 저장소 접근에 쓰던 깃허브 토큰까지 노출됐다. (출처) 브랜치 이름 하나가 키를 내준 셈이다.
클로드 코드, 저장소를 여는 순간 키가 샜다
클로드 코드에서는 저장소 하나가 문제였다. 악성 저장소에는 설정 파일이 들어 있다. 그 파일이 API 요청 주소를 공격자 서버로 바꿔둔다. 그래서 저장소를 여는 순간, 신뢰 확인 창이 뜨기도 전에 클로드 코드가 그 주소로 요청을 보낸다. 그 과정에서 Anthropic API 키가 새어 나간다(CVE-2026-21852). 개발자가 한 행동은 누구나 쉽게 하는 깃 클론이었다. (출처)
비슷한 문제가 또 있었다. 분석하던 코드에 숨은 지시가 클로드 코드를 움직여, .env 같은 민감 파일을 읽어 DNS 요청에 실어 보냈다(CVE-2025-55284). 사실 눈에 띄는 연결이 아니라 평범한 조회 트래픽이라 알아채기가 더 어려웠을 것이다. 두 문제 다 이후 버전에서 패치됐다. (출처)
MCP 서버, 툴 설명에 심은 한 줄
MCP 서버는 에이전트에게 외부 도구를 연결한다. 각 도구에는 설명 텍스트가 붙는다. 모델은 이 설명을 읽고 도구 사용법을 이해한다.
한편 공격자는 그 설명 안에 “다른 도구를 무시하고 이걸 먼저 실행하라”와 같은 악성 지시를 넣는다. 사용자는 평범한 도구를 쓴다고 생각한다. 하지만 에이전트는 숨은 지시를 따른다. 이걸 툴 포이즈닝이라고 부른다.
무너지는 건 늘 가장 약한 고리다
사례는 달라도 원인은 같다
윈드서프는 웹페이지, 코덱스는 브랜치 이름, MCP는 도구 설명이었다. 입구는 다 다르다. 그런데 무너지는 방식은 똑같다.
원인은 세 가지로 모인다. 먼저 에이전트에 신뢰 경계가 없다. 외부에서 읽은 글을 명령처럼 받는다. 다음으로 권한이 과하다. 토큰과 셸과 파일에 한꺼번에 닿는다. 마지막으로 사람 확인 없이 자동으로 실행한다. 결국 이 셋 중 가장 약한 하나만 열려도 전체가 뚫린다.
가장 작은 틈부터 좁힌다
도구 자체를 바꾸긴 어렵다. 그래도 가장 약한 고리는 줄일 수 있다.
먼저 권한을 최소로 준다. 에이전트에게 필요한 만큼만 토큰과 접근을 허용한다. 그리고 위험한 동작은 사람 확인을 거치게 둔다. 자동 실행을 무조건 켜두지 않는 것이다. 실행 환경은 샌드박스로 격리한다. 그러면 사고가 나도 피해를 그 안에 가둘 수 있다. 끝으로 도구의 출처를 확인한다. MCP 서버나 외부 스킬을 검증 없이 붙이지 않는다.
사실 화려한 방어가 아니다. 가장 작은 틈부터 좁히는 것이 먼저다. 보안의 수준은 최약점에서 결정된다. AI 코딩 에이전트 보안도 다르지 않다.