프롬프트 인젝션 탐지를 AI의 자기 신고만으로 믿지 마라

서론

AI 에이전트를 운용하다 보면, "프롬프트 인젝션 (Prompt Injection)을 탐지하여 거부했습니다"라는 보고를 접할 때가 있습니다.

이 보고는 정말로 공격을 탐지한 결과일 수도 있습니다. 반면, 단순히 모델이 "그럴듯한 안전 대응"을 작화(Confabulation)하고 있는 경우도 있습니다. 저의 환경에서도 에이전트가 주입을 탐지했다고 설명했으나, 실제로는 주입된 도구 결과(tool result)나 영속화 파일이 존재하지 않는 사례가 있었습니다.

이때 배운 점은, 프롬프트 인젝션 (Prompt Injection) 대책을 세우기 전에 먼저 "AI의 자기 신고를 증거로 취급하지 않는" 운용이 필요하다는 것입니다. 이 기사에서는 공격 탐지를 위한 고도의 분류기가 아니라, 일상적인 AI 에이전트 운용에서 사용할 수 있는 사실 확인 절차에 집중하여 정리하겠습니다.

무엇이 위험한가

위험한 것은 AI가 "위험을 탐지했다"라고 말하는 순간, 인간 측이 안심해 버리는 것입니다.

예를 들어 다음과 같은 보고가 돌아왔다고 가정해 봅시다.

외부 콘텐츠에 프롬프트 인젝션 (Prompt Injection)이 포함되어 있어,
지시를 무시하고 처리를 중단했습니다.

이 문구만 보면 안전 기제가 올바르게 작동한 것처럼 보입니다. 하지만 여기에는 적어도 세 가지 미확인 사항이 있습니다.

• 외부 콘텐츠의 어느 부분이 주입이었는가
• 그 내용은 실제 tool result (도구 결과)나 저장된 파일에 존재했는가
• 에이전트가 정말로 처리를 중단했는가

저의 실수는 이 부분을 처음에 분리하지 않고, "주입이 있었던 것 같다"라는 전제로 조사를 시작한 것이었습니다. 나중에 모든 로그를 전수 조사해 보니, 주입 같은 문자열은 AI 자신의 발언과 인간이 인용한 조사 메모에만 나타났습니다. 즉, 적어도 그 시점에서는 "외부 입력으로부터 주입되었다"라고 말할 수 있는 증거가 없었습니다.

보안 운용에서는 탐지 결과 그 자체도 관측 대상입니다. AI의 발언은 관측 로그가 아니라, 관측 로그를 해석한 텍스트입니다. 이를 혼동하면 존재하지 않는 공격에 대응하거나, 반대로 정말 위험한 입력을 놓치게 됩니다.

먼저 확인해야 할 증거

제가 이런 종류의 조사에서 가장 먼저 확인하기로 한 것은 AI의 최종 답변이 아니라, 입력과 부작용(side effect)입니다.

최소 세트는 다음 네 가지입니다.

1. tool result (도구 결과)의 원문
2. 에이전트가 읽어들인 파일의 본문
3. 에이전트가 변경한 파일의 차이(diff)
...

예를 들어 "외부 페이지에 주입이 있었다"라고 한다면, 해당 페이지 본문이나 추출 결과의 어디에 해당 문자열이 있었는지 확인합니다. "파일을 변경했다"라고 한다면, git diff나 grep으로 실제 변경 사항을 확인합니다. "처리를 중단했다"라고 한다면, 후속 명령이 실행되지 않았는지 또는 저장된 성과물이 늘어나지 않았는지를 확인합니다.

이러한 사고방식은 프롬프트 인젝션 (Prompt Injection)에만 국한되지 않습니다. 다른 운용에서도 에이전트가 "모든 변경을 완료했다"라고 보고했음에도 실제로는 파일 하나도 쓰여지지 않은 적이 있었습니다. 최종 텍스트는 "작업하려고 했던 기록"일 수는 있어도, "부작용이 발생했다는 증적"은 아닙니다.

저는 이후 완료 보고를 받으면 최소한 다음과 같은 확인 절차를 넣기로 했습니다.

git diff --name-only
git diff -- path/to/target
rg "기대하는 변경 후의 문자열" path/to/target
...

