오늘날 프로덕션에서 실행되는 대부분의 자율 에이전트는 이름, 이메일, 주민등록번호, 결제 데이터 같은 원본 PII를 토큰화나 감사 추적 없이 서드파티 MCP 툴 서버로 그대로 전달한다. 해결책은 정책 메모가 아니다. 에이전트와 모든 외부 툴 사이에 위치해, 데이터가 경계를 벗어나기 전에 토큰화하고 모든 접촉을 불변 원장에 기록하는 인터셉션 계층이 해결책이다. VeriSwarm Guard가 이를 처리하는 방식이 바로 이것이다.
AI 에이전트를 위한 PII 보호란 에이전트가 거치는 데이터 경로——프롬프트 입력, LLM 컨텍스트, MCP 툴 호출, 서드파티 서비스, 발신 응답——를 통해 개인 식별 정보가 유출되는 것을 막으면서도, 툴이 해당 데이터로 유용한 작업을 계속 수행할 수 있도록 하는 관행이다. 이는 LLM 입력 편집(redaction)의 상위 개념으로, 프로덕션에서 가장 큰 피해를 주는 유출 지점은 LLM 자체가 아니라 LLM이 호출을 결정한 이후의 툴 호출이다.
전형적인 에이전트 워크플로는 이렇다. 사용자가 이름, 이메일, 전화번호, 신용카드 정보를 입력한다. LLM이 이를 처리한다. 그런 다음 에이전트는 캘린더 API, CRM, 결제 프로세서 같은 툴을 호출하고, 그 데이터를 MCP를 통해 평문으로 전달한다. MCP 사양은 본질적으로 사용자 컨텍스트를 담지 않으며, 툴 서버는 사용자를 구분하거나 사용자별 제어를 적용할 수 없다. PII, 자격 증명, 재무 데이터 등 모든 데이터 카테고리가 기본값 상태에서 단일 워크플로 안에서 기계 속도로 외부에 전달될 수 있다.
이 격차를 메우는 단계별 메커니즘은 AI 에이전트 데이터 유출을 방지하는 방법을 참고하라.
2026년의 수치는 그리 자랑스럽지 않다.
데이터 손실 방지(DLP)는 사람이 파일을 복사하고 이메일을 보내던 세상을 위해 설계되었다. 에이전트의 툴 호출은 DLP가 의존하는 모든 전제를 깨뜨린다.
에이전트는 분당 수백 건의 툴 호출을 수행할 수 있다. 기존 DLP 검사는 자동화의 목적을 무력화하는 병목이 되지 않는 한 이 속도를 따라잡을 수 없다.
DLP 정책은 알려진 채널을 통한 저장 데이터 또는 전송 중 데이터를 분류한다. MCP 툴 호출은 동적이고 프로그래밍적이며, 보안팀이 존재조차 모를 수 있는 엔드포인트를 거친다.
패턴 매칭은 알려진 형식(카드 번호, 주민등록번호)은 포착하지만, 병력 정보처럼 컨텍스트에 의존하는 PII나 여러 토큰에 걸쳐 분산된 식별자는 놓친다. 구조화된 데이터에 대한 NER이 필요한 지점이 바로 여기다.
실제로 작동하는 아키텍처는 에이전트와 그 툴 사이에 위치한 런타임 인터셉션 계층이다. Guard Proxy가 바로 그 위치에 자리한다. Presidio(마이크로소프트의 오픈소스 NER 엔진)는 이름, 이메일, 전화번호, 주민등록번호, 신용카드, IP 주소, 금융 및 정부 발급 ID 번호(은행 계좌, 운전면허증, 여권)와 같은 PII 카테고리를 툴 호출이 경계를 벗어나기 전에 탐지하고 토큰화한다. 툴 서버가 보게 되는 것은 [PERSON_1]이며, “Jane Smith”가 아니다. LLM은 토큰을 바탕으로 추론한다. 원래 값은 인가된 사용자에게 전달되는 최종 응답에서만 복원된다. 이는 사후 스캔이 아니라 인라인 변환이다.
트랜스포머 파이프라인은 고정된 순서로 4개의 내장 트랜스포머를 실행한다——먼저 PII 토큰화, 그다음 컨텍스트 주입, 필드 마스킹, 스키마 검증 순이다. 각 트랜스포머가 무엇을 하는지, 무엇이 이를 트리거하는지, 커스텀 트랜스포머를 어떻게 추가하는지에 대한 전체 설명은 Guard Proxy의 네 가지 트랜스포머: 각각 무엇을, 어떤 순서로 가로채는가에 있다.
세 가지 배포 모드(클라우드 호스팅, 온프레미스 Docker, 로컬 stdio)는 “에이전트를 URL 하나에 연결하라”부터 “데이터가 VPC를 절대 벗어나지 않는다”까지 전체 범위를 아우른다.
토큰화는 가명처리이지 익명화가 아니다. GDPR 제4조(5)항에 따르면, 가명처리된 데이터는 여전히 개인 데이터다——토큰과 조회 테이블을 결합하면 개인을 재식별할 수 있으며, 조회 테이블이 없더라도 여러 토큰화된 필드를 결합해 신원을 드러낼 수 있다. 즉, Guard로 토큰화된 페이로드도 여전히 GDPR의 적용 범위 안에 있으며, 요구되는 통제 방식만 달라질 뿐이다.
실무적으로 토큰화는 노출 발생 시의 영향 범위를 줄이고, 제32조가 요구하는 “최신 기술 수준”의 통제를 입증한다——하지만 정보주체의 권리, 침해 통지 의무, 처리 활동 기록 요건을 없애지는 못한다. 토큰화가 PII를 “더 이상 개인 데이터가 아니게” 만든다고 주장하는 벤더는 잘못 알고 있거나, 무언가를 팔려는 것이다. 우리는 그렇지 않다.
모든 PII 인터셉션은 Vault의 해시 체인 원장에 기록된다——무엇이 전송되었는지, 무엇이 토큰화되었는지, 무엇이 반환되었는지, 언제, 어떤 에이전트 아이덴티티로, 어떤 툴에 대해서인지까지. 감사자가 “이 고객의 데이터가 어디로 갔는가?”라고 물으면, 답은 모니터링 도구의 스크린샷이 아니라 암호학적으로 검증 가능한 타임라인이다. 체인 검증은 변조를 탐지하며, 내보내기는 GDPR 제30조의 처리 활동 기록 요건에 직접 대응한다.
체인 검증이 실패하는 날을 위한 런북——엔드포인트, 응답 형식, 조사 단계——은 Vault 체인 검증하기: 무결성이 깨지는 날을 위한 런북에 있다.
헬스케어는 에이전트-툴 경계에서 PII 보호가 가장 까다롭게 요구되는 사용 사례다. 2025년 OCR 집행 기록을 보면 위험 분석 관련 지적 사항이 3:1의 비율로 합의 사건을 지배하며, 평균 벌금은 약 291,000달러이고 여기에 2년간의 모니터링 의무가 추가된다. Guard의 토큰화, Vault의 원장, 에이전트 수준의 스코어링 루프가 결합되어 이러한 감사를 견뎌내는 태세를 만든다——이는 헬스케어 버티컬 서피스에 통합되어 있으며, HIPAA에 부합하는 기본값이 기본적으로 활성화되어 있다.
토큰이다. Guard Proxy는 인터셉션 경계에서 PII를 토큰화한다——이름, 이메일, 전화번호, 주민등록번호, 신용카드, IP 주소, 금융 및 정부 발급 ID 번호(은행 계좌, 운전면허증, 여권)를 포함해서다——그리고 LLM은 토큰을 바탕으로 추론한다. 툴 서버는 토큰을 받는다. 원래 값은 인가된 사용자에게 전달되는 최종 응답에서만 복원되며, 그 하류의 어떤 곳도 평문을 보지 못한다.
이 매핑은 테넌트의 Guard Proxy 배포 내부에 존재하며, 토큰화된 페이로드와 함께 네트워크로 전송되는 일은 결코 없다. 클라우드 호스팅 모드에서는 테넌트 전용 암호화 뒤에 위치하고, 온프레미스 Docker 모드에서는 네트워크를 절대 벗어나지 않는다. 토큰 형식은 그 키로만 되돌릴 수 있으므로, 가로챈 툴 호출이 유출하는 것은 토큰일 뿐, 그 뒤에 있는 값이 아니다.
이는 통제 수단 중 하나다. 툴 호출 경계에서의 토큰화는 PHI를 LLM 컨텍스트에서, 그리고 직접 통제할 수 없는 MCP 툴 서버에서 배제하고, Vault의 해시 체인 원장에 기록해 데이터 흐름 기록이 감사를 견디도록 한다. 완전한 HIPAA 대응 태세를 갖추려면 하류 툴 서버와의 BAA, 에이전트 자체에 대한 서명된 매니페스트(Passport), 그리고 침해 대응을 둘러싼 운영 프로세스도 필요하다. 런타임 토큰화는 가장 큰 기술적 격차를 메우며, 나머지는 서류 작업과 운영의 문제다.
편집은 값을 파괴한다(비가역적)——텔레메트리와 로그에는 적합하지만, 툴이 기능을 위해 그 데이터를 필요로 하는 경우에는 쓸모가 없다. 마스킹은 부분적으로 가린다(카드의 마지막 4자리 등)——사람이 읽는 화면에 적합하다. 차단은 호출 자체를 완전히 막는다——중대한 정책 위반에 적합하다. 토큰화는 비밀을 제거하면서도 유용성을 보존한다——넷 중 유일하게 툴 서버가 원래 값을 보지 않고도 유용한 작업을 계속할 수 있는 방식이다. Guard는 이 네 가지를 모두 지원하며, 선택은 데이터 카테고리와 정책별로 이루어진다.
그렇다——그것이 주된 활용 영역이다. Guard Proxy는 세 가지 배포 모드(클라우드 호스팅, 온프레미스 Docker, 로컬 stdio)를 갖춘 투명한 MCP 인터셉션 계층이다. 에이전트의 MCP 클라이언트는 툴 서버에 직접 연결하는 대신 Guard Proxy에 연결한다. Guard Proxy는 PII를 제외한 호출을 전달하고 응답을 반환한다. 에이전트 코드 변경은 필요 없다.
그렇다——동일한 토큰화 메커니즘이 둘 다를 처리한다. 개인 데이터 외에도, 탐지기는 GitHub 토큰, OpenAI 키, AWS 키, Slack 토큰, GCP 키, Stripe 키, JWT, 개인 키 블록 같은 자격 증명 형식을 인식하고, 이름이나 주민등록번호를 토큰화하는 것과 동일한 방식으로 토큰화한다. 툴 호출로 향하던 중 유출된 API 키는 경계를 벗어나기 전에 가로채지며, 유출된 주민등록번호만 그런 것이 아니다.
토큰은 설정 가능한 TTL——기본값은 한 시간——이 지나면 만료되며, 특정 테넌트와 세션으로 범위가 제한되어 한 대화를 위해 발급된 토큰을 다른 대화에서 재사용할 수 없다. 원래 값은 저장 시 암호화되며(대칭형 Fernet 암호화), 평문으로의 재수화(rehydration)는 매번 감사를 위해 기록된다. 토큰이 단독으로 유출되더라도 암호화 키와 활성화된 범위 지정 세션이 모두 없다면 무용지물이다.
전체 구조를 순회한다. Guard의 토크나이저는 툴 호출의 인자——그리고 응답 본문——안에 있는 모든 dict와 list를 재귀적으로 순회하므로, `data.customer.email`처럼 깊숙이 묻혀 있거나 레코드 목록 안에 있는 PII도 최상위 필드와 동일하게 토큰화된다. 이전 버전은 최상위 수준만 검사했기 때문에, 전형적인 MCP 페이로드 형태에 중첩된 PII가 편집되지 않은 채 통과할 수 있었다——이 격차는 중대한 수정 사항으로 해결되었다.
Guard Proxy는 에이전트 코드를 전혀 변경할 필요가 없다. MCP 클라이언트를 툴 서버 대신 Guard Proxy로 연결하기만 하면 된다. Guard Proxy는 PII를 제외한 호출을 전달하고 응답을 반환한다. Gate의 무료 등급은 먼저 인벤토리와 이벤트 흐름에 대한 가시성을 제공한다——해결책을 켜기 전에 문제를 먼저 확인할 수 있도록.