€0.01 송금 한 번으로 은행 AI 어시스턴트를 뚫을 수 있다

A €0.01 bank transfer could compromise a banking AI agent

Jun 10, 2026•tvissers•View Original

TL;DR Highlight

송금 메모에 심은 지시문이 은행 AI를 피싱 도구로 바꿨다

Who Should Read

거래내역·문서·메시지를 LLM 컨텍스트에 넣는 AI 어시스턴트를 운영하는 백엔드 개발자

Core Mechanics

송금 메모가 프롬프트 인젝션 통로였다
- 공격자는 €0.02를 보내며 거래 설명란에 악성 지시문을 넣었다.
- 피해자 기기 접근, 악성코드, 전통적 사회공학은 필요 없었다.
사용자는 평범한 질문만 했다
- 사용자가 "최근 거래 보여줘"라고 묻자 어시스턴트가 거래 데이터를 LLM 컨텍스트로 가져왔다.
- 모델이 메모 속 지시문을 따라 은행의 재인증 요청처럼 보이는 스피어피싱 메시지를 만들었다.
은행 앱 안에서 나온 피싱이라 믿기 쉽다
- 메시지가 은행 자체 앱의 AI 어시스턴트에서 나온다.
- 실제 거래 내역과 사용자 정보를 언급할 수 있어 신뢰도가 높다.
가드레일이 있었는데도 뚫렸다
- 은행 AI 앱에는 이미 가드레일이 있었다.
- 페이로드가 "ignore previous instructions" 같은 전형적 패턴 없이 거래 데이터에 섞이도록 만들어져 단독 텍스트 검사로는 구분이 어려웠다.
위험은 텍스트가 아니라 데이터 흐름에 있다
- 위험은 신뢰할 수 없는 데이터, 검색 로직, 모델 동작, 앱 맥락, 출력·액션이 만나는 지점에서 생긴다.
- 글은 프롬프트 인젝션을 모델 문제가 아니라 앱 보안·데이터 흐름·런타임 모니터링 문제로 본다.
글이 권하는 4겹 방어
- 불필요한 필드는 컨텍스트에 넣지 않는다.
- 검색된 데이터는 신뢰하지 않고 지시와 데이터를 구분한다.
- 링크 생성·자격증명 요청·고위험 툴 호출을 제한하고 런타임 동작을 모니터링한다.

Community Reactions

거래 조회에 LLM이 왜 필요하냐는 의견
- 댓글에서 "최근 거래 보여줘"는 결정적 DB 조회라 LLM 해석이 필요 없다는 지적이 나왔다.
- 외부 입력이 닿는 고위험 구간에서는 신뢰할 수 없는 데이터를 가능하면 아예 빼야 한다는 의견도 있었다.
구조적 한계를 짚는 의견
- 댓글에서 컨텍스트 안의 데이터가 지시로 해석되는 한 안전한 LLM은 없다는 의견이 나왔다.
- 이 의견을 쓴 댓글러는 "데이터와 지시를 어떻게 분리하나"를 AI 기능 도입 논의의 기준 질문으로 쓰겠다고 했다.
방어 아이디어 제안과 반론
- 댓글에서 신뢰 불가 마커 감싸기, 구조화 출력 생성 후 다른 에이전트로 검증하는 방식이 제안됐다.
- 다른 댓글은 커스텀 메시지 롤과 들여쓴 XML을 쓰고, 위험한 액션은 독립된 새 컨텍스트에서 승인받아야 한다고 했다.
- 검증 AI를 또 검증해야 하는 무한 회귀라는 냉소도 있었다.
글이 삭제됐고 수정 내용도 안 나온다는 경험
- 댓글에서 원문 링크가 블로그 메인으로 리다이렉트되고 아카이브 링크가 공유됐다.
- 실제 적용한 수정 내용이 글에 없다는 불만도 있었다.

How to Apply

컨텍스트에 들어가는 외부 입력 필드 목록 만들기
- 오늘 RAG·툴 응답이 프롬프트에 넣는 필드를 전부 뽑아 제3자가 쓸 수 있는 것(메모, 메시지, 문서)에 표시하라.
- 질문 처리에 필요 없는 필드는 기본값으로 컨텍스트에서 빼라.
단순 조회는 LLM 없이 렌더링하기
- "최근 거래 보여줘" 같은 결정적 조회는 DB 결과를 코드로 바로 보여주도록 분기하라.
- LLM은 요약이 꼭 필요한 경우에만 호출하라.
응답의 링크와 자격증명 요청 차단하기
- 출력 단계에서 허용 도메인 외 URL과 "재인증"·"비밀번호" 요청 패턴을 걸러라.
- 걸린 응답은 막고 로그에 남겨라.
런타임 행동 로그로 이상 징후 탐지하기
- 어시스턴트가 가져온 데이터, 생성한 출력, 호출한 툴을 기록하라.
- 평소와 다른 외부 URL 삽입이나 예상 밖 툴 호출이 보이면 알림을 보내라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 그대로 붙여넣기 (원문 방법의 간이 버전: 인젝션 점검용)

