AI 에이전트에 고객정보와 도구 권한을 주기 전, 무엇을 막아야 할까

AI를 이용한 공격과 AI 서비스가 공격받는 문제를 구분합니다

“AI발 공격”에는 서로 다른 문제가 섞여 있습니다. 공격자가 AI를 이용해 사칭 메시지를 작성하거나 공격 준비를 돕는 경우에는 기존 계정·이메일·업무 승인 체계가 주요 방어 대상입니다. 반면 회사가 도입한 AI 에이전트가 악성 입력에 영향을 받아 정보를 내보내거나 도구를 오용한다면, AI와 연결된 업무 시스템의 신뢰 경계를 살펴야 합니다. NIST의 생성형 AI 위험 관리 자료도 다른 시스템을 공격하는 데 AI를 악용하는 문제와 프롬프트 인젝션 등 AI 시스템을 겨냥한 공격을 구분해 평가하도록 제안합니다.^[1]

이 글은 두 번째 문제를 다룹니다. 고객지원 에이전트가 주문을 조회하고 CRM 에이전트가 메시지를 준비하고 운영 에이전트가 업무 도구를 호출하는 환경을 가정합니다. 특정 모델의 공격 차단율이나 제품 순위를 비교하지 않습니다. 도입 조직이 통제할 수 있는 데이터·권한·승인·검증·복구 기준을 정리합니다.

MCP 연결의 토큰·프로토콜·서버 설정은 MCP 서버를 운영 환경에 연결하기 전에 확인할 보안 항목에서 다룹니다. 여기서는 업무 책임자가 고객정보의 조회부터 초안, 승인, 외부 전달과 파생 기억까지 이어지는 전체 경로를 검토할 수 있도록 범위를 잡았습니다. 연결 기술이 달라도 이 경로의 권한과 책임은 확인해야 합니다.

프롬프트 인젝션은 모델이 처리하는 입력이 원래 목적과 다른 행동을 유도하는 문제입니다. 사용자가 직접 입력하는 경우뿐 아니라 웹페이지, 이메일, 파일, 도구 응답에 포함된 지시가 경로가 될 수 있습니다. OWASP의 2026 LLM Top 10은 프롬프트 인젝션, 민감정보 노출, 과도한 자율 권한을 각각 주요 위험으로 다룹니다. 하나의 필터가 이 위험 전체를 해결한다고 해석해서는 안 됩니다.^[2]

먼저 정상 업무의 범위를 한 문장으로 정합니다

아래는 설명을 위한 가상 사례입니다. 실제 IXC 고객의 사고나 도입 실적을 의미하지 않습니다.

한 판매사가 고객지원 에이전트에게 “문의 내용을 읽고 해당 고객의 주문 상태를 확인한 뒤 답변 초안을 작성하라”는 업무를 맡깁니다. 에이전트는 문의 본문, 첨부 문서, 내부 상품 안내와 주문 조회 도구에 접근합니다. 운영자는 편의를 위해 메시지 발신과 환불 도구도 같은 에이전트에 연결해 둡니다.

고객이 제출한 문서에 업무 범위를 바꾸려는 내용이 들어오면 문제가 생길 수 있습니다. 문서가 다른 고객의 주문을 조회하도록 유도하거나, 발신 대상을 바꾸거나, 일반 안내를 환불 승인처럼 해석하게 만들 수 있기 때문입니다. 외부 콘텐츠가 에이전트의 행동에 영향을 줄 수 있다는 위험은 브라우저 에이전트를 다룬 Anthropic의 연구에서도 설명합니다. 해당 연구 역시 프롬프트 인젝션을 해결된 문제로 보지 않습니다.^[3]

이 가상 업무의 정상 범위는 다음처럼 정할 수 있습니다.

인증된 고객의 현재 문의와 연결된 주문을 조회하고 확인 가능한 근거를 이용해 상담원이 검토할 답변 초안을 만든다.

이 문장에는 세 가지 경계가 들어 있습니다. 어느 고객의 정보인지, 어느 문의·주문과 연결되는지, 결과물이 초안인지 실제 실행인지입니다. “상담을 도와준다”처럼 넓은 목적만으로 도구를 연결하면, 운영자가 기대하는 제한을 시스템에서 검사하기 어렵습니다.

범위를 정한 다음에는 업무마다 필요한 도구를 줄입니다. 초안 작성 작업에서 환불 실행 도구를 호출할 이유가 없다면 해당 실행 경로를 제공하지 않는 구성이 출발점입니다. 에이전트가 조회를 마친 뒤 발신이나 환불이 필요하다고 판단하면, 그 요청을 별도 권한과 검증 절차가 있는 작업으로 넘깁니다.

읽기·쓰기·발신·금전 처리를 나누어 허용합니다

