--- title: "보안 점검 맡긴 AI 에이전트가 악성코드를 직접 실행할 수 있다는 경고" published: 2026-07-12T14:05:04.487Z canonical: https://jeff.news/article/4990 --- # 보안 점검 맡긴 AI 에이전트가 악성코드를 직접 실행할 수 있다는 경고 AI 보안 에이전트가 저장소를 검사하다가 README 같은 문서에 숨은 프롬프트 인젝션에 속아 악성 바이너리를 실행할 수 있다는 연구가 나왔다. 클로드 코드와 코덱스의 자동 모드처럼 승인 없이 명령을 수행하는 구성에서 문제가 재현됐고, 여러 모델과 공급업체를 가로질러 같은 패턴이 통했다는 점이 핵심이다. - 보안 강화를 위해 붙인 AI 에이전트가 오히려 악성코드를 실행할 수 있다는 연구가 나옴. 이름부터 꽤 찝찝하게도 ‘Friendly Fire’, 즉 아군 오인 사격 공격으로 불림 - 공격자는 에이전트가 검사할 문서나 README 파일에 프롬프트 인젝션을 심어둠 - 사용자가 저장소 보안 평가를 맡기면, 에이전트가 그 텍스트를 ‘검사 대상’이 아니라 ‘따라야 할 지시’처럼 받아들일 수 있음 - 결과적으로 경고나 사용자 승인 없이 악성 바이너리를 실행하도록 조작될 수 있다는 게 연구진의 주장임 - 이번 PoC에서 거론된 대상은 앤트로픽의 클로드 코드와 오픈AI 코덱스임 - 특히 클로드 코드의 자동 모드, 코덱스의 자동 검토 자동화 모드처럼 에이전트가 자체 명령을 승인하는 구성에서 문제가 재현됐다고 소개됨 - 테스트에는 ‘클로드 소넷 4.6’, ‘소넷 5’, ‘오퍼스 4.8’, 오픈AI ‘GPT-5.5’가 언급됨 - 기사에 따르면 후킹, 스킬, 플러그인, MCP 서버, 별도 구성 파일 같은 추가 주입 벡터 없이도 공격이 가능하다는 점이 포인트임 > [!WARNING] > 핵심은 “AI가 나쁜 답변을 했다” 수준이 아님. 저장소를 분석하라고 줬더니, 그 안의 텍스트에 속아서 로컬 호스트에서 페이로드를 실행할 수 있다는 얘기임. - 공격 흐름은 생각보다 단순함. 그래서 더 골치 아픔 - 먼저 문서 파일에 프롬프트 인젝션을 삽입함 - 그다음 오픈소스 라이브러리의 평범한 보안 도구 README처럼 보이는 파일을 추가함 - 테스트에서는 지리 좌표 검색에 쓰이는 파이썬 라이브러리 `geopy`가 예시로 사용됨 - 연구진은 거의 모든 프로젝트에서 비슷한 방식으로 작동할 수 있다고 봄 ```mermaid sequenceDiagram participant 공격자 participant 저장소 participant 보안에이전트 participant 로컬호스트 공격자->>저장소: README나 문서에 숨은 지시 삽입 사용자->>보안에이전트: 저장소 보안 평가 요청 보안에이전트->>저장소: 코드와 문서 읽기 저장소-->>보안에이전트: 악성 프롬프트 포함 텍스트 반환 보안에이전트->>로컬호스트: 악성 바이너리 실행 로컬호스트-->>공격자: 페이로드 실행 결과 노출 가능 ``` - 보안업체 Salt Security는 이걸 최근 몇 달간 이어진 에이전트 조작 공격 흐름의 최신 사례로 봄 - 기사에서 언급된 공격은 Friendly Fire, GitLost, Agentjacking, TrustFall 네 가지임 - 기법은 조금씩 달라도 근본 원인은 비슷함 - 정체를 알 수 없는 텍스트가 명령 실행 권한을 가진 에이전트에게 도달하고, 에이전트가 ‘검토 중인 코드’와 ‘실행해야 할 명령’을 확실히 분리하지 못한다는 것임 - 더 불편한 지점은 이게 단순 패치로 끝날 모델 버그처럼 보이지 않는다는 점임 - 기사에 따르면 여러 모델이 같은 기법과 페이로드에 취약했음 - 공급업체나 모델 세대가 달라도 같은 공격이 통한다면, 특정 구현 실수보다 에이전트 구조 자체의 문제일 가능성이 커짐 - 즉 “모델만 업그레이드하면 해결” 같은 얘기가 잘 안 먹히는 유형임 > [!IMPORTANT] > 보안 에이전트의 가장 큰 역설은 권한이 커질수록 유용해지지만, 동시에 속았을 때 실행 가능한 피해도 커진다는 점임. - 그렇다고 AI를 보안 작업에서 빼자는 결론은 아님. 대신 자동화 경계를 훨씬 보수적으로 잡아야 함 - 저장소 분석, 취약점 탐지, 코드 리뷰 같은 방어 작업에 AI를 쓰는 흐름은 이미 빠르게 커지고 있음 - 다만 자동 실행 권한, 네트워크 접근, 파일 시스템 권한, 승인 정책을 느슨하게 주면 공격 표면이 그대로 넓어짐 - 특히 기업이 “AI 보안 도구니까 더 안전하겠지” 하고 들여오면 꽤 위험한 착각이 될 수 있음 --- ## 기술 맥락 - 이 이슈의 핵심은 프롬프트 인젝션 자체보다, 에이전트가 읽는 데이터와 실행할 명령을 같은 흐름에서 처리한다는 데 있어요. 보안 점검 에이전트는 저장소 안의 README, 코드, 설정 파일을 읽어야 하니까 공격자가 심어둔 텍스트도 자연스럽게 모델 컨텍스트로 들어오거든요. - 자동 모드가 위험해지는 이유는 승인 단계가 사라지기 때문이에요. 사람이 중간에 `이 명령을 실행해도 되나`를 판단하면 막을 수 있는 지점이 있는데, 에이전트가 자체 판단으로 계속 진행하면 프롬프트 인젝션이 곧 로컬 명령 실행으로 이어질 수 있어요. - 기사에서 MCP나 플러그인 같은 별도 확장 없이도 공격이 된다고 강조한 것도 중요해요. 보통은 외부 도구 연결부가 위험하다고 생각하기 쉬운데, 여기서는 그냥 저장소 문서와 자동 실행 권한만으로도 충분히 문제가 생긴다는 얘기거든요. - 실무에서는 에이전트에게 최소 권한을 주고, 실행 가능한 명령을 제한하고, 네트워크와 파일 접근을 분리하는 식의 샌드박싱이 필요해요. AI 보안 도구를 도입할 때 모델 성능만 볼 게 아니라, 실패했을 때 어디까지 실행될 수 있는지를 먼저 봐야 하는 이유가 여기에 있어요. ## 핵심 포인트 - 문서나 README에 심은 프롬프트 인젝션만으로 보안 점검 에이전트를 조작할 수 있음 - 클로드 코드 자동 모드와 코덱스 자동 검토 구성에서 사용자 승인 없이 악성 바이너리 실행 가능성이 제기됨 - Friendly Fire, GitLost, Agentjacking, TrustFall 등 최근 에이전트 조작 공격의 근본 원인은 비슷함 - 문제는 특정 모델 버그라기보다 에이전트가 코드와 명령을 구분하지 못하는 구조적 한계에 가까움 ## 인사이트 AI 에이전트를 보안 자동화에 넣는 순간, ‘분석 대상 코드’와 ‘에이전트에게 내리는 지시’가 같은 입력 공간에 섞이는 문제가 생김. 자동 승인 모드는 편하지만, 보안 작업에서는 사실상 원격 명령 실행 표면을 하나 더 여는 셈이라 운영 가드레일이 훨씬 빡세야 함.