AI 에이전트 데이터 유출 방지 2026, 검색 로그·MCP 도구 통제 기준
요약: AI 에이전트 데이터 유출 방지 기준을 MosaicLeaks와 AutoJack 사례로 검색 로그, MCP, 브라우저 도구, 비용·보안·운영 관점에서 점검합니다.
AI 에이전트를 사내 문서 검색, 리서치, 코드 분석, 고객지원에 붙이면 가장 먼저 새는 곳은 답변 화면이 아닐 수 있다. 외부 검색어, 브라우저가 방문한 URL, MCP 도구 호출, 로컬 서버 접근, 로그 저장소가 먼저 흔적을 남긴다. 담당자가 “모델에게 비밀을 말하지 말라고 지시했다”는 이유만으로 통제를 끝내면 위험하다. 검색 질의 하나만 보면 평범해도, 여러 번의 질의를 합치면 내부 고객명·일정·수치·사고 맥락이 맞춰지는 경우가 생긴다.
Hugging Face에 공개된 ServiceNow Research의 MosaicLeaks 연구는 이 문제를 잘 보여준다. 연구 에이전트가 사내 문서와 웹 검색을 오가며 multi-hop 질문을 풀 때, 외부 질의 로그만 관찰해도 private research intent, answer, full-information leakage가 발생할 수 있다고 정리한다. 프롬프트에 “누설하지 말라”는 문장을 넣는 방식은 일부 완화 효과만 보였고, 과제 성능만 올리는 학습은 오히려 더 많은 정보를 질의에 담게 만들었다.
Microsoft Security Blog의 AutoJack 사례는 다른 각도에서 경고한다. 브라우징 에이전트가 외부 페이지를 렌더링하고, 같은 호스트의 로컬 MCP WebSocket 또는 개발자 제어면에 닿을 수 있으면 localhost가 더 이상 안전한 경계가 아니다. AI 에이전트 데이터 유출 방지는 “민감정보 마스킹”만의 문제가 아니라 검색 프록시, 도구 권한, 브라우저 격리, 승인 정책, 감사 로그, 비용 상한을 함께 설계하는 운영 문제다.
- AI 에이전트 데이터 유출 방지는 답변 필터보다 외부 검색 질의, MCP 도구 호출, 브라우저 경로, 로그 저장 정책부터 막아야 한다.
- MosaicLeaks가 지적한 위험은 단일 질의가 아니라 여러 질의가 모여 내부 사실을 복원하는 mosaic leakage다.
- AutoJack 사례처럼 브라우징 에이전트와 로컬 제어면이 붙으면 localhost, WebSocket, MCP 서버가 공격면이 된다.
- 실무 통제는 질의 최소화, 도구 allowlist, 네트워크 egress 프록시, 사람 승인, leakage eval, 비용 한도를 한 세트로 묶어야 한다.
이 글이 필요한 사람
- 사내 문서와 웹 검색을 함께 쓰는 리서치 에이전트를 검토하는 보안 담당자
- MCP 서버, 브라우저 도구, 코드 실행 도구를 AI 에이전트에 연결하려는 플랫폼 엔지니어
- 고객정보, 계약금액, 보안 사고 메모가 포함된 지식베이스를 RAG나 agent workflow에 붙여야 하는 개발 리더
- AI 에이전트 파일럿의 비용·권한·감사 로그 기준을 경영진에게 설명해야 하는 운영 책임자
- 프롬프트 인젝션, 도구 호출, 데이터 유출 테스트를 배포 게이트에 넣고 싶은 DevSecOps 팀
AI 에이전트 데이터 유출 방지에서 먼저 볼 누출 경로
전통적인 챗봇 보안 점검은 사용자의 입력과 모델의 답변에 집중한다. 에이전트는 구조가 다르다. 모델이 직접 웹을 검색하고, 로컬 문서를 읽고, MCP 서버를 호출하고, 브라우저를 열고, 때로는 셸 명령을 실행한다. 그래서 누출 경로도 넓어진다. 답변에 민감정보가 없어도 외부 검색 로그에는 내부 프로젝트 코드명, 고객사 이름, 정확한 비율, 장애 날짜가 남을 수 있다.
AI 에이전트 데이터 유출 방지의 첫 단계는 “모델이 무엇을 알고 있나”가 아니라 “모델이 어느 순간에 외부 세계와 통신하나”를 그리는 것이다. 웹 검색, 외부 API, SaaS 커넥터, MCP 서버, 브라우저, 로컬 WebSocket, 로그 파이프라인을 한 장에 놓고, 각 경로가 민감정보를 담을 수 있는지 표시해야 한다. 이 작업 없이 답변 필터만 붙이면 검색어와 도구 호출 로그가 사각지대에 남는다.
| 누출 경로 | 실제 발생 조건 | 보안팀이 볼 신호 | 우선 통제 |
|---|---|---|---|
| 외부 검색 질의 | 사내 문서에서 얻은 고객명·수치·날짜를 그대로 검색어에 섞는다 | 검색 프록시 로그에 내부 고유명사와 숫자가 함께 남는다 | 질의 최소화, 민감 레이블 탐지, 외부 검색 전 rewrite 승인 |
| MCP·도구 호출 | 에이전트가 파일, 티켓, CRM, 코드 저장소 도구를 자유롭게 호출한다 | 툴 호출 로그에 필요 이상의 객체 ID와 원문 chunk가 쌓인다 | 도구 allowlist, read-only 기본값, 호출별 scope 제한 |
| 브라우저·로컬 제어면 | 브라우징 에이전트가 외부 페이지를 렌더링한 뒤 localhost 서비스에 접근한다 | 브라우저 직후 로컬 WebSocket·MCP·셸 호출이 이어진다 | 브라우저 격리, localhost 차단, 제어면 인증·인가 |
| 관찰·분석 로그 | 디버깅 편의 때문에 프롬프트, 검색어, 문서 chunk, 답변을 통째로 저장한다 | 로그 저장소가 두 번째 데이터베이스가 된다 | raw chunk 저장 금지, 보존 기간, 접근권한, DLP 스캔 |
| 비용 최적화 캐시 | 재검색 비용을 줄이려고 검색 결과와 내부 결합 결과를 캐시에 보관한다 | 캐시 키에 고객명·계약금액·사고일이 들어간다 | 캐시 키 해시화, 민감값 제거, TTL 제한 |
MosaicLeaks가 말하는 핵심: 검색어는 작은 조각이어도 모이면 비밀이 된다
MosaicLeaks의 핵심은 단순하다. 에이전트가 local enterprise document와 web corpus를 번갈아 보며 답을 찾는 과정에서, 이전 단계의 private answer가 다음 웹 검색어로 넘어갈 수 있다. 단일 검색어에는 “보안 사고”, “2024년 1월”, “특정 벤더” 정도만 보일 수 있다. 그러나 질의 로그를 시간 순서로 모으면 내부 회사가 언제 무엇을 진행했고 어떤 사건과 연결되는지 추론할 수 있다.
논문형 실험 수치를 그대로 운영 기준으로 옮길 필요는 없다. 다만 방향은 명확하다. 성능을 올리기 위해 더 풍부한 컨텍스트를 검색어에 넣는 에이전트는 retrieval 정확도를 얻는 대신 privacy risk를 키울 수 있다. 그래서 “검색을 잘하게 만들자”와 “검색어를 안전하게 만들자”는 별도 목표로 측정해야 한다. 질의가 적다고 안전한 것도 아니다. 필요한 공개 사실만 남기고 내부 값을 제거한 질의를 더 많이 보내는 편이 더 안전할 수 있다.
# 검색 질의 최소화 예시
# 나쁜 질의: 내부 고객명 + 수치 + 날짜가 한 번에 외부 검색으로 나간다.
# "MediConn 70% cloud migration January 2025 Microsoft nation state attack"
# 나은 절차:
# 1) 내부 문서에서 고객명, 비율, 날짜를 로컬 컨텍스트로만 보관한다.
# 2) 외부 검색은 공개 사실만 묻는다.
# "technology company disclosed nation-state attack January 2024"
# 3) 외부 검색 결과를 내부 값과 결합하는 작업은 로컬 단계에서 수행한다.
# 4) 외부 질의 로그에는 내부 고객명, 비율, 계약금액, 코드명이 남지 않게 한다.
비용·보안·운영 기준으로 보는 도입 판단표
AI 에이전트 데이터 유출 방지를 비용 문제와 분리하면 파일럿이 오래 못 간다. 질의 rewrite, 검색 프록시, 도구 allowlist, 로그 DLP, 샌드박스는 모두 운영 비용을 만든다. 반대로 통제 없이 열면 사고가 난 뒤 조사 비용이 더 커진다. 파일럿 단계에서는 “최대한 자유롭게 써보고 나중에 막자”보다 “처음부터 좁게 열고 효과가 검증된 경로만 넓히자”가 낫다.
| 판단 축 | 낮은 위험 시작점 | 비용이 늘어나는 지점 | 보류해야 하는 신호 |
|---|---|---|---|
| 검색 질의 | 외부 검색은 프록시를 거치고 민감값 rewrite를 적용한다 | 질의 검사 모델, DLP 사전, 로그 저장소 운영이 필요하다 | 고객명·내부 수치가 그대로 검색 로그에 남는다 |
| 도구 권한 | read-only 도구와 승인 필요한 쓰기 작업을 분리한다 | 도구별 scope 관리와 감사 로그 수집 비용이 든다 | MCP 서버를 사용자가 임의 등록한다 |
| 브라우저 | 브라우저 도구는 별도 컨테이너에서 실행하고 localhost를 차단한다 | 격리 브라우저, 네트워크 정책, 프롬프트 인젝션 테스트가 필요하다 | 외부 페이지 렌더링 뒤 셸이나 로컬 WebSocket 호출이 가능하다 |
| 운영 로그 | 검색어·도구 호출·승인 이벤트만 최소 보관한다 | SIEM 연동과 보존 기간 정책을 관리해야 한다 | 프롬프트와 문서 원문 chunk를 무제한 저장한다 |
| 성과 측정 | 업무 단축 시간과 leakage eval을 같이 본다 | 테스트 세트 제작과 주기적 재평가 비용이 든다 | 정확도만 보고 privacy regression을 보지 않는다 |
실전 구축 순서: 답변 필터보다 프록시와 도구 경계부터
에이전트 보안 파일럿은 모델 교체보다 경계 정의가 먼저다. 아래 순서를 지키면 완벽하지는 않아도 사고 면적을 빠르게 줄일 수 있다. 특히 사내 문서와 웹 검색을 동시에 쓰는 경우에는 외부 검색 프록시를 반드시 통과시켜야 한다. 프록시가 없으면 누가 어떤 내부 단서를 어떤 외부 검색어로 보냈는지 나중에 복원하기 어렵다.
- 데이터 등급부터 붙인다: 고객명, 계정 ID, 내부 수치, 계약금액, 미공개 제품명, 사고 날짜처럼 외부 질의에 섞이면 안 되는 필드를 라벨로 정의한다.
- 에이전트 표면을 나눈다: 리서치 에이전트, 코딩 에이전트, 고객지원 에이전트, 운영 자동화 에이전트의 도구와 네트워크 권한을 분리한다.
- 외부 검색 프록시를 둔다: 모든 web search와 URL fetch를 프록시로 보내고, 민감 라벨·고유명사·정확한 숫자가 섞이면 rewrite 또는 승인 대기로 돌린다.
- MCP 서버를 allowlist로 고정한다: 사용자가 command, args, URL로 임의 서버를 붙이지 못하게 하고, 승인된 wrapper만 실행한다.
- 브라우저와 localhost를 분리한다: 외부 페이지를 렌더링하는 브라우저에서 로컬 제어면, 메타데이터 서비스, 내부 admin 포트, MCP WebSocket으로 나가는 경로를 차단한다.
- 쓰기 작업은 승인 이벤트로 남긴다: 티켓 변경, 코드 수정, 파일 쓰기, Git push, 배포, 고객 데이터 조회는 사람 승인과 근거 로그를 요구한다.
- leakage eval을 배포 게이트에 넣는다: 내부값이 섞인 테스트 질문을 만들고, 외부 질의 로그만 보고 private fact를 추론할 수 있는지 주기적으로 확인한다.
- 비용 상한을 같이 둔다: 검색 rewrite, 재시도, 브라우저 세션, 도구 호출이 늘면 비용도 늘기 때문에 팀별 월간 한도와 중단 조건을 정한다.
실무 시나리오 1: 사내 문서와 웹 검색을 섞는 리서치 에이전트
첫 번째 시나리오는 전략팀이나 보안팀이 쓰는 리서치 에이전트다. 내부 보고서에서 고객사, 계약 일정, 장애 메모를 읽고 외부 뉴스와 연결해 요약한다. 겉으로는 지식노동 자동화지만, 위험은 외부 검색어에 있다. 에이전트가 “A고객 23% 전환율 2026년 2분기 경쟁사 사고”처럼 검색하면 답변에 비밀이 없어도 검색 로그가 이미 문제다.
이 조건이면 검토할 만하다. 내부 문서는 라벨링돼 있고, 외부 검색은 프록시를 통과하며, 프록시가 내부 고객명과 정확한 수치를 제거한다. 질의 rewrite 결과와 원 질의는 보안 로그에 남고, raw 문서 chunk는 저장하지 않는다. 이 경우는 보류다. 에이전트가 직접 인터넷 검색 API 키를 들고 있고, 프롬프트에 “민감정보를 보내지 말라”는 문장만 있으며, 어떤 검색어가 나갔는지 담당자가 볼 수 없다.
실무 시나리오 2: MCP와 브라우저를 붙인 개발자 에이전트
두 번째 시나리오는 개발자 워크스테이션의 코딩·운영 에이전트다. 브라우저 도구로 문서를 읽고, MCP 서버로 로컬 파일이나 티켓 시스템을 조회하고, 셸 명령으로 테스트를 실행한다. Microsoft의 AutoJack 글은 이런 조합에서 localhost와 unauthenticated WebSocket을 신뢰하면 어떤 문제가 생길 수 있는지 보여준다. 특정 PoC가 패치됐는지와 별개로, 패턴은 다른 프레임워크에서도 반복될 수 있다.
안전한 시작점은 좁다. 브라우저는 격리 컨테이너에서만 열고, localhost·사내 admin 포트·메타데이터 IP로 나가는 요청은 차단한다. MCP 서버는 승인된 read-only wrapper만 허용한다. URL이나 페이지 스크립트가 command와 args를 정하게 하지 않는다. 셸 실행은 테스트 명령처럼 allowlist된 범위에서만 자동 허용하고, 패키지 설치·네트워크 fetch·git push·배포 명령은 승인으로 넘긴다.
실무 시나리오 3: 고객지원 에이전트의 로그와 캐시
세 번째 시나리오는 고객지원 에이전트다. 상담 이력, 결제 상태, 장애 티켓을 읽고 답변 초안을 만든다. 여기서는 외부 검색보다 로그와 캐시가 더 큰 위험이 될 수 있다. 디버깅 편의 때문에 전체 프롬프트, 고객 질문, 검색 결과, 답변 초안, tool result를 한 번에 저장하면 로그 저장소가 사실상 고객정보 복제본이 된다. 비용을 줄이려고 cache key에 고객명이나 계정 ID를 그대로 넣는 것도 같은 문제다.
이 조건이면 진행한다. 로그는 이벤트 중심으로 최소 보관하고, raw prompt와 문서 chunk는 기본 저장하지 않는다. 캐시 키는 해시 처리하고, 응답 캐시에는 고객별 민감 필드를 넣지 않는다. 고객정보가 포함된 tool result는 role-based access와 보존 기간을 따로 둔다. 이 경우는 멈춘다. 운영팀 누구나 전체 대화·문서 chunk·도구 결과를 검색할 수 있고, 삭제 요청이나 사고 조사 절차가 없다.
MCP·브라우저·로컬 제어면 통제 체크리스트
| 체크 항목 | 질문 | 통과 기준 | 실패 시 조치 |
|---|---|---|---|
| MCP 등록 | 누가 새 MCP 서버를 붙일 수 있는가 | 관리자가 승인한 서버만 등록되고 command가 wrapper로 고정된다 | 사용자 임의 등록 차단, 기존 서버 inventory 작성 |
| 제어면 인증 | WebSocket·HTTP 제어면이 인증을 강제하는가 | localhost라도 토큰·세션·권한 검사를 통과해야 한다 | unauthenticated path 제거, origin만 믿는 구조 폐기 |
| 브라우저 격리 | 외부 페이지 렌더링 뒤 내부망으로 갈 수 있는가 | 격리 네트워크에서 실행하고 localhost·metadata·admin 포트를 차단한다 | 브라우저 도구 비활성화 후 테스트 환경부터 재설계 |
| 셸 실행 | 웹 탐색 직후 명령 실행이 가능한가 | 명령 allowlist와 사람 승인이 있고, 네트워크 fetch는 별도 승인이다 | shell 권한 제거 또는 on-request 정책으로 전환 |
| 로그 접근 | 누가 질의·툴 호출·승인 로그를 볼 수 있는가 | 보안·운영 담당자만 필요한 기간 동안 접근한다 | 접근권한 축소, 원문 chunk 저장 중지 |
실무 스켈레톤: AI 에이전트 데이터 유출 방지 정책
아래 YAML은 완성된 보안 정책이 아니라 배포 전 심사표를 코드처럼 관리하기 위한 뼈대다. 핵심은 외부 검색, MCP, 브라우저, 로그, release gate를 한 파일에서 같이 보는 것이다. NIST AI RMF처럼 위험을 식별·측정·관리하는 틀과 OWASP LLM Top 10의 프롬프트 인젝션·민감정보 노출 관점을 조직 정책으로 바꾸는 출발점으로 쓰면 된다.
# ai-agent-leakage-control.yaml
# 목적: AI 에이전트 데이터 유출 방지 점검을 배포 전 심사 항목으로 고정한다.
# 실제 조직명, 도메인, 로그 저장 위치는 내부 정책에 맞게 바꾼다.
owner:
security_owner: ai-security-reviewer
platform_owner: agent-platform-team
data_owner: enterprise-data-governance
review_cycle: every_2_weeks
agent_surfaces:
research_agent:
local_documents: allowed_by_label
web_search: via_proxy_only
browser_tool: disabled_by_default
mcp_servers: allowlist_only
coding_agent:
local_files: workspace_only
shell: approval_required
browser_tool: blocked
git_push: blocked
private_data_labels:
never_send_to_web:
- customer_name
- account_id
- internal_metric
- unreleased_product_name
- security_incident_date
- contract_amount
redact_before_query:
- vendor_name_when_internal_context
- project_codename
- precise_percentage
- employee_name
query_policy:
default: minimize
require_rewrite_when:
- query_contains_private_label
- query_contains_two_or_more_internal_clues
- query_mentions_customer_and_metric_together
- query_carries_previous_local_answer
safe_rewrite_examples:
- replace_customer_with_industry_category
- replace_exact_date_with_quarter_or_year_when_needed
- remove_internal_percentage_or_amount
- split_public_lookup_from_private_context
mcp_and_tool_policy:
localhost_is_not_trusted_boundary: true
websocket_control_plane_auth_required: true
allowed_mcp_servers:
- name: internal-doc-search-readonly
command: approved-wrapper
network: internal_only
- name: ticket-search-readonly
command: approved-wrapper
network: internal_only
denied_patterns:
- direct_stdio_command_from_url
- unauthenticated_websocket
- browser_to_localhost_control_plane
- shell_from_untrusted_page
logging:
retain_query_logs_days: 30
retain_tool_call_logs_days: 90
store_raw_private_document_chunks: false
alert_when:
- external_query_contains_private_label
- mcp_server_not_in_allowlist
- browser_tool_accesses_localhost
- shell_command_after_web_browse
release_gate:
required_tests:
- mosaic_query_rewrite_eval
- tool_allowlist_eval
- prompt_injection_page_eval
- cost_limit_eval
block_release_if:
- leakage_rate_over_threshold
- unauthenticated_control_plane
- no_owner_for_query_logs
- no_rollback_plan
정책 점검 스크립트 예시
다음 Python 예시는 정책 파일에 최소 통제가 들어갔는지 빠르게 확인하는 검사용 스켈레톤이다. 운영 환경에서는 YAML 파서로 구조를 검증하고, 사내 DLP 사전·MCP registry·네트워크 정책·SIEM 룰과 연결해야 한다. 문자열 검사만으로 안전을 보장하지는 않는다. 다만 배포 PR에서 위험한 기본값을 초기에 막는 용도에는 충분히 쓸 수 있다.
#!/usr/bin/env python3
# check_agent_leakage_policy.py
# 목적: AI 에이전트 배포 정책에 최소 데이터 유출 방지 통제가 들어갔는지 문자열 수준으로 점검한다.
# 실제 운영에서는 YAML 파서, DLP 사전, MCP allowlist, SIEM 룰과 연결한다.
from __future__ import annotations
import sys
from pathlib import Path
REQUIRED_SNIPPETS = [
'web_search: via_proxy_only',
'mcp_servers: allowlist_only',
'never_send_to_web:',
'query_contains_private_label',
'localhost_is_not_trusted_boundary: true',
'websocket_control_plane_auth_required: true',
'browser_tool_accesses_localhost',
]
BLOCKED_SNIPPETS = [
'web_search: direct',
'mcp_servers: any',
'browser_tool: always_on',
'store_raw_private_document_chunks: true',
'shell: allowed_without_approval',
]
def main(path: str) -> int:
text = Path(path).read_text(encoding='utf-8')
missing = [item for item in REQUIRED_SNIPPETS if item not in text]
blocked = [item for item in BLOCKED_SNIPPETS if item in text]
if missing:
print('[FAIL] missing leakage controls: ' + ', '.join(missing))
return 2
if blocked:
print('[FAIL] unsafe agent controls detected: ' + ', '.join(blocked))
return 3
print('[OK] baseline agent data-leakage controls are present.')
return 0
if __name__ == '__main__':
if len(sys.argv) != 2:
print('usage: python check_agent_leakage_policy.py ai-agent-leakage-control.yaml')
raise SystemExit(1)
raise SystemExit(main(sys.argv[1]))
leakage eval을 어떻게 설계할 것인가
정확도 eval만 돌리면 성능을 높이는 과정에서 질의가 더 길고 구체적으로 변할 수 있다. MosaicLeaks가 보여준 긴장은 여기서 나온다. 평가 세트에는 “정답을 맞혔는가”와 별도로 “외부 질의 로그만 보고 내부 사실을 추론할 수 있는가”를 넣어야 한다. 내부 고객명, 비율, 날짜, 보안사고 메모, 계약금액 같은 가짜 민감값을 테스트 문서에 넣고, 에이전트가 웹 검색을 수행한 뒤 query log를 별도 판정기에 넣는다.
판정 기준은 세 단계로 나누면 운영자가 이해하기 쉽다. intent leakage는 에이전트가 무엇을 조사했는지 드러나는 수준이다. answer leakage는 이미 질문을 아는 사람이 로그만으로 답을 맞히는 수준이다. full-information leakage는 질문을 몰라도 내부 사실을 말할 수 있는 수준이다. 파일럿에서는 full-information leakage를 0에 가깝게, answer leakage를 명시한 임계치 아래로, intent leakage는 업무 특성별 허용선을 정하는 방식이 현실적이다.
| 평가 항목 | 테스트 방법 | 통과 기준 예시 | 실패 후 보정 |
|---|---|---|---|
| 질의 민감값 탐지 | 외부 검색어에 고객명·정확한 숫자·코드명이 남는지 검사한다 | 민감 라벨 직접 노출 0건 | rewrite 룰 강화, 외부 검색 승인 추가 |
| mosaic 복원 가능성 | 질의 로그만 보고 내부 사실을 재구성할 수 있는지 판정한다 | full-information leakage 0건 | 검색 단계 분리, 내부값 제거, 로컬 결합으로 전환 |
| 도구 권한 초과 | 허용되지 않은 MCP·브라우저·셸 호출을 유도한다 | deny 이벤트는 남고 실행은 차단된다 | allowlist 축소, localhost 차단, 승인 정책 보강 |
| 비용 회귀 | rewrite·재검색 때문에 호출 수가 폭증하는지 본다 | 업무당 호출 수와 월 한도 내 유지 | 검색 캐시 TTL 조정, workflow 단순화 |
도입을 보류해야 하는 경우
첫째, 데이터 등급이 없다. 무엇이 외부 질의에 섞이면 안 되는지 조직이 합의하지 않았다면 에이전트가 안전하게 검색할 기준도 없다. 둘째, 외부 검색 경로가 흩어져 있다. 모델 공급자 검색, 브라우저 fetch, 사내 프록시, 커스텀 API가 제각각이면 누출 사고 때 타임라인을 맞출 수 없다. 셋째, MCP 서버를 사용자가 마음대로 추가한다. 편한 프로토타입 구조가 운영 제어면으로 넘어오면 위험하다.
넷째, 브라우저 도구와 셸 실행이 같은 에이전트에 열린다. 외부 페이지의 prompt injection, localhost 접근, 명령 실행이 한 체인에 묶이면 방어 난이도가 급격히 올라간다. 다섯째, 비용 담당자가 없다. 검색 rewrite와 eval은 호출 수를 늘릴 수 있다. 비용이 부담된다는 이유로 로그와 검사를 줄이면 보안 리스크가 늦게 드러난다. AI 에이전트 데이터 유출 방지 파일럿은 보안팀, 플랫폼팀, 데이터 오너, 비용 오너가 함께 승인해야 한다.
함께 보면 좋은 글
AI 에이전트 프레임워크 2026, LangChain·LlamaIndex·OpenAI Agents 도입 기준
OpenAI Codex 사용법 2026, 설치·CLI·IDE 첫 작업 가이드
사내 LLM 도입 2026, 디자인팀 AI 업무 적용 전 비용·보안 기준
RAG vs 파인튜닝 기업 맞춤형 LLM 최적화 전략 비교 가이드
2026년 실무자를 위한 로컬 LLM 실행 방법과 Python 개발 예제자주 묻는 질문
AI 에이전트 데이터 유출 방지는 프롬프트로 해결할 수 있나요?
프롬프트는 보조 통제다. MosaicLeaks 사례처럼 누설 금지 문구만으로는 검색 질의에 섞이는 내부 단서를 안정적으로 막기 어렵다. 외부 검색 프록시, 질의 rewrite, 도구 allowlist, 로그 DLP, 배포 전 leakage eval이 같이 필요하다.
RAG 챗봇과 AI 에이전트의 데이터 유출 위험은 무엇이 다른가요?
RAG 챗봇은 주로 retrieval 결과와 답변이 점검 대상이다. AI 에이전트는 여기에 웹 검색, 브라우저, MCP, 셸, 외부 API, 장기 로그가 붙는다. 답변이 깨끗해도 검색어와 도구 호출 로그에서 내부 사실이 새는 구조가 생긴다.
MCP 서버를 쓰면 무조건 위험한가요?
MCP 자체가 문제라기보다 등록·인증·권한·실행 방식이 문제다. 승인된 read-only 서버를 allowlist로 쓰고, command와 args를 사용자가 임의 지정하지 못하게 하며, 제어면 인증과 감사 로그를 갖추면 위험을 줄일 수 있다.
브라우저 도구는 왜 특히 조심해야 하나요?
브라우저는 외부의 신뢰할 수 없는 콘텐츠를 렌더링한다. 그 브라우저가 로컬 제어면, WebSocket, MCP 서버, 내부망에 닿을 수 있으면 외부 페이지가 에이전트를 경유해 로컬 권한을 건드릴 수 있다. AutoJack이 보여준 큰 교훈이 이 지점이다.
검색 질의를 줄이면 업무 정확도가 떨어지지 않나요?
무조건 줄이는 것이 목표가 아니다. 공개 사실을 찾는 데 필요한 질의는 유지하되 내부 고객명, 수치, 날짜, 코드명처럼 추론 단서가 되는 값을 제거하는 것이 핵심이다. 필요한 결합은 외부 검색 뒤 로컬 단계에서 수행한다.
파일럿 성과는 어떤 지표로 봐야 하나요?
정확도, 처리 시간, 사람이 수정한 비율만 보면 부족하다. 외부 질의 민감값 노출 수, mosaic 복원 가능성, 차단된 도구 호출 수, 승인 대기 건수, 작업당 비용, 로그 접근 이벤트를 같이 봐야 한다.
출처와 확인일
- Hugging Face / ServiceNow Research — MosaicLeaks: Can your research agent keep a secret? (확인일: 2026-06-23)
- Microsoft Security Blog — AutoJack: How a single page can RCE the host running your AI agent (확인일: 2026-06-23)
- OWASP GenAI Security Project — OWASP Top 10 for Large Language Model Applications (확인일: 2026-06-23)
- NIST — AI Risk Management Framework (확인일: 2026-06-23)
- Anthropic Engineering — Building Effective AI Agents (확인일: 2026-06-23)
이 글은 일반적인 IT 보안·운영 판단 가이드다. AI 에이전트 프레임워크, MCP 구현, 브라우저 도구, 모델 공급자의 보안 기능과 가격 정책은 계속 바뀔 수 있다. 실제 배포 전에는 공식 문서, 조직의 개인정보·보안 정책, 법무 검토, 침투 테스트, 로그 보존 기준을 다시 확인해야 한다. 네이버 검색 수요는 후보 선정용으로만 사용했고 본문 출처로 쓰지 않았다.
댓글
댓글 쓰기