Pipelock이 인바운드 WAF가 아닌 이그레스 에이전트 방화벽인 이유

방화벽이라는 단어 뒤에 숨겨진 질문

보안 팀은 "방화벽 (firewall)"이라는 말을 들으면 인바운드 (inbound) 형태를 떠올립니다. 방화벽, WAF (Web Application Firewall), 또는 IPS (Intrusion Prevention System)는 서비스 앞에 위치합니다. 트래픽은 외부 세계로부터 보호받는 앱을 향해 들어옵니다. 제어 장치는 요청이 앱에 도달하기 전에 검사하여 문 앞에서 악성 페이로드 (payload)를 차단합니다.

이것은 외부에서 내부로 향하는 보호 (outside-in protection) 방식입니다. 이는 많은 공격이 식별 가능한 요청 형태를 갖는 웹 애플리케이션에 적합합니다: SQL 인젝션 (SQL injection), 교차 사이트 스크립팅 (cross-site scripting), 알려진 익스플로잇 시그니처 (exploit signatures), 또는 잘못된 프로토콜 동작 등이 그것입니다. 웹 서버는 공격을 받는 대상이며, 공격자는 그곳으로 요청을 보냅니다.

AI 에이전트 (AI agents)는 그 모델을 뒤집습니다. 에이전트는 단순히 입력을 받는 서버가 아닙니다. 에이전트는 외부 콘텐츠를 읽고, 도구 (tools)를 호출하며, HTTP 요청을 보내고, MCP (Model Context Protocol) 서버를 호출하며, 자격 증명 (credentials)을 가지고 실행됩니다. 위험한 이벤트는 적대적인 패킷이 에이전트에 도달하는 경우가 거의 아닙니다. 위험한 이벤트는 에이전트가 외부 효과 (outbound effects)를 동반하는 무언가를 하도록 유도되는 것입니다.

이것이 바로 Pipelock이 WAF 스타일의 인바운드 방화벽이 아닌, 이그레스 에이전트 방화벽 (egress agent firewall)으로 구축된 이유입니다.

왜 인바운드 필터링이 잘못된 주요 모델인가

프롬프트 인젝션 (Prompt injection)은 구조화된 멀웨어 (malware) 패킷처럼 동작하지 않습니다. 그것은 에이전트가 읽어야 하는 위치에 놓인 자연어 지시 사항입니다: 웹 페이지, 티켓, 검색 결과, 도구 응답, MCP 서버 응답, 또는 사용자 메시지 등이 해당됩니다. 채널은 합법적입니다. 구문 (syntax)은 종종 정상적입니다. 공격은 의미론적 (semantic)이며 문맥 의존적 (context-dependent)입니다.

에이전트에 도달하기 전 모든 입력을 필터링하여 이 문제를 해결하려는 시도는 열거 (enumeration) 문제로 변질됩니다. "이전 지침을 무시하세요 (ignore previous instructions)"와 같은 패턴을 작성하면, 공격자는 이를 다시 표현합니다. 하나의 포맷팅 트릭을 차단하면, 지침이 여러 단락에 걸쳐 나뉘거나, 인용문 안에 숨겨지거나, 인코딩되거나, 정책 텍스트로 위장됩니다. 알려진 문구들을 잡아내는 것은 가치가 있으며, Pipelock은 자신이 중재하는 콘텐츠 내의 알려진 인젝션 마커 (injection markers)를 잡아내지만, 입력 필터링 (input filtering)이 보안 모델의 중심이 될 수는 없습니다.

결론은 냉혹합니다. 인바운드 (inbound) 콘텐츠를 검사하되, 모델이 확인하기 전에 모든 적대적 지침을 인식하는 것에 보안 모델을 걸지는 마십시오.

이그레스 제어 (Egress control): 결과로부터 보호하기

Pipelock의 더 강력한 경계는 이그레스 제어 (egress control)입니다. 모든 나쁜 지침이 들어오는 길에 차단될 수 있다고 가정하는 대신, Pipelock은 나가는 길에 발생하는 해로운 효과에 집중합니다.

프롬프트 인젝션 (prompt injection)은 다음과 같은 외부 결과 (outbound consequence)를 생성할 때 문제가 됩니다: 비밀 정보 유출, 169.254.169.254와 같은 클라우드 메타데이터 엔드포인트 (cloud metadata endpoint) 접속, 공격자가 제어하는 서버로 데이터 POST 전송, 파괴적인 도구 호출, 또는 MCP 서버로 안전하지 않은 도구 인자 (tool arguments) 전송. 만약 에이전트가 해로운 동작을 수행할 수 없다면, 인젝션은 실질적인 효과를 상실합니다.

짧은 요약: 들어오게 하되, 나가게 하지는 마십시오.

