2센트로 은행 AI 비서를 조종하다 — 송금 메모 한 줄의 프롬프트 인젝션

핵심 요약 (TL;DR)

보안 스타트업 Blue41이 네덜란드 네오뱅크 bunq의 AI 어시스턴트를 상대로 한 프롬프트 인젝션 검증을 공개했습니다. €0.02 송금의 메모 필드에 지시문을 심자, 피해자가 "최근 거래 보여줘"라고 묻는 순간 어시스턴트가 가짜 재인증 요청 — 스피어피싱 메시지를 출력했습니다. 자금이 이동한 건 아니지만, 계좌번호만 알면 누구나 2센트로 타인의 AI 비서 컨텍스트에 '지시'를 써넣을 수 있다는 게 증명된 겁니다.

은행 AI 비서가 어떻게 뚫린 건가요?

공격 경로가 무서울 정도로 단순합니다. SEPA 송금에는 '거래 설명'이라는 메모 필드가 있습니다. 공격자는 피해자 계좌로 €0.02를 보내면서 그 메모에 악성 지시문을 넣습니다. 피해자가 은행 AI 비서에게 최근 거래를 물으면, 그 메모가 LLM 컨텍스트로 들어갑니다 — 데이터가 아니라 지시로 읽히면서요. Blue41의 데모에서 어시스턴트는 가짜 재인증을 요구하는 피싱 메시지를 사용자에게 그대로 출력했습니다.

참고로 Hacker News 제목에는 €0.01로 알려졌지만(https://news.ycombinator.com/item?id=48476136), 원문 데모의 실제 송금액은 €0.02입니다. 원문은 4월 29일에 게시됐고 6월 10일 HN에서 화제가 됐습니다. 현재 원문 주소가 홈으로 리다이렉트되고 있어서, 전문은 아카이브(https://web.archive.org/web/20260611033555/https://blue41.com/blog/how-we-helped-bunq-secure-their-financial-ai-assistant/)에서 확인할 수 있습니다. Blue41은 bunq와 협업해 어시스턴트 보안을 강화한 뒤에 사례를 공개했습니다.

왜 막기 어려운 공격인가요?

LLM은 데이터와 지시를 구조적으로 구분하지 못합니다. SQL 인젝션과 닮았지만 결정적 차이가 있습니다. SQL에는 parameterization이라는 구조적 해법이 있는데, LLM에는 아직 그에 상응하는 게 없다는 것 — HN 댓글에서 모인 합의입니다. 침투 경로가 '정상적인 은행 송금'이라는 점도 무겁습니다. 방화벽도 인증도 다 통과한 합법적 데이터가 곧 공격 페이로드인 거죠.

내 서비스에 AI 챗봇을 붙일 때 뭘 점검해야 하나요?

원칙은 하나입니다. 사용자 입력이든 외부 데이터든, LLM에 닿는 모든 지점이 공격면입니다. 거래 메모, 리뷰, 닉네임, 이메일 제목 — 제3자가 쓸 수 있는 모든 필드가 잠재적 프롬프트입니다. 최소한 챗봇이 화이트리스트 밖의 클릭 가능한 링크를 출력하지 못하게 막고, 외부 데이터는 명시적으로 격리된 형태로 컨텍스트에 넣는 설계를 검토해보세요.

FAQ

Q. 실제로 돈이 빠져나갔나요?
아니요. 데모는 자금 이동이 아니라 어시스턴트가 피싱 메시지를 출력하게 만드는 수준이었습니다. 다만 그 메시지를 믿은 사용자가 자격증명을 넘기면 다음 단계는 충분히 가능해집니다.

Q. bunq만의 문제인가요?
아니요. 외부 데이터를 컨텍스트에 넣는 모든 LLM 서비스의 구조적 문제입니다. bunq는 협업으로 보완을 마친 사례로 공개된 것뿐입니다.

바이브코딩으로 만든 앱에 AI 비서를 붙이는 순간, 입력 필드 전부가 프롬프트 입력창이 됩니다. 당신 서비스에서 제3자가 글을 쓸 수 있는 곳, 몇 군데나 되는지 세어보셨나요?