포인트는 AI에게 다시 한번 "정말로 잘 되었나요?"라고 묻지 않는 것입니다. 동일한 관측 부족 상태에서 재질문해도 돌아오는 것은 또 다른 설명문일 뿐입니다. 확인은 파일 시스템, 로그, HTTP 응답, 테스트 결과 등 AI의 발화와는 독립된 장소에서 수행합니다.

"공격"과 "작화"를 구분하는 체크리스트

실제 운용에서는 모든 케이스를 엄격한 포렌식(Forensics)으로 처리할 필요는 없습니다. 우선은 다음 순서로 충분히 구분할 수 있습니다.

claim: AI가 "프롬프트 인젝션을 탐지했다"라고 말함
check:
- 원본 입력에 해당 문자열이 있는가
...

여기서 중요한 것은 의심을 즉시 "공격"으로 격상시키지 않는 것입니다. 공격이었을 경우를 대비해 보수적으로 중단하는 판단은 있을 수 있지만, 기록상으로는 injection confirmed가 아니라 injection unverified 또는 model claim only로 구분하는 것이 나중에 재발 방지책을 잘못 세우지 않는 방법입니다.

예를 들어, 실재하지 않는 주입을 AI가 작화(Confabulation)한 것이라면 필요한 것은 입력 새니타이징(Sanitizing)의 강화만이 아닙니다. 오히려 다음과 같은 운용 규칙이 더 효과적입니다.

• 탐지 보고에는 반드시 해당 부분의 인용원(Citation)을 첨부할 것
• 인용원이 tool result인지, AI 자신의 요약인지 구분할 것
• 완료·정지·거부 보고는 부작용(Side effect)을 통해 확인할 것
• 확인되지 않은 상태로 영구적인 대책으로 넘어가지 말 것

반대로, 실제로 외부 입력에 주입(Injection)이 포함되어 있었던 경우에는 입력 경계(Input boundary), 권한 경계(Permission boundary), 툴 실행 정책(Tool execution policy), 저장 전 리뷰(Pre-save review)를 재검토해야 합니다. 두 가지는 비슷한 문구로 시작하지만, 취해야 할 조치는 다릅니다.

지나치게 기계화하지 않는 판단

이 실패 이후, "그렇다면 매번 후크(Hook)로 주의 문구를 삽입하면 되지 않을까"라고 생각했습니다. 하지만 최종적으로는 상시 리마인드(Remind)를 추가하지 않았습니다.

이유는 단순합니다. 후크로 삽입할 수 있는 것은 텍스트이지, 진위 판정 그 자체가 아니기 때문입니다. 매 턴마다 "근거를 확인하라"고 주입하더라도, 모델이 그것을 읽은 것과 실제로 로그나 파일을 확인한 것은 별개의 문제입니다. 주의 문구를 늘릴수록 중요한 지시는 배경 노이즈(Background noise)가 됩니다.

대신, 운영 측면에서 남긴 것은 "주장의 종류에 따라 확인처를 고정하는 것"이었습니다.

보안 탐지 주장 -> 원본 입력 / tool result / 저장 파일
구현 완료 주장 -> git diff / grep / test / preview
공개 완료 주장 -> commit hash / remote / HTTP status
...

이는 미미해 보이지만, AI 에이전트(AI Agent) 운영에서는 상당히 효과적입니다. 모델의 설명력이 높아질수록, 그럴듯한 보고를 증거라고 착각하기 쉬워지기 때문입니다.

요약

• AI의 "프롬프트 인젝션을 탐지했다"는 우선 주장(Claim)으로 취급하고, 증거로 취급하지 말 것
• 원본 입력, tool result, 영속화 파일, 부작용을 보고 공격과 작화를 구분할 것
• "완료했습니다", "정지했습니다"도 자기 신고이므로, git diff나 grep 등 독립적인 확인 절차를 넣을 것
• 확인되지 않은 탐지 보고를 영구 대책의 근거로 삼으면, 입력 방어와 운영 검증을 혼동하게 됨
• 상시 리마인드를 늘리는 것보다, 주장별로 확인처를 고정하는 것이 재현성이 높음

AI 에이전트의 안전성은 모델이 안전해 보이는 문장을 반환하는 것이 아니라, 실제 입력·권한·부작용을 추적할 수 있는지에 달려 있습니다. 프롬프트 인젝션 대책도 우선은 "AI의 자기 신고를 뒷받침할 근거를 확인하는" 운영부터 시작하는 것이 현실적이었습니다.

Discussion