AX LABS
← 블로그 에이전트 제품 설계

DLP는 경계를 둘로 쪼갠다

읽기와 실행을 분리해야 유출이 멈춘다

AX LABS 6분 읽기

현장에서 에이전트 PoC가 멈추는 지점은 대개 같다. 내부 문서를 읽게 했더니 답변 품질은 올라간다. 메일, 티켓, Slack, 브라우저, MCP tool을 붙였더니 업무처럼 보인다. 그다음 보안팀이 묻는다. “악성 문서가 에이전트에게 외부 URL로 고객 정보를 보내라고 지시하면 어디서 막습니까?” 이 질문에 “시스템 프롬프트에 금지했습니다”라고 답하는 순간 운영 전환은 끝난다.

프롬프트 인젝션은 모델 문제가 아니라 경계 문제다

프롬프트 인젝션은 더 이상 “앞의 지시를 무시하라” 수준의 장난이 아니다. OpenAI는 2026년 글에서 외부 콘텐츠에 숨은 지시가 에이전트에게 사용자가 의도하지 않은 행동을 유도한다고 설명했고, URL 자체가 민감정보를 실어 나르는 유출 통로가 된다고 밝혔다. Anthropic도 브라우저 사용 에이전트에서 방어 성능이 개선됐지만 어떤 브라우저 에이전트도 면역은 아니라고 선을 그었다.

그래서 AX Ops에서는 에이전트 DLP를 모델 필터로 설계하지 않는다. 경계 설계로 본다. 모델은 판단자가 아니라 잠재적으로 속을 수 있는 실행 계획 생성기다. 보안은 모델 밖에서 강제되어야 한다.

에이전트 DLP의 핵심은 “무엇을 읽었는가”와 “어디로 영향을 냈는가”를 같은 선에서 다루지 않는 것이다.

읽기 경계는 지식 접근권을 정한다

read boundary는 에이전트가 어떤 데이터를 context로 가져올 수 있는지 정하는 선이다. 여기서 중요한 것은 접근 허용 여부만이 아니다. 데이터의 출처와 신뢰도를 라벨링해야 한다.

읽기 경계는 최소 네 가지를 구분한다.

  • 사용자가 명시적으로 제공한 데이터
  • 사내 권한으로 조회한 민감 데이터
  • 외부 웹·메일·문서에서 들어온 비신뢰 데이터
  • tool 설명, MCP 응답, 로그처럼 지시처럼 보일 수 있는 운영 데이터

OWASP GenAI Security Project는 Prompt Injection을 LLM01:2025로 다루며 직접·간접 인젝션을 핵심 위험으로 분류한다. NSA의 2026년 MCP 보안 설계 문서도 MCP 환경에서 조작, 프롬프트 인젝션, 데이터 유출이 발생할 수 있다고 경고한다. 결론은 분명하다. 외부 문서와 tool output은 “정보”이지 “명령”이 아니다.

실행 경계는 유출 통로를 잠근다

effect sink는 에이전트가 외부 세계에 영향을 내는 지점이다. 브라우저 fetch, 이미지 로드, webhook 호출, 이메일 발송, 파일 업로드, DB write, PR 생성, 티켓 코멘트, MCP tool call이 모두 sink다.

읽기 경계만 두면 답변창 유출은 줄어든다. 그러나 URL query, redirect, 이미지 요청, 로그성 tool call을 통한 조용한 유출은 남는다. OpenAI의 2026년 Safe URL 접근은 이 문제를 정확히 겨냥한다. 자동 fetch는 이미 공개적으로 관찰된 URL에 한정하고, 검증되지 않은 URL은 사용자 확인 또는 차단 대상으로 둔다.

구분 막는 것 놓치는 것
프롬프트 규칙 명시적 답변 유출 tool call을 통한 조용한 유출
read boundary 과도한 context 주입 허용된 데이터의 외부 전송
effect sink boundary URL·메일·API 유출 업무상 필요한 실행의 세부 맥락
dual-boundary DLP 데이터 흐름 전체 예외 정책 없는 현장 운영

Invariant Labs가 2025년에 설명한 toxic flow 분석도 같은 방향이다. 민감 데이터가 신뢰 낮은 경로를 거쳐 exfiltration sink로 흐르는지를 봐야 한다. “나쁜 문장 탐지”가 아니라 “나쁜 흐름 차단”이다.

운영 설계는 두 경계를 따로 배포한다

Dual-boundary agent DLP는 다음 순서로 설계한다.

  1. 데이터 소스마다 민감도와 신뢰도를 붙인다.
  2. 에이전트 context 조립 시 read policy를 적용한다.
  3. 모든 tool call 직전에 sink policy를 적용한다.
  4. read label과 sink type의 조합으로 허용·차단·승인 요청을 결정한다.
  5. 차단 로그를 AgentOps 지표로 남겨 정책을 조정한다.

예를 들어 “사내 계약서 요약”은 read boundary 안에서 허용된다. 그러나 그 요약을 외부 URL parameter에 실어 보내는 행위는 effect sink에서 차단된다. 사용자가 승인한 메일 발송도 수신자 도메인, 첨부 데이터 등급, 본문 내 민감 토큰 여부에 따라 별도 판정을 받아야 한다.

이 설계는 느려 보이지만 운영에서는 반대다. 보안팀, 현업, 개발팀이 같은 표를 놓고 예외를 합의할 수 있다. “모델이 알아서 조심한다”는 말보다 “이 등급의 데이터는 이 sink로 못 나간다”는 문장이 운영을 만든다.

지금 필요한 것은 더 센 프롬프트가 아니다

에이전트가 내부 데이터를 읽고 외부 tool을 실행하는 순간, DLP는 채팅창 검열이 아니다. 데이터 흐름 제어다. read boundary는 무엇을 보게 할지 정하고, effect sink는 무엇을 밖으로 내보낼지 정한다. 둘 중 하나만 있으면 프롬프트 인젝션은 빈틈을 찾는다.

AX LABS는 에이전트 설계를 기능 단위가 아니라 운영 경계 단위로 본다. PoC에서 보안 검토를 통과하지 못한 에이전트는 성능 문제가 아니라 경계 설계 문제가 있는 것이다. 이 경계를 먼저 그어야 에이전트가 현장 시스템이 된다. 더 자세한 설계 원칙은 AX Ops 방법론 →에서 확인할 수 있다.

참고