PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM Agents

Seongjae Kang; Taehyung Yu; Sung Ju Hwang

cs.AIAug 20, 2026

PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM Agents

Authors: Seongjae Kang, Taehyung Yu, Sung Ju Hwang

Organizations: KAIST

Abstract

Customer-service LLM agents must follow organizational policy when acting on a user's behalf. Compliance failures arise from either forbidden actions, such as granting an ineligible change, or omitted procedural requirements, such as identification or confirmation. Runtime safeguards can intervene on risky actions, but action-local checks do not guide an agent through a multi-step procedure. Workflow-following systems support prescribed process execution, but primarily target workflow completion rather than safeguarding agent behavior. PolicyGuide instead compiles each domain policy into a workflow graph and invokes a proactive verifier at user-turn boundaries. From persisted graph state, the verifier reconciles open requests and returns step-specific remediation along a policy-compliant path. Across the $τ^2$ -bench airline, retail, and telecom domains with a GPT-5.4 agent and verifier, PolicyGuide raises mean $\mathrm{Pass}^4$ from $0.42$ to $0.62$ , with the largest gain on telecom ( $0.19$ to $0.61$ ), the most workflow-structured domain. The same workflows transfer to Claude Sonnet 4.6 and Gemini 2.5 Pro agents. Complementary evaluations find the lowest observed attack-success rate under adversarial users and the strongest procedural compliance in an author-designed workflow-level validation.

Figures & tables

Panel of Figure 1 — Figure 1: Workflow systems execute prescribed procedures, while external safeguards monitor agent behavior. PolicyGuide combines both roles.

Panel of Figure 2 — Figure 2: One task under three enforcement regimes. (a) An action guard checks only the final mutating call, so skipped procedure is discovered late and returned as a block. (b) A workflow/SOP agent drives the procedure, but its checks are designed for faithful workflow execution rather than as a safeguard against policy-violating behavior by a general-purpose agent. (c) PolicyGuide runs as an external, advisory guide: at user-turn boundaries it tracks graph position across turns and stops at the first unsatisfied node. If the agent attempts a mutating tool call before completing the workflow, the runtime returns remediation for the unmet step. It recommends the mutation only after the required workflow steps are grounded.

Panel of Figure 3 — Figure 3: PolicyGuide separates offline policy authoring from online enforcement. Offline , the policy and tool registry are compiled, repaired, and validated into a reusable workflow bundle. Online , each verifier call consumes the conversation, grounded tool results, persisted request state, and workflow bundle; it reconciles requests, traverses the graph to the first unmet requirement, and returns remediation, updated state, and mutation-gate status for the next agent turn.

			Airline (50)			Retail (114)			Telecom (114)
	System	Verifier	Overall	PV	Mut	Overall	PV	Mut	Overall	PV	Mut
$\textsc{Pass}^{1}$	ReAct	—	0.640	0.865	0.433	0.800	0.900	0.791	0.384	0.721	0.180
	ToolGuard	static code	0.575	0.969	0.212	—	—	—	—	—	—
	PolicyGuard	GPT 5.4	0.710	1.000	0.442	0.645	0.975	0.613	0.406	0.733	0.208
	PolicyGuide	GPT 5.4	0.775	0.979	0.587	0.809	0.975	0.793	0.866	0.895	0.849
$\textsc{Pass}^{4}$	ReAct	—	0.460	0.750	0.192	0.596	0.700	0.587	0.193	0.442	0.042

Table 1: Main results on the base splits (GPT 5.4 agent,

n{=}4

; airline 50, retail/telecom 114 tasks). Cells report Pass 1 and Pass 4 overall and on the PV/Mut slices. The verifier is absent for ReAct, static code for ToolGuard, and GPT 5.4 for PolicyGuard and PolicyGuide .

Panel of Figure 4 — Figure 4: Pass k vs. $k$ (reliability; higher is better) on the base split of each domain, GPT 5.4, all cells $n{=}4$ .

Domain	Metric	ReAct	PolicyGuide Self	PolicyGuide Raw	PolicyGuide
Airline	Overall	0.460	0.480	0.520	0.620
	PV	0.750	0.833	0.875	0.917
	Mut	0.192	0.154	0.192	0.346
Retail	Overall	0.575	0.350	0.575	0.725
	PV	0.750	0.750	0.750	1.000
	Mut	0.556	0.306	0.556	0.694

Table 2: Workflow ablations (GPT 5.4 agent; Airline base split, Retail and Telecom benchmark test splits of 40 tasks). All cells report Pass 4 .

System	Runtime control	Pass 4
ReAct	actor only	0.250
PolicyGuard	action-local check	0.325
FlowAgent	PDL + API control	0.350
PolicyGuide	external graph verifier	0.675

