AI 에이전트는 읽기만 해도 속을 수 있다: 프롬프트 인젝션과 MCP 보안의 맹점

 

AI 에이전트에게 문서를 읽고 요약해 달라고 요청했을 뿐인데, 문서 안의 문장이 에이전트의 새로운 명령처럼 취급된다면 어떻게 될까요? 프롬프트 인젝션(Prompt Injection)은 이 경계를 공격합니다. 웹페이지, 이메일, 검색 결과, 도구 설명에 섞인 내용이 사용자의 원래 목적을 밀어내고 답변이나 도구 호출을 바꾸도록 유도하는 문제입니다. 읽기 기능을 연결하는 순간부터 살펴봐야 할 AI 보안 이슈인 이유입니다.

 

문제가 항상 데이터 삭제나 외부 발송처럼 눈에 띄는 사고로 나타나는 것은 아닙니다. 보고서에서 특정 업체를 근거 없이 추천하거나, 고객 문의의 사실관계를 바꾸거나, 승인 요청의 설명을 왜곡하는 형태로도 나타날 수 있습니다. 더 강한 모델과 더 긴 시스템 프롬프트가 도움을 줄 수는 있지만, 잘못된 판단이 곧바로 실제 권한으로 이어지는 구조까지 해결해 주지는 않습니다.

 

2026년 11월 5일 기준으로 OWASP의 LLM01:2025 문서, OpenAI의 에이전트 안전 설계 문서, MCP 공식 보안 문서를 확인하고 인포그랩과 다글로의 한국어 블로그를 함께 비교했습니다. 이 글은 사내 문서 검색과 고객 지원 자동화를 만드는 개발자를 위해 입력의 신뢰도, 실행 권한, 승인과 평가를 연결해 설명합니다. 아래 고객 지원 사례와 설계 예시는 이해를 돕기 위해 구성한 가상 시나리오이며 특정 기업에서 확인된 사고나 성능 측정 결과가 아닙니다.

 

먼저 기억할 핵심

- 외부 문서의 내용은 판단에 쓰는 자료이며 권한을 부여하는 주체가 아닙니다.

- MCP는 연결 방식의 표준이고, 연결된 도구의 권한과 실행 결과는 별도로 검증해야 합니다.

- 프롬프트, 구조화 출력, 서버의 접근 제어, 구체적인 승인, 공격 평가가 서로 보완해야 합니다.

 

이 글에서 다룰 내용

프롬프트 인젝션의 원리부터 고객 지원 사례를 따라 신뢰 경계를 살펴봅니다. 이어서 RAG와 MCP의 차이, 최소 권한 도구 설계, 구조화 출력의 한계, 승인과 외부 통신, 메모리 오염, 배포 전 평가 순서로 정리합니다.

 

문서의 내용이 실행 명령으로 승격되는 순간

 

프롬프트 인젝션은 모델이 처리하는 입력을 이용해 원래 의도와 다른 동작을 유도하는 문제입니다. 사용자의 입력에서 직접 시작되기도 하고, 에이전트가 읽은 외부 자료를 통해 간접적으로 들어오기도 합니다. OWASP는 사람이 알아보기 어려운 표현도 모델이 해석하면 영향을 줄 수 있다고 설명합니다. 따라서 화면에 수상한 문장이 없다는 사실만으로 입력이 안전하다고 판단할 수 없습니다.[1]

 

간접 프롬프트 인젝션에서 중요한 것은 문장의 위치보다 권한의 출처입니다. 고객 이메일에는 고객의 요청이 담길 수 있지만, 그것만으로 회사의 환불 정책이나 접근 제어가 바뀌지는 않습니다. 검색 결과는 제품의 특징을 설명할 수 있지만, 사용자가 맡기지 않은 작업을 새로 승인할 수는 없습니다. 문서가 스스로 관리자 지침이라고 주장하더라도 실제 관리자가 정한 정책과 같은 지위를 갖는 것은 아닙니다.

 

