저는 프로덕션 로그에서 이런 일이 발생하는 것을 한두 번 본 것이 아닙니다. MCP를 통해 데이터베이스나 제3자 API에 접근 권한을 부여받은 AI 에이전트가 요청된 데이터뿐만 아니라 세션 토큰(session token), AWS 비밀 키(AWS secret), 또는 모호한 API 키(API key)가 포함된 페이로드를 반환하는 경우입니다. 이 고엔트로피(high-entropy) 문자열이 이제 LLM 제공업체의 로그에 남아 있고, 잠재적으로 학습 데이터 세트의 일부가 되며, 채팅 기록에 접근할 수 있는 모든 사람에게 노출될 수 있다는 사실을 깨닫기 전까지는 이는 사소한 실수처럼 느껴집니다.

문제는 단순히 데이터 그 자체에 있는 것이 아니라, 우리가 도구 출력(tool outputs)을 처리하는 방식에 있습니다. MCP 서버를 구축할 때, 우리의 본능은 도움이 되는 것입니다. 즉, LLM이 작업을 완료하는 데 필요한 모든 것을 반환하려고 합니다. 하지만 에이전트에게 시스템에 대한 '읽기(read)' 권한을 부여하는 순간, 여러분은 사실상 해당 시스템의 민감한 메타데이터(metadata)를 들여다볼 수 있는 창을 여는 것과 같습니다.

정규 표현식(regex)을 사용하여 이 문제를 해결하려고 시도할 수 있습니다. 사회보장번호(SSN), 이메일, 또는 Stripe나 AWS와 같은 일반적인 API 키 형식에 대한 패턴을 작성할 수 있습니다. 이는 결정론적(deterministic) 데이터에는 효과적이며, PII Redaction Deterministic Scrubber와 같은 도구들이 이를 충분히 잘 처리합니다. 하지만 비밀 정보(secrets)는 근본적으로 다릅니다. 그것들은 고정된 스키마(schema)를 따르지 않습니다. 개발자가 어제 여러분의 정규 표현식 라이브러리에서 고려하지 않았던 형식으로 인증 토큰(auth token)을 교체할 수도 있습니다.

이 지점에서 우리는 결정론적 패턴 매칭(deterministic pattern matching)에서 확률적 탐지(probabilistic detection)로 넘어가야 합니다. 문자열 자체의 무작위성(randomness)을 살펴봐야 합니다.

저는 최근에 이러한 고엔트로피 세그먼트(high-entropy segments)가 LLM 컨텍스트 윈도우(context window)에 도달하기 전에 포착하도록 특별히 설계된 MCP 서버인 Tool Output Entropy Sanitizer를 사용하여 작업하기 시작했습니다. 이 도구는 비밀 정보가 어떻게 _생겼는지_는 상관하지 않습니다. 대신 텍스트의 특정 세그먼트에 얼마나 많은 정보 밀도(information density)가 압축되어 있는지를 확인합니다.

로직: 보안 프리미티브(Security Primitive)로서의 샤논 엔트로피 (Shannon Entropy)

이곳의 핵심 엔진은 샤논 엔트로피 (Shannon entropy) 계산을 사용합니다. 익숙하지 않으시다면, 이 문맥에서 엔트로피는 문자열 내의 예측 불가능성 또는 무작위성 (randomness)을 측정합니다. 표준적인 영어 문장은 특정 문자나 패턴(예: 'the', 'and', 공백)이 예측 가능한 빈도로 나타나기 때문에 상대적으로 낮은 엔트로피를 가집니다. 반면 API 키나 base64로 인코딩된 비밀 정보는 거의 순수한 노이즈에 가깝습니다. 이러한 정보는 문자 분포가 매우 균일하여 엔트로피 점수를 높입니다.

서버는 4.5라는 임계값 (threshold)을 기준으로 작동합니다. 텍스트를 스캔할 때, 슬라이딩 윈도우 (sliding-window) 분석을 사용하여 이 제한을 초과하는 세그먼트를 식별합니다. 단순히 전체 문자열을 한꺼번에 확인하는 것이 아닙니다. 엔트로피가 낮은 긴 이메일 뒤에 엔트로피가 높은 키가 하나 붙어 있는 경우, 전체를 한꺼번에 확인하는 방식은 무용지물이기 때문입니다. 입력값 전체에 걸쳐 윈도우를 슬라이딩함으로써, 무작위성이 급증하는 정확한 지점을 찾아낼 수 있습니다.

sanitize_text_output 도구를 사용하면, 정제된 텍스트와 무엇이 삭제되었는지에 대한 메타데이터 (metadata)를 반환합니다. 엔지니어들이 대개 높게 평가하는 세부 사항 중 하나는 삭제 (redaction) 자체를 처리하는 방식입니다. 단순히 문자를 삭제해 버리면 LLM을 위한 구조적 문맥 (structural context)이 파괴되는데, 이 도구는 대신 세그먼트를 [REDACTED_HIGH_ENTROPY:length]와 같은 구조화된 패턴으로 대체합니다. 이는 에이전트에게 "여기에 무언가가 있었고, 그 길이는 이 정도였다"라고 알려줌으로써, 모델이 민감한 페이로드 (payload)를 실제로 보지 않고도 주변 텍스트에 대한 추론을 유지할 수 있게 합니다.

