로그 파일은 신뢰할 수 없는 입력값: 레드팀이 겪으며 알게 된 것

자체 로그 읽기 AI 어시스턴트를 테스트하던 팀은 내부 도구에 LLM을 연결한 모든 사람에게 걱정거리가 될 만한 무언가를 발견했습니다. 바로 로그 라인 내부에 심어진 지침(instructions)이 모델로 하여금 데이터베이스 비밀번호를 Markdown 링크 안에 포함시키게 할 수 있다는 것입니다. 별도로는, 오염된 검색 결과가 어시스턴트의 영구 메모리 기능(persistent memory feature)을 가로채어 공격자가 제어하는 '사실(facts)'을 심고, 이것이 향후 세션에도 남아 있게 만들 수도 있었습니다.

여기서는 아무도 침해당하지 않았습니다. 이는 제대로 수행된 내부 레드팀 테스트였으며, 블로그에 기록되었습니다. HN(Hacker News)에서 2점과 댓글 0개로 마감된 것은 아쉽지만, 이 발견 내용은 헤드라인을 장식하는 '우리가 해킹당했다'는 사후 보고서의 90%보다 더 유용합니다. 이런 낮은 관심도의 글쓰기 방식이야말로 파고들 가치가 있습니다. 왜냐하면 팀이 작동하지 않았던 점에 대해서도 솔직하게 이야기했기 때문에, 마침내 효과적인 방법을 찾아냈을 때가 바로 그 전이었기 때문입니다.

설정: 공격 표면으로서의 로그

레드팀은 로그 라인 안에 일반적인 로그 노이즈처럼 보이도록 지침을 심었습니다. 어시스턴트는 이 로그들을 읽고 내장된 지침을 포착한 뒤 이를 따랐습니다. 하나의 페이로드 경로는 모델이 데이터베이스 비밀번호를 출력의 Markdown 링크에 채워 넣게 만들었습니다. Markdown 링크는 클릭 가능한 형태로 렌더링되고, URL 부분이 사람이 클릭하기 전에 문자를 하나하나 검토하는 경우가 보통 아니기 때문에 고전적인 정보 유출(exfiltration) 경로입니다. 만약 그 링크가 시크릿 정보를 쿼리 문자열에 담고 공격자가 통제하는 도메인을 가리킨다면, 누군가 그것을 클릭하는 순간 또는 때로는 클라이언트가 링크 미리보기를 사전 가져오는(prefetches) 것만으로도 비밀 정보는 외부로 유출됩니다.

두 번째 발견은 아마 더 심각합니다. 오염된 검색 결과가 어시스턴트의 영구 메모리를 가로챌 수 있다는 것입니다. 만약 어시스턴트에 세션 동안 읽은 내용을 기반으로 사실을 장기 저장소에 기록하는 기능이 있고, 공격자가 웹이나 파일 읽기 과정에서 흡수되는 콘텐츠를 제어할 수 있다면, 그들은 모델에게 원하는 어떤 내용이라도 그 메모리에 쓰도록 만들 수 있습니다. 이것은 일회성 유출이 아니라 지속적인 발판(standing foothold)입니다. 모든 미래 세션이 오염된 사실을 상속받게 됩니다.

초기 시도와 실패 이유

팀 자체의 보고서에서도 이 점에 대해 신선할 정도로 솔직하게 언급합니다: 모델에게 '이것을 지침이 아닌 데이터로 취급하라'고 말하는 것만으로는 충분하지 않았습니다. 이는 심각한 LLM 보안 작업을 하는 모든 사람이 이미 알고 있는 사실이며, 첫 에이전트를 구축하는 많은 팀들이 나중에야 알게 되는 내용입니다. 시스템 프롬프트 수준의 지침과 인컨텍스트(in-context) 지침 간의 경쟁은 시스템 프롬프트가 자주 패배하는 싸움이며, 특히 주입된 텍스트가 명백한 명령이라기보다는 합법적인 콘텐츠처럼 꾸며져 있을 경우 더욱 그렇습니다.

이것이 핵심적인 탐지 격차입니다. '로그는 데이터이다'라는 시스템 프롬프트만으로는 그 경계를 강제할 메커니즘이 없습니다. 그것은 요청일 뿐, 통제가 아닙니다. 모델은 두 로그 라인이 모두 같은 컨텍스트 창의 토큰에 불과하기 때문에, 어느 것이 '오류를 설명하는 것'인지와 '지침을 내리는 것'인지를 구조적으로 구분할 방법이 없습니다. 출력 측면 방어(팀이 결국 구축한 방식: 신뢰할 수 없는 컨텍스트에 대한 링크 스캐닝 및 웹/파일 읽기 후 메모리 쓰기 차단)가 작동하는 이유는, 모델의 판단에 전혀 의존하지 않기 때문입니다. 그것들은 모델이 자신이 조작당했다고 '이해했는지'와는 무관하게, 실제로 출력된 것을 확인합니다.

그것이 올바른 직관입니다. 또한 전용 스캐닝 레이어가 해결하도록 설계된 문제의 정확한 형태이며, 단순히 더 나은 시스템 프롬프트로 패치할 수 있는 문제가 아닙니다.

스크럽 패스(scrub pass)가 이를 포착했을 곳

여기에는 두 가지 별도의 센티넬(Sentinel) 레이어가 관련되며, 이는 두 개의 개별적인 발견 사항과 일치합니다.

