AI가 읽은 문서가 명령으로 바뀐다: 프롬프트 인젝션과 에이전트 보안의 진짜 경계

 

프롬프트 인젝션은 AI가 읽어야 할 자료 속 지시를 실제 명령처럼 받아들여 원래 요청에서 벗어나게 만드는 문제다. AI 에이전트가 웹페이지, 이메일, 사내 문서, 코드 저장소를 읽고 도구까지 실행하는 환경에서는 답변 오류가 데이터 전송이나 외부 시스템 변경으로 이어질 수 있다. 그래서 에이전트 보안은 좋은 시스템 프롬프트를 쓰는 단계에서 끝나지 않는다.

 

이 글은 프롬프트 인젝션의 뜻과 직접·간접 공격의 차이, RAG와 MCP 환경의 신뢰 경계, 도구 권한과 외부 전송 통제, 테스트와 사고 대응까지 정리한다. OpenAI의 2026년 공개 설명, OWASP의 LLM 보안 지침, NVIDIA와 국내 기술 블로그를 비교해 실제 서비스를 설계할 때 확인할 항목을 살펴본다.

 

핵심 요약

 

• 외부 문서가 주장하는 권한과 사용자가 실제로 부여한 권한은 구분해야 한다.

 

• 문서에 지시문이 있다고 모두 공격은 아니다. 그 문장을 읽는 목적과 실행 권한의 출처가 중요하다.

 

• RAG, XML 태그, JSON 출력, 별도 검토 모델은 도움이 될 수 있지만 각각 완전한 방어를 보장하지 않는다.

 

• 민감한 행동은 실행 계층에서 대상, 범위, 수신자, 권한을 검증해야 한다.

 

• 공격 차단률과 함께 정상 업무 완료율, 잘못된 차단, 실제 외부 상태를 측정해야 한다.

 

읽을 순서

 

① 프롬프트 인젝션의 개념과 실제 자료

② 문서·검색·도구 사이의 신뢰 경계

③ 권한·전송·승인·메모리 방어 설계

④ 업무 적용 예시와 평가·사고 대응

⑤ 도입 체크리스트와 자주 묻는 질문

 

1. 프롬프트 인젝션이란 무엇인가

 

 

AI 서비스는 보통 개발자가 정한 동작 규칙, 사용자의 요청, 검색한 자료, 도구의 응답을 함께 사용한다. 프롬프트 인젝션은 이 입력을 이용해 모델의 응답이나 행동을 의도하지 않은 방향으로 바꾸는 시도다. 외부 문서를 요약하라는 요청을 받았는데 문서 안의 문장을 따라 다른 일을 수행한다면 자료와 지시 사이의 경계가 무너진 것이다.

 

직접 인젝션은 사용자가 입력하는 대화나 요청을 통해 동작을 바꾸려는 방식이다. 간접 인젝션은 웹페이지, 파일, 검색 결과, 이메일 같은 외부 자료를 거쳐 영향을 준다. 사용자가 악성 문장을 직접 작성하지 않아도 정상적인 자료 조사 중에 노출될 수 있다는 점이 에이전트 환경에서 중요하다.[1]

 

모든 지시문이 악성인 것은 아니다. 사용 설명서에는 원래 명령형 문장이 많고 보안 교육 문서에는 공격 예시가 들어 있다. 문제는 문장의 모양만이 아니라 그 문장이 현재 작업에서 어떤 권한을 갖는지다. 문서 내용을 설명하는 일과 문서가 요구하는 외부 행동을 실행하는 일은 별도로 판단해야 한다.

 

환각과도 구분할 필요가 있다. 근거 없이 틀린 답을 만드는 현상이 있다고 모두 인젝션은 아니다. 외부 입력이 행동 방향을 바꾸는 경로가 있었는지 확인해야 원인에 맞는 개선을 할 수 있다. 실제 장애에서는 검색 품질 저하, 도구 오류, 인젝션이 함께 나타날 수도 있다.

 

2. 챗봇의 답변 오류가 에이전트의 행동 문제로 바뀐다

 

텍스트만 생성하는 챗봇에서도 잘못된 정보와 민감한 내용의 노출은 문제가 된다. 여기에 이메일 전송, 파일 수정, 고객 기록 변경, 코드 실행 도구가 연결되면 모델의 판단이 외부 상태를 바꾸는 경로가 생긴다. 같은 입력 오류라도 연결된 기능과 권한에 따라 영향이 달라진다.

 

 