최소 권한은 도구 이름을 몇 개 줄이는 것만으로 완성되지 않습니다. 호출하는 사용자, 고객사, 데이터 객체, 허용된 작업과 현재 업무 상태까지 검사해야 합니다. OWASP는 에이전트의 도구 호출을 사용자 권한과 세션 맥락에 맞춰 검증하고 도구별 입력값을 확인하도록 안내합니다.^[4]

다음 표는 고객지원 업무에 적용한 권한 설계 예시입니다. 법정 기준이나 모든 서비스에 동일하게 적용하는 등급표는 아닙니다.

읽기 전용이라고 정보 노출 위험이 사라지지는 않습니다. 여러 고객사의 데이터를 읽을 수 있는 계정으로 검색한 뒤 답변 단계에서 숨기도록 지시하면, 이미 권한 밖 정보가 모델 입력이나 로그에 포함될 수 있습니다. 조회 계층에서 현재 사용자에게 허용된 데이터만 가져오는지 확인해야 합니다. 검색 결과를 재사용하는 캐시와 대화 기억에도 고객사·사용자 경계가 유지되어야 합니다.

또한 에이전트가 요청한 고객 ID나 조직 ID를 그대로 권한 근거로 쓰지 않습니다. 인증된 세션과 서버가 확인한 관계를 기준으로 조회 범위를 정해야 합니다. 필요한 값을 모델이 추출할 수는 있지만 그 값에 접근할 자격은 별도로 확인합니다.

외부 발신에서는 허용된 서비스에 연결했다는 사실만으로 충분하지 않습니다. 회사가 승인한 이메일 도구라도 수신자나 첨부파일이 잘못되면 정보가 나갈 수 있습니다. 연결 대상의 신뢰와 이번 실행의 정당성을 각각 확인해야 하는 이유입니다.

사용 중인 SaaS나 연동 도구가 고객별 조회 범위 또는 발신 대상을 제한하지 못한다면, 필요한 제한을 프롬프트에만 맡기지 않습니다. 공급사가 지원하는 권한을 확인하고 통제가 마련될 때까지 허용된 자료로 초안을 만드는 범위로 줄이거나 별도의 실행 계층을 검토합니다. 실제 도구가 제공하는 통제 수준이 도입 범위를 결정해야 합니다.

외부 자료와 업무 지시 사이에 경계를 둡니다

외부 콘텐츠에는 출처와 용도를 붙여 전달합니다. 고객이 작성한 문의, 내부 운영자가 승인한 정책, 외부 웹페이지와 도구 실행 결과를 같은 지위의 지시문으로 섞지 않습니다. 무엇을 읽은 결과인지 확인할 수 있어야 이후 조사도 가능합니다.

이 구분은 방어의 한 층입니다. 문서를 구분해 보여 주거나 의심스러운 입력을 탐지하는 것만으로 권한 검사를 대체할 수는 없습니다. Microsoft의 간접 프롬프트 인젝션 대응 지침은 입력 탐지, 콘텐츠 격리, 행동 관찰과 권한 통제를 여러 층으로 결합하고 비용·지연·오탐의 영향도 고려하도록 설명합니다.^[5]

실무에서는 세 경로를 따로 살피는 편이 좋습니다. 첫째는 모델에 들어오는 자료, 둘째는 모델이 제안하는 도구 호출, 셋째는 실제로 데이터가 나가거나 상태가 바뀌는 실행 지점입니다. 앞 단계에서 놓친 입력이 있더라도 뒤 단계의 권한과 업무 규칙이 유지되는지 검증합니다.

내부 문서도 작성 권한이 넓거나 외부 자료를 복사해 둔 문서라면 그대로 신뢰하기 어렵습니다. 출처가 내부라는 이유로 그 문장에 권한 변경 능력을 부여하지 않습니다. 문서의 내용과 업무 정책을 바꾸는 관리 경로를 구분합니다.

장기 기억도 같은 관점이 필요합니다. 한 번 읽은 자료가 요약·기억·검색 색인으로 남으면 다음 작업에 다시 영향을 줄 수 있습니다. OWASP의 에이전트 보안 가이드는 기억의 출처와 신뢰 표시를 유지하고 저장을 승인하며 검색된 기억이 중요한 실행에 영향을 주기 전에 정책을 다시 적용하도록 안내합니다.^[6]

따라서 의심스러운 원문을 삭제하는 조치만으로 정리가 끝났다고 판단하지 않습니다. 어떤 요약과 기억이 그 원문에서 만들어졌는지 추적하고 이후 작업에서 재사용되는 경로까지 확인하는 절차를 준비합니다.

고객정보가 지나가는 경로를 업무 책임자가 확인합니다

가상 고객지원 사례에서 정보는 한 번 읽히고 끝나지 않습니다. 상담 초안이 내부 기록으로 저장되고 승인한 답변이 발송되며 요약이 다음 상담의 참고 자료로 남을 수 있습니다. 아래 표는 이 경로에 필요한 기록의 예시입니다. 고객정보 원문을 모든 지점에 복제하라는 의미는 아닙니다.

