Blue41은 2,000만 명 이상의 고객을 보유한 유럽에서 두 번째로 큰 디지털 은행인 Bunq가 스피어 피싱 (Spearphishing) 위

Blue41은 2,000만 명 이상의 고객을 보유한 유럽에서 두 번째로 큰 디지털 은행인 Bunq가 스피어 피싱 (Spearphishing) 위험으로부터 AI 어시스턴트를 보호할 수 있도록 도왔습니다. 테스트 과정에서 당사는 단 한 번의 은행 송금만으로도 어시스턴트가 매우 신뢰도 높은 피싱 공격의 전달 채널로 변질될 수 있는 간접 프롬프트 주입 (Indirect Prompt Injection) 취약점을 식별했습니다.

우리가 이 사례를 공유하는 이유는 근본적인 문제가 특정 은행에만 국한된 것이 아니기 때문입니다. 이는 거래 데이터, 고객 기록, 문서, 메시지 또는 기타 신뢰할 수 없는 입력값을 처리하는 AI 어시스턴트를 배포하는 금융 기관들이 직면한 더 광범위한 아키텍처 (Architecture) 측의 과제입니다.

0.02유로의 은행 송금에서 뱅킹 AI 어시스턴트 내부의 개인화된 피싱 시나리오까지.

현대의 뱅킹 앱에는 AI 기반 기능이 점점 더 많이 포함되고 있습니다. 이러한 기능은 사용자와 거래 기록, 제품 문서, 계좌 세부 정보, 지원 콘텐츠 및 기타 내부 시스템과 같은 다양한 백엔드 (Backend) 데이터 소스 사이에 위치합니다. 이들은 해당 컨텍스트 (Context)를 기반으로 자연어 질문에 답하기 위해 대규모 언어 모델 (LLM)을 사용합니다.

전형적인 금융 AI 어시스턴트의 아키텍처: 사용자는 뱅킹 앱을 통해 상호작용하며, 어시스턴트는 거래 데이터, 문서 및 기타 소스에서 컨텍스트를 검색하고 외부 도구를 호출할 수 있습니다.

사용자가 “최근 거래 내역을 요약해 줘”라고 요청하면, 어시스턴트는 관련 기록을 가져와 이를 LLM에 컨텍스트로 전달합니다. 그러면 모델은 대화형 응답으로 데이터를 요약합니다.

보안상의 과제는 검색된 모든 컨텍스트를 동일하게 신뢰해서는 안 된다는 점입니다. 거래 설명은 제3자에 의해 설정된 데이터입니다. 이는 일반적인 텍스트처럼 보일 수 있지만, LLM의 컨텍스트 윈도우 (Context Window)에 배치될 때 모델은 이를 데이터가 아닌 명령 (Instruction)으로 해석할 수 있습니다.

이것이 간접 프롬프트 인젝션 (Indirect Prompt Injection)의 핵심 문제입니다. 악의적인 명령 (Instruction)은 어시스턴트와 상호작용하는 사용자에 의해 입력되는 것이 아닙니다. 대신, 어시스턴트가 나중에 처리하게 될 외부 데이터나 검색된 데이터 내부에 숨겨져 있습니다. 개발자와 보안 팀 입장에서는 AI 모델로 간접적으로 끌어오는 각 데이터 조각의 위험 수준 (Risk-level)을 평가하는 것이 매우 복잡합니다.

이 개념 증명 (Proof of Concept)에는 피해자의 기기에 대한 접근, 멀웨어 (Malware), 또는 전통적인 사회 공학 (Social Engineering) 기법이 전혀 필요하지 않았습니다. 공격자는 단지 소액의 은행 송금만 보내면 되었습니다.

1단계. 공격자는 대상에게 소액, 본 사례의 경우 0.02유로를 송금합니다. 이때 거래 내역 설명 (Transaction description) 필드에 정교하게 제작된 프롬프트 인젝션 (Prompt injection) 페이로드 (Payload)를 포함합니다. 이것이 공격자가 취해야 할 유일한 행동입니다.

2단계. 피해자가 뱅킹 앱을 열고 AI 어시스턴트에게 "최근 거래 내역을 보여줘"와 같은 일상적인 질문을 합니다. 공격의 나머지 과정은 AI 어시스턴트에 의해 자동으로, 그리고 자율적으로 실행됩니다.

