대부분의 개발자들은 시스템 프롬프트 (System Prompt)를 숨겨진 설정값처럼 취급합니다.

그것은 실수입니다.

LLM 애플리케이션에서 시스템 프롬프트는 액세스 제어 (Access Controls) 뒤에 안전하게 자리 잡고 있는 소스 코드 (Source Code)가 아닙니다. 그것은 모델의 컨텍스트 (Context) 내부에 존재하며, 사용자의 지침, 외부 콘텐츠, 그리고 대화 기록이 모델이 다음에 수행할 작업에 영향을 미칠 수 있는 곳에 위치합니다.

이것이 바로 시스템 프롬프트 유출 (System Prompt Leakage)이 단순한 예외적인 사례가 아닌 설계상의 리스크 (Design Risk)인 이유입니다.

시스템 프롬프트는 종종 LLM 애플리케이션 내에서 기밀 자산으로 취급됩니다. 프롬프트는 모델의 동작을 정의하고, 안전 경계 (Safety Boundaries)를 설정하며, 주제를 제한하고, 워크플로우 (Workflows)를 지정하며, 외부 도구가 어떻게 사용되어야 하는지를 결정합니다. 많은 개발자들은 이러한 지침이 최종 사용자로부터 숨겨져 있다고 가정하며, 따라서 이를 신뢰할 수 있는 제어 메커니즘으로 간주합니다.

하지만 실제로 그러한 가정은 점점 더 도전을 받고 있습니다. 시스템 프롬프트 유출의 확산은 프롬프트가 소스 코드나 전통적인 비밀 정보 (Secrets)와 동일하지 않다는 것을 보여줍니다. 액세스 제어 뒤에 저장된 설정 파일 (Configuration Files)과 달리, 프롬프트는 모델의 컨텍스트 윈도우 (Context Window) 내에 존재하며 궁극적으로 모델이 처리하는 정보의 일부가 됩니다. 결과적으로 공격자는 이러한 숨겨진 지침을 노출하거나 재구성하는 방식으로 대화를 조작하려고 시도할 수 있습니다.

이는 프롬프트 유출 (Prompt Leakage)을 프롬프트 인젝션 (Prompt Injection)과 구분 짓는 지점입니다. 프롬프트 인젝션은 모델의 동작에 영향을 미치는 데 집중하는 반면, 프롬프트 유출은 그 동작을 규정하는 지침을 드러내는 것을 목표로 합니다. 이러한 지침에 접근하면 안전 메커니즘, 도구 사용법, 애플리케이션 로직에 대한 귀중한 정보를 얻을 수 있어, 공격자가 더욱 효과적인 적대적 입력 (Adversarial Inputs)을 설계할 수 있게 합니다.

궁극적으로 프롬프트는 입력값 (Inputs)이지, 보안 경계 (Security Boundaries)가 아닙니다. 프롬프트를 본질적으로 비밀이라고 취급하는 것은 현대 AI 시스템이 항상 보장할 수 없는 가정을 만드는 것입니다.

프롬프트 추출 공격의 작동 방식

프롬프트 추출 공격 (Prompt extraction attack)은 LLM 애플리케이션의 동작을 제어하는 숨겨진 지침을 드러내는 것을 목표로 합니다. 이러한 공격은 소프트웨어의 취약점을 악용하기보다는, 정교하게 설계된 입력값과 대화 기법을 통해 모델을 조작하는 방식에 의존합니다.

일반적인 접근 방식으로는 직접적인 요청, 역할극 (Role-playing) 시나리오, 문맥 전환 (Context switching), 번역 프롬프트, 그리고 내부 지침을 점진적으로 노출하도록 설계된 다회차 대화 (Multi-turn conversations) 등이 있습니다. 많은 경우, 공격자는 모델에게 규칙을 명시적으로 위반하라고 요구하지 않습니다. 대신, 모델이 의도치 않게 정보를 드러내도록 유도하는 방식으로 상호작용을 재구성합니다.

근본적인 문제는 언어 모델이 시스템 지침 (System instructions)과 사용자 지침 (User instructions) 사이의 내재적인 구분을 갖지 못한다는 점입니다. 두 지침 모두 궁극적으로 동일한 컨텍스트 윈도우 (Context window) 내에 존재하며 함께 처리됩니다. 이로 인해 프롬프트 비밀성은 상대적으로 취약한 보안 경계가 됩니다.

responsible AI security framework와 같은 프레임워크는 AI 시스템을 보호하기 위해서는 숨겨진 지침에만 의존하기보다 프롬프트, 컨텍스트, 그리고 런타임 상호작용 (Runtime interactions)을 보안 처리해야 한다고 강조합니다.

결국, 프롬프트 추출 공격의 효과는 모델을 파괴하는 데 달려 있는 것이 아니라, 모델을 설득하는 데 달려 있습니다. 따라서 조직은 프롬프트가 결국 노출될 수 있음을 가정하고 그에 따라 시스템을 설계해야 합니다.

시스템 프롬프트를 유출하는 데 사용되는 일반적인 기술들

프롬프트 추출 공격은 정교한 익스플로잇 (Exploits)에 의존하는 경우가 드뭅니다. 그보다는 지침을 대화 형식으로 해석하려는 모델의 경향을 이용하는 경우가 더 많습니다. 공격자들은 숨겨져 있어야 할 정보를 드러내도록 모델을 설득하기 위해 다양한 기술을 채택합니다.

가장 일반적인 접근 방식 중 일부는 다음과 같습니다:

역할극 공격 (Roleplay Attacks)

공격자는 자신을 개발자, 보안 감사관(Security Auditor) 또는 관리자로 재설정하고, 검토 목적으로 부여받은 지침을 공개하도록 모델에 요청합니다.

지침 계층 구조 조작 (Instruction Hierarchy Manipulation)

사용자 프롬프트는 새로운 맥락(Context)이나 우선순위를 도입함으로써 숨겨진 지침을 재해석하거나 무효화하려고 시도합니다.

번역 및 요약 기법 (Translation and Summarization Tricks)

모델에게 자신의 운영 규칙을 의역, 설명 또는 번역하도록 요청하며, 이 과정에서 시스템 프롬프트의 일부가 노출되는 경우가 많습니다.

컨텍스트 윈도우 악용 (Context Window Exploitation)

긴 대화는 이전의 지침을 점진적으로 약화시켜, 의도하지 않은 정보가 유출될 가능성을 높일 수 있습니다.

간접 프롬프트 주입 (Indirect Prompt Injection)

웹 페이지, 문서 또는 이메일과 같은 외부 콘텐츠가 모델에 영향을 미쳐, 공격자의 프롬프트가 직접적으로 요청하지 않더라도 내부 지침을 드러내도록 유도합니다.

시스템 프롬프트 유출의 까다로운 점은 이러한 공격이 기반 모델(Underlying Model) 자체를 해킹하는 경우가 드물다는 것입니다. 대신, 언어 모델(Language Models)이 자연어를 해석하고 우선순위를 정하는 방식을 악용합니다.

프롬프트 보안에 프롬프트 은닉 이상의 것이 필요한 이유

비밀 유지에만 의존하는 것은 프롬프트 추출(Prompt Extraction)에 대한 지속 가능한 방어책이 아닙니다. 숨겨진 지침은 공격자에게 어느 정도의 마찰을 줄 수는 있지만, 이를 AI 애플리케이션을 보호하는 주요 메커니즘으로 취급해서는 안 됩니다. 효과적인 프롬프트 보안을 위해서는 더 넓은 범위의 심층 방어(Defense-in-depth) 접근 방식이 필요합니다.

다음의 몇 가지 원칙이 특히 중요합니다:

프롬프트는 비밀로 취급되어서는 안 됩니다

시스템 지침은 적대적 상호작용(Adversarial Interactions)을 통해 결국 공개될 수 있습니다. 조직은 프롬프트 노출이 가능하다고 가정하고 그에 따라 시스템을 설계해야 합니다.

계층화된 보안이 더 큰 회복탄력성을 제공합니다

런타임 검사(Runtime Inspection), 정책 집행(Policy Enforcement), 그리고 입력 유효성 검사(Input Validation)는 비밀 유지만 하는 것보다 더 강력한 보호를 제공합니다.

최소 권한 도구 액세스 (Least-Privilege Tool Access)는 영향을 제한합니다

프롬프트가 노출되더라도 권한을 제한하면 공격자가 프롬프트 노출로 인한 결과를 확대하는 것을 방지할 수 있습니다.

지속적인 모니터링 (Continuous Monitoring)은 탐지 능력을 향상시킵니다

프롬프트 상호작용과 비정상적인 동작을 관찰하면, 광범위한 침해로 이어지기 전에 추출 시도를 식별하는 데 도움이 됩니다.

자체 개발 AI 애플리케이션을 보호하고자 하는 조직은 프롬프트 기밀성이 무기한 보장될 수 없음을 인식해야 합니다. 대신, 내부 지침이 노출되더라도 보안이 자동으로 침해되지 않도록 시스템을 설계해야 합니다.

시스템 프롬프트 유출은 모델의 문제가 아니라 설계의 문제입니다

궁극적으로 시스템 프롬프트 유출은 모델 자체의 실패가 아닙니다. 또한 프롬프트 추출 공격이 반드시 기반이 되는 LLM (Large Language Model)에 결함이 있다는 증거도 아닙니다. 대부분의 경우, 프롬프트 공개는 숨겨진 지침을 운영 가이드가 아닌 보안 통제 수단으로 취급하는 아키텍처적 가정(architectural assumptions)을 반영합니다.

대신 조직은 권한 경계, 런타임 제어 (runtime controls), 모니터링 및 최소 권한 액세스 (least-privilege access)를 기반으로 한 심층 방어 (defense-in-depth) 접근 방식을 채택해야 합니다. 목표는 프롬프트가 무기한 비밀로 유지되는 것을 보장하는 것이 아니라, 프롬프트 노출이 애플리케이션을 침해하지 않도록 보장하는 것입니다.

AI 애플리케이션이 계속 진화함에 따라, 과제는 프롬프트가 절대 노출되지 않도록 막는 것이 아닐 것입니다. 프롬프트가 노출되더라도 보안을 유지할 수 있는 시스템을 설계하는 것이 과제가 될 것입니다.

이 지점에서 LangProtect와 같은 도구들이 유효해집니다. 목표는 프롬프트가 영원히 숨겨져 있을 것이라고 가정하는 것이 아닙니다. 목표는 AI 상호작용 주변에 런타임 검사 (runtime inspection), 정책 집행 (policy enforcement), 모니터링 및 감사 가시성 (audit visibility)을 추가하여, 프롬프트 노출이 자동으로 시스템 침해로 이어지지 않도록 하는 것입니다.