예를 들어 오염된 문서를 회수했더라도 그 내용을 요약한 상담 기록이 검색에 남아 있으면 같은 영향이 다시 나타날 수 있습니다. 의심 원천과 연결된 기억은 조사 중 사용을 제한하고 어떤 범위에 영향을 주었는지 확인한 뒤 승인된 원천으로 재생성하거나 폐기하는 절차를 검토합니다. 조사 기록을 보존해야 하는 범위와 실제 업무에서 재사용할 범위는 분리합니다.

복구 시험도 다음 요청까지 이어져야 합니다. 기존 대화를 다시 열었을 때, 다른 상담원이 같은 고객을 조회했을 때, 요약이 재검색됐을 때 회수한 내용이 다시 권한이나 실행 판단의 근거가 되지 않는지 확인합니다. 원천을 수정한 시각과 검색·캐시·기억에 변경이 반영된 시각을 따로 기록하면 아직 영향을 받는 경로를 찾을 수 있습니다.

실행 승인은 사람이 이해할 수 있는 거래 단위로 만듭니다

“계속 진행할까요?”라는 질문에는 승인할 대상이 충분히 드러나지 않습니다. 외부 발신이라면 수신자와 본문, 첨부파일을 보여 줘야 합니다. 환불이라면 주문·금액·사유·처리 후 상태가 필요합니다. 승인자는 그 행동을 승인할 권한이 있는 사람이어야 합니다.

OWASP의 AI Agent Security 자료는 중요한 실행의 미리보기, 위험에 따른 자율 범위, 감사 기록과 유효한 승인 검증을 제시합니다.^[7] 이를 앞의 가상 환불 업무에 적용하면 다음과 같은 설계 판단이 필요합니다.

상담원이 승인한 것은 특정 주문의 특정 금액입니다. 승인 후 에이전트가 대상 주문이나 금액을 바꾸면 기존 승인은 그 실행을 뒷받침하지 못합니다. 승인 기록을 실제 실행값과 연결하고 값이 달라지면 다시 검토하도록 만듭니다. 승인과 실행 사이에 주문이 이미 취소되거나 환불됐다면 현재 상태를 다시 확인해야 합니다.

승인에는 사용할 수 있는 횟수와 유효 범위도 정합니다. 네트워크 응답이 늦었다는 이유로 같은 환불이 두 번 실행되어서는 안 됩니다. 같은 업무 요청의 재시도를 식별하는 방식과 이미 처리된 거래를 확인하는 절차가 함께 필요합니다. 이 부분은 프롬프트 인젝션 여부와 무관하게 금전 처리의 정확성에도 영향을 줍니다.

모든 조회에 수동 승인을 붙이는 설계는 검토 부담을 크게 만들 수 있습니다. 대신 허용 범위가 명확한 조회와 초안 생성은 정해진 범위 안에서 처리하고 영향이 큰 변경이나 예외 처리는 검토자가 실제 결과를 확인할 수 있도록 집중합니다. 승인 건수보다 승인자가 대상과 영향을 이해하고 결정할 수 있는지가 중요합니다.

보안 테스트는 실제 실행 결과를 확인해야 합니다

최종 답변에 거절 문구가 있어도, 그 전에 도구 호출이 실행되었을 수 있습니다. 반대로 답변이 정상이어도 외부 요청이나 로그에 데이터가 남았을 수 있습니다. OWASP의 검증 안내는 정보 공개, 도구 오용, 외부 유출을 각각 관측하고 증거가 없는 경우를 차단 성공과 구분하도록 설명합니다.^[4]

다음은 앞의 고객지원 사례를 위한 IXC의 시험 설계 예시입니다. 실제 고객정보와 운영 결제는 사용하지 않고, 격리된 테스트 환경에서 가상 계정·주문·외부 수신처로 확인합니다.

기록에는 테스트 대상의 모델·프롬프트·도구·정책·검색 구성 버전, 입력 자료의 조건, 기대 결과와 실제 관측을 남깁니다. 도구가 호출되지 않은 것인지, 호출되었지만 거부된 것인지, 실행 결과를 확인할 수 없었던 것인지도 구분합니다.

짧은 입력 한 개를 한 번 통과시킨 결과로 보안을 일반화하지 않습니다. 실제 업무의 언어, 첨부파일 종류, 대화 길이와 다단계 호출을 고려해 반복 확인합니다. 시험 건수와 반복 횟수는 위험과 변화량에 맞춰 정하고 결과를 “해당 조건에서 위반이 관측되지 않음”처럼 범위와 함께 설명합니다.

