east✦yul

AI 보안 에이전트는 어디서 트래픽을 잡는가: 브라우저 확장과 로컬 프록시

Check Point Workforce AI Security를 예로, 엔드포인트 AI 통제 제품이 프롬프트를 가로채는 두 지점과 각각의 한계를 정리했습니다.

  • AI Security
  • Endpoint
  • DLP
  • PAC

사내에서 ChatGPT나 Claude 사용을 통제하겠다고 하면 대부분 “차단하면 되는 거 아니냐”는 이야기부터 나옵니다. 도메인을 막는 건 쉽습니다. 어려운 건 허용하되 내용을 보는 것입니다. 프롬프트에 주민등록번호가 들어가는지, 사내 소스코드가 붙여넣기되는지를 판단하려면 그 텍스트를 실제로 읽어야 합니다.

엔드포인트 AI 보안 제품들은 이 문제를 두 개의 서로 다른 지점에서 풉니다. Check Point Workforce AI Security를 예로 구조를 뜯어보겠습니다.

두 개의 집행 지점

같은 정책을 브라우저 안에서 집행하느냐, 단말 네트워크 계층에서 집행하느냐의 차이입니다.

구분브라우저 확장로컬 프록시
집행 지점브라우저 렌더러 (DOM/JS 이벤트)단말 루프백 프록시 (127.0.0.1)
트래픽 유입확장이 페이지에 주입시스템 전역 PAC이 유도
커버 범위Chrome, Edge, Brave, Firefox브라우저 + 데스크톱 앱 + CLI + API 직호출
TLS 복호화불필요필수 (전용 루트 CA로 MITM)
탐지 대상입력 텍스트, 붙여넣기, 파일 첨부HTTP 요청·응답 바디
주요 실패 요인확장 미설치·비활성PAC 미적용, 루트 CA 미신뢰, 커널 필터 선점

브라우저 확장

브라우저가 AI 서비스 페이지를 열면 확장이 입력창과 paste·drop·submit 이벤트를 후킹합니다. 사용자가 프롬프트를 치거나 붙여넣는 순간 그 텍스트가 정책 엔진으로 넘어가고, 매칭되면 전송 전에 막습니다.

핵심은 네트워크로 나가기 전 단계라는 것입니다. 브라우저 메모리 안에서는 아직 평문이니 복호화가 필요 없습니다. 붙여넣기 자체를 막는 사전 통제도 이 계층에서만 가능합니다. 문맥 기반 탐지 기능이 Text Control이나 Paste 이벤트에서만 동작하는 제품이 많은 것도 같은 이유입니다.

한계는 명확합니다. 브라우저를 벗어나면 아무것도 못 봅니다. ChatGPT 데스크톱 앱, Cursor, 터미널에서 돌리는 CLI 도구는 전부 사각지대입니다.

로컬 프록시

에이전트가 단말에 프록시를 하나 띄우고, 시스템 전역 PAC으로 AI 도메인만 그쪽으로 보냅니다. PAC 구조는 단순합니다.

function FindProxyForURL(url, host) {
    if (
        shExpMatch(host, "api.openai.com") ||
        shExpMatch(host, "chatgpt.com") ||
        shExpMatch(host, "*.anthropic.com") ||
        shExpMatch(host, "claude.ai") ||
        // ... Copilot, Gemini, Perplexity, DeepSeek, Mistral 등
        shExpMatch(host, "chat.deepseek.com")) {

        return "PROXY 127.0.0.1:8080; DIRECT";
    }

    return "DIRECT";
}

프록시는 CONNECT를 받아 자체 루트 CA로 인증서를 재서명하고 TLS를 풉니다. 요청 바디를 검사해서 위반이면 세션을 끊고, 정상이면 상위로 릴레이합니다.

여기서 세 가지를 짚어야 합니다.

선별 인터셉트

PAC에 등재된 도메인만 프록시를 타고 나머지는 전부 DIRECT입니다. 사내 전 트래픽을 훑는 구조가 아니라서 일반 웹 성능에는 영향이 없습니다. 도입 심의에서 “모든 통신을 감청하는 것 아니냐”는 질문이 반드시 나오는데, 답은 여기 있습니다.

세미콜론 뒤의 DIRECT

PROXY 127.0.0.1:8080; DIRECT에서 뒤쪽 DIRECT는 폴백입니다. 프록시 프로세스가 죽거나 포트를 열지 못하면 브라우저는 조용히 직결로 빠집니다.

가용성을 우선한 설계이고 사용자 입장에서는 서비스가 안 끊기니 좋습니다. 다만 통제 실패가 사용자에게도 관리자에게도 즉시 드러나지 않는다는 뜻이기도 합니다. 감사 대응 시나리오를 쓸 때 이 구간을 어떻게 탐지할지 미리 정해두는 게 좋습니다.

PAC은 유저레벨이다

가장 실무적으로 아픈 지점입니다. PAC 기반 프록시 우회는 유저 공간에서 일어납니다. 같은 단말에 커널 레벨 필터 드라이버(WFP 콜아웃)를 쓰는 제품 — 국내 DLP 상당수가 여기 해당합니다 — 가 깔려 있으면, 그쪽이 먼저 소켓을 가로챕니다.

증상이 고약합니다. 프록시 프로세스는 정상 기동해 있고 포트도 열려 있고 하트비트도 살아 있는데, 특정 트래픽만 도달하지 않습니다. 리스너를 확인하면 다 정상이니 원인을 네트워크 계층에서 찾게 되고, 실제 원인은 훨씬 아래에 있습니다.

이런 조합 충돌을 만나면 리스너·포트가 아니라 패킷 필터 계층부터 의심하는 게 빠릅니다. 필터 드라이버 서비스를 비활성화했다가 원복하며 증상이 재현되는지 보는 A/B 테스트가 가장 확실합니다. 한 번 껐다 켜서 증상이 그대로 돌아오면 인과가 확정됩니다.

브라우저도 프록시도 아닌 것들

에이전틱 코딩 도구는 세 번째 계층입니다. Claude Code, Cursor, Codex 같은 도구는 브라우저가 아니고, 도메인 기반 PAC으로도 완전히는 잡히지 않습니다. MCP 서버를 경유하면 트래픽 모양 자체가 달라집니다.

그래서 제품들이 별도의 훅 스크립트와 MCP 통제 바이너리를 함께 배포합니다. 툴 호출 자체를 검사하는 방식입니다. 도입 검토 시 이 부분을 빠뜨리면, 정작 소스코드가 가장 많이 흘러나가는 경로가 통제 밖에 남습니다.

정리

확장과 프록시는 택일이 아니라 중첩 배치가 기본입니다. 확장만 쓰면 비브라우저 경로가 통째로 비고, 프록시만 쓰면 붙여넣기 차단 같은 사전 통제와 세밀한 UI 이벤트 판정이 빠집니다.

도입 검토 시 반드시 확인할 세 가지는 이렇습니다.

  1. 로컬 프록시의 MITM이 기존 SSL 인스펙션 장비나 DLP와 이중으로 걸리는 구간이 있는가
  2. PAC 폴백으로 통제가 우회되는 상황을 어떻게 탐지할 것인가
  3. 단말에 이미 깔린 커널 레벨 보안 제품과 선점 충돌이 나지 않는가

세 번째는 PoC 단계에서 반드시 실제 단말 조합으로 검증해야 합니다. 벤더 문서에는 나오지 않고, 국내 환경에서만 나타나는 조합이 대부분입니다.

← 글 목록으로