가상의 보고서 작성 에이전트를 생각해 보자. 사용자는 공개 자료를 비교해 초안을 만들어 달라고 했다. 그런데 조사한 문서가 별도의 등록 절차를 요구하며 사내 자료를 다른 수신자에게 보내라고 주장한다. 그 문서는 조사 대상일 뿐 전송 권한을 부여할 수 있는 주체가 아니다.

 

이때 모델이 문장을 따를지 여부만 점검하면 방어 범위가 좁다. 보고서 작성 작업에 사내 비밀 자료가 꼭 필요한지, 전송 도구가 열려 있어야 하는지, 수신자가 업무 범위에 있는지 함께 봐야 한다. 도구의 접근 범위를 줄이면 잘못된 판단이 발생해도 실제 피해로 연결되는 경로를 줄일 수 있다.

 

사람 직원이 외부 이메일을 읽을 때도 메시지 안의 주장만으로 회사의 결재 권한이 생기지는 않는다. AI도 비슷한 관점으로 설계할 수 있다. 읽을 수 있는 정보, 판단에 참고할 정보, 실제로 실행할 수 있는 행동을 분리해서 관리하는 것이다.

 

3. 2026년 OpenAI 설명에서 읽어야 할 핵심

 

OpenAI는 2026년 3월 ‘프롬프트 인젝션을 거부하는 AI 에이전트 설계하기’에서 실제 공격이 단순한 지시 덮어쓰기를 넘어 사회공학적 설득과 유사해지고 있다고 설명했다. 정상 업무처럼 보이는 맥락에 조작된 행동 요구를 섞으면 단순한 악성 문자열 탐지로 구별하기 어렵다는 관점이다.[2]

 

해당 글은 외부 입력이 들어오는 소스와 민감한 기능이 실행되는 싱크를 함께 보는 접근을 소개한다. 소스는 웹페이지나 이메일처럼 시스템에 영향을 주는 입력 경로이고, 싱크는 정보 전송이나 도구 사용처럼 잘못된 맥락에서 위험해질 수 있는 기능이다.

 

 

또한 OpenAI는 대화에서 얻은 정보를 제3자에게 보내려는 상황을 감지하고 확인을 요구하거나 차단하는 Safe Url 완화 전략을 설명한다. 이는 해당 서비스가 공개한 방어 방식에 관한 설명이다. 모든 AI 제품이나 모든 링크 이동에 동일한 보호 장치가 적용된다는 뜻으로 일반화해서는 안 된다.

 

실무에서 가져올 원칙은 분명하다. 모델이 악성 문장을 전부 알아보도록 기대하는 것과 별개로, 정보가 어디에서 들어와 어떤 기능을 통해 나갈 수 있는지 추적해야 한다. 입력 분류와 행동 통제를 함께 설계해야 하는 이유다. 이 글은 공개 자료를 해석한 설계 제안이며 특정 제품을 직접 침투 테스트한 결과는 아니다.

 

4. 국내 기술 블로그와 NVIDIA 사례가 더해 주는 관점

 

인포그랩의 2025년 기술 글은 직접·간접 인젝션, 멀티모달 입력, 메모리와 다중 에이전트로 이어지는 경로, 여러 계층의 방어를 폭넓게 소개한다. 특히 웹 문서 외에 코드 주석과 이메일도 입력 경로가 된다는 점, 모델 외부의 애플리케이션과 인프라를 함께 강화해야 한다는 점을 참고할 만하다.[3]

 

다만 모델이 모든 입력을 문자 그대로 구분하지 못한다거나 항상 최신 문장을 따른다는 식의 단순한 설명은 실제 시스템 전체를 설명하기에 부족하다. 오늘날 모델은 역할과 지시 우선순위를 학습하고 애플리케이션도 구조화된 메시지를 사용한다. 그렇더라도 공격에 대한 완전한 보안 경계가 저절로 생기는 것은 아니라는 식으로 이해하는 편이 정확하다.

 

NVIDIA의 한국어 기술 블로그는 2025년 시각적 기호와 이미지의 의미를 이용하는 멀티모달 인젝션 사례를 소개했다. 텍스트를 추출해 금지어만 검사하는 접근으로는 이미지에서 추론되는 행동의 의미를 모두 다루기 어렵다는 문제를 제기하고, 실행 전 출력과 후속 영향을 점검하는 방어를 강조한다.[4]

 

 