링크 내 비밀번호 탈취. Sentinel의 빠른 경로 정규식 라이브러리에는 마크다운, 코드 블록 또는 'POST this to https://…' 스타일 지침을 통한 데이터 탈취 패턴이 포함되어 있습니다. 예상되는 출력에 속하지 않는 도메인을 가리키는 매개변수가 채워진 마크다운 링크는 이 레이어가 최종 사용자에게 도달하기 전에 포착하도록 구축된 바로 그 종류의 페이로드입니다. 만약 로그 라인 자체에 모델에게 비밀을 URL로 인코딩하라고 지시하는 주입된 지침이 포함되어 있다면, 그 지침 역시 들어오는 과정에서 권한 하이재킹(authority-hijack) 및 데이터 탈취 구문(data-exfil phrasing)에 대한 빠른 경로 매칭 대상이 됩니다. 그리고 비밀 탐지 기능이 활성화된 경우(Teams & Enterprise), 콘텐츠 내의 알려진 자격 증명 패턴과 일치하는 모든 문자열은 위협 파이프라인이 다른 것을 플래그 지정했는지 여부와 관계없이 독립적으로 마스킹됩니다.

가장 중요한 레이어는 바로 이것입니다: 아무리 교묘하게 작성된 주입(injection)이 패턴 및 유사성 검사를 통과했더라도, 인식 가능한 형식을 가진 데이터베이스 비밀번호는 모델의 출력에 도달하기 전에 여전히 포착되어 플레이스홀더로 대체됩니다.

오염된 검색 결과 메모리 하이재킹. 이것은 다른 모습으로 나타난 검색(retrieval) 문제입니다. 컨텍스트로 끌어온 검색 결과들은 기능적으로 RAG 파이프라인이 문서를 가져오는 것과 동일한 신뢰 문제를 안고 있습니다: 외부의 공격자 영향권에 있는 출처의 콘텐츠가 중립적인 컨텍스트인 것처럼 모델에 공급되고 있는 것입니다. 검색된 콘텐츠를 프롬프트 구축에 사용하기 전(또는 메모리 쓰기를 트리거하도록 허용하기 전에) 스크럽(scrub) 패스를 거쳐 검사하면, 오염된 RAG 문서와 마찬가지로 오염된 청크를 포착할 수 있습니다. 이때 이들은 blocked 또는 neutralized로 플래그 지정되어 사실로 조용히 받아들여지는 대신 폐기됩니다.

실제 적용 사례

실례 예시 — 사건 보고서에 포함되지 않은 실제 Sentinel 출력은 아닙니다. 이는 심어놓은 로그 라인에 대한 스크럽 호출이 어떻게 반환될 수 있는지 보여줍니다:

{
  "request_id": "f3a9c21e",
  "security": {
...

그리고 비밀 탐지(secret detection)만을 위해, 콘텐츠의 어떤 부분이 위협 파이프라인을 건드리는지와는 별개로, 원시 로그 라인을 /v1/scrub에 secret_filter_level: redact를 설정하여 실행하는 경우:

{
  "request_id": "b7c88ef1",
  "security": {
...

두 가지 다른 결과를 주목하십시오. 첫 번째 예시는 주입된 명령 자체가 들어오는 과정에서 차단되는 것입니다. 두 번째는 로그 라인의 다른 부분이 위협적이지 않더라도, 비밀 탐지가 독립적인 사전 패스로 실행되기 때문에 비밀번호가 마스킹(redact)된다는 점입니다. 이는 매우 중요합니다. 왜냐하면 이 사건의 주입은 모델에게 주의를 기울이도록 지시하는 시스템 프롬프트에도 불구하고 작동했기 때문입니다. 유일한 방어 수단이 이미 한 번 실패했던 것과 같은 메커니즘이어서는 안 됩니다.

메모리 하이재킹(memory-hijack)의 절반에 대해서는 단일 API 호출보다는 아키텍처적인 접근 방식이 더 중요합니다. 어시스턴트가 검색이나 파일 내용에서 읽은 모든 것을 영구 저장소에 쓰기(write)를 트리거하기 전에 스크럽 패스(scrub pass)를 거치도록 경로를 설정해야 합니다. 이는 RAG 수집 시점 스캐닝(ingestion-time scanning)에 대해 설명된 것과 동일한 패턴입니다. 메모리로의 쓰기 경로는 신뢰할 수 없는 콘텐츠가 직접 접근해서는 안 되는 특권 작업(privileged operation)으로 취급하고, 모델이 방금 읽은 내용에 대한 자체 판단을 신뢰하기보다는 스캔을 통해 이를 검증해야 합니다.

핵심 요약 (Takeaway)

만약 LLM 기반 도구가 스스로 생성하지 않은 어떤 것(로그, 검색 결과, 파일 내용, 크롤링된 페이지)이라도 읽는다면, 그 콘텐츠는 공격자가 영향을 미칠 수 있게 되는 순간부터 공격자에게 도달 가능합니다. 그리고 모델에게 그것을 '단순한 데이터'로 취급하라고 지시하는 시스템 프롬프트(system-prompt)의 지침은 제어가 아니라 단지 제안일 뿐이며, 모델이 이를 무시할 수도 있습니다. 레드팀이 찾아낸 해결책(출력 스캔, 메모리 쓰기 게이트, 모델 판단만 신뢰하지 않기)이 올바른 형태입니다. 자체적인 링크 스캐너나 메모리 쓰기 게이트를 수동으로 구현하지 않고 여기에 도달하는 가장 빠른 방법은 파이프라인의 입력과 출력 양쪽에 모두 스크럽 패스를 배치하고, 시스템 프롬프트가 할 수 없는 일을 전용 탐지 계층(detection layer)에 맡기는 것입니다.

sentinelaifirewall.com에서 직접 시도해 보세요. 스타터 티어는 무료이며 신용카드 등록이 필요 없습니다.

출처 (Sources)

• Prompt injection through log files: what red-teaming our assistant found

AI 지원 초안 또는 이미징, 인간이 큐레이션하고 검토 및 편집함.