언어 모델은 자연어를 읽고 의미를 연결하므로, 명령처럼 보이는 내용과 분석 대상의 내용을 혼동할 가능성을 시스템 차원에서 다뤄야 합니다. 그렇다고 문서에 포함된 모든 요청을 무시하라는 뜻은 아닙니다. 문의 내용에서 요구 사항을 추출하는 일과 그 요구를 실제로 이행할 권한이 있는지 판단하는 일은 분리해야 합니다. 이 구분이 없으면 친절하게 업무를 끝내려는 동작이 공격 경로가 될 수 있습니다.

프롬프트 엔지니어링은 역할과 금지 사항, 처리 예시를 명확히 만드는 데 필요합니다. 다만 그 문장은 모델의 행동을 유도하는 장치입니다. 서버가 인증된 사용자에게 허용한 데이터만 반환하는 접근 제어와는 성격이 다릅니다. 모델이 지침을 잘 지킨다는 기대와, 지침을 어겨도 실행되지 않는 통제를 함께 갖추는 것이 AI 에이전트 보안의 출발점입니다.

 

고객 지원 에이전트로 따라가는 공격 경로

 

가상의 고객 지원 에이전트를 생각해 보겠습니다. 사용자는 최근 문의를 요약하고 환불 검토가 필요한 건을 분류해 달라고 요청했습니다. 에이전트에는 문의 조회, 주문 확인, 환불 초안 생성, 실제 환불 실행 도구가 연결되어 있습니다. 여기서 작업의 목적은 분류와 검토 준비입니다. 실제 환불을 실행할 수 있다는 사실이 곧 모든 환불 실행을 승인받았다는 뜻은 아닙니다.

 

외부 문의에 업무 규칙을 바꾸라는 내용이 섞여 있으면 첫 번째 경계가 시험됩니다. 에이전트가 이를 고객이 한 주장으로 기록하는 대신 내부 정책으로 받아들이면 판단이 오염됩니다. 이후 요약 결과만 보는 다른 단계는 잘못된 정책을 정상적인 입력처럼 받을 수 있습니다. 마지막 실행 단계에서 주문과 사용자 권한을 다시 확인하지 않으면 언어적 혼동이 실제 처리로 이어집니다.

 

이 경로를 막기 위해 읽기 단계는 고객의 주장, 주문 식별자, 확인이 필요한 항목을 구분해 반환하도록 설계할 수 있습니다. 정책은 별도의 관리 경로에서 제공하고, 고객의 문장이 정책을 덮어쓰지 못하게 합니다. 실제 환불 여부는 주문 상태와 금액, 담당자의 권한, 현재의 업무 규칙을 서버에서 확인합니다. 정보 추출과 업무 결정을 분리하면 어느 단계에서 오류가 생겼는지도 찾기 쉬워집니다.

 

또한 거부와 업무 중단을 같은 것으로 취급할 필요는 없습니다. 외부 자료가 실행을 유도하더라도 문의 요약과 검토 대상 분류는 계속 수행할 수 있습니다. 필요한 것은 수상한 내용을 발견할 때마다 모든 일을 포기하는 동작이 아니라, 허용된 작업을 유지하면서 권한을 넘어서는 전이를 차단하는 구조입니다. 이때 결과에는 확인된 사실과 고객의 주장, 아직 판단하지 못한 부분이 구분되어야 합니다.

 

RAG가 사실성을 높여도 프롬프트 인젝션은 남는다

 

RAG는 검색한 자료를 모델의 답변에 활용하는 방식입니다. 최신 문서와 사내 지식을 참고하게 해 근거가 있는 답변을 만드는 데 도움을 줍니다. 그러나 검색 결과가 관련성이 높다는 사실과 그 안의 지시를 따라도 된다는 판단은 별개입니다. OWASP도 RAG와 파인튜닝이 프롬프트 인젝션 취약점을 완전히 해소하지는 못한다고 설명합니다.[1]

 

사내 문서라는 위치만으로 모든 내용을 같은 수준으로 신뢰해서도 안 됩니다. 고객이 작성한 티켓, 외부 협력사가 올린 첨부파일, 여러 사람이 편집하는 위키는 작성 권한과 검토 절차가 다릅니다. 공식 업무 정책 문서와 참고 메모가 같은 검색 결과에 나타나면, 모델이 어느 문서를 정책 근거로 사용해야 하는지 분명히 해야 합니다. 출처의 조직 이름보다 실제 관리와 변경 경로가 중요합니다.

 

