요약(TL;DR)— 대부분의 프롬프트 인젝션(Prompt Injection) 방어책은 이를 스팸 탐지처럼 취급합니다. 즉, 나쁜 입력을 분류하고, 차단하고, 다음으로 넘어가는 방식입니다. 이러한 접근 방식은 자연어에 지시(Instruction)와 데이터(Data) 사이의 신뢰할 수 있는 경계가 없기 때문에 한계에 부딪힙니다. 실제로 확장 가능한 해결책은 아키텍처적인 것입니다. 즉, 수십 년 전 SQL 인젝션(SQL Injection)이 준비된 문구(Prepared Statements)를 통해 우리에게 가르쳐준 것과 동일한 교훈인 출처 추적(Provenance tracking)과 권한 범위가 제한된 실행(Capability-scoped execution)입니다.

몇 주마다 새로운 탈옥(Jailbreak) 기술이 유행하고, 벤더(Vendor)가 패치를 출시하며, 이 사이클은 반복됩니다. 이 사이클의 형태를 자세히 살펴보면 2000년대의 스팸 필터 군비 경쟁과 동일하다는 것을 알 수 있습니다. 나쁜 입력을 분류하고, 차단하고, 다음 변종을 기다리는 방식입니다. 당시에도 결코 수렴되지 않았습니다. 프롬프트 인젝션 방어가 계속해서 정체되는 이유는 업계가 문제의 잘못된 계층(Layer)을 해결하고 있기 때문입니다. 악성 텍스트를 탐지하는 것은 패배할 수밖에 없는 게임입니다. 왜냐하면 자연어에는 지시(Instruction)와 데이터(Data) 조각 사이에 구문론적 경계(Syntactic boundary)가 없기 때문입니다. SQL도 정확히 이 문제를 겪었으며, 이는 악성 문자열의 패턴 매칭(Pattern-matching)을 개선함으로써 해결된 것이 아니었습니다. 모호함을 구조적으로 불가능하게 만듦으로써 해결되었습니다.

범주 오류 (The category error)

프롬프트 인젝션 분류기(Classifier)—미세 조정된 모델(Fine-tuned model), 정규 표현식 휴리스틱(Regex heuristics) 세트, 또는 호스팅된 중재 API(Moderation API)이든 간에—는 근본적으로 다음과 같은 질문에 답하려고 시도합니다: 이 텍스트가 공격처럼 보이는가? 이것은 콘텐츠(Content)에 관한 질문입니다. 하지만 실제 취약점은 콘텐츠에 있는 것이 아닙니다. 취약점은 귀하의 시스템이 신뢰할 수 없는 데이터(스크래핑된 웹페이지, 지원 티켓, 도구 응답, 다른 에이전트의 출력)를 신뢰할 수 있는 시스템 지시문(System instructions)과 동일한 컨텍스트 창(Context window)에 결합하면서, 모델이 이 둘을 확실하게 구별할 수 있는 메커니즘이 없다는 사실에 있습니다.

이는 SQL 인젝션(SQL injection)을 문자열 정제(string-sanitization) 문제로 생각하는 것과 같은 범주 오류(category error)입니다. 하루 종일 따옴표를 제거하고, 특수 문자를 이스케이프(escape)하며, 키워드를 차단 목록(blocklist)에 추가하더라도, 누군가는 당신이 놓친 인코딩 방식을 찾아낼 것입니다. 실제 해결책은 준비된 문구(prepared statements)였습니다. 프로토콜 수준에서 쿼리 구조를 데이터 값과 분리함으로써, 데이터베이스 엔진이 데이터를 코드로 오해할 기회 자체를 주지 않는 방식입니다. 취약점이 패치된 것이 아니라, 아키텍처를 통해 제거된 것입니다.

탐지가 정체되는 이유

가드레일 모델(Guardrail models)과 탈옥 분류기(jailbreak classifiers)는 적대적이고 경계가 없는 입력 공간(unbounded input space)에서 작동하는 베이지안 필터(Bayesian filters)입니다. 당신이 발표하는 모든 방어책은 다음 공격을 위한 학습 신호(training signal)가 됩니다. 간접 프롬프트 인젝션(Indirect prompt injection)은 이 상황을 더욱 악화시키는데, 공격자가 당신의 채팅 인터페이스에 접근할 필요조차 없기 때문입니다. 그들은 단지 자신들의 페이로드(payload)가 에이전트가 읽게 될 어딘가—PDF, 캘린더 초대장, GitHub 이슈, 제품 리뷰 등—에 도달하기만 하면 됩니다. 공격 표면(attack surface)은 당신의 프롬프트 입력창이 아닙니다. 에이전트가 읽도록 허용된 모든 문서가 공격 표면입니다.

