AI 에이전트 보안에 관한 대부분의 대화는 여전히 프롬프트 인젝션 (Prompt Injection)이 마치 순수하게 모델의 문제인 것처럼 다뤄지고 있습니다. "입력을 정제하라(Sanitize the input)." "더 나은 가드레일 (Guardrails)을 추가하라." "더 강력한 시스템 프롬프트 (System Prompt)를 사용하라."와 같은 식입니다.

이러한 프레임워크는 가장 효과적인 공격들이 실제로 어디에서 발생하는지를 놓치고 있습니다.

최근의 시연 사례들을 보면, 자율 에이전트 (Autonomous Agents)들이 오염된 설정 파일 (Configuration Files)과 리포지토리 (Repositories) 내의 코드를 통해 침해되었습니다. 에이전트가 신뢰할 수 있는 소스 자료로 취급하는 곳에 악의적인 지침을 배치함으로써, 사용자 입력(User Input)을 통한 모델의 추론을 직접적으로 조작하지 않고도 클라우드 자격 증명 (Cloud Credentials)을 수집하고, 내부 인프라를 열거하며, CI/CD 키를 추출하도록 만들었습니다. 에이전트는 단순히 자신이 구축된 목적대로 수행했을 뿐입니다: 환경 내의 코드/설정을 읽고 그에 따라 행동한 것입니다.

이것이 바로 공급망 (Supply Chain)을 통해 전달되는 간접 프롬프트 인젝션 (Indirect Prompt Injection)입니다.

이것이 왜 다른가
전통적인 프롬프트 인젝션은 공격자가 "사용자" 채널을 통해 모델에 도달해야 한다고 가정합니다. 하지만 오염된 리포지토리 접근 방식은 그 과정을 완전히 우회합니다.

에이전트는 리포지토리, 설정 파일 또는 의존성 매니페스트 (Dependency Manifests)를 읽을 수 있는 정당한 권한(종종 기능 수행을 위해 필수적인 권한)을 가지고 있습니다. 일단 이러한 소스들이 침해되면, 에이전트는 공격자의 지침을 실행하는 자신도 모르는 실행기 (Unwitting Executor)가 됩니다.

이것은 새로운 종류의 버그가 아닙니다. 수년간 소프트웨어 개발을 괴롭혀온 것과 동일한 공급망 및 신뢰 문제이며, 이제는 자율적으로 행동할 수 있는 시스템을 겨냥하여 무기화된 것입니다.

우리는 2025년에 다음과 같은 사건들을 통해 유사한 패턴을 목격했습니다:
• Cline: 조작된 GitHub 이슈 제목이 인증된 코딩 세션을 약 4,000대의 머신에 영향을 미치는 패키지 설치기로 변질시켰습니다.
• LiteLLM: PyPI에 백도어가 심어진 릴리스가 올라왔으며, 3시간 만에 약 47,000회 다운로드되었습니다.
• MCP 서버: 설계상 인증 없이 약 200,000개가 노출되어 있었습니다.
각 사례에서 침해는 AI 모델을 깨뜨릴 필요가 없었습니다. 대신 주변 시스템이 설계된 방식 때문에 에이전트가 이미 보유하고 있던 권한을 남용하는 방식이었습니다.

가드레일의 사각지대 (The Guardrail Blind Spot)

에이전트를 위한 현재의 방어 도구들은 주로 프롬프트 계층 (Prompt layer)과 도구 사용 제한 (Tool-use restrictions)에 집중되어 있습니다. 이것들은 유용하지만, 에이전트가 소비하는 데이터가 비교적 깨끗하거나 최소한 실시간으로 감사 (Auditable) 가능하다는 가정을 전제로 합니다.

독성 데이터가 Git 저장소, 에이전트가 로드하도록 예정된 설정 파일, 또는 에이전트가 자율적으로 가져오는 종속성 (Dependency) 내에 존재할 때, 이러한 가정들은 무너집니다.

많은 팀이 여전히 "우리 저장소"를 신뢰할 수 있는 경계로 취급합니다. 하지만 에이전트가 그곳에서 읽은 내용을 바탕으로 의사결정을 내리기 시작하는 순간, 그 경계는 사라집니다.

실질적인 현실 점검 (Practical Reality Check)

만약 당신의 에이전트가 다음과 같은 작업을 수행할 수 있다면:
• 외부 또는 내부 저장소로부터 코드/설정을 읽음
• 읽은 내용에 대해 실행하거나 행동함
• 파이프라인을 트리거하거나, 파일을 수정하거나, API를 호출함

...당신은 전통적인 애플리케이션 보안 제어 장치가 자율 실행 (Autonomous execution)을 방어하도록 설계되지 않았던 공급망 공격 표면 (Supply chain attack surface)을 갖게 된 것입니다.

커밋에 서명하는 것 (Signing commits)은 도움이 됩니다. 종속성을 고정하는 것 (Pinning dependencies)도 도움이 됩니다. 하지만 이것들은 부분적인 조치일 뿐입니다. 대규모로 운영되는 에이전트는 결국 행동을 취할 만큼 충분히 합법적으로 보이는 독성 또는 악성 콘텐츠를 마주하게 될 것입니다.

실질적인 변화를 이끌어내는 것 (What Actually Moves the Needle)

공격 보안 (Offensive Security) 관점에서 볼 때, 진전을 보이고 있는 팀들은 에이전트가 읽는 모든 외부 소스(및 많은 내부 소스)를 기본적으로 신뢰할 수 없는 것으로 취급하고 있습니다. 이들은 다음과 같은 조치를 취하고 있습니다:
• 에이전트가 코드나 설정 (Config)에 따라 동작하기 전에 출처 (Provenance) 및 무결성 (Integrity) 검사를 구현함
• "신뢰할 수 있는" 소스에서 작동할 때조차 에이전트가 할 수 있는 일을 엄격하게 제한함
• 에이전트가 저장소 (Repositories) 또는 의존성 (Dependencies)과 상호 작용할 때 행동 이상 (Behavioral Anomalies)을 모니터링함
• 영향력이 큰 작업은 자율적인 실행 대신 명시적인 확인을 요구하는 워크플로 (Workflows)를 설계함

불편한 진실은 현재의 많은 에이전트 아키텍처 (Architectures)가 보안보다 기능을 우선시하여 최적화하는 팀들에 의해 구축되었다는 점입니다. 이러한 순서는 이제 공급망 공격 (Supply Chain Attacks)이 기계의 속도로 성공할 수 있는 정확한 조건을 만들어내고 있습니다.

질문은 오염된 저장소 (Poisoned Repositories)가 에이전트에 대한 표준 공격 벡터 (Attack Vector)가 될 것인가 하는 것이 아닙니다. 그것은 이미 그러합니다.

진정한 질문은 당신의 에이전트 설계가 소비하는 코드가 안전하다고 가정하는지, 아니면 그 반대로 가정하는지 여부입니다.