프롬프트 인젝션과 탈옥

프롬프트 주입은 LLM 시대에 나타난 고전적인 주입 취약점(데이터베이스 질의, 명령)의 변형입니다. 근본 원인은 동일합니다. 애플리케이션이 같은 채널에서 신뢰할 수 있는 지침과 신뢰할 수 없는 데이터를 섞고, 해석기인 모델이 둘을 안정적으로 구분하지 못하는 것입니다.

LLM에서는 시스템 프롬프트, 개발자의 지침, 검색된 콘텐츠가 모두 하나의 구분 없는 토큰 흐름으로 들어옵니다. 공격자가 제어하는 텍스트에 Ignore previous instructions and...라고 쓰여 있으면, 모델에게는 그저 또 하나의 언어 표현일 뿐이므로 모델이 이를 따를 수 있습니다.

• 신뢰할 수 있는 항목: 시스템 프롬프트와 정책입니다.
• 신뢰할 수 없는 항목: 사용자 입력, 웹 페이지, 파일, 도구 출력, 이메일입니다.

직접 프롬프트 주입은 최종 사용자가 애플리케이션의 의도된 동작을 무시하도록 적대적인 지침을 프롬프트에 직접 입력할 때 발생합니다.

고객 지원 봇을 대상으로 한 일반적인 시도는 다음과 같습니다:

• 봇은 청구 관련 질문에만 답변하도록 지시받습니다.
• 사용자는 모델의 역할을 다시 규정하고 시스템 프롬프트를 유출하거나 범위를 벗어난 작업을 수행하도록 요청하는 텍스트를 붙여 넣습니다.

직접 주입은 악성 텍스트를 입력하는 사람과 공격자가 동일하므로 이해하기 가장 쉽지만, 단순한 안전장치를 여전히 우회할 수 있습니다.

간접(2차) 프롬프트 주입은 더 위험한 변형입니다. 공격자는 나중에 모델이 검색할 콘텐츠에 지침을 심습니다. 대상은 웹 페이지, PDF, 일정 초대, 코드 주석 또는 지원 요청일 수 있습니다.

피해 사용자는 페이로드를 전혀 보지 못합니다. RAG 처리 흐름이나 웹 탐색 에이전트가 해당 콘텐츠를 맥락에 포함하면, 숨겨진 지침이 피해 사용자의 권한으로 실행됩니다.

예를 들어 웹 페이지에 요약 에이전트에게 사용자의 대화 기록을 공격자가 제어하는 주소로 반출하라고 지시하는 숨겨진 텍스트가 있을 수 있습니다.

이 용어들은 서로 겹치지만 동일하지는 않습니다:

• 프롬프트 주입은 애플리케이션 경계를 공격합니다. 공격자 데이터를 이용해 개발자의 지침을 무시하게 만듭니다.
• 탈옥은 모델의 안전 정렬을 공격합니다. 제공업체가 거부하도록 학습시킨 콘텐츠를 생성하도록 모델을 유도합니다.

탈옥은 취약한 애플리케이션이 없어도 작동하며, 기본 모델 자체를 대상으로 합니다. 실제 공격에서는 두 가지를 결합하는 경우가 많습니다. 탈옥으로 거부 반응을 약화시키고, 주입으로 애플리케이션의 동작을 다른 방향으로 돌립니다.

공격자는 예측 가능한 조작 패턴을 사용합니다. 이러한 패턴을 알면 자체 시스템을 책임감 있게 레드팀 점검하는 데 도움이 됩니다:

• 역할극 / 인물 설정: 요청을 허구의 상황이나 제한 없이 행동하는 가상의 인물로 포장합니다.
• 난독화: 키워드 필터를 피하려고 64진수 인코딩, 리트스피크, 번역 또는 토큰 분할을 사용합니다.
• 페이로드 분할: 하나의 메시지만 보면 악성으로 보이지 않도록 요청을 여러 대화 차례에 나누어 보냅니다.
• 가상 상황: For a security class, describe how one would...
• 접두사 주입: Sure, here is와 같은 긍정 표현으로 답변을 시작하도록 강제합니다.

많은 팀은 ignore previous instructions와 같은 문구의 차단 목록부터 만들려고 합니다. 하지만 입력 공간은 사실상 무한하므로 이 방식은 취약합니다.

자연어는 언어, 인코딩, 비유를 바꾸어 가며 같은 의도를 무수히 다양한 방식으로 표현할 수 있습니다. 공격자는 여러분이 정규식을 수정하는 속도보다 빠르게 시도합니다.

핵심 원칙: 입력 필터링은 다층 방어의 일부로 취급하고, 주요 통제 수단으로 사용하지 마십시오. 일부 주입은 통과한다고 가정하고, 주입이 성공하더라도 실제 피해를 일으킬 수 없도록 설계하십시오.