검색 단계에서 사용자에게 허용된 문서만 반환하는 것도 기본입니다. 모델에게 민감한 문서를 먼저 보여 준 뒤 답변에서 알아서 가리도록 맡기면, 이미 과도한 정보가 컨텍스트에 들어간 상태가 됩니다. 검색 권한과 문서의 신뢰도는 서로 다른 축이므로 함께 관리해야 합니다. 볼 수 있는 문서라고 해서 정책을 변경할 수 있는 문서는 아니고, 신뢰할 수 있는 정책이라도 모든 사용자가 열람할 수 있는 것은 아닙니다.

검색 결과를 요약할 때는 문서 식별자, 작성 또는 수정 시점, 근거 위치와 같은 출처 정보를 보존하는 편이 좋습니다. 다글로의 2026년 10월 23일 글도 원문과 결과를 대조하는 습관을 설명합니다.[5] 다만 출처가 있다는 사실 자체가 내용의 무해함을 보장하지는 않습니다. 추적 가능한 출처는 판단을 검토할 수 있게 만드는 근거이며, 최종 실행 권한을 대신하지 않습니다.

 

MCP 보안에서는 연결 표준과 권한 검증을 구분한다

 

MCP(Model Context Protocol)는 AI 애플리케이션이 도구와 데이터에 연결되는 공통 인터페이스를 제공합니다. 도구를 발견하고 호출하는 방식이 표준화되면 통합이 쉬워집니다. 그러나 표준에 맞는 메시지를 주고받는다는 사실만으로 서버의 코드, 도구 설명, 반환 데이터와 인증 구성이 모두 안전해지는 것은 아닙니다. 통신 규약과 업무의 권한 정책을 같은 것으로 취급하면 중요한 공백이 생깁니다.

 

인포그랩의 2025년 10월 29일 기술 블로그는 프롬프트 인젝션뿐 아니라 도구 메타데이터를 악용하는 툴 포이즈닝, 자격증명 노출, 공급망 변조와 권한 남용을 구분합니다.[4] 이 구분은 문제를 진단하는 데 유용합니다. 도구 설명이 모델의 선택을 흔드는 문제와 서버 코드가 변조된 문제, 과도한 토큰 권한 문제는 나타나는 증상이 비슷해도 대응 지점이 다르기 때문입니다.

 

MCP 공식 보안 문서는 인증 흐름의 경계도 별도로 다룹니다. 예를 들어 MCP 서버용으로 발급되었는지 검증하지 않은 토큰을 받아 하위 API로 그대로 넘기는 토큰 패스스루를 금지된 패턴으로 설명합니다. 사용자가 한 서비스에 동의한 사실을 다른 클라이언트의 동의로 오해하는 대리인 혼동 문제도 다룹니다.[3] 이러한 문제는 모델에게 조심하라고 지시하는 것만으로 해결되지 않습니다.

 

따라서 MCP를 도입할 때는 서버 운영자와 배포 경로, 연결 대상, 토큰의 사용 대상과 범위, 도구별 서버 검증을 확인해야 합니다. 도구 설명이 바뀌면 모델의 선택도 달라질 수 있으므로 설명과 스키마의 변경 이력을 관리하는 것도 도움이 됩니다. 특정 전송 방식이나 제품을 사용한다는 이유만으로 보안 상태를 단정하지 않고, 실제 구현과 배포 조건에서 어떤 통제가 적용되는지 확인해야 합니다.

 

최소 권한은 도구 이름보다 실행 범위에서 결정된다

 

도구 이름에 조회나 요약이라는 단어가 들어 있어도 실제 동작은 다를 수 있습니다. 조회 과정에서 외부 서비스로 전체 문서를 전송할 수 있고, 하나의 범용 실행 도구가 다양한 변경 작업을 처리할 수도 있습니다. 최소 권한을 적용하려면 도구가 어떤 데이터를 읽고 어느 시스템에 무엇을 보낼 수 있는지를 기준으로 나눠야 합니다. 모델에게 보이는 이름만으로 판단해서는 안 됩니다.

 

