프롬프트 인젝션 대응 가이드: 무엇을 막고 무엇을 포기해야 하나

전제: 완전 차단은 목표가 아니다

프롬프트 인젝션은 입력 검증으로 완전히 막을 수 있는 종류의 문제가 아닙니다. LLM은 명령과 데이터를 같은 채널로 받기 때문에, 데이터 안에 들어온 명령을 구조적으로 구분하지 못합니다.

따라서 현실적인 목표는 "주입을 막는 것"이 아니라 "주입이 성공해도 할 수 있는 일이 없게 만드는 것" 입니다. 이 전제를 받아들이지 않으면 대응 설계가 계속 어긋납니다.

유형 구분

직접 주입 (Direct)

사용자가 직접 입력창에 지시를 넣어 시스템 프롬프트를 무력화하려는 시도입니다. 서비스 정책 우회, 시스템 프롬프트 탈취가 주된 목적입니다. 피해는 보통 해당 세션에 한정됩니다.

간접 주입 (Indirect)

모델이 읽어 들이는 외부 콘텐츠 안에 명령이 심어져 있는 경우입니다. 웹 페이지, 문서, 이메일, 코드 주석, 이미지의 메타데이터 등이 경로가 됩니다. 사용자는 아무 잘못도 하지 않았는데 공격이 성립합니다.

에이전트가 도구를 쓰는 구조에서는 이쪽이 훨씬 위험합니다. 외부 문서 하나가 파일 삭제, 메일 발송, 외부 전송 같은 행동을 유도할 수 있기 때문입니다.

방어 전략

1. 권한 최소화가 1순위다

프롬프트 방어 문구보다 도구 권한 설계가 압도적으로 중요합니다.

• 읽기 전용으로 충분한 작업에 쓰기 권한을 주지 않습니다.
• 외부 전송(메일, 웹훅, API 호출)은 별도 승인 단계를 둡니다.
• 삭제·결제·배포처럼 되돌리기 어려운 작업은 사람 확인을 강제합니다.

2. 신뢰 경계를 명시한다

시스템이 다루는 텍스트를 "지시"와 "데이터"로 분리하고, 외부에서 들어온 것은 항상 데이터로 취급합니다. 도구 실행 결과, 검색 결과, 업로드 문서에 들어 있는 지시문은 실행 대상이 아니라 검토 대상입니다.

3. 출력 검증

모델 출력이 그대로 다른 시스템에 전달되는 경로를 점검합니다.

• HTML로 렌더링된다면 XSS 관점의 이스케이프
• SQL이나 셸로 전달된다면 파라미터 바인딩과 허용 목록
• 다른 에이전트의 입력이 된다면 다시 데이터로 취급

4. 관측 가능성

무엇이 언제 어떤 근거로 실행됐는지 남지 않으면 사고 후 분석이 불가능합니다. 도구 호출 로그, 입력 출처, 승인 이력을 보존하세요.

운영 점검 체크리스트

• 에이전트가 쓸 수 있는 도구 목록과 각 권한 범위를 문서화했는가
• 되돌리기 어려운 작업에 사람 승인이 강제되는가
• 외부 콘텐츠를 데이터로 취급하도록 시스템 프롬프트에 명시했는가
• 모델 출력이 들어가는 다운스트림 경로를 모두 파악했는가
• 도구 호출 로그가 사고 분석이 가능한 수준으로 남는가
• 비정상적인 도구 호출 패턴에 대한 알림이 있는가

정리

프롬프트 인젝션 대응은 AI 보안 문제이기 전에 권한 설계 문제입니다. "모델이 속을 수 있다"를 전제로 두고, 속았을 때 실행 가능한 행동을 줄이는 방향으로 설계하면 대부분의 심각한 시나리오가 사라집니다.