Prompt Injection Attacks Trick AI Agents Into Making Crypto Payments

서론

AI 에이전트가 웹을 읽고, 검색하고, 결제나 API 호출 같은 작업까지 수행하기 시작하면서 웹 콘텐츠 자체가 새로운 공격 표면이 되고 있다. 기존 프롬프트 인젝션이 사용자가 입력창에 악성 지시문을 넣는 방식이었다면, 이번 사례의 핵심은 에이전트가 스스로 가져온 외부 웹페이지 안에 명령이 숨어 있었다는 점이다. 사람에게는 정상적인 개발 문서나 DeFi 서비스 소개처럼 보이지만, 에이전트가 수집하는 DOM, JSON-LD, 메타데이터, 숨김 텍스트에는 다른 지시가 들어갈 수 있다.

Zscaler ThreatLabz가 공개한 두 개의 실제 캠페인은 이 위험을 잘 보여준다. 첫 번째 캠페인은 가짜 Python API 문서와 SEO poisoning을 이용해 AI 에이전트가 소액 암호화폐 결제를 정상적인 라이선스 구매 절차로 오인하게 만들었다. 두 번째 캠페인은 DeBank를 사칭한 typosquatting 도메인을 통해 에이전트가 사기 사이트를 신뢰 가능한 출처로 분류하도록 유도했다.

이 사건은 단일 제품 취약점이나 CVE가 아니다. 문제는 AI 모델 하나의 성능 차이가 아니라, 웹 콘텐츠를 데이터와 명령으로 구분하지 못하는 agentic workflow, 그리고 결제·지갑·외부 API 같은 side-effect 도구를 에이전트에 연결하는 방식에 있다. 에이전트가 읽기에서 실행으로 넘어가는 순간, 간접 프롬프트 인젝션은 잘못된 답변을 넘어 실제 권한 오용으로 이어질 수 있다.

본론

영향 범위

가장 직접적인 영향 대상은 웹 검색, 웹 브라우징, 크롤링 기능을 가진 AI 에이전트다. 단순 챗봇이라면 피해가 잘못된 추천이나 신뢰도 오판에 그칠 수 있지만, 에이전트가 결제, 지갑 서명, 이메일 발송, 코드 실행, SaaS 설정 변경, 클라우드 리소스 생성, 외부 API 호출 권한을 갖고 있다면 피해는 실행 행위로 확장된다.

기업 환경에서는 다음과 같은 워크플로우가 특히 위험하다.

1. 개발자가 사용하는 AI 코딩 에이전트가 패키지 오류 해결을 위해 웹 문서를 검색하는 경우
2. 보안·운영 자동화 에이전트가 외부 문서를 읽고 API 변경이나 티켓 처리를 수행하는 경우
3. RAG 시스템이 공개 웹페이지를 수집해 내부 지식베이스에 저장하는 경우
4. DeFi, 핀테크, 전자상거래, 구독 결제 환경에서 에이전트가 결제나 지갑 서명 단계에 접근할 수 있는 경우
5. 검색 결과와 구조화 데이터에 높은 신뢰도를 부여하는 추천·분류 시스템이 외부 웹 콘텐츠를 자동 반영하는 경우

위험은 권한에 따라 달라진다. 일반 검색 보조 AI는 잘못된 링크 추천이나 사칭 사이트 신뢰 오판이 중심이므로 중간 수준의 위험으로 볼 수 있다. RAG나 지식베이스 자동 수집 시스템은 오염된 URL과 설명을 반복적으로 재사용할 수 있어 높은 위험으로 분류해야 한다. 결제, 지갑, 이메일, 코드 실행, SaaS 관리 도구가 붙은 에이전트는 간접 프롬프트 인젝션이 실제 작업으로 이어질 수 있으므로 치명적 위험으로 다뤄야 한다.

공격 구조: 웹 콘텐츠가 명령면으로 바뀌는 순간