가상의 환불 업무라면 주문 조회, 환불 가능 여부 계산, 초안 작성, 실제 실행을 구분할 수 있습니다. 조회 도구는 필요한 필드만 반환하고, 계산 도구는 정해진 업무 규칙에 따라 판단 근거를 돌려줍니다. 실행 도구는 대상 주문과 허용 금액, 요청자의 권한을 서버에서 검증합니다. 모델이 주문 식별자나 금액을 제시하더라도 그것은 검증할 입력이지 이미 허가된 명령이 아닙니다.

 

데이터 접근 범위도 작업에 맞게 제한해야 합니다. 한 고객의 문의를 처리하는데 전체 고객 목록이 컨텍스트에 필요하지는 않습니다. 인증된 사용자와 조직의 범위를 서버에서 결정하고, 모델이 전달한 조직 이름만으로 접근 대상을 정하지 않는 설계가 중요합니다. 사용자가 볼 수 없는 기록은 검색 단계에서 제외하고, 도구 호출마다 해당 자원에 대한 권한을 다시 확인해야 합니다.

인포그랩은 서버와 클라이언트에 필요한 최소 권한을 주고 시크릿을 중앙에서 관리하는 접근을 설명합니다.[4] 여기서 최소 권한은 설치할 때 한 번 설정하는 체크 항목으로 끝나지 않습니다. 새 도구가 추가되거나 기존 도구가 새로운 필드를 반환할 때도 범위가 달라집니다. 기능 변경과 함께 접근 범위, 외부 전송, 로그 노출을 다시 검토하는 운영 절차가 필요합니다.

 

JSON으로 바꾸면 안전하다는 오해

 

OpenAI의 에이전트 안전 설계 문서는 단계 사이에 고정된 스키마, 열거형과 구조화 출력을 사용해 자유로운 텍스트가 흘러가는 경로를 줄이라고 설명합니다.[2] 외부 문서에서 필요한 사실만 추출해 다음 단계로 넘기면 문서 전체가 실행 판단에 영향을 미치는 범위를 줄일 수 있습니다. 고객 문의를 분류할 때도 임의의 행동 지시 대신 문의 유형과 주문 식별자 같은 필드를 전달할 수 있습니다.

 

하지만 JSON이라는 형식은 권한을 증명하지 않습니다. 허용된 필드에 잘못된 주문 식별자가 들어갈 수 있고, 설명 필드에는 여전히 자유로운 문장이 들어갈 수 있습니다. 스키마를 통과한 주소라도 업무상 허용되지 않은 수신자일 수 있습니다. 문법 검증과 필드의 업무상 타당성, 해당 사용자가 그 값을 사용할 수 있는지는 각각 다른 검증입니다.

 

실무에서는 허용되는 필드와 값의 범위를 좁히고, 식별자는 서버에서 실제 자원과 대조하는 방식이 유용합니다. 금액과 상태 전이는 업무 규칙으로 확인하고, 외부 전송 대상은 승인된 범위와 비교합니다. 설명 문자열은 사람이 읽는 참고 정보로 남기되, 그 문자열에 새로운 권한을 부여하는 문장이 있다는 이유로 실행 정책을 바꾸지 않게 해야 합니다.

 

구조화 출력은 공격 표면을 줄이는 설계 도구로 이해하는 편이 정확합니다. 파서가 통과시킨 값을 그대로 운영 시스템에 반영하는 것은 다른 문제입니다. 스키마 오류를 복구하는 단계에서도 외부 입력이 새로운 관리자 지침으로 바뀌지 않아야 합니다. 정상 형식의 잘못된 요청을 서버가 차단할 수 있어야 모델의 형식 준수와 실제 업무 안전성이 연결됩니다.

 

승인 버튼에는 구체적인 실행 내용을 묶어야 한다

 

승인 절차는 모델의 판단과 실제 변경 사이에 검토 지점을 만듭니다. OWASP는 고위험 작업에 사람의 승인을 두는 방식을 권고하고, OpenAI 문서도 MCP 도구 승인과 여러 통제의 결합을 강조합니다.[1][2] 그러나 승인 창에 작업을 진행하겠다는 문장만 보인다면 검토자는 무엇을 허용하는지 알기 어렵습니다. 승인 여부보다 승인 대상의 구체성이 먼저입니다.

 