해당 질문에 답하기 위해, AI 어시스턴트는 공격자의 송금을 포함한 거래 데이터를 검색하고, 이를 사용자의 질문에 답하는 데 필요한 컨텍스트 (Context)의 일부로 LLM (Large Language Model)에 전달합니다. 그러면 LLM은 거래 설명 내에 삽입된 명령 (Instruction)을 처리합니다. 통제된 시연 환경에서, 어시스턴트는 은행의 사용자를 대상으로 스피어 피싱 (Spearphishing) 공격을 시작하도록 조작되었으며, 이는 은행에서 보낸 정당한 재인증 요청인 것처럼 제시되었습니다.

공격의 구조: 공격자가 거래 설명을 통해 악의적인 명령을 주입하고 (1), 사용자가 어시스턴트에게 질의하며 (2), 거래 데이터가 LLM 컨텍스트로 검색되고 (3), 어시스턴트의 응답이 주입된 콘텐츠에 의해 영향을 받습니다 (4).

결과적으로 생성된 메시지는 은행 자체 애플리케이션 내부에서, 은행의 자체 AI 어시스턴트를 통해 나타납니다. 이 메시지는 실제 거래 세부 정보와 사용자별 정보를 참조할 수 있으므로, 매우 신뢰도가 높은 피싱 (Phishing) 공격이 될 수 있습니다.

동일한 신뢰 경계 실패 (trust-boundary failure)는 AI 에이전트의 역량에 따라 여러 가지 공격 시나리오로 이어질 수 있습니다.

몇 가지 특성으로 인해 이러한 유형의 공격은 뱅킹 및 금융 서비스에 특히 유의미합니다.

주입 표면 (injection surface)이 흔합니다. 거래 내역 설명, 결제 참조 (payment references), 가맹점 메타데이터 (merchant metadata), 고객 지원 메시지, 업로드된 문서, 이메일, 그리고 CRM 노트 등은 모두 AI 어시스턴트가 결국 검색하게 될 수 있는 데이터 필드의 예시입니다. 이러한 필드 중 상당수는 처음부터 신뢰할 수 있는 지시 경계 (instruction boundaries)로 설계되지 않았습니다.

전달 메커니즘이 저렴하고 신뢰도가 높습니다. 아주 적은 금액의 송금만으로도 공격자가 제어하는 텍스트를 피해자의 거래 내역 안에 배치할 수 있습니다. 그 후 페이로드 (payload)는 은행 자체 애플리케이션이라는 매우 신뢰할 수 있는 채널을 통해 전달됩니다.

어시스턴트는 권한이 있는 컨텍스트 (privileged context)를 가집니다. 피싱 이메일과 달리, 뱅킹 AI 어시스턴트는 실제 계정 컨텍스트에 접근할 수 있습니다. 이는 조작된 응답을 더욱 개인화되고, 시의적절하며, 믿을 수 있게 만듭니다.

역량이 커질수록 위험도 증가합니다. 읽기 전용 (read-only) 어시스턴트도 여전히 사용자를 오도할 수 있습니다. 도구 (tools), 워크플로우 (workflows), 또는 계정 운영에 접근할 수 있는 어시스턴트는 더 큰 위험 표면 (risk surface)을 유발합니다. 어시스턴트가 유용해질수록, 그 보안 모델은 더욱 중요해집니다.

더 넓은 관점에서의 교훈은 간단합니다. AI 어시스턴트의 컨텍스트로 들어오는 모든 신뢰할 수 없는 데이터 소스는 어시스턴트의 공격 표면 (attack surface)의 일부가 됩니다.

자연스러운 대응책은 입력 필터 (input filters), 프롬프트 인젝션 분류기 (prompt injection classifiers), 또는 콘텐츠 모더레이션 (content moderation) 규칙을 추가하는 것입니다. 이러한 제어 장치들이 도움이 될 수는 있지만, 그것만으로는 충분하지 않습니다.

Bunq의 AI 애플리케이션에는 가드레일 (guardrails)이 마련되어 있었습니다. 문제는 악의적인 의도가 거래 내역(transaction description) 자체만으로는 명확히 드러나지 않았기 때문에 문제가 지속되었다는 점입니다. 페이로드 (payload)에 “이전 지침을 무시하라(ignore previous instructions)”와 같은 전형적인 탈옥 (jailbreak) 패턴을 포함할 필요도 없었습니다. 이는 거래 데이터 속에 자연스럽게 섞이도록 설계되었으며, 어시스턴트 (assistant)가 해당 데이터를 검색(retrieval)하여 컨텍스트 (context)에 배치하고 이를 바탕으로 응답을 생성하는 순간에만 위험해졌습니다.

