BrassCoders는 소스 코드를 결정론적(deterministically)으로 스캔하며, 프롬프트 인젝션 (Prompt Injection)은 BrassCoders가 잡아낼 수 없는 공격 유형입니다. 이는 프롬프트 인젝션이 에이전트가 작성하는 코드 내의 패턴이 아니라, 저장소를 읽는 AI 에이전트에 대한 런타임 (runtime) 공격이기 때문입니다. 연구원들은 에이전트가 오염된 외부 콘텐츠를 흡수했을 때 GitHub Copilot 및 Cursor를 대상으로 한 공격 성공률이 최대 84%에 달한다는 것을 측정했습니다. 소스 스캐너가 어디에서 멈추는지 아는 것은 무엇을 잡아내는지 아는 것만큼이나 가치가 있습니다.

대부분의 벤더 보안 포스트는 자사의 도구가 해당 리스크를 커버한다고 주장합니다. 이 글은 대신 그 경계를 설정합니다. 어떤 정적 분석기 (static analyzer)도 도달할 수 없는 AI-코드 리스크 계층이 전체적으로 존재하며, 그렇지 않은 척하는 것은 당신이 보호받고 있다고 생각한 바로 그 지점에서 당신을 무방비 상태로 방치할 것입니다.

프롬프트 인젝션 (Prompt Injection)이란 실제로 무엇인가

BrassCoders는 프롬프트 인젝션을 LLM 애플리케이션을 위한 Top 10에서 가장 높은 순위의 리스크인 OWASP의 LLM01로 인덱싱합니다. 이는 AI로 보강된 코드베이스에 도달할 가능성이 가장 높은 공격이기 때문입니다. 프롬프트 인젝션은 에이전트가 읽는 텍스트가 따라야 할 지침 (instructions)으로 취급될 때 발생합니다. 코딩 에이전트의 경우 위험한 형태는 간접 인젝션 (indirect injection)으로, 에이전트가 업무를 수행하는 동안 흡수하는 README, GitHub 이슈, 또는 종속성 (dependency)의 문서 안에 페이로드 (payload)가 숨겨져 있는 경우입니다.

모델은 작업하도록 지시받은 콘텐츠에 포함된 공격자의 텍스트와 운영자 지침을 안정적으로 구분할 수 없습니다. 당신이 에이전트를 특정 저장소로 지정하면, 그 저장소에 지침처럼 보이는 한 줄이 포함되어 있고, 에이전트는 그것을 따릅니다. 주입된 텍스트가 일반적인 산문처럼 보이기 때문에 악성 저장소는 인간의 검토를 통과하며, 공격은 에이전트가 그것을 읽을 때만 실행됩니다.

Copilot과 Cursor가 얼마나 취약한가