가상의 환불 요청이라면 대상 주문, 환불 금액, 처리 이유, 적용 정책과 실제 영향이 함께 보여야 합니다. 메일 발송이라면 수신자와 첨부파일, 본문에 포함되는 정보가 확인 대상입니다. 요약 화면의 설명만 믿게 하면 그 요약이 오염됐을 때 승인까지 잘못 유도될 수 있습니다. 가능한 한 실행에 쓰는 실제 값과 검증 결과를 검토 화면에 연결해야 합니다.

 

승인 이후 입력이 바뀌는 상황도 고려해야 합니다. 검토한 수신자와 실행 시점의 수신자가 다르거나, 승인받은 금액과 실제 금액이 달라지면 같은 승인을 재사용해서는 안 됩니다. 승인 대상을 실행 파라미터와 연결하고 변경 시 다시 확인하는 방식은 이 글에서 제안하는 설계 예시입니다. 구체적인 구현은 시스템의 트랜잭션 구조와 기존 업무 절차에 맞춰 정해야 합니다.

모든 사소한 조회에 반복적으로 확인을 요구하면 피로 때문에 중요한 승인도 형식적으로 처리될 수 있습니다. 제품과 조직의 정책에 따라 필요한 승인을 유지하면서, 권한과 영향이 달라지는 지점을 명확히 나누는 것이 좋습니다. 이미 허가된 작업 범위 안의 진행과 새로운 외부 발송 또는 변경 권한을 얻는 상황을 구분하면 사용자도 무엇을 판단해야 하는지 이해하기 쉬워집니다.

 

읽기 전용 도구도 데이터 반출 경로가 될 수 있다

 

읽기 전용은 일반적으로 원본 데이터를 변경하지 않는다는 뜻입니다. 그러나 데이터를 읽어 어디로 보내는지는 별도의 문제입니다. 외부 도구의 호출 인자에 내부 문서가 포함되거나, 생성한 링크를 불러오는 과정에서 정보가 전달될 수 있습니다. OpenAI 문서는 공격이 없더라도 모델이 사용자의 기대보다 많은 정보를 연결된 MCP로 공유하는 위험을 설명합니다.[2]

 

OWASP도 웹페이지 요약 과정에서 생성한 이미지 링크를 통해 대화 정보가 외부로 전달되는 시나리오를 소개합니다.[1] 여기서 관심을 가져야 할 것은 공격 문구의 정확한 형태가 아니라 출력이 다시 실행과 통신으로 이어지는 구조입니다. 생성된 마크다운이나 링크를 화면에 표시할 때 외부 자원을 자동으로 불러오는지, 서버가 어떤 주소에 접근하는지 살펴봐야 합니다.

 

서버의 외부 통신 정책은 문장 필터와 함께 다룰 수 있습니다. 허용된 서비스와 전송 목적을 정하고, 민감한 데이터는 필요한 필드만 전달하도록 줄입니다. 주소 검증도 처음 주소만 확인하고 끝낼 일이 아닙니다. MCP 공식 문서는 서버 측 요청 위조와 관련해 리다이렉트 대상과 네트워크 경계를 고려하는 방식을 설명합니다.[3] 세부 설정은 서버가 배포된 네트워크 환경에 맞춰 결정해야 합니다.

 

관측용 로그 역시 데이터 복사본입니다. 모든 프롬프트와 도구 응답을 무조건 평문 저장하면 장애 분석이 쉬워지는 대신 민감한 정보가 넓게 남을 수 있습니다. 사건을 재현할 식별자와 필요한 필드를 정하고, 접근 권한과 보존 기간, 비식별화 기준을 함께 두는 편이 좋습니다. 추적 가능성을 높이는 일과 비밀정보를 더 많이 복제하는 일을 같은 목표로 취급해서는 안 됩니다.

 

요약과 메모리를 거쳐도 외부 자료의 신뢰도는 바뀌지 않는다

 

여러 단계의 에이전트가 협업하면 외부 문서는 요약문으로 바뀌고, 요약문은 다음 작업의 메모리로 저장될 수 있습니다. 이 과정에서 원래 고객의 주장이었던 내용이 확인된 업무 규칙처럼 기록되면 이후 판단도 흔들립니다. 한 단계가 문장을 자연스럽게 정리했다는 사실은 그 내용의 권위가 높아졌다는 증거가 아닙니다. 신뢰도는 문체가 아니라 출처와 검증 경로에서 나와야 합니다.

 