이그레스 제어 (egress control)에서 가장 지속 가능한 부분은 목적지 및 동작 확인 (destination-and-action check)입니다. 공격자는 프롬프트 인젝션 (prompt injection)을 끊임없이 재구성할 수 있습니다. 하지만 목적지를 재구성하는 것은 훨씬 더 어렵습니다. 링크 로컬 메타데이터 주소 (link-local metadata address), 블랙리스트에 등록된 도메인 (blocklisted domain), 또는 거부된 도구 (denied tool)에 도달하려는 요청은 가장 위장하기 어려운 패턴, 즉 동작이 어디로 향하는지(where the action is going)와 무엇을 수행하려 하는지(what it is asking to do)에 의해 차단됩니다. 나가는 경로에서의 콘텐츠 검사 (Content inspection, 예: 요청 본문에 포함된 비밀 정보를 위한 DLP)는 도움을 주는 두 번째 계층이지만, 인바운드 스캐닝 (inbound scanning)과 동일한 회피 압박에 직면합니다. 공격자는 인젝션을 재구성하는 것과 동일한 방식으로 유출되는 비밀 정보를 인코딩하거나 분할할 수 있습니다. 따라서 목적지 및 동작 정책 (destination-and-action policy)이 핵심적인 역할을 수행하며, 콘텐츠 DLP (content DLP)가 이를 뒷받침합니다.

입력 필터링 (Input filtering)은 "해를 끼칠 수 있는 모든 명령을 인식할 수 있는가?"라고 묻습니다. 반면 이그레스 제어 (Egress control)는 "이 동작이 경계를 넘는 것이 허용되는가?"라고 묻습니다. 두 번째 질문이 더 좁고, 구체적이며, 보안 팀이 방지해야 하는 필요 사항에 더 가깝습니다.

출구 경비원 비유 (The exit-guard analogy)

인바운드 필터 (inbound filter)는 정문에서 모든 사람을 몸수색하며 무기를 찾는 경비원과 같습니다. 무기가 금속 물체라면 이 방식이 효과적입니다. 하지만 에이전트 (agent)에게 무기는 속삭이는 명령이며, 사기꾼은 말이 칼처럼 보이지 않는다는 점을 이용해 안내 데스크를 말로 통과합니다.

Pipelock은 경비원을 출구에 배치하여 누군가 밖으로 가지고 나가려는 것이 무엇인지 확인합니다.

사기꾼은 말로 침입하여 직원에게 파일을 집어 들도록 설득할 수 있습니다. 하지만 그는 여전히 서류 가방을 문 밖으로 가지고 나가야 합니다. 출구에서 경비원은 결과 (consequence)를 확인합니다. 즉, 무엇이 나가고 있는지, 어디로 가는지, 그리고 정책이 이를 허용하는지를 확인합니다.

현재 Pipelock이 인바운드에서 검사하는 것

Pipelock은 인바운드 콘텐츠를 보지 못하는 것이 아닙니다. Pipelock은 중재된 경로 (mediated paths)를 통해 에이전트의 컨텍스트 (context)로 흘러 들어가는 콘텐츠를 검사합니다.

HTTP 스타일의 fetch (가져오기)의 경우, fetch 프록시 (proxy)는 에이전트가 콘텐츠를 소비하기 전에 가져온 응답 콘텐츠 내의 프롬프트 인젝션 (prompt injection)을 스캔합니다. MCP의 경우, Pipelock은 도구 결과 (tool results)와 도구 메타데이터 (tool metadata)를 스캔하여 인젝션 및 도구 오염 (tool-poisoning) 패턴을 탐지합니다. 오염된 응답은 나중에 유출을 유발하는 지침 (instruction)이 될 수 있으므로, 이러한 경로에서는 인바운드 (inbound) 측면이 중요합니다.

이는 전형적인 인바운드 요청 WAF (inbound-request WAF)와는 다릅니다. Pipelock은 임의의 인터넷 클라이언트가 에이전트가 호스팅하는 웹 엔드포인트 (web endpoint)로 요청을 보내고 Pipelock이 해당 요청의 서비스 도달 여부를 결정하는, 서비스 전면 필터 (service-fronting filter)로 위치하지 않습니다. 핵심 위협 모델 (threat model)은 에이전트 이그레스 (agent egress) 및 도구 트래픽 (tool traffic)입니다.

공개 웹 앱을 운영한다면 WAF, 인증 (auth), 속도 제한 (rate limits), 요청 검증 (request validation), 애플리케이션 계층 권한 부여 (app-layer authorization), 그리고 남용 처리 (abuse handling)와 같은 웹 제어 장치가 여전히 필요합니다. Pipelock은 에이전트 측면, 즉 에이전트가 보내는 트래픽, 에이전트가 수행하는 도구 호출 (tool calls), 그리고 중재된 경로 (mediated paths)를 통해 컨텍스트 (context)로 가져오는 응답을 보호합니다.

기능 분리 및 중재된 트래픽의 주의사항

