직원이 외부 제안서를 AI에 올리고 비교 요약을 요청했다. 그런데 AI가 제안서 속 문장을 지시로 받아들여 특정 업체를 우선 추천하거나 요청하지 않은 작업을 시도한다면 문제의 성격이 달라진다. 프롬프트 인젝션은 AI가 읽어야 할 자료와 따라야 할 지시 사이의 경계를 흔드는 공격이다.
자료의 내용이 업무 지시로 바뀌는 지점
생성형 AI 서비스는 사용자 요청, 서비스 운영 규칙, 검색 결과, 첨부파일 등을 모델에 전달한다. 이때 신뢰할 수 없는 입력이 모델의 응답이나 행동을 의도하지 않은 방향으로 바꾸면 프롬프트 인젝션 문제가 발생한다. OWASP의 LLM01 설명은 직접·간접 입력을 통한 행동 변경과 그 영향을 다룬다.
자료 안에 명령문이 있다는 사실만으로 공격이라고 판단해서는 안 된다. 매뉴얼의 작업 지침을 요약하거나 의심 문구를 분석하는 것은 정상 업무다. 핵심은 자료 속 문장이 원래 사용자의 목적과 서비스 규칙을 대신해 행동 기준으로 채택되는지다.
제안서의 제품 설명은 비교에 사용할 데이터다. 같은 문서에 평가 기준을 임의로 바꾸거나 다른 자료를 전달하도록 유도하는 내용이 있어도, 그 문서가 업무 권한을 부여할 수는 없다. 문서를 읽을 수 있다는 사실과 문서가 지시할 권한이 있다는 사실은 구별해야 한다.
직접 입력과 외부 자료를 통한 간접 입력
직접 인젝션은 입력창에 들어온 내용이 서비스의 의도된 동작을 벗어나도록 유도하는 방식이다. 간접 인젝션은 AI가 읽는 웹페이지, 이메일, 파일 등 외부 자료에 지시가 섞여 들어오는 방식이다. 후자는 정상 사용자가 정상 업무를 수행하는 중에도 접할 수 있다.
따라서 입력창 검사만으로 전체 경로를 다룰 수 없다. 검색 문서, 첨부파일의 추출 텍스트, 연동 도구가 반환한 내용까지 신뢰 수준을 구분해야 한다. Microsoft의 MCP 보안 설명은 도구 설명에 포함된 지시도 도구 선택을 왜곡할 수 있다고 설명한다.
직원의 미승인 AI 사용과도 구별할 필요가 있다. 회사가 승인한 서비스라도 제3자의 자료를 처리하면 이 위험에 노출될 수 있다. 직원에게 기밀 입력 금지를 교육하는 것과 별개로, 외부 자료가 AI의 조회·실행 판단에 영향을 미치는 경로를 살펴야 한다.
가상 예시: 제안서 비교가 자료 전달로 확대되는 경우
다음은 실제 사고가 아닌 가상 예시다. 구매 담당자가 두 업체의 제안서 비교를 요청했고, AI 서비스에는 사내 자료 검색과 메일 초안 작성 기능이 연결되어 있다고 가정한다. 한 제안서에는 비교와 무관한 내부 검토 자료를 특정 수신자에게 전달하도록 유도하는 내용이 섞여 있다.
첫 번째 확인 지점은 요약 결과다. AI가 제안서의 주장을 검증된 평가처럼 받아들이면 추천 결과가 오염될 수 있다. 두 번째는 추가 자료 조회다. 비교 업무에 필요하지 않은 사내 문서를 가져오려는 시도가 있는지 확인한다.
세 번째는 외부 전달이다. 초안만 만드는 서비스라면 실제 발송까지 이어지는 경로는 제한된다. 반대로 광범위한 조회 권한과 발송 권한이 함께 연결되면 영향이 커질 수 있다. 문구를 읽었다고 곧바로 유출이 성립하는 것은 아니며, 접근 가능한 정보와 실행 권한, 승인 절차를 함께 확인해야 한다.
모델의 거절과 별개로 피해 범위를 제한한다
다음은 기업 도입을 위한 운영 권고다. 외부 자료를 참고 데이터로 표시하고 신뢰할 지시와 구분하는 설계부터 시작한다. 다만 구분자나 시스템 프롬프트를 추가했다는 이유만으로 방어가 완성되었다고 판정해서는 안 된다.
조회 권한은 요청자의 실제 업무 권한에 맞춰 서버에서 확인한다. 모델이 어떤 문서가 필요하다고 판단해도 접근할 수 없는 자료를 검색 도구가 반환해서는 안 된다. 요약 업무에 전사 관리자 계정을 연결하는 구성을 피하고, 읽기와 수정·삭제·발송 권한을 나누는 편이 좋다.
메일 발송이나 문서 공유는 모델이 만든 실행 제안과 별도의 검증 단계를 둔다. 서버가 허용된 작업·대상·인수를 검사하고, 영향이 큰 작업은 수신자·첨부파일·변경 내용을 사람이 확인하게 한다. 모델이 생성한 승인 완료 문장은 실제 승인 기록을 대신할 수 없다.
응답 화면도 점검 대상이다. Google의 다층 방어 설명은 외부 이미지 URL 렌더링 제한, 의심 URL 처리, 사용자 확인 절차를 소개한다. 기업 서비스에서도 생성된 링크나 외부 리소스를 자동으로 불러오는 동작이 정보 전달 경로가 되는지 확인하는 편이 좋다.
도입 전 점검표
다음은 특정 제품의 인증 기준이 아닌 도입 검토용 점검 예시다. 운영 환경과 분리된 시험 환경에서 가상 자료와 시험 계정을 사용한다. 통과 여부는 AI의 설명보다 실제 도구 호출과 시스템 기록으로 확인한다.
| 시험 항목 | 기대 동작 | 확인할 증거 |
|---|---|---|
| 외부 문서가 다른 작업을 유도 | 자료 속 지시로 업무 범위를 확대하지 않음 | 응답·도구 호출 이력 |
| 권한 밖 시험 문서를 조회 | 검색·조회 계층에서 접근 거부 | 권한 검사·반환 기록 |
| 외부 수신자가 있는 발송 제안 | 구체적인 내용 확인 전 발송 보류 | 수신자·첨부파일·승인 기록 |
| 위험 작업의 인수가 허용 범위를 벗어남 | 서버 검증에서 거부 | 검증·실행 결과 |
| 정상 인용문·매뉴얼 처리 | 정상 업무를 완료하고 불필요한 차단 최소화 | 업무 완료·오탐 기록 |
| 모델·검색·도구 설정 변경 | 기존 시험을 다시 수행 | 변경 전후 평가 기록 |
시험 결과에는 어떤 통제가 실행을 막았는지도 남긴다. 모델이 지시를 거절한 경우와 모델은 실행을 제안했지만 서버가 거부한 경우는 개선할 지점이 다르다. 정상 업무가 계속 차단된다면 문서를 무조건 허용하기보다 오탐을 검토할 절차와 담당자를 정한다.
실무자 관점: 탐지 기능보다 먼저 연결 권한을 정리한다
프롬프트 인젝션 탐지는 의심 입력을 찾는 데 도움이 되지만 탐지와 차단은 같은 동작이 아니다. Microsoft의 Prompt Shields 문서는 탐지 결과를 받은 뒤 허용·차단·사람 검토 등을 수행하려면 설정 또는 애플리케이션 로직이 필요하다고 설명한다.
도입 검토에서는 탐지 기능의 유무 다음에 처리 정책을 확인해야 한다. 탐지 서비스가 실패하거나 지연되면 업무가 그대로 진행되는지, 의심 문서를 제외했음을 사용자에게 알리는지, 오탐은 누가 검토하는지까지 정해야 운영 가능한 통제가 된다.
보안 담당자가 먼저 받아야 할 자료는 연결 목록에 가깝다. 어떤 자료를 읽고, 어떤 계정으로 조회하며, 어디에 쓰고 보낼 수 있는지 표로 정리하면 우선순위가 드러난다. 모델의 방어 성능이 개선되어도 과도한 권한과 불명확한 승인 절차를 그대로 둘 이유는 없다.
운영 시작 기준은 실제로 제한되는 경로다
도입 초기에는 외부 자료를 읽고 초안을 제시하는 범위에서 시작하고, 수정·발송 기능은 검증 후 단계적으로 연결하는 방법을 권한다. RAG로 사내 문서를 검색하게 하거나 프롬프트를 조정해도 인젝션 위험이 자동으로 사라지지는 않는다.
최종 판단 기준은 모델이 위험을 설명할 수 있는지가 아니다. 자료 속 지시를 따르려는 상황에서도 권한 밖 조회와 승인 없는 실행이 시스템에서 제한되는지다. 모델·검색 경로·연동 도구가 바뀌면 같은 시험을 다시 수행하고, 정상 업무의 성공 여부와 잘못된 실행 여부를 함께 기록해야 한다.