더 깊은 문제는 트랜스포머(transformer)가 라벨이 지정된 데이터 구조(labeled data structure)가 아닌 토큰 스트림(token stream)을 처리한다는 점입니다. 지시 사항(Instructions)과 데이터(data)는 동일한 표현 공간(representational space)에 존재합니다. 구분자(delimiters), 역할 태그(role tags), 시스템 프롬프트 프레이밍(system-prompt framing)을 추가할 수는 있지만, 모델은 여전히 평탄한 시퀀스(flat sequence) 위에서 다음 토큰 예측(next-token prediction)을 수행하고 있으며, 충분히 잘 설계된 "데이터" 조각은 지시 사항과 정확히 똑같이 모델의 동작을 변화시킬 수 있습니다. 이것은 더 나은 학습으로 제거할 수 있는 버그가 아닙니다. 이는 현재 모델들이 컨텍스트를 수용하는 방식의 구조적 특성입니다. 이를 더 강력한 분류기로 패치하여 없앨 수 있는 버그로 취급하는 것이 바로 이 군비 경쟁이 끝나지 않는 이유입니다.

SQL 비유가 실제로 가르쳐 주는 것

Prepared Statements(준비된 문구)가 주는 교훈은 "이스케이프(escaping)를 더 많이 추가하라"가 아닙니다. 그것은 "채널이 스스로의 신뢰 수준을 보고하도록 믿는 것을 멈추고, 대신 콘텐츠 자체 외부에서 출처(provenance)를 추적하라"는 것입니다. 이를 LLM 시스템에 적용하면, 프롬프트에 들어오는 모든 컨텍스트 조각은 모델이 보는 텍스트 내부가 아니라, 여러분의 오케스트레이션 계층(orchestration layer)에 존재하는 출처 태그를 지녀야 함을 의미합니다: system, user, retrieved_untrusted, tool_output_untrusted. 모델이 이 태그를 의미론적(semantically)으로 이해할 필요는 없습니다. 여러분의 제어 평면(control plane)이 이해하면 됩니다.

출처를 확보하면, 모델 외부에서 정책을 강제할 수 있습니다: retrieved_untrusted로 태그된 콘텐츠는 직접적으로 도구 호출(tool call)을 트리거할 수 없으며, 시스템 지시문(system instruction)과 유사한 위치에 결합될 수 없고, 신뢰할 수 있는 소스에서 시작된 재인증(re-authorization) 단계 없이 에이전트의 계획을 수정하는 것이 허용되지 않습니다. 이것은 웹 보안에서 직접 빌려온 오염 추적(taint tracking)이며, 변수 할당 대신 컨텍스트 조립(context assembly)에 적용된 것입니다. 이는 모델이 공격을 탐지하는 데 더 똑똑해질 것을 요구하지 않습니다. 대신 여러분의 파이프라인이 신뢰할 수 없는 텍스트에 신뢰할 수 있는 지시문과 동일한 실행 권한을 부여하는 것을 중단할 것을 요구합니다.

심층 방어(Defense in depth)는 더 많은 분류기가 아니라 역량의 경계를 의미합니다

출처 추적이 스키마 수준의 해결책이라면, 역량 범위 지정(capability scoping)은 런타임(runtime) 해결책입니다. 성공적인 인젝션으로 인한 실제 피해는 텍스트 출력에서 발생하는 경우가 거의 없습니다. 그것은 모델이 그 이후에 수행하도록 허용된 행동, 즉 이메일 전송, 데이터베이스 쓰기 실행, 결제 API 호출, 조작된 URL을 통한 데이터 유출 등에서 발생합니다. 에이전트 시스템을 위한 심층 방어(Defense in depth)란 모든 도구 호출을 그 이면의 지시문이 공격자에 의해 제어될 수 있다고 가정하고, "만약 그렇다면 폭발 반경(blast radius)은 어디까지인가?"라고 묻는 것을 의미합니다.

