AI DLP는 생성형 AI를 쓰는 과정에서 발생하는 데이터 유출을 입력 시점에 방지하는 보안 접근이다. 직원이 ChatGPT·Claude·Gemini 같은 AI에 개인정보·API 키·소스코드를 입력하거나 파일로 올리는 순간, 그리고 Claude Desktop·Cursor·Claude Code에 붙은 MCP 서버·에이전트가 회사 데이터와 도구에 접근하는 지점을 통제한다. 기존 DLP가 이메일·USB·파일 서버·네트워크 같은 정해진 채널을 감시했다면, AI DLP는 "AI로 들어가는 입력"과 "AI 에이전트가 가진 권한"을 대상으로 삼는다는 점이 다르다.
AI DLP = AI 사용에서의 데이터 유출 방지. 감시 대상이 "채널(메일·USB·웹)"에서 "AI 입력과 에이전트 권한"으로 이동한 것이 기존 DLP와의 본질적 차이다.
왜 웹·네트워크 DLP는 MCP를 못 보는가
기존 DLP와 보안 웹 게이트웨이(SWG)는 브라우저와 네트워크 트래픽을 검사하도록 설계됐다. 이 구조는 웹 채팅창 유출까지는 일부 볼 수 있어도, 개발 도구 계층에서 벌어지는 일에는 구조적으로 눈이 없다.
이유는 간단하다. 많은 MCP(Model Context Protocol) 서버는 stdio 기반으로 개발자 PC 안에서 로컬 프로세스로 동작한다. Claude Desktop이 로컬 파일을 읽고, Cursor가 GitHub PR을 만들고, 에이전트가 터미널을 실행하는 접근이 네트워크를 타지 않고 프로세스 대 프로세스로 일어난다. 그래서 네트워크 계층에서는 관찰되지 않는다.
웹 트래픽만 보는 보안으로는 Claude Desktop의 로컬 MCP 서버도, Cursor가 여는 저장소도 보이지 않는다. 이건 설정을 잘못한 문제가 아니라 아키텍처의 사각지대다.
여기에 더해, 로컬 에이전트가 가진 것은 "데이터를 어디로 보내느냐"만이 아니라 "무엇에 접근할 권한이 있느냐"다. 홈 디렉토리 전체를 읽는 filesystem 서버, write 스코프를 가진 GitHub 서버, env에 평문으로 박힌 API 키 — 이런 위험은 트래픽 검사로는 결코 드러나지 않는다.
AI 사용·에이전트 보안이 더 다루는 것
그래서 우리는 이 영역을 AI 사용·에이전트 보안(AI Usage & Agent Security)이라 부른다. AI DLP의 "입력 시점 유출 방지"에, 에이전트 권한 관점을 더한 범주다. 네 가지를 다룬다.
- AI 사용 지도화(AI-BOM) — 조직이 실제로 어떤 AI 서비스와 MCP 서버를 쓰는지, 각각 무엇에 접근하는지 목록화한다. Shadow AI를 드러내는 첫 단계.
- 입력 시점 유출 차단 — 개인정보(주민등록번호·사업자번호·계좌·계약정보), API 키, 소스코드, 고객 데이터가 AI에 들어가기 전에 경고·마스킹·차단·승인 요청한다.
- MCP·개발 도구 권한 점검 — Claude Desktop·Cursor·Claude Code의 MCP 설정, OAuth 스코프, 폴더 접근 범위, 평문 시크릿을 스캔하고 위험을 점수화한다. 새 서버가 붙으면 알린다.
- 원문 없는 증적 — 무엇을 언제 어떻게 통제했는지 로그를 남기되, 프롬프트·파일 원문은 저장하지 않고 이벤트 메타데이터만 기록한다.
핵심 프레임은 이것이다. 위험은 "AI를 쓰는 것"이 아니라 "AI 에이전트가 무엇을 할 수 있는지 아무도 모르는 것"이다. 그러므로 답은 금지가 아니라 가시성과 권한 통제다.
탐지는 기기 내(on-device)에서 수행하고, 서버에는 원문 대신 이벤트 메타데이터(이벤트 유형·AI 서비스·사용자/팀·시간·조치·위험도·선택적 단방향 해시)만 남긴다. AI 사용을 막지 않고, 회사 데이터와 AI 에이전트 권한만 통제한다. — 보안 설계 자세히 보기
기존 DLP vs AI DLP
같은 "데이터 유출 방지"라는 말을 쓰지만, 감시 대상과 방식이 다르다.
| 구분 | 기존 DLP | AI DLP · AI 사용·에이전트 보안 |
|---|---|---|
| 주 감시 대상 | 이메일·USB·파일 서버·웹 업로드 등 정해진 채널 | AI 채팅 입력·파일 업로드 + AI 에이전트 권한 |
| 개발 도구 계층 | 대상 아님(웹·네트워크 한정) | Claude Desktop·Cursor·Claude Code의 MCP 설정·권한 포함 |
| 로컬 MCP 서버 | 보이지 않음(stdio 로컬 프로세스) | 엔드포인트에서 config·스코프·시크릿 직접 스캔 |
| 통제 시점 | 주로 전송·이동 시점 | 입력 시점(전송 전) + 지속적 권한 점검 |
| 관점 | 데이터가 어디로 나가는가 | 데이터 유출 + 에이전트가 무엇에 접근하는가 |
정리하면, AI DLP는 기존 DLP를 대체하기보다 기존 DLP가 구조적으로 볼 수 없는 새 채널(AI 입력·에이전트 권한)을 담당한다. 특히 개발 도구 계층은 기존 DLP의 사각지대이므로, 이 영역을 위한 전용 접근이 필요하다.
도입 체크리스트
AI DLP를 검토한다면 다음을 확인하면 된다.
- 우리 조직이 쓰는 AI 서비스와 MCP 서버 목록을 만들 수 있는가?
- 개인정보·API 키·소스코드를 입력 시점에 검출·차단할 수 있는가?
- 개발자 PC의 MCP 설정·권한·평문 시크릿을 점검할 수 있는가?
- 새 MCP 서버·AI 도구가 붙었을 때 알 방법이 있는가?
- 보안 벤더가 프롬프트 원문을 저장하는가, 아니면 메타데이터만 남기는가?
- 남긴 기록으로 ISMS-P·개인정보보호법 관점의 증적을 만들 수 있는가?
- 도입이 직원 감시가 아니라 데이터·권한 통제에 한정되는가?(도입 저항 최소화)
세 개 이상 "아니오"라면, AI DLP 관점의 점검을 시작할 때다.