따라서 요약에는 사실, 주장, 제안과 검증 결과를 구분해 담는 방식이 도움이 됩니다. 출처 식별자와 근거 위치를 남기고, 외부 자료에서 나온 요청을 내부 운영 정책과 섞지 않습니다. 장기 메모리에 저장하는 정보도 같은 기준을 적용해야 합니다. 특히 업무 규칙을 바꾸는 내용은 일반 대화 요약과 다른 관리 경로를 거치도록 설계할 수 있습니다.

 

예를 들어 고객이 특정 처리를 원한다고 썼다면 메모리에는 고객의 요청으로 남겨야 합니다. 그 처리 방식이 앞으로 모든 주문에 적용되는 정책이라고 일반화해서는 안 됩니다. 이후 담당자가 정책을 공식 변경했다면 변경 주체와 적용 범위, 시점을 별도로 기록합니다. 이렇게 해야 다음 에이전트가 오래된 요청을 최신 지침으로 잘못 사용하는 문제를 줄일 수 있습니다.

다른 모델에게 검토를 한 번 더 맡기는 것만으로 이 문제가 사라지지도 않습니다. 검토 모델도 같은 오염된 요약을 입력으로 받으면 비슷한 판단을 할 수 있습니다. 검토 단계에는 원문 근거와 실제 정책, 실행 대상의 상태를 확인할 수 있는 정보가 필요합니다. 모델 수를 늘리는 선택보다 어떤 근거를 어느 권한으로 확인하게 할지 먼저 설계해야 합니다.

 

공격을 얼마나 막았는지와 업무를 얼마나 끝냈는지 함께 측정한다

 

프롬프트 인젝션 방어를 평가할 때 몇 개의 공격 문장을 막았다는 결과만으로 배포를 결정하기 어렵습니다. 같은 공격 의도가 이메일 본문, 첨부파일, 도구 응답, 이미지에서 다른 형태로 나타날 수 있습니다. 또한 공격을 잘 차단하더라도 정상 고객 문의까지 대부분 거부한다면 업무 도구로서의 성능이 떨어집니다. 보안과 유용성을 같은 시험 체계 안에서 확인해야 합니다.

 

이 글에서 제안하는 평가 묶음은 정상 업무 사례, 명백한 권한 변경 유도, 정상 자료 안에 섞인 간접 지시, 여러 단계를 거치는 입력, 허용 범위 밖의 자원 접근으로 구성할 수 있습니다. 각 사례에는 사용자의 실제 요청과 허용된 동작, 차단해야 할 결과를 명시합니다. 운영 고객의 원본 데이터 대신 합성 데이터와 시험용 계정을 쓰면 실패를 관찰하면서 실제 피해를 만들지 않을 수 있습니다.

 

지표도 단계별로 나눠야 합니다. 공격 의도가 답변을 바꾼 비율, 잘못된 도구 호출을 시도한 비율, 서버 통제를 넘어 실제 실행된 비율은 다릅니다. 실행이 차단됐더라도 모델이 계속 잘못된 호출을 제안한다면 개선할 부분이 남아 있습니다. 반대로 모델이 공격을 알아차리지 못해도 서버의 접근 제어가 차단했다면 어느 방어층이 효과를 냈는지 기록할 수 있습니다.

 

정상 업무 완료율과 오탐, 사용자 개입 횟수, 지연 시간도 함께 측정합니다. 모델, 프롬프트, 검색기, 도구 설명이나 승인 UI를 바꾸면 결과가 달라질 수 있으므로 동일한 평가 묶음을 다시 실행할 근거가 됩니다. OWASP가 권고하는 공격 시험과 OpenAI가 설명하는 실행 기록 평가를 연결하면, 단순한 성공 또는 실패 대신 어느 경계가 유지됐는지를 검토할 수 있습니다.[1][2]

 

작게 배포하고 경계를 넓히는 실무 순서

 