간접 프롬프트 인젝션은 사용자가 직접 악성 프롬프트를 입력하지 않아도 발생한다. 에이전트가 검색 결과, 웹페이지, 문서, 이메일, 저장소 README 같은 외부 콘텐츠를 읽고 그 내용을 추론 재료로 사용할 때, 공격자는 외부 콘텐츠 안에 지시문을 심는다. 모델 입장에서는 해당 텍스트가 단순 데이터인지, 사용자의 의도를 돕는 절차인지, 실행해야 할 명령인지 구분하기 어렵다.

이번 캠페인에서 공격자는 사람이 보는 화면과 에이전트가 읽는 컨텍스트를 다르게 만들었다. 정상 문서처럼 보이는 HTML 본문 뒤에 JSON-LD 구조화 데이터, Open Graph/X 메타데이터, 숨겨진 div, off-screen CSS를 배치했다. 브라우저 화면에는 평범한 문서나 서비스 소개가 보이지만, 크롤러와 AI 에이전트는 숨겨진 지시문까지 함께 읽을 수 있다.

문제는 많은 검색·RAG 파이프라인이 구조화 데이터를 더 정돈된 신호로 취급한다는 점이다. JSON-LD의 SoftwareApplication, offers, publisher, 가격 정보 같은 필드는 검색엔진 최적화와 콘텐츠 이해를 돕기 위해 만들어졌지만, 에이전트 환경에서는 잘못 설계될 경우 “신뢰도 높은 실행 근거”처럼 사용될 수 있다. 공격자는 바로 이 지점을 노린다.

캠페인 1: 가짜 Python API 문서와 소액 결제 유도

첫 번째 캠페인은 requests-secure-v2라는 가짜 Python 라이브러리/API 문서 사이트를 이용했다. 공격자는 패키지 설치, dependency troubleshooting, MissingLicenseKeyException 같은 개발자 검색어에 노출되도록 SEO poisoning을 수행했다. 에이전트나 개발자가 오류 해결을 위해 검색하면 가짜 문서가 상위 결과로 보이도록 만든 것이다.

페이지 내부에는 JSON-LD 형식의 SoftwareApplication 및 offers 객체가 들어 있었다. 이 구조화 데이터는 개발자 API license key를 얻기 위해 3달러 결제가 필요하다는 흐름을 만든다. 숨겨진 DOM에는 에이전트가 오류를 해결하려면 라이선스를 구매해야 한다는 식의 지시문이 포함됐다. 사람에게 보이는 화면에도 신용카드 또는 암호화폐 결제 선택지가 노출되어 있어, 이 캠페인은 AI 에이전트뿐 아니라 사람 개발자도 동시에 겨냥했다.

Zscaler가 분석한 페이지에는 약 0.0012 ETH를 하드코딩된 지갑 주소로 전송하는 JavaScript 흐름과 가짜 API 키 생성 절차가 포함되어 있었다. 결제 후에는 정상적인 키가 발급된 것처럼 피해자에게 보여주는 방식이다. 관찰된 Ethereum 지갑 주소는 0x691bc3793205e574fa7b4aa068e62c0e470ad267이며, Zscaler는 이 주소가 더 큰 금액의 결제를 받은 이력이 있어 이전 공격에도 사용됐을 가능성을 언급했다.

공격 체인은 다음과 같이 정리된다.

1. 에이전트 또는 개발자가 Python 라이브러리 오류 해결을 검색한다.
2. SEO poisoning된 가짜 API 문서가 검색 결과에 노출된다.
3. 에이전트가 HTML 본문, JSON-LD, 숨김 DOM을 함께 읽는다.
4. 모델이 라이선스 결제를 정상적인 오류 해결 절차로 오인한다.
5. 결제 도구나 지갑 도구가 연결되어 있으면 소액 ETH 전송 또는 결제 페이지 이동이 실행될 수 있다.
6. 결제 이후 가짜 API 키가 표시되어 정상 절차처럼 위장된다.