여기서 모든 이미지가 위험하다거나 특정 모델은 반드시 공격에 성공한다는 결론을 낼 수는 없다. 공개된 연구 사례의 시사점은 입력 표면이 텍스트에 한정되지 않는다는 것이다. 서비스가 이미지와 음성을 처리한다면 평가와 권한 설계도 그 범위를 포함해야 한다.

 

5. RAG를 붙여도 문서가 안전해지는 것은 아니다

 

RAG는 필요한 자료를 검색해 모델의 응답에 활용하는 방식이다. 최신 정보나 사내 지식을 참고하는 데 유용하지만 검색된 문서의 모든 문장을 신뢰할 수 있는 명령으로 바꾸는 장치는 아니다. OWASP도 RAG와 파인튜닝이 프롬프트 인젝션 취약점을 완전히 완화하지는 못한다고 설명한다.[1]

 

검색 품질과 입력 신뢰성은 서로 다른 문제다. 질문과 매우 관련 있는 문서에도 조작된 지시가 섞일 수 있다. 검색 순위가 높다는 사실은 읽을 가치가 높다는 신호일 수 있어도 행동 권한의 근거가 되지는 않는다. 답변의 정확도를 높이는 기법과 행동의 권한을 보장하는 통제를 혼동하면 안 된다.

 

사내 저장소도 예외는 아니다. 협력사가 올린 자료, 고객이 제출한 파일, 공개 자료를 복사한 문서가 사내 검색 색인에 포함될 수 있다. 저장 위치가 내부라는 이유만으로 모든 작성자를 같은 신뢰 수준으로 취급하면 외부 내용이 내부 자료처럼 보이는 문제가 생긴다.

 

문서에는 작성 주체, 수집 경로, 접근 권한, 버전, 기준일을 연결할 수 있다. 검색 단계에서 사용자가 볼 수 있는 자료만 반환하도록 권한을 확인하고, 생성 단계에서는 출처를 남긴다. 다만 출처를 표시했다고 인젝션이 차단되는 것은 아니다. 추적 가능성과 실행 권한 검증은 각각 필요하다.

 

6. 신뢰 경계는 누가 지시할 수 있는지를 정한다

 

 

가장 먼저 정리할 질문은 ‘이 입력이 할 수 있는 일은 무엇인가’다. 사용자의 요청은 업무 목표를 정할 수 있지만 외부 문서는 일반적으로 그 목표를 수행하기 위한 참고 자료다. 문서가 자신을 관리자 공지나 보안 업데이트라고 주장해도 그 주장 자체가 권한의 증거가 되지는 않는다.

 

업무를 시작할 때 목표와 범위를 기록하면 이후 행동을 판단하기 쉽다. 예를 들어 공개 문서 세 건을 비교해 초안을 작성하는 작업이라면 외부 전송이나 계정 설정 변경은 별도 요청에 해당한다. 자료가 그런 절차를 요구하더라도 원래 작업의 권한이 자동으로 넓어지지 않게 해야 한다.

 

이 원칙은 문서 속 정상적인 절차를 모두 무시하라는 뜻은 아니다. 사용자가 공식 매뉴얼에 따라 설정을 바꾸라고 요청했다면 매뉴얼의 절차가 작업 자료가 된다. 그래도 실제 변경 대상과 범위, 사용자가 허용한 조치인지는 확인해야 한다. 실행 근거는 사용자 요청과 검증된 권한에서 온다.

 

시스템은 이 구분을 프롬프트에만 적지 말고 도구 호출 계층에도 반영할 수 있다. 요청한 동작이 현재 작업에서 허용된 유형인지 확인하고 범위가 달라지면 실행을 보류하도록 설계한다. 자연어의 해석과 실제 권한 판정이 서로 보완해야 한다.

 

7. XML 태그와 JSON 출력은 어디까지 도움이 될까

 

외부 자료를 구분자로 감싸고 데이터라고 명시하는 방법은 모델이 입력 구조를 이해하는 데 도움을 줄 수 있다. 시스템 규칙과 문서 본문을 섞어 붙이는 것보다 각 입력의 역할을 분명히 표현하는 편이 낫다. 하지만 태그 이름이 곧 보안 장벽이 되는 것은 아니다.

 

 