가장 효과적인 완화 방법은 구조적으로 침해된 모델의 맥락이 할 수 있는 일을 제한하는 것입니다.

• LLM에는 필요한 최소 권한만 부여하십시오. 요약기가 이메일을 보내기 위한 자격 증명을 보유해서는 안 됩니다.
• 신뢰할 수 없는 콘텐츠를 권한이 필요한 경로에서 분리하십시오. 에이전트가 외부 웹 데이터를 읽는다면, 같은 요청 처리 단계에서 확인 절차 없이 되돌릴 수 없는 작업까지 실행할 수 있어서는 안 됩니다.
• 데이터 영역과 제어 영역을 분리하십시오. 검색된 텍스트는 명령이 아니라 데이터여야 합니다.

완벽한 방법은 아니지만, 프롬프트 구조를 조정하면 공격 난이도를 높일 수 있습니다. 신뢰할 수 없는 데이터를 명확히 구분하고, 모델에 해당 데이터를 어떻게 취급할지 지시하십시오.

명시적인 구분자를 사용하고, 구분자 안의 모든 내용은 따라야 할 지침이 아니라 분석할 데이터라고 모델에 알리십시오. 또한 애플리케이션이 호출할 때마다 강력한 시스템 역할을 다시 적용하십시오.

모델의 출력도 신뢰할 수 없습니다. 애플리케이션이 LLM 출력을 셸, 데이터베이스, 브라우저 또는 다른 도구로 전달하면, 주입은 원격 코드 실행 또는 데이터 반출로 이어질 수 있습니다.

사이먼 윌리슨의 치명적 삼요소는 다음과 같은 위험한 조합을 설명합니다:

• 비공개 데이터에 대한 접근 권한,
• 신뢰할 수 없는 콘텐츠에 대한 노출,
• 외부와 통신하여 데이터를 반출할 수 있는 능력.

이 세 가지를 모두 갖춘 에이전트는 단 하나의 주입된 지침으로 데이터 탈취 도구로 바뀔 수 있습니다. 삼요소 중 하나를 제거하면 공격도 차단할 수 있습니다.

주입은 발생한다고 가정하고, 이를 탐지할 수 있도록 계측하십시오:

• 전체 맥락을 기록하십시오(프롬프트, 검색된 조각, 도구 호출). 사고를 검토할 때 사용합니다.
• 보조 분류기나 보호 모델을 사용하여 의심스러운 입력과 출력을 표시하십시오.
• 비정상적인 도구 사용을 모니터링하십시오. 갑작스러운 외부 요청, 예상하지 못한 데이터 접근, 프롬프트 유출 패턴 등을 살펴보십시오.
• 시스템 프롬프트에 카나리 토큰을 넣으십시오. 카나리가 출력에 나타나면 유출이 발생한 것입니다.

경고를 실제 사고로 취급하고 대응 절차서에 따라 조치하십시오.

자체 시스템의 주입 취약점을 검사하는 일은 필수적이며 정당합니다. 책임감 있게 수행하십시오:

• 여러분이 소유하거나 평가 권한을 부여받은 시스템만 검사하십시오.
• 통제된 환경과 합성 데이터를 사용하고, 실제 사용자 데이터를 절대 반출하지 마십시오.
• 발견 사항을 문서화하고 회귀 검사에 반영하여, 수정한 우회 방법이 다시 통하지 않도록 하십시오.
• 타사 모델이나 애플리케이션에서 문제를 발견하면 공개 절차를 조율하십시오.

목표는 애플리케이션의 회복력을 높이는 것이지, 유해한 기능을 만들어 내는 것이 아닙니다.

주입과 신뢰 경계에 대한 이해도를 확인하십시오.

프롬프트 주입과 탈옥의 핵심 내용:

• 주입은 하나의 채널에서 신뢰할 수 있는 지침과 신뢰할 수 없는 데이터를 섞을 때 발생합니다.
• 직접 주입은 사용자에게서 발생하고, 간접 주입은 검색된 콘텐츠에 숨겨져 더 은밀합니다.
• 탈옥은 모델 정렬을 공격하고, 주입은 애플리케이션 경계를 공격합니다. 두 공격은 결합될 수 있습니다.
• 입력 필터링은 다층 방어의 일부일 뿐이며, 결코 주요 통제 수단이 아닙니다.
• 구조적으로 완화하십시오. 최소 권한을 적용하고, 데이터를 제어 영역과 분리하며, 치명적 삼요소(비공개 데이터 + 신뢰할 수 없는 콘텐츠 + 데이터 반출)를 깨뜨리십시오.
• 모델 출력을 신뢰할 수 없는 것으로 취급하고, 모든 것을 기록하며, 윤리적으로 레드팀 점검을 수행하십시오.