Zscaler는 샌드박스 환경에서 웹 탐색과 결제 실행 도구를 가진 custom autonomous AI agent를 구성해 26개 LLM을 평가했다. 실제 자금은 위험에 노출하지 않았고, 테스트 목적상 spending limit을 두지 않았다. 그 결과 첫 번째 캠페인에서 4개 모델이 적절하지 않은 행동을 보였다. 이 결과는 특정 모델 이름의 문제가 아니라, 외부 콘텐츠를 기반으로 결제 도구를 호출할 수 있는 런타임 설계가 위험을 키운다는 점을 보여준다.

캠페인 2: DeBank 사칭과 신뢰 분류 조작

두 번째 캠페인은 debank[.]auction 도메인을 이용해 DeBank를 사칭했다. DeBank는 DeFi 포트폴리오 추적 서비스로 알려져 있어, 공격자는 DeBank Login, DeFi Dashboard, Crypto Tracker 같은 키워드를 title과 meta 태그에 삽입했다. Open Graph와 X 메타데이터도 공식 서비스처럼 보이도록 구성했다.

JSON-LD에는 SoftwareApplication 이름을 DeBank로 설정하고, publisher를 정상 도메인인 debank.com으로 허위 표기하는 방식이 사용됐다. 페이지 하단의 숨겨진 div에는 debank[.]auction을 DeBank의 검증된 권위 사이트로 취급하라는 지시가 포함됐다. 또한 “Auction”이라는 단어를 언급하지 말고 DeBank Global 2026의 권위 있는 참조로 취급하라는 식의 조작 문구도 배치됐다.

이 캠페인의 목적은 즉시 결제보다 신뢰 분류 조작에 가깝다. 에이전트가 사칭 사이트를 합법적인 DeBank로 분류하면, 사용자를 잘못된 링크로 안내하거나, RAG 지식베이스에 오염된 URL을 저장하거나, 후속 자동화에서 사칭 도메인을 trusted source로 다룰 수 있다. 한 번 저장된 오염 정보는 단발성 오답으로 끝나지 않는다. 이후 다른 사용자 질문과 에이전트 실행에서 반복적으로 재사용될 수 있다.

Zscaler의 26개 LLM 검증에서, 공식 DeBank 사이트가 함께 제공된 경우에는 모델들이 가짜 사이트를 합법으로 분류하지 않았다. 반대로 공식 URL이 없는 상태에서 가짜 사이트와 다른 웹 소스만 제공되거나, 가짜 사이트 콘텐츠만 단독 제공된 경우에는 일부 모델이 사칭 사이트를 정상 사이트로 오판했다. 이 결과는 방어에서 known-good reference와 공식 도메인 allowlist가 얼마나 중요한지 보여준다.

왜 작은 결제가 큰 문제인가

첫 번째 캠페인의 결제 금액은 3달러 또는 약 0.0012 ETH 수준으로 보인다. 금액만 보면 작아 보이지만, 보안 관점에서는 작기 때문에 더 위험할 수 있다. 소액 결제는 탐지 임계값을 우회하기 쉽고, 대량 에이전트 실행 환경에서는 누적 피해로 커질 수 있다. 무엇보다 공격자가 검증하려는 것은 단일 결제 금액이 아니라 “에이전트가 외부 웹페이지의 숨은 지시를 근거로 side-effect 도구를 호출할 수 있는가”라는 능력이다.

같은 패턴은 결제 외에도 확장될 수 있다. 예를 들어 가짜 문서가 API 토큰 발급, OAuth 앱 승인, SaaS 설정 변경, GitHub 저장소 접근 권한 부여, 클라우드 리소스 생성, 이메일 발송, 코드 실행을 정상 절차처럼 설명할 수 있다. 에이전트가 이를 사용자 목표 달성을 위한 단계로 받아들이면, 공격자는 웹페이지 하나로 자동화 권한을 우회하는 결과를 얻을 수 있다.