JSON 출력도 형식 검증에는 유용하다. 필수 필드가 있는지, 값의 유형이 맞는지, 허용한 명령 이름인지 코드로 검사할 수 있다. 그러나 문법적으로 올바른 JSON에 잘못된 수신자나 허용되지 않은 대상이 담길 수 있다. 구조가 맞는지와 실행이 정당한지는 다른 검사다.

 

예를 들어 문서 전송 도구가 수신자와 문서 식별자를 받는다면 두 값이 문자열이라는 사실만 확인해서는 부족하다. 그 수신자에게 해당 문서를 보낼 권한이 있는지, 사용자가 그 행동을 요청했는지, 현재 문서 버전이 맞는지도 검증해야 한다.

 

따라서 형식 검증, 의미 검증, 권한 검증을 구분해 설계하는 편이 좋다. 첫째는 값의 모양, 둘째는 업무상 유효성, 셋째는 실행 허용 여부를 다룬다. 모델이 그럴듯한 인자를 생성했다고 세 검사를 통과한 것으로 취급해서는 안 된다.

 

8. 도구 권한은 읽기·쓰기·외부 전송으로 나눠라

 

읽기 전용 조사와 외부 상태 변경을 같은 권한 묶음으로 제공하면 공격이 이용할 수 있는 기능이 커진다. 자료를 요약하는 작업에는 대개 결제, 삭제, 이메일 발송이 필요하지 않다. 사용 목적에 맞게 도구와 계정 권한을 제한하는 최소 권한 원칙이 중요하다.[1]

 

도구 이름만 분리해도 실제 서버 계정이 관리자 권한을 갖고 있으면 제한이 약해질 수 있다. API가 요청한 사용자와 작업의 권한을 직접 검사하도록 해야 한다. 모델이 보낸 설명을 권한 증명으로 사용하지 말고 서버가 알고 있는 계정, 리소스, 정책으로 판단한다.

 

범용 실행 도구보다 업무 범위가 정해진 인터페이스를 고려할 수 있다. 예를 들어 모든 데이터베이스 쿼리를 자유롭게 실행하게 하는 대신 특정 업무의 조회 기능을 제공하면 노출 범위를 줄일 수 있다. 다만 기능이 좁아도 접근 대상과 매개변수 검증이 빠지면 취약점이 남는다.

 

 

오류 메시지에도 주의가 필요하다. 권한이 없다는 오류를 읽은 에이전트가 다른 도구나 다른 계정으로 같은 작업을 시도하도록 만들면 통제가 약해진다. 권한 거부와 일시적인 서비스 장애를 구분하고 전자는 권한을 바꾸지 않는 한 재시도 대상에서 제외하는 정책이 필요하다.

 

9. 데이터 유출은 전송 버튼에서만 발생하지 않는다

 

외부로 나가는 데이터 경로는 이메일 본문에만 있지 않다. 검색어, 링크 주소의 매개변수, 업로드 파일, 외부 API 호출에도 업무 정보가 실릴 수 있다. 자료 속 링크를 여는 행동이 단순한 읽기처럼 보여도 요청 주소에 민감한 값이 들어가면 전송이 발생한다.

 

따라서 모델이 생성한 목적지와 전송 내용을 함께 봐야 한다. 허용한 도메인인지 확인하는 것에 더해 실제 수신 서비스와 전송 필드, 요청 목적을 검사한다. 중간 리디렉션이 있는 환경에서는 최초 주소만 보고 판단해도 충분한지 검토할 필요가 있다.

 

이 통제를 구현할 때 모든 문자열을 민감정보라고 차단하면 정상 검색이 불가능해질 수 있다. 공개 검색에 사용해도 되는 정보와 외부 반출이 제한된 자료를 구분하고 업무별 정책을 정한다. 중요한 문서가 모델 입력에 들어오기 전에 필요한 최소 범위만 제공하는 것도 노출을 줄이는 방법이다.

 

입력에서 한 번 탐지하는 것보다 실제 전송 직전에 다시 확인하는 단계가 유용하다. 여러 출처에서 얻은 정보가 나중에 하나의 요청으로 결합될 수 있기 때문이다. 외부 행동을 수행하는 실행 계층이 최종 목적지와 내용을 확인해야 한다.

 

10. 사람의 승인은 구체적인 행동에 연결해야 한다

 

 

