0.01유로 이체가 은행 AI 에이전트를 위협할 수 있다
출처: Hacker News
Blue41은 유럽에서 두 번째로 큰 디지털 은행이자 2천만 명 이상의 고객을 보유한 Bunq 가 AI 비서를 스피어피싱 위험으로부터 보호하도록 도왔습니다. 테스트 과정에서 단일 은행 이체만으로 비서를 고도로 신뢰할 수 있는 피싱 공격의 전달 채널로 전환시킬 수 있는 간접 프롬프트 인젝션 취약점을 발견했습니다.
이 사례를 공유하는 이유는 근본적인 문제가 특정 은행에만 국한된 것이 아니기 때문입니다. 거래 데이터, 고객 기록, 문서, 메시지 또는 기타 신뢰할 수 없는 입력을 처리하는 AI 비서를 배포하는 금융 기관 전반에 걸친 아키텍처적 과제이기 때문입니다.
€0.02의 은행 이체가 은행 AI 비서 내부에서 개인화된 피싱 시나리오로 변하는 과정.
설정
현대 은행 앱에는 AI 기반 기능이 점점 더 많이 포함되고 있습니다. 이러한 기능은 사용자와 다양한 백엔드 데이터 소스(거래 기록, 제품 문서, 계좌 상세 정보, 지원 콘텐츠 및 기타 내부 시스템) 사이에 위치합니다. 대형 언어 모델(LLM)을 활용해 해당 컨텍스트를 기반으로 자연어 질문에 답합니다.
전형적인 금융 AI 비서 아키텍처: 사용자는 은행 앱을 통해 상호작용하고, 비서는 거래 데이터, 문서 등에서 컨텍스트를 가져와 필요 시 외부 도구를 호출합니다.
예를 들어 사용자가 “최근 거래 내역을 요약해 줘”라고 물으면, 비서는 관련 레코드를 가져와 LLM에 컨텍스트로 전달합니다. 모델은 그 데이터를 요약해 대화형 응답을 생성합니다.
보안상의 문제는 모든 컨텍스트가 동일하게 신뢰될 수 없다는 점입니다. 거래 설명은 제3자가 입력한 데이터이며, 겉보기에 일반 텍스트일지라도 LLM의 컨텍스트 창에 들어가면 모델이 이를 데이터가 아닌 명령으로 해석할 수 있습니다.
이것이 간접 프롬프트 인젝션의 핵심 문제입니다. 악의적인 명령이 사용자가 직접 비서와 상호작용하면서 입력하는 것이 아니라, 비서가 나중에 처리하는 외부 혹은 검색된 데이터 안에 숨겨져 있습니다. 개발자와 보안 팀은 AI 모델에 간접적으로 끌어들여지는 각 데이터 조각의 위험 수준을 평가하기가 복잡합니다.
공격 시나리오
개념 증명은 피해자의 기기에 접근할 필요도, 악성코드가 필요하지도, 전통적인 사회공학 기법이 필요하지도 않았습니다. 공격자는 작은 은행 이체만 보내면 되었습니다.
1단계. 공격자는 목표 계좌에 소액(예시에서는 €0.02)을 이체하고, 거래 설명란에 정교하게 만든 프롬프트 인젝션 페이로드를 삽입합니다. 이것이 공격자가 해야 할 전부입니다.
2단계. 피해자는 은행 앱을 열고 AI 비서에게 “최근 거래를 보여줘”와 같은 일상적인 질문을 합니다. 이후 공격은 AI 비서에 의해 자동·자율적으로 실행됩니다.
비서는 질문에 답하기 위해 거래 데이터를 가져오는데, 여기에는 공격자의 이체도 포함됩니다. 이 데이터를 LLM에 컨텍스트로 전달하면서, LLM은 거래 설명에 숨겨진 악성 명령을 처리합니다. 우리 통제된 시연에서는 비서가 은행 사용자를 대상으로 스피어피싱 공격을 수행하도록 조작되었습니다. 이 공격은 은행이 보낸 정식 재인증 요청처럼 가장되었습니다.
공격 흐름도: (1) 공격자가 거래 설명에 악성 명령을 삽입 → (2) 사용자가 비서에 질의 → (3) 거래 데이터가 LLM 컨텍스트에 포함 → (4) 비서의 응답이 삽입된 내용에 의해 영향을 받음.
그 결과 메시지는 은행 자체 애플리케이션 내, 은행 AI 비서가 보낸 것으로 표시됩니다. 실제 거래 세부 정보와 사용자 맞춤 정보를 참조할 수 있어 극히 설득력 있는 피싱이 됩니다.
AI 에이전트의 기능에 따라 동일한 신뢰 경계 실패가 여러 공격 시나리오로 이어질 수 있습니다.
금융 기관에 중요한 이유
다음과 같은 특성 때문에 이 공격 유형은 은행·금융 서비스에 특히 위협적입니다.
인젝션 표면이 흔함. 거래 설명, 결제 참조, 가맹점 메타데이터, 지원 메시지, 업로드된 문서, 이메일, CRM 메모 등은 모두 AI 비서가 결국 검색할 수 있는 데이터 필드이며, 대부분은 신뢰할 수 있는 명령 경계로 설계되지 않았습니다.
전달 메커니즘이 저비용·고신뢰. 아주 작은 이체만으로 공격자가 제어하는 텍스트를 피해자의 거래 내역에 삽입할 수 있습니다. 이후 이 페이로드는 은행 자체 애플리케이션이라는 극히 신뢰받는 채널을 통해 전달됩니다.
비서는 특권 컨텍스트를 가짐. 일반 피싱 이메일과 달리, 은행 AI 비서는 실제 계좌 정보를 접근할 수 있습니다. 따라서 조작된 응답은 더 개인적이고, 시의적절하며, 믿음직스럽습니다.
위험은 기능에 비례해 증가. 읽기 전용 비서라도 사용자를 오도할 수 있습니다. 도구, 워크플로, 계좌 작업에 접근 가능한 비서는 위험 표면이 크게 확대됩니다. 비서가 유용해질수록 보안 모델도 중요해집니다.
핵심 교훈은 간단합니다. AI 비서의 컨텍스트에 들어가는 모든 신뢰할 수 없는 데이터 소스는 비서의 공격 표면이 된다는 점입니다.
가드레일만으로는 부족한 이유
자연스러운 대응은 입력 필터, 프롬프트 인젝션 분류기, 콘텐츠 모더레이션 규칙 등을 추가하는 것입니다. 이러한 제어는 도움이 되지만 단독으로는 충분하지 않습니다.
Bunq의 AI 애플리케이션에도 가드레일이 있었지만, 문제는 여전히 지속되었습니다. 악의적인 의도가 거래 설명만으로는 명확히 드러나지 않았기 때문입니다. 페이로드는 “이전 명령 무시”와 같은 전형적인 탈옥 패턴을 사용하지 않았고, 거래 데이터에 섞여 있어 비서가 이를 검색·컨텍스트에 삽입하고 응답을 생성할 때 비로소 위험해졌습니다.
상단: 순진한 프롬프트 인젝션은 높은 신뢰도로 차단됨. 하단: 정교하게 만든 페이로드는 단독으로 검토했을 때 일반 거래 데이터와 구분하기 어려움.
이는 정적 텍스트 분류에만 의존하는 한계를 보여줍니다. 위험은 텍스트 자체에만 있는 것이 아니라, 신뢰할 수 없는 데이터 ↔ 검색 로직 ↔ 모델 동작 ↔ 애플리케이션 컨텍스트 ↔ 비서의 출력·행동 사이의 상호작용에서 발생합니다.
결론은 가드레일만으로는 부족하며, 다계층 보안 모델의 일부로 활용해야 한다는 것입니다. 입력 필터링은 명백한 공격을 감소시키고, 출력 제한은 해로운 응답이나 데이터 유출을 방지하며, 최소 권한 접근은 영향을 제한하고, 런타임 모니터링은 비서가 의도된 운영 프로파일을 벗어났을 때 탐지합니다.
효과적인 완화 방안
간접 프롬프트 인젝션을 완전히 차단하는 단일 제어는 없습니다. 실용적인 목표는 노출을 최소화하고, 위험한 행동을 제한하며, 방어가 무력화될 경우 침해를 탐지하는 것입니다.
이번 사례에서는 불필요한 거래 필드 노출 감소, 데이터와 명령의 명확한 구분, 외부 링크 제한, 비서 행동에 대한 이상 출력 모니터링 등을 포함한 완화 옵션을 논의하고, 구현된 방어책이 취약점을 효과적으로 해결함을 함께 검증했습니다.
일반적으로 AI 비서를 도입하는 금융 기관은 네 가지 계층의 제어를 고려해야 합니다.
1. 불필요한 컨텍스트 최소화. 비서에게 전달하는 필드가 다음 조건을 만족해야 합니다.