아래는 우리 AI 어시스턴트가 사용자 질문에 답하려고 컨텍스트에 넣는 데이터 필드 목록과 시스템 프롬프트다.

[시스템 프롬프트]
{{시스템 프롬프트}}

[컨텍스트에 들어가는 필드]
{{필드 목록: 예) 거래 설명, 가맹점명, 고객 메시지}}

[어시스턴트가 쓸 수 있는 출력/툴]
{{링크 생성 여부, 호출 가능한 툴}}

다음을 해줘.
1. 각 필드를 제3자가 쓸 수 있는지 여부로 분류해줘.
2. 제3자가 쓸 수 있는 필드에 간접 프롬프트 인젝션이 들어갈 때 가능한 시나리오를 필드별로 3개씩 써줘. (고전적인 "이전 지시 무시" 문구 없이 데이터에 섞인 형태로)
3. 각 시나리오에 대해 (a) 컨텍스트 최소화 (b) 데이터와 지시 분리 (c) 출력·액션 제한 (d) 런타임 모니터링 중 어떤 방어가 효과적인지 표로 정리해줘.

Terminology

간접 프롬프트 인젝션사용자가 아니라 검색·조회된 외부 데이터 속에 악성 지시를 숨겨두는 공격이다. 택배 상자 안에 몰래 넣은 쪽지를 직원이 명령으로 읽는 것과 비슷하다.

스피어피싱특정 개인의 정보를 활용해 맞춤형으로 속이는 피싱이다. 불특정 다수에게 보내는 스팸과 달리 내 거래 내역까지 아는 척한다.

신뢰 경계믿을 수 있는 코드·데이터와 믿을 수 없는 입력을 나누는 선이다. 건물 출입구의 보안 검색대 같은 역할이다.

최소 권한작업에 꼭 필요한 접근 권한만 주는 원칙이다. 청소부에게 금고 열쇠를 주지 않는 것과 같다.

행동 프로파일어시스턴트가 평소 어떤 데이터에 접근하고 어떤 툴을 쓰는지 정리한 기준선이다. 평소와 다르면 이상 신호로 본다.

Related Resources

€0.01 송금 한 번으로 은행 AI 어시스턴트를 뚫을 수 있다

A €0.01 bank transfer could compromise a banking AI agent

Jun 10, 2026•tvissers•View Original

TL;DR Highlight

송금 메모에 심은 지시문이 은행 AI를 피싱 도구로 바꿨다

Who Should Read

거래내역·문서·메시지를 LLM 컨텍스트에 넣는 AI 어시스턴트를 운영하는 백엔드 개발자

Core Mechanics

송금 메모가 프롬프트 인젝션 통로였다
- 공격자는 €0.02를 보내며 거래 설명란에 악성 지시문을 넣었다.
- 피해자 기기 접근, 악성코드, 전통적 사회공학은 필요 없었다.
사용자는 평범한 질문만 했다
- 사용자가 "최근 거래 보여줘"라고 묻자 어시스턴트가 거래 데이터를 LLM 컨텍스트로 가져왔다.
- 모델이 메모 속 지시문을 따라 은행의 재인증 요청처럼 보이는 스피어피싱 메시지를 만들었다.
은행 앱 안에서 나온 피싱이라 믿기 쉽다
- 메시지가 은행 자체 앱의 AI 어시스턴트에서 나온다.
- 실제 거래 내역과 사용자 정보를 언급할 수 있어 신뢰도가 높다.
가드레일이 있었는데도 뚫렸다
- 은행 AI 앱에는 이미 가드레일이 있었다.
- 페이로드가 "ignore previous instructions" 같은 전형적 패턴 없이 거래 데이터에 섞이도록 만들어져 단독 텍스트 검사로는 구분이 어려웠다.
위험은 텍스트가 아니라 데이터 흐름에 있다
- 위험은 신뢰할 수 없는 데이터, 검색 로직, 모델 동작, 앱 맥락, 출력·액션이 만나는 지점에서 생긴다.
- 글은 프롬프트 인젝션을 모델 문제가 아니라 앱 보안·데이터 흐름·런타임 모니터링 문제로 본다.
글이 권하는 4겹 방어
- 불필요한 필드는 컨텍스트에 넣지 않는다.
- 검색된 데이터는 신뢰하지 않고 지시와 데이터를 구분한다.
- 링크 생성·자격증명 요청·고위험 툴 호출을 제한하고 런타임 동작을 모니터링한다.

Community Reactions