확인창이 있다는 사실만으로 안전한 것은 아니다. 사용자가 ‘계속’이라는 버튼만 보고 무엇이 바뀌는지 모르면 충분한 판단을 하기 어렵다. 중요한 행동의 승인 화면에는 변경 대상, 수신자, 전송 항목, 영향 범위처럼 결정에 필요한 정보를 보여주는 편이 좋다.

 

승인은 사용자가 검토한 행동에만 연결돼야 한다. 초안을 승인했는데 나중에 수신자나 첨부 파일이 바뀌었다면 처음 승인을 그대로 재사용하면 안 된다. 승인 대상의 버전이나 핵심 값을 고정하고 실행 직전에 일치하는지 검사하는 방식으로 설계할 수 있다.

 

그렇다고 모든 조회마다 확인창을 띄우면 정상적인 자동화가 어려워진다. 사용자가 이미 허용한 반복 업무와 새로 발생한 고위험 행동을 구분해야 한다. 예를 들어 읽기 전용 자료 조사에는 정해진 범위를 적용하고 외부 게시나 민감한 전송은 별도 기준을 적용할 수 있다.

 

외부 문서가 ‘이미 승인됐다’고 적는 것은 승인 증거가 아니다. 승인 상태는 문서 본문이나 모델의 설명이 아니라 신뢰할 수 있는 애플리케이션 상태에서 읽어야 한다. 사용자가 승인한 작업을 불필요하게 다시 묻는 문제와 승인하지 않은 행동을 실행하는 문제를 함께 줄이는 설계가 필요하다.

 

11. MCP와 멀티 에이전트에서는 경계가 한 번 더 필요하다

 

MCP를 통해 데이터와 도구에 접근할 수 있어도 반환된 내용이 모두 권한 있는 지시는 아니다. 도구가 성공 상태로 응답했다는 사실은 호출이 처리됐다는 뜻이지, 본문에 포함된 모든 행동 요구가 사용자의 승인을 받았다는 뜻이 아니다.

 

도구 설명과 연결 설정 자체를 관리하는 경로도 중요하다. 어떤 서버와 기능을 연결할지, 업데이트를 누가 검토할지, 어느 계정 권한으로 실행할지 정해야 한다. 연결 표준의 존재가 개별 서버의 신뢰성이나 데이터의 안전성을 자동으로 보증하지는 않는다.

 

 

여러 에이전트가 협업하면 한 작업자가 읽은 내용이 요약을 거쳐 다른 작업자에게 전달된다. 이때 외부 문장의 출처와 신뢰 수준이 사라지면 단순한 참고 자료가 내부의 확정 지시처럼 보일 수 있다. 결과에는 확인된 사실, 원문이 주장한 내용, 수행이 필요한 제안을 구분해 담는 편이 좋다.

 

실행 권한을 가진 에이전트는 다른 에이전트의 요청도 최종 사용자 목표와 정책에 대조해야 한다. 동료 에이전트가 말했다는 이유만으로 권한을 확대하지 않는다. 분업은 정보 처리를 나누는 방법이며 책임과 권한 검증을 없애는 방법은 아니다.

 

12. 장기 메모리는 외부 지시를 오래 보관할 수 있다

 

문서에서 읽은 행동 요구가 사용자 선호나 운영 규칙으로 메모리에 저장되면 현재 작업이 끝난 뒤에도 영향을 줄 수 있다. 단순한 검색 결과의 문제가 다음 요청으로 이어지는 셈이다. 메모리에 무엇을 넣을지 정하는 기준은 응답 생성 기준과 별도로 필요하다.

 

외부 문서의 주장을 사용자 본인의 선호와 구분해야 한다. 사용자가 직접 설정한 기본 언어와 자료에 적힌 ‘다음부터 특정 수신자에게 전송하라’는 문장은 성격이 다르다. 후자를 장기 정책으로 저장하려면 별도의 정당한 근거가 있어야 한다.

 

저장 항목에는 출처와 작성 시점, 적용 범위, 만료 기준을 연결할 수 있다. 중요한 설정은 사용자가 확인하고 수정할 수 있게 한다. 저장된 정보가 다시 검색됐을 때도 사실·선호·명령을 구분하고, 오래됐거나 상충하는 항목을 처리하는 규칙이 필요하다.

 

인젝션이 의심되면 현재 대화만 초기화해서 끝내면 부족할 수 있다. 영향을 받은 메모리와 요약, 검색 색인, 생성 문서에 같은 내용이 남았는지 확인해야 한다. 복구는 실행 상태와 저장 상태를 함께 살펴보는 작업이다.

 

