PolicyGuard: LLM 에이전트의 대화 기반 서브에이전트 검증기로서의 정책 준수 보장

기업 정책 준수는 단일 호출의 인수값 오류가 아니라 대화 전반에 걸친 절차적 전제와 사용자 확인을 충족하는 문제이다. 기존의 인수·구조 수준 가드들은 대화 문맥을 보지 않거나 패러프레이즈에 취약한 문자열 매칭에 의존하여 절차적 요구를 놓치는 경향이 있다. PolicyGuard는 전체 대화를 판독하고 정책을 문맥에 따라 추론하여 차단 시 구체적 보완 메시지를 제공함으로써 실무 에이전트의 신뢰성과 일관성을 크게 높였다.

정책 준수 문제는 에이전트가 환경을 변이시키기 전후의 절차적 전제들을 충족했는지를 판단하는 것이다. 이러한 전제들은 '사용자 확인을 받았는가', '보험을 제안하고 응답을 기록했는가'처럼 대화 행위에 대한 명제이며, 단일 도구 호출의 인자(argument)만으로는 이들 전제를 표현하기 어렵다. 따라서 판별기는 대화 전체를 입력으로 받아야 하며, 대화에 드러난 발화들의 의미적 연결을 추론할 수 있어야 한다.

LLM은 자연어를 입력으로 받아 내부적 연상과 추론을 수행할 수 있으므로 검증기 역할에 적합하다. PolicyGuard는 변이적 호출마다 하나의 LLM 완성(completion)을 호출하여 세 가지 요소를 수행한다: 전체 대화를 읽는 것, 정책 요구사항(원문 텍스트와/또는 자동 생성된 체크리스트)에 대해 항목별로 근거를 들어 Met/Not Met 판정을 내리는 것, 그리고 차단 시 구체적이고 대화-특화된 보완 메시지를 생성하는 것이다. 이때 chain-of-thought 구조를 출력 형식으로 사용하여 항목별 근거가 명시되게 한다.

대화가 포함된 입력과 체크리스트가 결합되면 검증기는 절차적 항목을 견고하게 판단할 수 있다. 본 논문 실험에서는 대화가 제거된 상태의 동일 검증기가 변이 작업을 모두 차단하여 성공률을 0에 가깝게 만들었고, 체크리스트만 있을 때는 성능이 부분적으로 회복되었다. 즉 대화 기반 근거가 판정의 원인적 입력이며 체크리스트는 이를 보강하는 역할을 한다.

전반적 접근은 오프라인과 온라인 두 단계로 구성되었다. 오프라인 단계에서는 원문 정책 문서를 입력으로 네 단계 LLM 파이프라인을 실행하여 도구별 요구와 제약을 YAML 체크리스트로 자동 생성했다. 이 체크리스트는 각 도구에 필요한 데이터검증 항목과 절차적 항목을 구조화해서 담으며 인간 수작업 없이 재사용 가능한 정책 규격을 만든다.

온라인 단계에서는 변이적 도구 호출이 발생할 때마다 검증기가 호출된다. 검증기는 세 입력을 받는다: 대화의 형식화된 메시지 히스토리(에이전트와 동일한 뷰), 원문 정책 텍스트(옵션), 그리고 해당 도구의 체크리스트(옵션). 검증기는 항목별로 Met/Not Met를 출력한 뒤 최종적으로 Pass 또는 Block 판정을 내리며 Block일 경우 1~3문장 분량의 Agent_Message 보완 문장을 반환한다. 이 과정은 온톨로지적 룰이 아닌 LLM 완성으로 이루어지며 본 실험에서는 온도 temperature=0으로 설정했다.

실험 설정은 paired-verifier 프로토콜을 사용하여 검증기와 에이전트를 같은 벤더·티어로 짝지었다. 평가 지표로는 Pass4(네 번의 독립 시도 모두 성공한 작업 비율), PV(24개 정책 위반 작업)과 Mut(26개 변이 작업) 분할, per-call PV 재현율, 블록 비율 및 near-miss 비율을 채택했다. 읽기 전용 호출은 검증기를 우회하도록 설계하여 검증 비용을 통제했고 검증기의 블록은 에이전트의 동일 시뮬레이션 경로에 블록 흔적을 남기지 않도록 런타임 패치가 적용되었다.

PG-Checklist 구성은 τ2-bench airline에서 세 에이전트 전부에 대해 Pass4를 유의미하게 향상시켰다. 구체적으로 GPT 5.4에서 +12.0pp, Claude Sonnet 4.6에서 +6.0pp, Gemini 2.5 Pro에서 +12.0pp의 향상을 보고했으며 PG-Checklist는 모든 에이전트에서 PV(정책 위반) 집합에 대해 완전한 재현율(24/24)을 달성했다. ToolGuard는 일부 에이전트에서 Pass4를 올렸으나 강한 에이전트들에서는 과도 차단으로 Mut 성능을 저하시켰다.