첫 단계에서는 사용자가 맡기는 작업을 한 문장으로 고정합니다. 고객 문의 요약인지, 환불 검토 초안인지, 실제 처리까지 포함하는지 구분합니다. 그다음 작업에 필요한 데이터와 도구를 적고, 어떤 단계에서 외부 입력이 들어오는지 표시합니다. 이 목록은 모델의 능력 소개보다 실제 권한 경계를 정의하는 데 더 직접적으로 도움이 됩니다.

 

다음 단계에서는 좁은 읽기 도구와 검증된 정책 데이터로 시작합니다. 외부 문서에서 추출한 정보는 출처와 함께 구조화해 넘기고, 실제 변경 기능은 시험 환경에 연결합니다. 잘못된 호출이 발생했을 때 어느 단계에서 차단되는지 관찰합니다. 처음부터 모든 도구를 한 번에 연결하면 실패 원인과 효과적인 통제를 분리하기 어렵습니다.

 

이후 제한된 사용자와 작업 범위에서 실행 기능을 열 수 있습니다. 실행 전 서버 검증과 필요한 승인, 변경 후 결과 확인을 붙입니다. 도구가 성공했다고 응답한 사실과 실제 시스템 상태가 일치하는지도 점검해야 합니다. 네트워크 지연으로 결과가 모호한 경우에는 같은 변경을 반복하기 전에 현재 상태를 조회해 중복 처리를 방지하는 흐름을 설계합니다.

운영 중에는 차단 사건뿐 아니라 예상하지 않은 데이터 전송과 과도한 권한 요청도 살펴봅니다. 사고가 의심되면 관련 실행을 멈추고 연결 범위를 줄인 뒤, 영향을 받은 자원과 인증 정보를 확인합니다. 이후 재현 가능한 시험 사례를 추가하고 수정 효과를 검증합니다. 이는 특정 제품의 기본 기능을 가정한 절차가 아니라 조직의 기존 사고 대응 과정에 연결할 수 있는 설계 방향입니다.

 

도입 전 확인할 질문

- 외부 자료와 내부 정책의 출처를 구분할 수 있는가?

- 모델이 잘못된 자원을 지정해도 서버가 사용자 권한을 검증하는가?

- 조회 도구가 어느 외부 서비스로 어떤 정보를 보내는지 아는가?

- 승인 화면에서 실제 대상과 실행 파라미터를 확인할 수 있는가?

- 요약과 메모리를 거쳐도 출처와 검증 상태가 유지되는가?

- 정상 업무 완료율과 공격의 실제 실행 여부를 함께 측정하는가?

 

프롬프트 인젝션과 MCP에 관한 자주 묻는 질문

 

Q. 시스템 프롬프트에 외부 지시를 무시하라고 쓰면 충분한가요?

A. 필요한 방어층이지만 단독 보장으로 볼 수는 없습니다. 역할과 처리 예시를 명확하게 쓰면서 서버의 접근 제어, 입력 검증과 실행 통제를 함께 적용해야 합니다. OWASP와 OpenAI 문서 모두 여러 기법을 결합하고 남는 위험을 평가하는 접근을 설명합니다.

 

Q. 읽기 권한만 주면 프롬프트 인젝션은 무해한가요?

A. 원본을 변경할 위험은 줄어들 수 있지만 답변 왜곡과 정보의 외부 전달은 여전히 살펴봐야 합니다. 어떤 데이터를 읽는지뿐 아니라 모델의 출력과 도구 인자가 어디로 전송되는지를 확인해야 합니다. 읽기 전용이라는 표현만으로 전체 데이터 흐름의 안전성을 결론 내릴 수는 없습니다.

 

Q. 공식 MCP 서버를 사용하면 별도 검토가 필요 없나요?

A. 신뢰할 수 있는 배포 경로를 선택하는 것은 중요하지만, 운영 권한과 데이터 범위까지 대신 정해 주지는 않습니다. 공식 제공 도구라도 현재 작업에 과도한 권한을 줄 수 있습니다. 실제 구성에서 인증, 자원별 권한 검증, 외부 전송과 변경 이력을 확인해야 합니다.

 

Q. 악성 문장을 지우는 필터가 가장 먼저 필요한가요?