NIST의 생성형 AI 프로파일도 실제 배포와 유사한 조건에서 평가하고 보안·복원력의 측정 근거와 한계를 기록하도록 다룹니다.^[1] 모델이나 프롬프트를 바꿀 때뿐 아니라 새 도구, 검색 자료원, 기억 기능과 권한 정책을 추가할 때에도 관련 시험을 다시 실행해야 합니다.

출시 전에 중단 조건과 재개 책임을 합의합니다

보안 검토가 끝나는 지점은 테스트 보고서 작성이 아닙니다. 운영 중 같은 징후를 발견했을 때 담당자가 실제로 노출을 멈출 수 있어야 합니다. NIST의 사고 대응 지침은 준비, 탐지, 대응과 복구를 조직의 위험 관리 활동에 연결합니다.^[8]

다음 표는 이 가상 서비스에 적용할 운영 기준 예시입니다. 역할은 한 사람이 겸할 수 있지만 결정 책임과 실행 권한은 문서에 남깁니다.

운영 로그는 조사에 필요한 사실을 남기는 방향으로 설계합니다. 요청 식별자, 도구와 정책 버전, 접근 대상의 식별 정보, 허용·거부 결정, 승인 연결, 실제 외부 실행 결과가 중요합니다. 고객정보와 인증정보를 로그에 무제한 복제하면 조사 도구 자체가 새로운 노출 지점이 될 수 있으므로, 수집 항목·가림 처리·접근 권한·보존 범위를 함께 정합니다.

사고가 의심되면 영향 기능을 멈추면서 조사에 필요한 기록을 보존합니다. 확인되지 않은 상태에서 로그나 기억을 일괄 삭제하면 범위 파악이 어려워질 수 있습니다. 의심 자료가 만든 파생 기억과 대기 실행을 식별하고 자격증명 노출 가능성이 있으면 관련 접근을 회수·교체하는 절차를 담당자가 수행하도록 준비합니다.

재개할 때에는 프롬프트 수정 사실만 보지 않습니다. 문제가 발생한 경로가 차단되는지, 정상 업무가 다시 가능한지, 같은 증상이 생기면 관측하고 멈출 수 있는지 확인합니다. 이미 외부로 전달된 정보나 실행된 거래는 설정을 되돌린다고 사라지지 않으므로, 후속 처리의 담당과 완료 기준도 남겨야 합니다.

도입 회의에는 권한표와 검증 공백을 가져갑니다

검토자는 다음 질문에 답할 수 있어야 합니다.

• 에이전트가 수행할 업무와 제외할 작업이 정해졌는가?
• 사용자·고객사·데이터 객체의 접근 경계를 서버가 검사하는가?
• 외부 자료와 기억이 실행 권한을 바꿀 수 없도록 통제하는가?
• 고영향 실행의 대상과 내용이 승인 기록에 연결되는가?
• 최종 답변 외에 도구·데이터·외부 전달 결과를 관측할 수 있는가?
• 미검증 항목과 잔여 위험에 담당자와 다음 확인 시점이 있는가?
• 중단 권한, 수동 처리 경로와 재개 조건을 실제로 확인했는가?

권한 밖 고객정보 접근이나 승인 없는 금전 처리가 확인되면, 그 실행 경로를 운영에 허용하기 어렵습니다. 관련 경계를 확인하지 못한 상태 역시 통과와 구분해야 합니다. 제한된 도입이 가능한지는 줄인 범위에서도 데이터·권한·관측 조건이 성립하는지 검토해 판단합니다.

출시 판정의 공통 틀은 출시 여부를 결정할 때 테스트 결과 외에 무엇을 확인해야 할까에서 함께 살펴볼 수 있습니다. AI 에이전트의 경우 그 틀에 외부 입력, 도구 권한, 승인과 기억의 변경을 추가해 검증 범위를 구체화합니다.

검증 결과를 다음 조치로 연결하기

에이전트 보안을 검토하려면 어떤 조건을 시험했고, 무엇이 차단됐으며, 어떤 경로를 아직 확인하지 못했는지 남겨야 합니다. 이 기록을 요구사항과 수정·재검증에 연결하면 도구나 모델이 바뀔 때 다시 확인할 범위가 분명해집니다.

Qoretix는 공개 제품 소개에서 테스트 계획과 케이스, API·브라우저 실행, 실패 증거와 미검증 항목, 연결된 저장소의 코드·시크릿·의존성 점검을 설명합니다.^[9] 에이전트 특화 검증의 적용 범위는 프로젝트 구성에 맞춰 확인해야 하며 운영 중 권한 차단과 실행 승인은 실제 애플리케이션에서 구현·검증할 책임입니다.

AI 에이전트의 고객정보 접근과 도구 실행을 운영에 연결할 계획이라면, IXC에 프로젝트 문의를 통해 업무 범위·권한 경계·검증 시나리오를 함께 정리할 수 있습니다.