대화 제거 실험(PG-Raw-Traj)은 대화가 판정의 필수 입력임을 인과적으로 확인했다. 동일한 검증기와 정책 텍스트를 사용하되 대화 기록을 제거하면 모든 104개의 Mut 시뮬레이션에서 단일 변이도 통과하지 못했고 변이 성공률이 붕괴했다. 체크리스트만 제공하는 변형(PG-Checklist-Only)은 블록 비율을 높였으나 체크리스트에 원문 정책을 더하면 Mut 성능이 부분적으로 회복되어 원문은 보강적 역할을 한다는 사실이 드러났다.

검증기 규모를 낮춘 ablation에서는 GPT 5.4-mini 검증기를 사용해도 PG-Checklist가 유의한 향상을 유지했고 약한 에이전트에서는 검증기 효과가 더 크게 나타났다. 추가 분석으로는 블록 당 에이전트+사용자 턴 증가(trajectory cost)가 ToolGuard보다 PG-Checklist에서 적게 발생했으며 실행된 변이 호출의 near-miss 비율(call-NMR)도 PG-Checklist가 모든 에이전트에서 더 낮았다.

아키텍처는 에이전트→검증기→환경의 도구 호출 루프에 검증기 서브에이전트를 끼워 넣는 구조이다. 변이적 도구 호출이 발생하면 검증기는 하나의 LLM 완성으로 응답을 생성하고 입력으로는 포맷화된 메시지 히스토리, 원문 정책 텍스트(선택적), 그리고 도구별 YAML 체크리스트를 받는다. 출력은 각 요구사항에 대한 Met/Not Met 표기와 최종 verdict( Pass 또는 Block )이며 Block 시에는 1~3문장 분량의 Agent_Message 보완 문장을 포함한다.

체크리스트는 오프라인에서 네 단계의 LLM 파이프라인으로 자동 생성되며 각 항목은 데이터검증 유형 또는 절차적 유형으로 분류된다. 데이터검증 항목은 특정 읽기 전용 도구가 호출되었음을 요구하고 절차적 항목은 사용자 확인 같은 대화 행위 존재 여부를 요구한다. 온라인 검증기는 항목별 힌트를 사용하여 대화 내 패러프레이즈와 문맥을 고려한 판정을 수행하며, strict verdict 모드에서는 하나의 Not Met 이면 Block을 강제할 수 있다.

성능·계산 세부에서는 검증기 호출을 온도 0으로 고정해 결정론적 출력을 유도했고 paired-verifier 프로토콜을 통해 검증기와 에이전트를 같은 벤더·티어로 짝지어 방법 기여를 격리했다. 읽기 전용 호출은 검증기를 통과하지 않으므로 검증 호출 비용을 변이 호출 빈도에만 의존하도록 통제했다. 런타임 집계는 두 관점으로 이루어졌는데, verdict view는 모든 검증기 개입을 집계하고 runtime view는 실제 환경에 실행된 변이 호출만 집계하도록 설계되어 블록 비대칭을 처리했다.

평가는 τ2-bench airline 도메인(50개 작업)에 국한되어 있으며 논문 저자들은 다른 도메인(의료·법률)과 비영어 대화로의 일반화는 검증되지 않았다고 명시했다. 체크리스트 자동 생성은 본 실험에서 단일 벤더(GPT 5.4)로 생성되어 모든 에이전트에 재사용되었으며 이로 인해 벤더별 세부 조율이 필요할 수 있음을 보고했다. 검증기는 변이적 도구 호출에 대해서만 트리거되므로 읽기 전용 호출이나 언어적 약속만으로 발생하는 정책 위반은 본 방법의 적용 범위 밖이다.

PolicyGuard는 LLM 기반 검증기이므로 확정적(formal) 보증을 제공하지 못하며 확정적 감시가 필요한 안전비평역(예: 약물감시) 도메인에는 적합하지 않다. 또한 대화 내용을 검증기가 읽기 때문에 검증기 로그와 프롬프트가 프라이버시·PII 규정의 적용 범위에 포함되어야 하며 프롬프트 주입과 같은 적대적 공격에 대한 포괄적 방어는 본 연구의 범위를 벗어났다. 논문은 일부 적대적 탐침을 평가했지만 포괄적 레드팀 결과는 향후 연구 과제로 남겨두었다.