Table 3: Matched workflow-controller comparison on the 40-task Telecom benchmark test split. All values are Pass 4 .

Agent	Metric	ReAct	PolicyGuard	PolicyGuide
GPT 5.4	Overall	0.460	0.580	0.620
	PV	0.750	1.000	0.917
	Mut	0.192	0.192	0.346
Claude Sonnet 4.6	Overall	0.720	0.780	0.780
	PV	0.958	1.000	1.000
	Mut	0.500	0.577	0.577

Table 4: Agent-family generalization on Airline (50 tasks,

n{=}4

; verifier model paired to the agent). All metrics are Pass 4 . The GPT 5.4-authored workflow graph is reused without re-authoring.

Panel of Figure 5 — Figure 5: Pass k for Claude Sonnet 4.6 and Gemini 2.5 Pro agents on airline (verifier $=$ agent), with $n{=}4$ for every system.

Panel of Figure 6 — Figure 6: CRAFT red-team attack-success rate on airline (20 attack tasks, GPT 5.4, $n{=}4$ ); lower is safer .

System	Step-TCR	Trace-TCR	Process-valid rate
ReAct	86.4	35.4	17.5
PolicyGuard	85.7	23.9	13.1
PolicyGuide	94.5	63.4	56.2

Table 5: Author-designed Telecom ordered trace compliance (%;

n{=}4

). Step- and Trace-TCR condition on outcome-passing traces.

Appendix figures & tables21 assets

Supplementary material from the paper’s appendix.

Appendix

Domain	A	P	W	Total	% P+W	% W
Airline	14	27	2	43	67.4%	4.7%
Retail	0	27	1	28	${\sim}100\%$	3.6%
Telecom (main)	1	21	7	29	96.6%	24.1%
Telecom (manual)	0	1	20	21	100%	95.2%
Telecom (both)	1	22	27	50	98.0%	54.0%

Appendix

Table 6: Argument- (A), process- (P), and workflow-level (W) partition of the source policies (W splits PolicyGuard’s process-level class; P+W equals it).

ID	Line	Requirement (paraphrased)	Type
Global rules
G1	10	Authenticate identity by locating the user id via email or name+zip—even when the user already provides the id	P (D+T)
G2	14	One user per conversation; deny any request about another user	P (D)
G3	16	List action details + obtain explicit “yes” before any DB-updating action	P (D)
G4	18	No fabricated information/knowledge/procedures; no subjective recommendations	P (D)
G5	20	At most one tool call per turn (not paired with a user-facing reply)	P (D)

Appendix

Table 7: Hand-classified atomic requirements of the

\tau^{2}

-bench Retail policy document (28 requirements,

0

A /

27

P /

1

W; subtypes D-only

13

, T-only

14

, D+T

1

). Line refers to retail/policy.md as released with

\tau^{2}

-bench; Type A = argument-level, P = process-level (flat), W = workflow-level (order-bound; Appendix B.1 ), with D = dialogue-dependent, T = requires a prior read-only tool call.

ID	Line	Requirement (paraphrased)	Type
Global rules
G1	7	No fabricated information/knowledge/procedures; no subjective recommendations	P (D)
G2	9	At most one tool call per turn (not paired with a user-facing reply)	P (D)
G3	11	Deny user requests that are against the policy	P (D)
G4	13	Transfer iff unhandleable: call transfer_to_human_agents , then the literal handoff message	W (D)
G5	15	Try your best to resolve the issue before transferring	W (D)

Appendix

Table 8: Hand-classified atomic requirements of the

\tau^{2}

-bench Telecom main_policy.md (29 requirements,

1

A /

21

P /

7

W). Line refers to the document as released with

\tau^{2}

-bench; \raisebox{-0.4pt}{\scriptsize

n

}⃝ marks a step in an ordered procedure (“To do so you need to follow these steps”). Types as in Table 7 .

ID	Line	Requirement (diagnose $\to$ conditional fix $\to$ verify)	Type
Cellular service (ll. 55–99)
TSS1	69–72	Diagnose service via check_status_bar	P (T)
TSS2	74–78	If Airplane Mode ON $\to$ guide toggle_airplane_mode OFF	W (D+T)
TSS3	79–87	Check SIM: Missing $\to$ reseat; Locked $\to$ escalate; Active $\to$ ok (three-way branch)	W (D+T)
TSS4	88–92	If APN incorrect $\to$ guide reset_apn_settings , then reboot_device	W (D+T)
TSS5	93–99	If line suspended $\to$ handle per main policy, then verify service restored	W (T)

Appendix

Table 9: Hand-classified atomic requirements of the

\tau^{2}