거래 조회에 LLM이 왜 필요하냐는 의견
- 댓글에서 "최근 거래 보여줘"는 결정적 DB 조회라 LLM 해석이 필요 없다는 지적이 나왔다.
- 외부 입력이 닿는 고위험 구간에서는 신뢰할 수 없는 데이터를 가능하면 아예 빼야 한다는 의견도 있었다.
구조적 한계를 짚는 의견
- 댓글에서 컨텍스트 안의 데이터가 지시로 해석되는 한 안전한 LLM은 없다는 의견이 나왔다.
- 이 의견을 쓴 댓글러는 "데이터와 지시를 어떻게 분리하나"를 AI 기능 도입 논의의 기준 질문으로 쓰겠다고 했다.
방어 아이디어 제안과 반론
- 댓글에서 신뢰 불가 마커 감싸기, 구조화 출력 생성 후 다른 에이전트로 검증하는 방식이 제안됐다.
- 다른 댓글은 커스텀 메시지 롤과 들여쓴 XML을 쓰고, 위험한 액션은 독립된 새 컨텍스트에서 승인받아야 한다고 했다.
- 검증 AI를 또 검증해야 하는 무한 회귀라는 냉소도 있었다.
글이 삭제됐고 수정 내용도 안 나온다는 경험
- 댓글에서 원문 링크가 블로그 메인으로 리다이렉트되고 아카이브 링크가 공유됐다.
- 실제 적용한 수정 내용이 글에 없다는 불만도 있었다.

How to Apply

컨텍스트에 들어가는 외부 입력 필드 목록 만들기
- 오늘 RAG·툴 응답이 프롬프트에 넣는 필드를 전부 뽑아 제3자가 쓸 수 있는 것(메모, 메시지, 문서)에 표시하라.
- 질문 처리에 필요 없는 필드는 기본값으로 컨텍스트에서 빼라.
단순 조회는 LLM 없이 렌더링하기
- "최근 거래 보여줘" 같은 결정적 조회는 DB 결과를 코드로 바로 보여주도록 분기하라.
- LLM은 요약이 꼭 필요한 경우에만 호출하라.
응답의 링크와 자격증명 요청 차단하기
- 출력 단계에서 허용 도메인 외 URL과 "재인증"·"비밀번호" 요청 패턴을 걸러라.
- 걸린 응답은 막고 로그에 남겨라.
런타임 행동 로그로 이상 징후 탐지하기
- 어시스턴트가 가져온 데이터, 생성한 출력, 호출한 툴을 기록하라.
- 평소와 다른 외부 URL 삽입이나 예상 밖 툴 호출이 보이면 알림을 보내라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 그대로 붙여넣기 (원문 방법의 간이 버전: 인젝션 점검용)

아래는 우리 AI 어시스턴트가 사용자 질문에 답하려고 컨텍스트에 넣는 데이터 필드 목록과 시스템 프롬프트다.

[시스템 프롬프트]
{{시스템 프롬프트}}

[컨텍스트에 들어가는 필드]
{{필드 목록: 예) 거래 설명, 가맹점명, 고객 메시지}}

[어시스턴트가 쓸 수 있는 출력/툴]
{{링크 생성 여부, 호출 가능한 툴}}

다음을 해줘.
1. 각 필드를 제3자가 쓸 수 있는지 여부로 분류해줘.
2. 제3자가 쓸 수 있는 필드에 간접 프롬프트 인젝션이 들어갈 때 가능한 시나리오를 필드별로 3개씩 써줘. (고전적인 "이전 지시 무시" 문구 없이 데이터에 섞인 형태로)
3. 각 시나리오에 대해 (a) 컨텍스트 최소화 (b) 데이터와 지시 분리 (c) 출력·액션 제한 (d) 런타임 모니터링 중 어떤 방어가 효과적인지 표로 정리해줘.

Terminology

스피어피싱특정 개인의 정보를 활용해 맞춤형으로 속이는 피싱이다. 불특정 다수에게 보내는 스팸과 달리 내 거래 내역까지 아는 척한다.

신뢰 경계믿을 수 있는 코드·데이터와 믿을 수 없는 입력을 나누는 선이다. 건물 출입구의 보안 검색대 같은 역할이다.

최소 권한작업에 꼭 필요한 접근 권한만 주는 원칙이다. 청소부에게 금고 열쇠를 주지 않는 것과 같다.

행동 프로파일어시스턴트가 평소 어떤 데이터에 접근하고 어떤 툴을 쓰는지 정리한 기준선이다. 평소와 다르면 이상 신호로 본다.

€0.01 송금 한 번으로 은행 AI 어시스턴트를 뚫을 수 있다

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

€0.01 송금 한 번으로 은행 AI 어시스턴트를 뚫을 수 있다

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources