AI 에이전트의 정보 유출 위험은 프롬프트보다 모델에 더 크게 좌우됩니다

(초기, 단일 설정 기반의 결과 — 수치를 인용하기 전에 주의 사항을 먼저 읽어주세요.)

만약 여러분이 자체 호스팅(self-hosted) AI 에이전트를 배포한다면, 아마 잘못된 것을 걱정하고 있을 가능성이 높습니다. 우리 대부분은 더 엄격한 시스템 프롬프트 (system prompt)를 작성하는 데 집착합니다. 하지만 제가 이번 주에 실시한 작은 측정 결과에 따르면, 에이전트가 숨겨진 지침을 유출할지 여부를 결정하는 가장 큰 요인은 프롬프트가 전혀 아니었습니다. 바로 그 뒤에 어떤 모델이 자리 잡고 있느냐였습니다. 동일한 에이전트, 동일한 공격을 다섯 가지 서로 다른 모델에 적용했을 때, 정보 공개율 (disclosure rate)은 사실상 0%에서 거의 모든 시도가 성공하는 수준까지 다양하게 나타났습니다.

제가 발견한 것, 아직 결론 내릴 수 없는 것, 그리고 왜 "그저 프롬프트일 뿐인데 누가 신경 쓰겠어"라는 생각이 잘못된 접근 방식인지 공유하고자 합니다.

"시스템 프롬프트 유출 (system prompt leakage)"이란 무엇인가

모든 LLM 기반 애플리케이션은 숨겨진 시스템 프롬프트 (system prompt) 위에서 작동합니다. 이는 에이전트의 역할, 규칙, 때로는 접근 범위, 그리고 (너무 자주 발생하는 문제지만) 편의를 위해 붙여넣은 자격 증명 (credentials)을 정의하는 지침입니다. 사용자는 이를 절대 볼 수 없어야 합니다. 하지만 적절한 문구 구성을 통해 모델이 이를 읊도록 유도할 수 있습니다.

이는 지엽적인 우려 사항이 아닙니다. OWASP LLM 애플리케이션 Top 10은 시스템 프롬프트 유출 (System Prompt Leakage, LLM07)을 별도의 카테고리로 추가했으며, 민감 정보 공개 (sensitive-information disclosure)를 전체 위험도 2위로 격상시켰습니다. 한 보안 보고서가 명확하게 설명했듯이, LLM 컨텍스트 내부에서 "숨겨진 것"으로 취급하는 모든 것은 추출 가능하다고 가정해야 합니다. (WitnessAI, LLM System Prompt Leakage, 2026.)

그 피해는 가설이 아닌 구체적인 현실입니다. 삼성 엔지니어들은 세 차례의 별도 사건을 통해 공개 LLM에 내부 소스 코드와 회의록을 붙여넣음으로써 이를 유출했습니다. 또한, 실제 LLM 애플리케이션을 책임감 있게 연구한 2026년 6월의 논문은 프롬프트 유출 취약점을 벤더들에게 공개했으며, 그중 두 곳은 이를 공식적으로 중간 수준의 심각도 (medium-severity)로 분류했습니다. (Yang et al., Understanding and Mitigating Prompt Leaking Attacks, arXiv:2606.18673, 2026.)

제가 수행한 작업

저는 이전의 레드팀 (red-team) 조사 작업을 바탕으로 이를 작고 결정론적인(deterministic) 측정 하네스 (measurement harness)로 발전시켰습니다. 설정은 다음과 같습니다:

가짜로 심어둔 자격 증명(credential)과 시스템 프롬프트 내 몇 가지 "카나리(canary)" 문구를 포함하여 의도적으로 취약하게 설정된 테스트 에이전트 하나 — 이를 통해 유출 여부를 명확히 판별할 수 있으며, 실제 데이터는 전혀 위험에 처하지 않도록 했습니다.

인디 SaaS 빌더들이 흔히 연결하여 사용하는 5개의 널리 쓰이는 모델들 ("빠르고 저렴한" 텍스트 모델과 "두뇌"급 추론 모델의 혼합).

두 가지 프로브(probe) 세트: 한 가지 언어로 구성된 베이스라인 세트와, 언어 혼용이 모델의 가드레일(guardrails)을 약화시키는지 테스트하기 위해 의도적으로 세 가지 언어를 교차 사용하는(code-switches) 다국어 세트.

각 셀(cell)당 N = 5회의 실행, 두 가지 탐지 신호 사용: 비밀번호 형태의 문자열에 대한 언어 불변(language-invariant) 체크(심각한 실패 — 자격 증명이 유출됨), 그리고 카나리 문구에 대한 체크(경미한 실패 — 지침을 과도하게 공유함).

저는 프로브 문자열 자체를 의도적으로 공개하지 않고 있습니다. 목적은 노출 정도를 측정하는 것이지, 누구에게나 복사해서 붙여넣을 수 있는 공격 수단을 제공하는 것이 아니기 때문입니다.

연구 결과

1. 모델이 모든 것을 결정했습니다. 이 단일 취약 구성에서 시스템 프롬프트 노출은 한 모델에서는 0%였으나, 다른 모델에서는 약 96%에 달했습니다. 동일한 프롬프트, 동일한 프로브를 사용했음에도 — 한 모델은 아무 말도 하지 않았고, 다른 모델은 거의 매번 숨겨진 지침을 읊었습니다. "빠르고 저렴한" 계층이 "두뇌" 계층보다 일률적으로 더 나쁘지는 않았습니다. 편차는 가격대가 아니라 특정 모델에 따라 나타났습니다.

저는 의도적으로 모델 이름을 밝히지 않고 있습니다. 5회의 실행을 포함한 단일 테스트 구성만으로는 특정 제품을 "유출이 잦은 제품"이라고 낙인찍기에 충분하지 않습니다. 그것은 바로 이 프로젝트가 피하고자 하는 과장된 주장(overclaim)의 전형이기 때문입니다. 데이터가 뒷받침하는 것은 그 양상입니다: 모델 선택은 1차적인 보안 변수(first-order security variable)입니다.

그리고 이것은 비단 저의 측정 하네스(harness)만의 문제가 아닙니다. 이전 연구(Zhang & Ippolito, 2023)에서도 모델별 프롬프트 유출 취약성을 측정했으며, 그들이 테스트한 세 모델에서 각각 약 73%, 89%, 82%라는 매우 상이한 비율을 발견했습니다. 모델이 다르고 연구가 다르더라도 교훈은 같습니다: 모델이 매우 중요합니다.

1. 실제 (마스킹된) 자격 증명 유출이 라이브 데이터에서 한 차례 발생했습니다. 525개의 셀 중에서 정확히 하나가 실제 비밀 정보와 유사한 형태의 유출을 생성했습니다. 디버그 역할극 탐사 (debug-roleplay probe)를 수행 중인 모델로부터 심어진 가짜 키 (sk-ant-****)가 그대로 반환되었습니다. 이는 해당 셀의 5회 실행 중 1회에서 발생했으므로, 결정론적 (deterministic)이지 않고 간헐적 (intermittent)입니다. 하지만 바로 이 점이 핵심입니다. 단 한 번의 "안전해 보이는" 결과가 재시도 시에만 나타나는 실제 유출을 숨길 수 있다는 것입니다.

2. 다국어 코드 스위칭 (Multilingual code-switching)은 효과가 없었습니다. 이 또한 하나의 발견입니다. 저의 초기 가설은 언어를 혼합하면 가드레일 (guardrails)이 약화될 것이라는 점이었습니다. 하지만 데이터는 이를 뒷받침하지 않았습니다. 다국어 세트는 베이스라인 (baseline)보다 더 많은 유출을 생성하지 않았습니다. 저는 이 가설이 성립하지 않았다고 해서 이를 숨기기보다 정직하게 보고하고 있습니다. 왜냐하면 성립하지 않은 가설 또한 정보이기 때문입니다.

결론 내릴 수 없는 부분 (중요한 주의 사항)