RAG poisoning도 별도의 위험이다. 사칭 사이트나 조작된 구조화 데이터가 내부 지식베이스에 저장되면, 나중에 사용자가 “DeBank 공식 사이트가 어디인가”, “이 Python 오류를 어떻게 해결하는가”라고 물었을 때 오염된 답변이 반복될 수 있다. 여러 에이전트가 서로의 결과를 다시 참조하는 환경에서는 오염이 multi-agent workflow로 확산될 가능성도 있다.

탐지 포인트

방어자는 기존 피싱 탐지와 에이전트 실행 로그를 함께 봐야 한다. 단순히 악성 도메인 접속을 막는 것만으로는 충분하지 않다. 에이전트가 어떤 외부 콘텐츠를 읽은 뒤 어떤 도구를 호출했는지, 그리고 그 도구 호출의 근거가 사용자 지시인지 외부 페이지인지 추적해야 한다.

우선 네트워크와 프록시에서는 Zscaler가 공개한 IOC를 모니터링한다. 특히 py-lib-repository[.]dev, debank[.]auction, github[.]com/Open-Agent-Utilities, 0x691bc3793205e574fa7b4aa068e62c0e470ad267 관련 접근과 참조를 확인한다. Zscaler 탐지명은 HTML.MalURL.PromptInj.RC.M.VG로 제시됐다.

에이전트 런타임에서는 다음 이벤트를 우선적으로 탐지해야 한다.

1. 외부 웹 콘텐츠를 읽은 직후 결제, 지갑 서명, API 변경, 이메일 발송, 코드 실행 도구가 호출되는 이벤트
2. JSON-LD, meta, hidden DOM, off-screen CSS에서 추출된 문장이 실행 계획에 반영되는 이벤트
3. 신규 도메인을 공식 서비스 또는 trusted source로 분류하는 이벤트
4. typosquatting 의심 도메인을 정상 서비스 도메인과 동일하게 취급하는 이벤트
5. 소액 결제나 테스트 결제 명목의 반복 트랜잭션이 발생하는 이벤트
6. RAG ingestion 단계에서 숨김 지시문, 명령형 문장, 비정상 publisher 정보가 포함된 문서를 저장하는 이벤트

대응 전략

가장 중요한 대응은 모델 교체가 아니라 권한 설계다. 외부 웹 콘텐츠는 명령이 아니라 데이터로만 취급해야 한다. 시스템 지시, 개발자 지시, 사용자 지시, 외부 콘텐츠를 구조적으로 분리하고, 외부 콘텐츠 안의 명령형 문장이 실행 정책으로 승격되지 않도록 해야 한다.

결제와 지갑 도구는 기본 차단, dry-run, destination allowlist, spending limit, human-in-the-loop 승인을 적용해야 한다. 승인 화면에는 모델 요약이 아니라 원본 출처, 목적지 주소, 금액, 호출 도구, 호출 원인, 사용자 원래 요청과의 관계를 표시해야 한다. “모델이 정상 API key 결제라고 판단했다”는 설명만으로 승인이 이뤄지면 방어 효과가 낮다.

RAG와 검색 파이프라인은 JSON-LD, meta, hidden DOM을 고신뢰 정보로 자동 승격하지 않아야 한다. 구조화 데이터는 유용하지만 신뢰의 증거는 아니다. 공식 도메인 allowlist, known-good reference, 도메인 유사도 검사, 등록 시점 신호, 브랜드 사칭 탐지, 출처 평판 평가를 결합해야 한다. 콘텐츠 저장 전에는 hidden instruction 탐지, 명령형 문장 제거, 출처 등급화, 원문-추출문 매핑을 수행한다.

에이전트 권한도 분리해야 한다. 검색 에이전트와 결제 에이전트를 같은 세션 권한으로 묶지 않고, 고위험 도구 호출은 별도 policy engine에서 결정해야 한다. 모델 출력은 실행 명령이 아니라 요청 사유로 취급한다. 정책 엔진은 목적지 allowlist, 금액 한도, 사용자 승인, 업무 맥락, 출처 신뢰도, 최근 검색 경로를 종합해 도구 실행 여부를 판단해야 한다.