깔끔한 Pipelock 배포 방식은 기능을 분리합니다. 에이전트 환경은 비밀 정보 (secrets)를 보유하고 유용한 작업을 수행하지만, 직접적인 네트워크 이그레스 (network egress)를 가져서는 안 됩니다. Pipelock은 네트워크 이그레스를 가지지만, 에이전트의 비밀 정보를 보유해서는 안 됩니다. 인터넷 및 MCP 서버로 향하는 의도된 경로는 정책이 집행되는 Pipelock을 통과합니다.

이러한 구조가 제공하는 이점은 두 가지 제한 사항에 의해 정의됩니다.

첫째, 보호 범위는 중재된 트래픽 (mediated traffic), 즉 실제로 Pipelock을 통해 라우팅되는 트래픽에 한정됩니다. 만약 HTTP 요청, WebSocket 프레임 (frame), MCP 호출, 또는 도구 결과가 Pipelock을 통과하지 않는다면, Pipelock은 이를 검사하거나 차단할 수 없습니다.

콘텐츠 가시성 (Content visibility) 또한 이 문제의 일부입니다. Pipelock은 본문 (body)을 볼 수 있을 때만 요청 본문을 스캔합니다. 즉, fetch 엔드포인트, 평문 포워드 프록시 (plaintext forward-proxy) 트래픽, 또는 TLS 인터셉션 (TLS interception)이 활성화된 CONNECT 터널의 경우에만 가능합니다. 인터셉션이 없는 일반 CONNECT 터널에서는 Pipelock이 목적지 호스트는 볼 수 있지만 암호화된 본문은 볼 수 없으므로, 해당 경로에서는 본문 DLP (Data Loss Prevention) 대신 목적지 정책 (destination policy)을 강제합니다. CONNECT 트래픽에서 본문 및 응답 스캔을 수행하려면 TLS 인터셉션을 활성화하십시오.

둘째, Pipelock을 우회하는 직접적인 이그레스 (egress) 차단은 바이너리 (binary) 자체의 속성이 아니라 배포 (deployment) 단계에서 강제되는 사항입니다. Pipelock 바이너리는 자신이 중재 (mediate) 하는 트래픽에 대해서만 정책을 강제합니다. 바이너리 스스로가 호스트 네트워크를 재배선하여 모든 프로세스가 반드시 자신을 통과하도록 강제하지는 않습니다. 운영자는 컨테이너 네트워킹 (container networking), Kubernetes NetworkPolicy, 방화벽 규칙 (firewall rules), 또는 Pipelock 자체의 containment 명령을 통해 이를 강제합니다.

Linux의 경우, pipelock contain install 명령이 이를 직접 설정합니다. 이 명령은 별도의 권한이 낮은 에이전트 사용자 (low-privilege agent user)를 생성하고 nftables owner-match 규칙을 설치하여, 에이전트가 네트워크로 나가는 유일한 경로가 Pipelock 프록시가 되도록 합니다. 해당 사용자의 직접적인 이그레스는 커널 (kernel) 단계에서 드롭 (drop) 되며, pipelock contain verify를 통해 규칙이 활성화되었는지 확인할 수 있습니다. 이를 통해 격리된 사용자 (contained user)에 대해 "트래픽이 Pipelock을 통과해야 한다"는 상태를 "트래픽이 Pipelock을 통해서만 통과할 수 있다"는 상태로 전환합니다. 이는 여전히 사용자가 실행해야 하는 배포 단계이며, 바이너리가 호스트에 스스로 수행하는 작업이 아닙니다.

이러한 구분이 바로 보안 모델 (security model)입니다. 바이너리에 의해 강제되는 제어 (Binary-enforced controls)는 중재된 경로 (mediated path) 상에서 적용됩니다. 직접 이그레스 방지 (Direct-egress prevention)는 에이전트가 어떻게 실행되는지에 달려 있습니다.

향후 인바운드 (inbound)가 적용될 수 있는 부분

호스팅되거나 멀티 테넌트 (multi-tenant) 에이전트 배포 환경에서는 향후 인바운드 요청 필터링 (inbound request filtering)이 도입될 합리적인 형태가 존재합니다. 에이전트 엔드포인트를 네트워크 서비스로 노출하는 조직은 일반적인 API 보안과 에이전트 전용 컨텍스트 검사 (context checks), 서명된 중재자 헤더 (signed mediator headers), 그리고 테넌트 격리 (tenant isolation)를 결합한 에이전트 전용 인바운드 승인 계층 (admission layer)을 추가할 수 있습니다.

그것은 Pipelock의 핵심 모델을 대체하는 것이 아니라, 핵심 모델 옆에 위치하게 될 것입니다. 에이전트 방화벽 (agent firewall)을 배포하는 주요 이유는 여전히 이그레스 (egress) 문제입니다. 에이전트는 신뢰할 수 없는 콘텐츠를 읽고, 유용한 권한을 보유하며, 외부로 나가는 동작 (outbound actions)을 수행합니다. 가장 중요한 경계는 이러한 동작들이 에이전트 환경을 벗어나는 지점입니다.