-bench Telecom tech_support_manual.md (21 requirements,

1

P /

20

W). Line refers to the document as released with

\tau^{2}

-bench. Every rule is a diagnostic-gated (T) user-guidance (D) step; the three chapters form the prerequisite chain Service

\subset

Data

\subset

MMS; every row except TSS1 (the entry diagnostic) is workflow-level.

Domain	System	$\mathrm{P}^{1}$	$\mathrm{P}^{2}$	$\mathrm{P}^{3}$	$\mathrm{P}^{4}$	$\mathrm{P}^{4}/\mathrm{P}^{1}$
Airline	ReAct	0.640	0.530	0.485	0.460	0.72
	ToolGuard	0.575	0.553	0.535	0.520	0.90
	PolicyGuard	0.710	0.630	0.595	0.580	0.82
	PolicyGuide	0.775	0.707	0.660	0.620	0.80
Retail	ReAct	0.800	0.700	0.638	0.596	0.75
	PolicyGuard	0.645	0.506	0.421	0.360	0.56

Appendix

Table 10: Pass k breakdown for the base-split results in Table 1 and Figure 4 (GPT 5.4,

n{=}4

\mathrm{P}^{4}/\mathrm{P}^{1}

is the consistency ratio.

Domain	System	T1	T2	T3	T4	pstd
Airline	ReAct	0.620	0.620	0.640	0.680	0.024
	ToolGuard	0.560	0.580	0.580	0.580	0.009
	PolicyGuard	0.700	0.740	0.700	0.700	0.017
	PolicyGuide	0.800	0.720	0.820	0.760	0.038
Retail	ReAct	0.807	0.746	0.842	0.807	0.035
	PolicyGuard	0.649	0.623	0.632	0.675	0.020

Appendix

Table 11: Pass 1 in each of the four trials on the base splits. pstd is the population standard deviation across trial-level values.

Opponent	$D$	$\sum a$	$\sum b$	$n_{\rm disc}$	$Z$	$p$
ReAct	3	77	19	96	$+5.92$	$<10^{-8}$
PolicyGuard	3	97	19	116	$+7.24$	$<10^{-12}$

Appendix

Table 12: Pooled stratified McNemar tests on per-task Pass 4 .

D

is the number of domain strata;

a

counts PolicyGuide -only passes and

b

the reverse, summed across strata.

Domain	Opponent	$n$	$\Delta\mathrm{P}^{4}$ [95% CI]
Airline	ReAct	50	$+0.160$ [ $+0.020$ , $+0.300$ ]
	ToolGuard	50	$+0.100$ [ $-0.040$ , $+0.260$ ]
	PolicyGuard	50	$+0.040$ [ $-0.080$ , $+0.160$ ]
Retail	ReAct	114	$+0.018$ [ $-0.070$ , $+0.105$ ]
Retail	PolicyGuard	114	$+0.254$ [ $+0.149$ , $+0.360$ ]
Telecom	ReAct	114	$+0.421$ [ $+0.316$ , $+0.526$ ]

Appendix

Table 13: Per-domain paired-bootstrap differences in Pass 4 on the base splits (10,000 task-level resamples). Positive values favor PolicyGuide .

Domain	Calls/ task	Prompt tok./call	Cached input	Output tok./call	Guide total $	Guide $/task
Airline	7.56	32,360	88.1%	2,478	20.10	0.40
Retail	7.42	22,803	85.8%	2,179	13.67	0.34
Telecom	11.47	28,518	86.5%	2,186	22.29	0.56

Appendix

Table 14: Guide-side model usage for the GPT 5.4 configuration (50 Airline and 40 Retail/Telecom tasks). Costs exclude the actor and user simulator.

Domain	ReAct (s/task)	PolicyGuide (s/task)	Ratio
Airline	36.4	210.1	$5.78\times$
Retail	34.6	193.6	$5.60\times$
Telecom	45.5	247.6	$5.45\times$

Appendix

Table 15: Mean end-to-end wall-clock time per task.

Domain	Nodes	Auth. nodes	Validator flags
Airline	158	11	0
Retail	104	7	0
Telecom	127	5	1

Appendix

Table 16: Programmatic validation rerun on the frozen workflow graphs.

Call-NMR (%; $\downarrow$ )	Airline	Retail	Telecom †
ReAct	25.4	47.6	0.0
PolicyGuard	32.5	34.8	0.0
PolicyGuide	15.6	34.7	0.0

Appendix

Table 17: Call-NMR on passing Mut trajectories (

n{=}4

): percentage of successfully executed agent mutations missing a frozen guard-derived read prerequisite. † Telecom is an adapted, agent-side diagnostic whose read oracle saturates; its zeros do not establish equal procedural quality.

Panel of Figure 7 — Figure 7: Guide system prompt, part 1 of 3. Left: the protocol block (reconcile-then-traverse, one generation per fired turn) and the per-turn trigger, which is folded into the cached static prefix rather than re-sent. Right: the Part-2 output contract—the single fenced JSON block the runtime parses into code-owned state.

Panel of Figure 8 — Figure 8: Guide system prompt, part 2 of 3: judging rules (i)—evidence grounding and mutating-tool authorization.

Panel of Figure 9 — Figure 9: Guide system prompt, part 3 of 3: judging rules (ii)—argument sourcing, transfer scoping, corrective-fix traversal, read-tool delegation (left) and the remediation contract (right).

Panel of Figure 10 — Figure 10: Workflow-generation system prompt: the runtime contract the graph must satisfy, and the authoring-essentials contract every stage must follow.

Panel of Figure 11 — Figure 11: Workflow-generation stage prompts: the plan stage’s requirements (left) and the adversarial reviewer’s checklist (right).

Panel of Figure 12 — Figure 12: Airline : the composed workflow graph—the shared spine (start, intake, the identify_user subflow, classify) and the full transactional book_reservation request path. Solid edges fire only when: satisfied ; dashed edges are classifier branches. The mutating tool is represented downstream of its tool_authorization node (trapezoid), immediately followed by the verify node that demands a successful TOOL_RESULT .

Panel of Figure 13 — Figure 13: Retail : the shared entry–intake–identification spine and classifier dispatch into request-specific subflows, with cancel_pending_order expanded. Its status and reason gates, shared summary-and-confirm step, authorization, and post-call verification form the complete cancellation path. The gray box marks the expanded cancellation subflow; the dotted box summarizes the other classifier branches.

Panel of Figure 14 — Figure 14: Telecom : the shared entry–intake–identification spine and classifier dispatch, with two request branches expanded. The overdue-bill branch invokes pay_overdue_bill , which gates send_payment_request ; the MMS branch invokes troubleshoot_mms , which checks service and data prerequisites before the documented MMS causes and closes by resolving or transferring. The dotted box summarizes the remaining classifier branches.

Explore similar work

PolicyGuard: A Dialogue-Grounded Sub-Agent Verifier for Policy Adherence in LLM Agents
Jun 28, 2026Seongjae Kang, Taehyung Yu, Sung Ju HwangTool-Augmented Language Model Agents LLM Guardrails
KAIST
NOMOS: Compiling Written Policies into Statically Verified Tool-Call Gates for LLM Agents
Oct 8, 2026Min-Young Yu, Tony Kim, Jang Won ChoiTool Access Control for LLM Agents LLM Agent Safety
Corners Co., Ltd.
Governance by Construction for Generalist Agents
May 20, 2026Segev Shlomov, Iftach Shoham, Alon Oved +7LLM Guardrails AI Agent Governance
IBM Haifa, Israel

Jun 28, 2026J/K move · Enter open · S save

PolicyGuard: A Dialogue-Grounded Sub-Agent Verifier for Policy Adherence in LLM Agents

Seongjae Kang, Taehyung Yu, Sung Ju Hwang

KAIST

Tool-Augmented Language Model Agents LLM Guardrails LLM Agent Evaluation LLM Agent Verification LLM Agent Safety

Open paper AskPDF arXiv

LLM agents handle user requests on behalf of organizations through tool calls and must follow the company policies stated in their system prompts. Prior work approaches this as a safeguarding problem -- external checks that block non-compliant agent actions. We argue that policy adherence is a broader problem: real workflows unfold across many turns, require explicit user confirmation and prerequisite reads, and hinge on the content of the dialogue rather than on any single argument value. Meeting this bar requires (i) full conversation context, (ii) self-reasoning over the policy and the current dialogue, and (iii) conversation-specific remediation that guides the agent's next turn -- three capabilities that prior safeguard work has often underestimated. We introduce POLICYGUARD, a sub-agent verifier that shares the agent's view of the dialogue, reasons over the policy in context, and provides actionable feedback for the agent's next turn. On tau^2-BENCH airline across three vendors (GPT-5.4, Claude Sonnet 4.6, Gemini 2.5 Pro) with four trials per setting, POLICYGUARD improves PASS4 by +12.0 / +6.0 / +12.0 pp. Per-call analyses show POLICYGUARD achieves higher policy-violation recall while blocking roughly half as often as argument-level guards.

Abstract

Explore similar work

PolicyGuard: A Dialogue-Grounded Sub-Agent Verifier for Policy Adherence in LLM Agents

NOMOS: Compiling Written Policies into Statically Verified Tool-Call Gates for LLM Agents

Governance by Construction for Generalist Agents