13. 멀티모달 AI와 피지컬 AI로 이어지는 설계 질문

 

 

이미지와 음성을 처리하는 모델은 사람이 보는 화면이나 듣는 말에서 정보를 얻는다. NVIDIA 사례가 보여주는 문제의식은 텍스트 키워드 검사만으로 모든 입력 의미를 판단하기 어렵다는 것이다. 이미지에서 추론한 행동도 사용자가 허용한 작업인지 확인해야 한다.[4]

 

다만 문서의 실증 사례를 곧바로 실제 로봇 전체의 취약성으로 일반화해서는 안 된다. 특정 연구 환경에서 관찰된 모델 행동과 실제 로봇의 제어 구조, 안전 장치, 운영 조건은 다르다. 시각적 인젝션 연구가 모든 물리 시스템에서 같은 결과를 낸다고 말할 근거는 없다.

 

피지컬 AI를 설계한다면 고수준 언어 판단과 실제 동작의 안전 조건을 분리하는 질문이 필요하다. 현장 표지나 사람의 발화가 어떤 권한을 갖는지, 허용된 작업 구역과 동작 범위를 어디에서 검증하는지, 센서와 제어기의 별도 안전 체계가 무엇인지 살펴봐야 한다.

 

이 부분은 공개 자료에서 확장한 설계상의 시사점이다. 특정 로봇 제품의 사고를 주장하는 내용이 아니다. 언어 모델이 상황을 해석하는 기능과 실제로 움직이거나 설비를 변경할 수 있는 권한 사이에 확인 가능한 경계를 둬야 한다는 원칙이다.

 

14. 사내 문서 요약 서비스를 설계한다면

 

다음은 실제 사고가 아닌 가상 설계 예시다. 직원이 사내 문서를 검색해 요약하고 담당자에게 보낼 초안을 만드는 서비스를 가정하자. 먼저 사용자가 접근 가능한 문서만 검색하고, 요약 작업에는 읽기 기능만 제공한다. 초안 생성과 실제 발송은 서로 다른 단계로 둔다.

 

검색된 자료는 원문 출처와 문서 버전을 유지한다. 모델에는 자료의 내용을 정리하되 문서 안의 행동 요구가 자동으로 권한을 바꾸지 않는다고 설명한다. 문서가 외부 절차를 요구하면 이를 사실처럼 실행하지 않고 필요에 따라 해당 문서의 주장으로 요약한다.

 

 

발송 단계에서는 수신자와 문서의 공유 가능 범위를 확인한다. 사용자가 검토한 초안과 실제 전송본이 일치하는지도 검사한다. 만약 외부 전송이 허용되지 않은 자료라면 표현을 조금 바꾸거나 다른 도구를 찾는 대신 정책에 따라 중단하거나 승인된 내부 경로를 사용한다.

 

이 구조의 장점은 어느 한 방어가 실패해도 다음 단계에서 영향을 제한할 여지가 있다는 점이다. 모델이 잘못된 행동을 제안했더라도 읽기 전용 단계에서는 실행할 수 없고, 발송 계층에서도 수신자와 권한을 확인한다. 각각의 계층을 독립적으로 테스트할 수 있어야 한다.

 

15. 공격 차단률만 보면 좋은 방어를 고르기 어렵다

 

보안 필터가 모든 요청을 거절하면 공격 성공은 줄어들겠지만 서비스도 사용할 수 없다. 따라서 공격 성공률과 정상 업무 완료율을 함께 측정해야 한다. 보안 교육 자료를 요약하는 정상 요청을 악성으로 오인하는지 같은 잘못된 차단도 평가 대상이다.

 

테스트는 실제 업무와 비슷한 조건에서 수행한다. 웹 문서, 이메일, 도구 응답, 이미지, 장기 메모리처럼 서비스가 사용하는 입력 경로를 포함한다. 단일 문장만 넣는 검사 외에 여러 단계의 조사와 요약을 거친 뒤 어떤 행동이 제안되는지도 확인할 필요가 있다.

 

모델이 위험한 문장을 생성했는지와 실제로 민감한 행동이 실행됐는지는 별도로 기록한다. 실행 계층이 차단했다면 그 사실을 확인하고, 외부 상태가 바뀌지 않았는지 검증한다. 최종 답변이 ‘차단했다’고 말하는 것만으로 테스트를 통과시키면 안 된다.

 

 