구현 제약 사항 (Implementation Constraints)

프로덕션급 (production-grade) 도구 세트를 구축할 때는 예외 케이스 (edge cases)를 다뤄야 합니다. 윈도우 크기를 무한대로 설정할 수는 없습니다. 윈도우가 너무 작으면 패턴을 놓치게 되고, 너무 크면 엄청난 지연 시간 (latency)을 유발하며 잠재적으로 오탐 (false positives)을 일으키는 낮은 엔트로피의 노이즈까지 포함하게 됩니다.

서버는 엄격한 운영 경계(operational bounds)를 강제합니다. 제안된 모든 윈도우 크기는 16자에서 64자 사이여야 합니다. 배포 전에 설정을 감사(audit)하려면 verify_window_bounds 도구를 사용할 수 있습니다. 이는 단순히 오류를 방지하기 위한 것이 아닙니다. 지연 시간 급증(latency spikes)이 전체 오케스트레이션 계층(orchestration layer)을 망가뜨릴 수 있는 에이전트 루프(agentic loop) 내에서 예측 가능한 성능을 보장하기 위함입니다.

내용을 수정하지 않고 특정 서브스트링(substring)을 감사해야 하는 경우—예를 들어 디버깅 세션 중이거나 감사 목적인 경우—evaluate_segment_entropy 도구를 통해 엔트로피 점수(entropy score)와 고엔트로피 플래그(high-entropy flag)를 직접 확인할 수 있습니다. 이는 임계값(threshold) 설정을 미세 조정(fine-tune)하려고 할 때 유용합니다.

이 서버의 전체 구현체는 다음에서 확인할 수 있습니다: https://vinkius.com/mcp/tool-output-entropy-sanitizer

보안 파이프라인으로의 통합

MCP에서의 보안은 사후 고려 사항이나 단일 장벽이 되어서는 안 됩니다. 이는 일련의 점검 과정이어야 합니다. 만약 제가 민감한 CRM 데이터에 접근하는 에이전트 워크플로우(agentic workflow)를 구축한다면, 저의 파이프라인은 다음과 같습니다:

1. 결정론적 스크러빙 (Deterministic Scrubbing): 정규 표현식(regex) 기반 도구를 사용하여 알려진 패턴(이메일, IBAN 등)을 제거합니다.
2. 엔트로피 정화 (Entropy Sanitization): 출력을 Entropy Sanitizer에 통과시켜 첫 번째 단계에서 빠져나간 '알려지지 않은 미지의 것들(unknown unknowns)', 즉 고밀도 문자열을 잡아냅니다.
3. 거버넌스 및 샌드박싱 (Governance & Sandboxing): 실행 컨텍스트(execution context) 자체가 격리되어 있는지 확인합니다. 이것이 Vinkius에서 모든 MCP를 실행 컨텍스트에 DLP 및 SSRF 방지 같은 특정 정책이 내장된 격리된 V8 샌드박스(sandboxes)에서 실행하는 이유입니다.

목표는 LLM을 "맹목적(blind)"으로 만드는 것이 아니라, "자격 증명에 노출되지 않으면서 컨텍스트를 인식(context-aware)하게" 만드는 것입니다.

이것이 에이전트의 미래에 중요한 이유

Salesforce, GitHub 또는 WhatsApp Business에서 작업을 실행할 수 있는 더 자율적인 에이전트(autonomous agents)로 나아감에 따라, 실수로 인한 데이터 유출(data leakage)의 표면적(surface area)은 기하급수적으로 증가합니다. 우리는 단순한 '채팅(chat)'을 넘어 '행동(action)'의 단계로 이동하고 있습니다. 모든 도구 호출(tool call)은 잠재적인 유출 벡터(leak vector)가 됩니다.

만약 여전히 수동 감독이나 기본적인 정규 표현식(regex)에 의존하고 있다면, 너무 많은 것을 운에 맡기고 있는 것입니다. 엔트로피 기반 탐지(entropy-based detection) 계층을 구현하면 에이전트가 리스크(liabilities)가 되지 않으면서도 강력한 성능을 발휘할 수 있게 합니다. 이는 문제를 "어떻게 하면 에이전트가 비밀 정보를 보지 못하게 할까?"에서 "비밀 정보가 어떻게 생겼는지 어떻게 수학적으로 정의할 것인가?"로 전환시킵니다.

이는 정규 표현식(regex)보다 어려운 문제이지만, 에이전트의 역량을 확장하는 속도와 동일한 속도로 보안을 확장할 수 있는 유일한 방법입니다.

MCP는 AI 에이전트의 음악입니다. 저희가 카탈로그를 구축했습니다. Vinkius MCP Catalog를 확인해보세요.