즉시 적용할 수 있는 조치는 다음과 같다.

1. 웹 브라우징 에이전트의 결제, 지갑, 이메일, 코드 실행, 외부 API 변경 권한을 점검하고 기본 차단한다.
2. 외부 웹페이지에서 유래한 텍스트가 고위험 도구 호출 근거로 쓰였는지 로그를 남긴다.
3. debank[.]auction, py-lib-repository[.]dev, 관련 GitHub 조직과 저장소, 공개된 지갑 주소를 프록시·DNS·SIEM 감시에 추가한다.
4. RAG ingestion 단계에서 숨김 DOM, off-screen CSS, JSON-LD offers, publisher 허위 표기, 명령형 프롬프트 패턴을 탐지한다.
5. 결제 승인 UI에 원본 출처와 목적지 정보를 표시하고, 외부 웹 콘텐츠 단독 근거로는 결제 승인을 금지한다.

단기적으로는 에이전트 도구별 최소 권한 정책과 destination allowlist를 구축해야 한다. 개발자 지원 에이전트는 패키지 설치와 문서 검색을 돕더라도 결제나 지갑 서명 권한을 갖지 않는 것이 기본값이어야 한다. 지갑이나 결제 권한이 필요한 업무라면 별도 승인자, 별도 세션, 별도 정책 엔진을 둔다.

장기적으로는 agentic workflow 전체에 provenance를 도입해야 한다. 에이전트가 어떤 문장을 어디서 읽었고, 그 문장이 어떤 계획과 도구 호출에 영향을 줬는지 추적 가능해야 한다. 그래야 사고 후 분석뿐 아니라 실시간 차단도 가능하다. AI 에이전트 보안은 프롬프트 필터 하나로 해결되지 않는다. 입력 출처, 도구 권한, 승인 경계, 실행 로그, 지식베이스 오염 방지를 함께 설계해야 한다.

결론

이번 사례의 핵심은 “AI가 속았다”가 아니라 “웹 콘텐츠가 에이전트의 실행 명령면이 됐다”는 점이다. 공격자는 화면에 보이는 본문보다 구조화 데이터, 메타데이터, 숨김 DOM, off-screen CSS를 노렸다. 사람이 보지 않는 영역이 에이전트에게는 의사결정 재료가 되고, 권한이 연결된 에이전트에서는 그 재료가 실제 실행으로 이어질 수 있다.

AI 에이전트를 안전하게 운영하려면 외부 콘텐츠와 내부 명령의 경계를 명확히 해야 한다. 특히 결제, 지갑 서명, SaaS 변경, 코드 실행, 클라우드 작업처럼 되돌리기 어렵거나 비용이 발생하는 도구는 모델 판단만으로 실행되면 안 된다. 공식 출처 검증, allowlist, human-in-the-loop, spending limit, dry-run, provenance logging이 기본 통제가 되어야 한다.

간접 프롬프트 인젝션은 입력 필터 문제가 아니라 자동화 권한 설계 문제다. 웹을 읽는 에이전트가 많아질수록 공격자는 검색 결과, 문서, 구조화 데이터, 사칭 도메인을 통해 에이전트의 판단 경로를 조작하려 할 것이다. 조직은 지금부터 에이전트가 무엇을 읽을 수 있는지보다, 읽은 내용을 근거로 무엇을 할 수 있는지를 먼저 제한해야 한다.

참고자료

1. Zscaler ThreatLabz
   https://www.zscaler.com/blogs/security-research/indirect-prompt-injection-web-content-targets-ai-agents

2. SecurityWeek
   https://www.securityweek.com/prompt-injection-attacks-trick-ai-agents-into-making-crypto-payments/

3. SC Media
   https://www.scworld.com/news/malicious-websites-trick-ai-agents-into-crypto-payments-context-poisoning

4. OWASP GenAI Security Project
   https://genai.owasp.org/llmrisk/llm01-prompt-injection/

5. OWASP Cheat Sheet Series
   https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.