평가에는 모의 데이터와 통제된 실행 환경을 사용한다. 실제 고객 정보나 실제 외부 발송을 공격 실험에 사용할 이유는 없다. 모델·프롬프트·도구·정책 버전을 기록하고 변경 후 같은 사례를 다시 확인한다. 새로운 실패는 회귀 평가에 추가하되 정상 업무가 과도하게 막히지 않는지도 함께 본다.

 

16. 로그와 사고 대응에서 확인할 것

 

문제가 생겼을 때 최종 답변만 보면 원인을 놓치기 쉽다. 어떤 출처가 들어왔고, 어떤 행동이 제안됐으며, 어떤 정책이 허용하거나 거부했는지 연결할 수 있어야 한다. 동시에 로그에 불필요한 비밀 정보나 개인정보를 복제하지 않도록 수집 범위와 접근 권한을 정한다.

 

사고 대응의 첫 단계는 영향 경로를 제한하는 것이다. 의심스러운 연결이나 도구를 중지하고 관련 실행을 보류할 수 있어야 한다. 이후 실제로 외부에 전송된 정보가 있는지, 어떤 문서와 상태가 변경됐는지, 저장된 메모리와 후속 결과에 영향이 남았는지 확인한다.

 

복구 가능성도 행동마다 다르다. 초안 수정은 되돌릴 수 있지만 이미 발송된 이메일이나 공개된 정보는 단순한 상태 복원만으로 회수되지 않을 수 있다. 따라서 모든 행동에 일괄적으로 ‘롤백 가능’이라고 표시하기보다 실제로 되돌릴 수 있는 범위를 구분해야 한다.

 

원인을 확인한 뒤에는 입력 탐지 규칙만 추가하지 말고 권한과 실행 경계가 왜 통과됐는지 살펴본다. 과도한 도구 권한, 승인 재사용, 출처 누락, 전송 검사 부재 중 무엇이 영향을 키웠는지 확인해야 비슷한 형태의 다른 공격에도 대응할 수 있다.

 

17. 도입 전에 확인할 실무 체크리스트

 

 

• 사용자 요청과 외부 자료의 역할이 구분돼 있는가?

• 검색 권한과 실제 실행 권한을 각각 검사하는가?

• 모델이 접근하는 도구와 계정에 필요한 최소 권한만 있는가?

• 전송 직전에 목적지와 전송 내용을 확인할 수 있는가?

• 승인이 구체적인 행동과 버전에 연결되는가?

• 다른 에이전트의 결과와 메모리에도 출처가 남는가?

• 정상 업무와 공격 시도를 함께 평가하는가?

• 최종 답변 외에 실제 외부 상태를 확인하는가?

• 사고 시 연결 중지, 영향 조사, 복구 경로가 마련돼 있는가?

 

처음부터 모든 기능을 열기보다 읽기 전용의 좁은 업무에서 시작하면 입력과 행동의 흐름을 관찰하기 쉽다. 이후 필요한 쓰기와 전송 기능을 하나씩 추가하면서 권한 검증과 평가를 함께 확장한다. 이런 순서는 실험 속도를 떨어뜨리기 위한 절차가 아니라 실패 원인을 구체적으로 확인하기 위한 방법이다.

 

AI 에이전트 보안의 목표는 낯선 문장을 모두 금지하는 데 있지 않다. 필요한 자료를 충분히 읽으면서도 그 자료가 사용자의 권한을 대신하지 못하게 만드는 것이다. 좋은 프롬프트, 명확한 출처, 좁은 권한, 실행 전 검사, 실제 결과 검증이 함께 있어야 자동화를 신뢰할 근거가 생긴다.

 

자주 묻는 질문

 

Q1. 프롬프트 인젝션과 탈옥은 같은 말인가요?

 

자료마다 용어 범위가 조금 다르다. OWASP는 탈옥을 안전 규칙을 무시하게 만드는 프롬프트 인젝션의 한 형태로 설명한다. 실무에서는 이름보다 입력 경로, 바뀐 행동, 위반된 권한을 구체적으로 기록하는 편이 원인 분석에 유용하다.

 

Q2. 시스템 프롬프트를 길게 쓰면 막을 수 있나요?

 

 