BrassCoders는 이러한 노출의 가장 강력한 측정 지표를 제시합니다: Liu 등이 70개의 MITRE ATT&CK 기법을 포괄하는 314개의 공격 페이로드 프레임워크인 AIShellJack을 구축하여 GitHub Copilot 및 Cursor를 대상으로 테스트한 결과, 악성 명령 실행에 대한 공격 성공률(attack-success rates)이 84%에 달했습니다. 해당 논문인 ["Your AI, My Shell">(https://arxiv.org/abs/2509.22040)은 초기 액세스(initial access) 및 시스템 탐색(system discovery)부터 자격 증명 탈취(credential theft) 및 데이터 유출(data exfiltration)에 이르는 다양한 목적을 기록하고 있습니다.

84%라는 수치는 신뢰할 수 없는 콘텐츠에 대해 명령을 자동 실행하는 에이전트(agent)에 적용됩니다. 확인 절차 없이 실행되도록 구성된 에이전트가 공격자가 심어놓은 저장소를 가리키게 되면, 대부분의 경우 공격자의 명령을 실행하게 됩니다. 이는 더 나은 모델로 해결할 수 있는 튜닝(tuning)의 문제가 아닙니다. 신뢰할 수 없는 입력값으로부터 읽어온 지침에 따라 에이전트가 행동하도록 허용하는 방식 자체의 속성입니다.

치명적인 삼중주 (The Lethal Trifecta)

BrassCoders는 프롬프트 인젝션(prompt injection)이 데이터 탈취로 이어지는 가장 명확한 모델로 Simon Willison의 치명적인 삼중주 (lethal trifecta)를 사용합니다: 즉, 개인 데이터에 접근할 수 있고, 신뢰할 수 없는 콘텐츠에 노출되어 있으며, 외부와 통신할 수 있는 능력을 가진 에이전트입니다. 이 세 가지를 모두 갖춘 에이전트는 주입된 지침에 의해 유도되어 비밀 정보를 읽고 이를 공격자에게 전송할 수 있습니다.

AI 코딩 에이전트는 이 세 가지를 모두 갖추는 경향이 있습니다. 저장소 접근 권한이 있어 사용자의 개인 코드와 자격 증명을 읽습니다. 모든 의존성(dependency)의 문서와 트래커의 모든 이슈를 포함한 신뢰할 수 없는 콘텐츠를 흡수합니다. 그리고 패키지를 가져오고 API를 호출하기 위한 네트워크 송신(network egress) 권한을 가집니다. Willison의 실질적인 조언은 사용 가능한 가장 저렴한 방어책입니다: 이 중 하나만 제거해도 데이터 유출 경로가 차단됩니다.

소스 스캐너가 이를 볼 수 없는 이유

BrassCoders는 커밋된 소스 코드 내의 구조적 패턴(예: 연결(concatenation)로 생성된 SQL 문자열, md5 호출, 하드코딩된 키 등)을 매칭합니다. 하지만 프롬프트 인젝션 (Prompt Injection) 페이로드는 이러한 패턴 중 그 어느 것도 아닙니다. 페이로드는 에이전트가 런타임 (runtime)에 읽는 콘텐츠(GitHub 이슈 또는 웹 페이지 등)에 존재하며, 에이전트가 작성하는 코드 내에 존재하는 것이 아닙니다. 저장소의 Python 코드에는 스캐너가 플래그(flag)를 표시할 만한 요소가 전혀 없습니다.

이것이 결정론적 소스 분석 (deterministic source analysis)의 경계이며, 이를 명확히 밝혀둘 가치가 있습니다. BrassCoders는 코드를 위한 패턴 리포터 (pattern reporter)인 반면, 프롬프트 인젝션은 에이전트의 런타임 동작에 대한 공격입니다. 이를 탐지할 수 있다고 주장하는 스캐너는 평가할 방법이 없는 콘텐츠로부터 의도를 추론해야 하며, 이는 명확한 경계를 보여주는 것보다 잘못된 보안 범위를 제공하여 더 위험할 수 있습니다. 정확한 답변은 이러한 종류의 공격은 그 어떤 소스 스캐너도 볼 수 있는 범위를 벗어나 있다는 것입니다.

완화책이 존재하는 위치

BrassCoders는 프롬프트 인젝션 방어책이 실제로 작동하는 구체적인 사례로 Anthropic의 Claude Code 보안 문서를 지목합니다: 바로 에이전트 런타임 (agent runtime)입니다. 문서에 명시된 통제 수단들은 런타임 통제 (runtime controls)입니다. 여기에는 민감한 작업에 대해 명시적 승인을 요구하는 권한 시스템, 검색된 콘텐츠가 명령을 주입할 수 없도록 웹 페치 (web fetch)를 위한 격리된 컨텍스트 윈도우 (context windows), 처음 접하는 코드베이스 및 새로운 MCP 서버에 대한 신뢰 검증, 그리고 의심스러운 명령에 대해 수동 승인을 강제하는 커맨드 인젝션 (command-injection) 탐지 등이 포함됩니다.

위협은 에디터(editor)를 넘어 확장됩니다. Cloud Security Alliance는 2026년의 한 사례를 기록했습니다. 이 사례에서 AI 코딩 에이전트의 GitHub Action은 모든 GitHub App 액터(actor)를 신뢰하는 권한 확인 절차를 가지고 있었으며, 이로 인해 외부 공격자가 단 하나의 정교하게 제작된 이슈(issue)를 통해 악성 프롬프트를 주입하고, 쓰기 권한(write access) 없이도 저장소 침해(repository compromise)로 에스컬레이션할 수 있었습니다. 에이전트(Agent)에 자동화와 신뢰할 수 없는 입력(untrusted input)이 결합되면 실질적인 공급망 공격 벡터(supply-chain vector)가 되므로, 에디터에서와 마찬가지로 CI(지속적 통합)에서도 동일한 권한 관리 규율이 적용되어야 합니다.

BrassCoders가 대신 다루는 범위

BrassCoders는 AI 어시스턴트가 일정한 비율로 배포하는 결정론적 패턴(deterministic patterns), 즉 SQL 인젝션 (SQL injection), 커맨드 인젝션 (command injection), 취약한 암호화 (weak cryptography), 그리고 하드코딩된 비밀값 (hardcoded secrets)을 탐지하기 위해 에이전트가 생성한 코드를 스캔합니다. 이러한 것들은 구조적이며, 커밋된 소스 코드 내에 존재하며, 패턴 스캐너가 매 실행 시 동일한 방식으로 잡아낼 수 있는 것들입니다.

이 두 계층은 상호 보완적이며 어느 하나가 다른 하나를 대체하지 않습니다. 런타임 제어 (Runtime controls)는 에이전트가 읽어들이는 명령으로부터 에이전트를 강화하며, 소스 스캔 (source scan)은 에이전트가 작성한 보안에 취약한 코드를 잡아냅니다. 프롬프트 인젝션 (prompt-injection) 경로를 차단하기 위해 권한 설정과 샌드박싱 (sandboxing)을 구성한 다음, 출력물에 대해 결정론적 스캔을 실행하여 배포되는 코드가 깨끗하도록 만드십시오.

pip install brasscoders
brasscoders --offline scan /path/to/your/project

스캔은 코드 내의 패턴을 잡아냅니다. 프롬프트 인젝션은 스캐너가 아닌 런타임 강화 (runtime hardening)가 필요하며, 신뢰할 만한 도구라면 자신이 어디까지 수행할 수 있는지(어디서 멈추는지)를 사용자에게 알려줍니다.