30장. 프롬프트 인젝션은 권한 문제다

OWASP 생성형 AI 보안 프로젝트는 프롬프트 인젝션, 민감정보 노출, 공급망, 과도한 권한 같은 위험을 다룬다. 인젝션을 “모델이 이상한 문장을 믿는 문제”로만 보면 부족하다. 믿은 뒤 어떤 도구와 데이터에 접근할 수 있는지가 피해를 결정한다.

방어는 여러 층으로 겹친다.

1. 지시와 외부 자료를 분리한다.
2. 신뢰 출처와 데이터 분류를 표시한다.
3. 필요한 도구만 노출하고 인자를 검증한다.
4. 사용자 권한을 서버에서 다시 확인한다.
5. 읽기와 외부 쓰기를 분리한다.
6. 고위험 행동은 사람 승인과 재인증을 요구한다.
7. 출력이 코드·HTML·SQL로 실행되기 전에 검증한다.
8. 호출과 결과, 중단, 롤백을 감사한다.

모델 출력은 명령이 아니라 불신 입력이다. SQL로 실행할 때 parameter binding과 허용 쿼리를 사용하고, HTML은 escape하고, shell command에 그대로 연결하지 않는다.

금지: exec(model_output)
금지: shell("deploy " + model_output)
권장: validate(schema) → authorize(user, action) → execute(allowlisted action)

레드팀 fixture에는 직접·간접 인젝션, 인코딩, 다국어, 도구 결과 속 지시, 권한 상승, 데이터 유출을 넣는다. 방어 문구 하나를 통과했다고 안전을 선언하지 않는다.

사건이 발생하면 입력 원문을 무분별하게 공유하지 않고 접근 제한된 증거로 보존한다. 영향받은 자격 증명을 회전하고 도구 권한을 줄이며 재현 fixture를 평가 세트에 추가한다.

인젝션 탁상 훈련

가정: 고객 PDF에 결제 도구 호출을 유도하는 숨은 문장이 있고 에이전트가 환불 준비를 시작했다. 팀은 기능 플래그로 행동을 멈추고, 실제 환불 여부를 receipt로 대사하고, 영향 사용자와 문서를 찾고, 자격 증명 회전 여부와 통지 경로를 결정해야 한다.

답이 특정 개인의 기억에만 있으면 운영 준비가 부족하다. 훈련 뒤 탐지 시간, 중단 시간, 대사 시간, 누락 로그를 기록한다. 공격 문구를 공개 문서에 그대로 확산하지 않고 안전한 fixture로 축약한다.