단순한 프롬프트 인젝션 (prompt injection)은 높은 신뢰도로 탐지됩니다 (상단). 하지만 더 정교하게 설계된 페이로드는 단독으로 검토될 때 일반적인 거래 데이터와 구별하기 어려울 수 있습니다 (하단).

이것이 정적 텍스트 분류 (static text classification)에만 의존할 때의 한계입니다. 위험은 텍스트 자체에만 있는 것이 아닙니다. 위험은 신뢰할 수 없는 데이터 (untrusted data), 검색 로직 (retrieval logic), 모델 동작 (model behavior), 애플리케이션 컨텍스트 (application context), 그리고 어시스턴트가 사용할 수 있는 출력 (outputs) 또는 동작 (actions) 사이의 상호작용에서 발생합니다.

결론은 가드레일만으로는 충분하지 않으며, 계층화된 보안 모델 (layered security model)의 일부가 되어야 한다는 것입니다. 입력 필터링 (input filtering)은 명백한 공격을 줄이는 데 도움이 됩니다. 출력 제약 (output constraints)은 일부 유해한 응답이나 데이터 유출을 방지할 수 있습니다. 최소 권한 원칙 (least-privilege access)은 영향 범위를 제한합니다. 런타임 모니터링 (runtime monitoring)은 어시스턴트가 의도된 운영 프로필을 벗어나 동작할 때 이를 탐지하는 데 도움이 됩니다.

간접 프롬프트 인젝션 (indirect prompt injection)을 해결하는 단일 제어 장치는 없습니다. 실질적인 목표는 노출을 줄이고, 위험한 동작을 제한하며, 보호 조치가 실패했을 때 침해 사실을 탐지하는 것입니다.

이 사례에서 우리는 신뢰할 수 없는 거래 필드에 대한 불필요한 노출을 줄이고, 데이터와 지침을 명확히 분리하며, 외부 링크 (outbound links)를 제한하고, 비정상적인 출력을 위해 어시스턴트의 동작을 모니터링하는 등의 완화 옵션 (remediation options)을 논의했습니다. 그런 다음 구현된 완화 조치들이 취약점을 효과적으로 해결했음을 함께 검증했습니다.

보다 일반적으로, AI 어시스턴트를 도입하는 금융 기관은 네 가지 계층의 제어 (layers of control)를 고려해야 합니다.

1. 불필요한 컨텍스트 (context) 최소화. 사용자의 작업에 필요하지 않은 필드는 어시스턴트에게 전달하지 마십시오. 질문에 답하기 위해 거래 내역 설명 (transaction description)이 필요하지 않다면, 기본적으로 모델의 컨텍스트 (context)에 포함되어서는 안 됩니다.

2. 검색된 데이터를 신뢰할 수 없는 것으로 취급. 거래 내역 설명, 고객 메시지, 문서, 이메일 및 API 응답은 지시 사항 (instructions)이 아닌 데이터 (data)로 취급해야 합니다. 어시스턴트 아키텍처 (architecture)는 이러한 구분을 명시적으로 유지해야 합니다.

3. 민감한 출력 및 작업 제한. 어시스턴트는 추가적인 제어 장치 없이 자유롭게 링크를 생성하거나, 인증 정보 (credentials)를 요청하거나, 민감한 워크플로 (workflows)를 시작하거나, 영향력이 큰 도구 (tools)를 호출해서는 안 됩니다.

4. 런타임 동작 (runtime behavior) 모니터링. 훌륭한 예방 제어 장치가 있더라도 새로운 공격은 계속 나타날 것입니다. 보안 팀은 어시스턴트가 무엇을 검색했는지, 무엇을 생성했는지, 어떤 도구를 사용했는지, 그리고 해당 동작이 애플리케이션의 의도된 프로필 (profile)과 일치하는지에 대한 가시성 (visibility)을 확보해야 합니다.

가능한 모든 인젝션 페이로드 (injection payload)를 방지하는 것은 비현실적입니다. 공격자는 문구를 조정하고, 의도를 숨기며, 일반적인 분류기 (classifiers)가 이해하지 못하는 애플리케이션 특유의 컨텍스트 (context)를 악용할 수 있습니다.