• 기본적으로 최소 권한 원칙 (Least privilege by default) 적용. 고객 이메일을 요약하는 에이전트는 환불을 실행할 수 있는 에이전트와 동일한 자격 증명 (credential)을 가져서는 안 됩니다. 설령 동일한 기반 모델 (underlying model)을 사용하더라도, 이들을 분리하십시오.
• 신뢰할 수 없는 데이터에서 실행으로 이어지는 지름길 금지 (No untrusted-to-action shortcuts). 검색 (retrieval) 결과나 도구 출력 (tool output)에서 나온 콘텐츠는, 모델 자체의 판단에 의존하지 않는 정책 검사 (policy check)를 거치지 않고는 결코 높은 권한을 가진 동작을 직접 트리거할 수 없어야 합니다.
• 출력 측 정화 (Output-side sanitization). 에이전트의 출력이 브라우저에 렌더링되거나, 코드로 실행되거나, 혹은 하류 (downstream)의 다른 프롬프트에 보간 (interpolate)될 수 있다면, 해당 출력을 신뢰할 수 없는 문자열이 싱크 (sink)로 향할 때와 동일하게 취급하십시오. 즉, 목적지에 맞게 인코딩 (encode)해야 합니다.
• 권한 경계에서의 인간 확인 (Human confirmation at privilege boundaries). 모든 동작에 대해 확인을 요구하는 것이 아닙니다. 그것은 사람들을 단순히 클릭만 하게 만드는 훈련이 될 뿐입니다. 대신, 에이전트가 읽기에서 쓰기로, 또는 내부 효과에서 외부 효과로 넘어가는 바로 그 시점에 확인을 요구하십시오.

이 중 그 어떤 것도 인젝션 (injection) 발생 자체를 막지는 못합니다. 다만 인젝션이 '의미 있는 결과'를 초래하는 것을 막을 뿐입니다. 이것이 바로 심층 방어 (defense in depth)의 실제 정의입니다. 즉, 외부 계층이 결국 실패할 것이라고 가정하고, 그 실패가 침해된 동작으로 연쇄적으로 이어지지 않도록 설계된 계층들을 의미합니다.

실제로 구축해야 할 것

만약 당신이 오늘날 LLM 시스템을 책임지고 있다면, 투자 대비 효과 (ROI)의 우선순위는 다음과 같지 않습니다: 더 나은 탈옥 분류기 (jailbreak classifier), 그다음 더 나은 시스템 프롬프트 (system prompt), 그다음 더 나은 가드레일 모델 (guardrail model). 순서는 그 반대입니다.

첫째, 신뢰할 수 없는 콘텐츠가 컨텍스트 (context)에 유입되는 모든 지점을 파악하고, 오케스트레이션 계층 (orchestration layer)에서 이를 태깅 (tag)하십시오. 둘째, 에이전트가 수행할 수 있는 모든 도구 호출 (tool call)을 열거하고, 데모 중에 편리했다는 이유로 특정 도구에 포괄적인 권한을 부여하는 대신 필요한 최소한의 권한만을 할당하십시오. 셋째, 텍스트가 아닌 동작 (action)에 정책 집행 (policy enforcement)을 적용하십시오. 특정 지시가 정당한지에 대한 모델의 의견은 보안 경계 (security boundary)가 될 수 없습니다. 이 세 가지가 모두 갖춰진 후에야 탈옥 분류기 (jailbreak classifier)는 게이트 (gate)가 아닌 모니터링 신호로서 제 역할을 다할 수 있습니다.

모델 제공업체들은 지시 이행 (instruction-following) 강건성을 계속해서 개선할 것이며, 이는 도움이 될 것입니다. 하지만 모델이 인젝션이 불가능해질 때까지 기다리는 것은 현재의 어떤 아키텍처도 보장하지 못하는 속성을 기다리는 것과 같습니다. 실제 적대적 압력 (adversarial pressure) 하에서도 견뎌내는 시스템은 인젝션이 결국 성공할 것이라고 가정하고, 인젝션이 발생했을 때 문제가 되지 않을 만큼 폭발 반경 (blast radius)을 충분히 작게 구축한 시스템들입니다.