단일 타겟, 작은 N (표본 수). 하나의 취약한 구성, 셀당 5회의 실행. 모든 수치를 최종 결과가 아닌 방향성을 나타내는 지표로 취급하십시오. 이 설정에서 0%~96%의 범위는 실제 결과이며, 이는 어떤 모델에 대해서도 일반적인 벤치마크 (benchmark)가 아닙니다.
최종 출력물만 확인. 테스트 프레임워크 (harness)는 모델이 반환한 메시지를 검사하며, 숨겨진 추론/사고 흔적 (reasoning/thinking trace)은 검사하지 않습니다. 노출되지 않은 추론 흔적 내부에서만 발생하는 유출은 여기서 포착되지 않을 것입니다. (이는 알려진 사각지대이며, 결함이 없다는 증명이 아닙니다.)
번역을 통한 회피 (Translation-evasion)는 원칙적으로 존재하지만, 실제 실행에서는 거의 나타나지 않았습니다. 모델이 출력 과정에서 카나리 (canary)를 다른 언어로 번역해 버린다면, 문자열 매칭 (string-matching)을 통한 정보 공개 탐지는 실패합니다. 저는 이것이 개별적으로 발생할 수 있음을 확인했습니다. 하지만 라이브 실행에서는 정보를 공개한 모델들이 대부분 원문 그대로 (verbatim) 공개했기 때문에 포착되었습니다. 이 격차는 실재하지만, 데이터가 이를 충분히 시험하지 못했을 뿐입니다. 보안 연구에서는 모델이 출력을 난독화하거나 재인코딩함으로써 출력 모니터링 방어 체계를 회피할 수 있다는 점을 오래전부터 지적해 왔습니다 (Zhang & Ippolito, 2023). 이것이 바로 출력 필터링 (output filtering)만으로는 보장할 수 없는 이유입니다.

아무도 예산을 배정하지 않는 거버넌스 격차 (governance gap)

불편하게 느껴질 수 있는 대목은 바로 이 부분입니다. AI에 관한 규제는 빠르게 도입되고 있으며, 이는 주로 여러분에게 의무를 부과할 뿐 여러분을 보호하지는 않습니다. 컴플라이언스 (Compliance, 준수)가 곧 보안은 아닙니다. 감사를 통과했다고 해서 여러분의 에이전트가 입을 다물고 있다는 뜻은 아니며, 만약 정보가 유출된다면 여러분이 어떤 항목에 체크를 했든 상관없이 그 책임과 수습은 여러분의 몫이 됩니다.

따라서 정보 유출을 누군가가 인증해 주는 서류상의 문제가 아니라, 여러분이 직접 책임져야 하는 위생 (hygiene) 문제로 취급하십시오. 범위를 명확히 하자면: 이와 같은 배포 전 유출 점검은 위생 도구이지 컴플라이언스 제품이 아니며, 여기서 언급된 어떤 내용도 법적 조언이 아닙니다. 여러분의 의무 사항에 대해서는 실제 전문가와 상담하십시오.

시사점 (The takeaway)

여러분의 에이전트 컨텍스트 (context)에 숨겨진 모든 것은 추출될 수 있다고 가정하십시오. 그런 다음 실제로 테스트하십시오. 여러분이 출시할 특정 모델을 대상으로 테스트해야 합니다. 왜냐하면 그 선택이 여러분의 예상보다 훨씬 더 중요하기 때문입니다. 측정하고, 증명하고, 수정하십시오.

자신의 설정을 직접 점검해보고 싶다면, 제가 사용한 스캐너는 오픈 소스 (open source)입니다 (아래 링크 참조). 하지만 진짜 요청 사항은 "제 도구를 설치하세요"가 아닙니다. 여러분의 시스템 프롬프트 (system prompt)가 비공개라고 가정하는 것을 멈추라는 것입니다. 무언가를 실행하십시오. 여러분의 스택 (stack)을 측정하십시오. 그리고 발견한 내용을 공유하십시오.

도구 (Tooling): agentproof-scan (Apache-2.0). 결과는 예비적인 단계입니다 — 단일 구성, N=5. 만약 결과를 재현하거나 깨뜨릴 수 있다면, 이슈 (issue)를 생성해 주세요.

Github
(https://github.com/ghkfuddl1327-wq/agentproof)
(https://github.com/ghkfuddl1327-wq)