하지만 AI 어시스턴트가 침해되면, 그 동작은 종종 관찰 가능한 방식으로 변화합니다. 외부 URL을 삽입하기 시작하거나, 평소에 표시하던 정보를 억제하거나, 비정상적인 응답 패턴을 따르거나, 예상치 못한 데이터 소스에 접근하거나, 일반적인 사용 방식과 일치하지 않는 방식으로 도구 (tools)를 호출할 수 있습니다.

이것이 Blue41이 취하는 접근 방식입니다. 우리는 AI 에이전트의 런타임 동작 (runtime behavior)을 모니터링하고, 각 어시스턴트가 정상적으로 작동하는 방식에 대한 행동 프로필 (behavioral profiles)을 구축합니다. 즉, 어떤 데이터 소스에 접근하는지, 어떤 응답 패턴이 예상되는지, 어떤 도구와 API를 사용하는지, 그리고 어떤 편차가 조사를 촉발해야 하는지를 정의합니다.

목표는 AI 어시스턴트가 실제 비즈니스 워크플로 (workflows)의 일부가 되었을 때, 보안 및 AI 팀에 필요한 가시성 (visibility)을 제공하는 것입니다.

금융 서비스 분야의 AI 어시스턴트 (AI assistants)는 더 이상 실험적인 사이드 프로젝트가 아닙니다. 이들은 고객 대면 및 직원 대면 워크플로 (workflows)에 배치되어 민감한 데이터를 처리하고 실제 의사 결정에 영향을 미치고 있습니다.

전통적인 애플리케이션 보안 (application security)은 코드와 데이터 사이에 비교적 명확한 경계가 있다고 가정합니다. 하지만 AI 어시스턴트는 그 경계를 모호하게 만듭니다. 이들은 데이터를 검색하고, 해석하며, 추론하고, 궁극적으로는 그 데이터를 바탕으로 행동할 수 있습니다. 결과적으로, 한때 무해했던 텍스트 필드(fields)가 강력한 애플리케이션 내에서 명령 채널 (instruction channels)로 변할 수 있습니다.

이는 어시스턴트가 거래 데이터, 고객 기록, 컴플라이언스 (compliance) 정보, 제품 문서, 지원 티켓 (support tickets), 그리고 궁극적으로는 운영 도구와 상호작용할 수 있는 은행 분야에서 특히 중요합니다.

금융 기관이 AI 어시스턴트 배포를 중단할 필요는 없습니다. 하지만 새로운 신뢰 경계 (trust boundaries), 새로운 실패 모드 (failure modes), 그리고 새로운 모니터링 요구 사항을 가진 프로덕션 시스템 (production systems)으로 취급해야 합니다.

이 사례는 아주 작고 평범한 은행 송금이 어떻게 AI 어시스턴트 아키텍처 (architecture)의 훨씬 더 큰 문제를 드러낼 수 있는지 보여줍니다. 문제는 송금 그 자체가 아닙니다. 신뢰할 수 없는 데이터가 어시스턴트의 컨텍스트 (context)에 유입되어 어시스턴트가 말하거나 행동하는 것에 영향을 미칠 수 있다는 사실입니다.

더 넓은 관점에서의 교훈은 AI 어시스턴트를 배포하는 모든 금융 기관에 해당됩니다. 프롬프트 인젝션 (prompt injection)은 단지 모델의 문제만이 아닙니다. 이는 애플리케이션 보안 문제이자, 데이터 흐름 (data-flow) 문제이며, 런타임 모니터링 (runtime monitoring) 문제입니다.

귀하의 팀이 금융 서비스에서 AI 어시스턴트를 배포하거나 평가하고 있다면, Blue41은 신뢰할 수 없는 데이터가 에이전트 컨텍스트의 어디로 유입되는지, 어떤 동작을 모니터링해야 하는지, 그리고 프로덕션으로 확장하기 전에 어떤 통제 장치 (controls)가 필요한지를 평가하는 데 도움을 줄 수 있습니다.

간단한 소개 미팅을 예약하세요. 귀하의 AI 배포 현황에 대해 알아보고 저희가 도움을 드릴 수 있는 부분을 탐색하게 되어 기쁠 것입니다.