외부 자료의 역할과 금지 행동을 명확히 설명하는 것은 도움이 될 수 있다. 하지만 길이 자체가 방어 성능을 보장하지 않는다. 실행 권한, 전송 통제, 평가를 함께 설계하고 실제 업무에서 확인해야 한다.

 

Q3. RAG 자료가 모두 사내 문서라면 안전한가요?

 

저장 위치만으로 판단하기 어렵다. 외부 자료를 옮긴 문서나 여러 작성자의 내용이 섞일 수 있고 권한도 서로 다르다. 출처와 접근 권한을 유지하고 문서 내용이 실행 권한을 바꾸지 못하게 해야 한다.

 

Q4. 별도 검토 모델을 붙이면 충분한가요?

 

검토 모델은 추가 방어 계층이 될 수 있지만 오류와 우회 가능성이 있다. 검토 결과와 별개로 실제 도구 호출의 권한과 인자를 코드에서 검사하는 통제가 필요하다. 정상 요청을 잘못 차단하는지도 측정해야 한다.

 

Q5. 문서에 있는 링크를 여는 것도 전송인가요?

 

링크를 열면 대상 서버로 요청이 전달된다. 주소나 매개변수에 정보가 담기면 그 정보도 전달될 수 있다. 공개 자료를 여는 정상 행동과 민감한 정보를 포함한 요청을 구분해 목적지와 내용을 확인해야 한다.

 

Q6. 작은 팀은 어디부터 시작하면 되나요?

 

사용하는 외부 입력과 실행 도구를 목록으로 만들고 읽기·쓰기·전송 권한을 구분하는 일부터 시작할 수 있다. 그다음 중요한 업무 몇 개에 정상 사례와 공격 사례를 마련해 실제 결과를 확인한다. 측정한 실패 경로부터 개선하면 된다.

 

참고 자료와 확인 범위

 

 

[1] OWASP Gen AI Security Project, LLM01:2025 Prompt Injection.

https://genai.owasp.org/llmrisk/llm01-prompt-injection/

직접·간접 인젝션의 구분, RAG의 한계, 최소 권한과 외부 내용 구분, 적대적 테스트에 관한 지침을 확인했다. 보안 목록의 식별 번호가 특정 서비스의 실제 사고 빈도 순위를 뜻하는 것은 아니다.

 

[2] OpenAI, 프롬프트 인젝션을 거부하는 AI 에이전트 설계하기, 2026.03.11.

https://openai.com/ko-KR/index/designing-agents-to-resist-prompt-injection/

프롬프트 인젝션을 거부하는 AI 에이전트 설계하기

사회공학적 공격 관점과 소스·싱크 분석, 정보 전송을 제한하는 공개 방어 설명을 참고했다. 해당 제품의 설명을 모든 에이전트에 적용되는 보증으로 해석하지 않았다.

 

[3] 인포그랩 기술 블로그, 프롬프트 인젝션이 노리는 당신의 AI, 2025.08.06.

https://insight.infograb.net/blog/2025/08/06/prompt-injection/

프롬프트 인젝션이 노리는 당신의 AI

국내 기술 블로그에서 다루는 공격 표면과 다층 방어의 구성 관점을 참고했다. 원문의 공격 예문을 재현하거나 실제 사고가 아닌 개념 증명을 사고 통계로 사용하지 않았다.

 

 

[4] NVIDIA Technical Blog, 에이전틱 AI 보안: 시맨틱 프롬프트 인젝션이 AI 안전장치를 우회하는 방법, 2025.08.01.

https://developer.nvidia.com/ko-kr/blog/securing-agentic-ai-how-semantic-prompt-injections-bypass-ai-guardrails/

에이전틱 AI 보안: 시맨틱 프롬프트 인젝션이 AI 안전장치를 우회하는 방법

멀티모달 입력의 공격 표면과 실행 전 출력·영향 점검이라는 연구 시사점을 참고했다. 특정 실험을 모든 이미지 모델과 로봇의 동작으로 일반화하지 않았다.

 

자료 확인일: 2026년 10월 16일. 본문의 업무 흐름과 체크리스트는 공개 자료를 바탕으로 구성한 설계 예시다. 특정 기업의 실제 사고를 재현하거나 자체 공격 성공률을 측정한 결과가 아니다.

 

 

함께 읽기: AI 에이전트는 많을수록 좋을까? 멀티 에이전트의 비용과 실패를 가르는 설계 기준