간접 프롬프트 인젝션에 대한 은행 AI 에이전트 보안

은행 송금을 통한 간접 프롬프트 인젝션

‘’0.02만큼 작은 은행 송금 하나라도, altamente 신뢰할 수 있는 스피어피싱 공격의 전달 채널로 변하게 하여 은행 AI 어시스턴트를 손상시킬 수 있습니다. 이 취약점은 디지털 은행 Bunq를 테스트하는 동안 Blue41이 식별했으며, AI 어시스턴트가 신뢰할 수 없는 트랜잭션 데이터를 검색하여 Large Language Model(LLM)의 컨텍스트로 전달할 때 발생합니다.これにより、모델은 트랜잭션 설명에 숨겨진 악성 명령을 정당한 명령으로 해석할 수 있게 됩니다.

공격 메커니즘: 데이터에서 명령으로

간접 프롬프트 인젝션은 사용자가 제공하지 않은 악성 명령이 AI 어시스턴트가 나중에 처리하는 외부 데이터에 내장될 때 발생합니다. Bunq AI 어시스턴트의 경우, 공격은 다음과 같은 특정 순서를 따릅니다:

1. 주입: 공격자는 목표물에 작은 은행 송금(예: ‘’0.02)을 보냅니다. 트랜잭션 설명 필드는 신중하게 제작된 프롬프트 인젝션 페이로드를 담는 데 사용됩니다.
2. 검색: 피해자는 AI 어시스턴트에게 routine한 질문, 예를 들어 ‘‘Show me my recent transactions’’을 합니다. 어시스턴트는 공격자의 송금을 포함한 트랜잭션 기록을 가져와 LLM 컨텍스트 윈도우에 공급합니다.
3. 실행: LLM은 트랜잭션 설명 내의 주입된 명령을 처리합니다. 입증된 개념 증명에서, 어시스턴트는 스피어피싱 공격을 시작하도록 조작되어, 은행 자체에서 온 것처럼 보이는 가짜 재인증 요청을 사용자에게 제시했습니다.

은행 자체 애플리케이션을 통해 메시지가 전달되고 실제 계정 세부 정보를 참조할 수 있기 때문에, 이 피싱 시도는 전통적인 이메일 기반 피싱보다 훨씬 더 신뢰할 수 있습니다.

왜 금융 AI 어시스턴트가 고위험인가

금융 기관은 다음과 같은 구조적 요인으로 인해 이 유형의 공격에 특히 취약합니다:

• 일반적인 주입 표면: 결제 참조, 상인 메타데이터, 지원 메시지와 같은 필드는 AI 어시스턴트에 의해 자주 검색되지만 신뢰할 수 있는 명령 경계로 설계되지 않았습니다.
• 저비용 전달: 미세한 송금만으로 공격자는 피해자의 트랜잭션 기록에 직접 제어된 텍스트를 배치할 수 있습니다.
• 특권 컨텍스트: 외부 피싱과 달리, AI 어시스턴트는 실제 계정 데이터에 접근할 수 있어 조작된 응답이 더 개인화되고 믿을 수 있게 됩니다.
• 확장되는 기능: 어시스턴트가 읽기 전용 요약에서 도구 및 워크플로 실행으로 이동함에 따라, 성공적인 주입의 잠재적 영향이 증가합니다.

정적 가드레일의 실패

입력 필터 및 프롬프트 인젝션 분류자와 같은 표준 보안 조치는 페이로드가 고립되어 볼 때 악의적인 의도가 자주 보이지 않기 때문에 종종 부족합니다.

Blue41은 Bunq의 AI 애플리케이션에 가드레일이 존재함에도 불구하고 취약점이 지속되었다고 지적했습니다. 페이로드는 ‘‘ignore previous instructions’’와 같은 클래식 제이브레이크 패턴에 의존하지 않았으며, 대신 트랜잭션 데이터에 녹아들도록 제작되었으며, LLM이 이를 더 넓은 애플리케이션 컨텍스트에 통합할 때만 위험해졌습니다.

AI 에이전트를 위한 완화 전략

효과적인 방어는 단일 통제가 아닌 계층 보안 모델이 필요합니다. 권장되는 완화 조치는 다음과 같습니다:

1. 컨텍스트 최소화

사용자의 현재 작업에 엄격히 필요한 경우가 아니면 데이터 필드를 LLM에 전달하지 마세요. 트랜잭션 설명이 쿼리에 답변하는 데 필요하지 않다면, 모델 컨텍스트에서 제외해야 합니다.

2. 명시적 데이터-명령 분리

아키텍처는 검색된 데이터(트랜잭션 설명, 이메일, API 응답)를 지시가 아닌 신뢰할 수 없는 데이터로 취급해야 합니다. 이는 사용자의 의도와 검색된 컨텍스트 사이에 엄격한 경계를 유지하는 것을 포함합니다.

3. 출력 제한

어시스턴트는 보조적인 독립 검증 없이 외부 링크를 자유롭게 생성하거나, 자격 증명을 요청하거나, 민감한 워크플로우를 시작해서는 안 됩니다.

4. 행동 런타임 모니터링

모든 가능한 페이로드를 방지하는 것은 비현실적이므로, 보안 팀은 이상 행동을 모니터링해야 합니다. 여기에는 어시스턴트가 갑자기 외부 URL을 임베딩하기 시작하거나, 표준 정보를 억제하거나, 확립된 행동 프로필에서 벗어난 패턴으로 API를 호출하는지 추적하는 것이 포함됩니다.

기술적 관점과 비판

이 취약점에 대한 산업 논의는 LLM 아키텍처에서의 근본적인 긴장을 강조합니다. 일부 비평가들은 LLMs가 데이터와 명령을 본질적으로 분리할 수 없는 inability이 금융 응용 프로그램에 근본적으로 안전하지 않게 만든다고 주장합니다.

"I feel like as long as this is case, we'll never have secure LLMs... how do you plan on separating data from instructions?"

다른 기술 관찰자들은 이 문제를 웹의 초기 시기와 비교하며, 프롬프트 인젝션이 개발자가 모든 인간 제공 입력을 정화하기 전에 발생한 SQL 인젝션 또는 크로스 사이트 스크립팅(XSS) 취약점의 현대판이라고 지적했습니다.

일부 회의론자는 공격의 실용성을 의문시하며, 사용자가 특정 트랜잭션에 대해 AI에게 적극적으로 물어보고 링크를 클릭해야 한다는 점을 들어 대규모 공격에 대한 높은 마찰 경로로 볼 수 있다고 지적했습니다. 그러나 핵심 취약점은 외부 데이터와 모델 명령 사이의 신뢰 경계 실패로 남아 있습니다.