A. 필터는 알려진 패턴과 민감한 내용을 탐지하는 데 도움을 줄 수 있습니다. 그러나 정상 요청과 유사한 표현이나 여러 입력을 조합하는 경우까지 한 번에 해결한다고 기대해서는 안 됩니다. 탐지와 함께 실행 범위를 제한하면 필터를 놓친 경우의 영향도 줄일 수 있습니다.

 

Q. 프롬프트 인젝션과 일반적인 모델 오류는 어떻게 구분하나요?

A. 결과가 틀렸다는 사실만으로 공격이라고 단정할 수는 없습니다. 외부 입력이 어떤 경로로 들어왔고 어느 판단이나 호출에 영향을 줬는지 확인해야 합니다. OpenAI 문서가 설명하듯 공격자가 없어도 정보가 과도하게 공유될 수 있으므로, 원인 분석과 별개로 같은 데이터 경계를 점검하는 것이 유용합니다.

 

에이전트의 신뢰성은 더 강한 문장만으로 완성되지 않는다

 

AI 에이전트 보안에서 중요한 질문은 모델이 수상한 문장을 알아볼 수 있는지에서 끝나지 않습니다. 문서를 읽은 뒤 어떤 정보가 다음 단계로 넘어가며, 누가 그 행동을 허가하고, 실행 시스템이 무엇을 검증하는지까지 이어져야 합니다. 이 연결이 명확하면 모델의 판단이 흔들려도 영향 범위를 줄일 수 있습니다.

 

프롬프트 엔지니어링은 작업의 뜻과 경계를 분명히 하고, 구조화 출력은 전달할 정보를 줄이며, 서버의 접근 제어는 실제 권한을 집행합니다. 필요한 승인과 평가, 로그는 그 경계가 유지되는지 확인하게 합니다. 어느 한 층이 다른 모든 층을 대체한다고 가정하지 않는 것이 현실적인 출발점입니다.

새로운 MCP 도구를 연결하기 전에 사용자 요청에서 데이터 조회, 판단, 승인, 실행, 결과 확인까지 한 번의 흐름을 그려 보세요. 외부 자료가 어느 지점에서 권한처럼 취급되는지 찾을 수 있다면, 더 긴 지시문을 작성하는 것보다 먼저 고칠 구조가 보일 수 있습니다. AI 에이전트의 자율성을 넓히는 속도는 그 경계를 검증할 수 있는 속도와 함께 결정해야 합니다.

 

참고 자료와 원문 링크

 

자료 확인일: 2026년 11월 5일. 개념과 공개 권고는 아래 문서에 근거해 정리했습니다. 고객 지원 사례, 평가 항목과 배포 순서는 이 글에서 구성한 설계 예시이며 도입 효과를 측정한 실험 결과가 아닙니다.

 

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

직접 및 간접 프롬프트 인젝션의 정의, RAG의 한계, 출력 검증, 최소 권한과 공격 평가를 참고했습니다.

 

[2] OpenAI API 문서, Safety in building agents

신뢰하지 않는 입력의 분리, 구조화된 데이터 전달, 도구 승인과 실행 기록 평가의 원칙을 참고했습니다. Agent Builder용 문서의 공통 설계 원칙을 인용했으며 특정 제품의 신규 도입을 권장하는 의미는 아닙니다.

 

[3] Model Context Protocol, Security Best Practices, 2026-07-28 버전

토큰 패스스루, 대리인 혼동, 외부 요청과 권한 범위 최소화에 관한 구현상의 고려 사항을 참고했습니다. 구체적인 적용은 사용하는 프로토콜 버전과 배포 환경에 맞춰 확인해야 합니다.

 

[4] 인포그랩 기술 블로그, MCP 보안 위협과 실무 대응 전략 알아보기, 2025년 10월 29일

프롬프트 인젝션과 툴 포이즈닝, 공급망과 권한 문제를 구분하는 관점을 비교했습니다.

 

[5] 다글로 블로그, 프롬프트 인젝션(Prompt Injection)이란? AI 에이전트 방어 점검표, 2026년 10월 23일

개인 사용자의 권한 점검과 원문 대조 관점을 비교했습니다. 제품 소개와 보안 원칙은 구분해 참고했습니다.