The interesting claim in HazardAuditor isn’t the accuracy number — it’s where the safety check lives. Most guard models we run in production sit on the prompt and the response: classify the input, classify the output, move on. That framing breaks the moment an agent starts driving a browser, a shell, and a filesystem, because the harm shows up in what it does three tool calls deep, not in any single message.
HazardAuditor moves the guard onto the execution trace. It runs heterogeneous agents — Claude Code, Codex, and others — in controlled environments and normalizes their behavior into a canonical event representation, so one guard supervises across frameworks instead of being retrained per stack. The arXiv paper also names a training bug I hadn’t considered: token-level objectives let long rationales dominate the gradient, so a generative guard learns to explain rather than to decide. Their GuardPO fix makes the verdict the unit of optimization and reports up to 16.5 points over the strongest prior guard.
The part I’d actually chase is the cross-framework normalization. Every team I know runs a different agent runtime, and a guard that only works on one is a guard you rewrite every quarter. A canonical event schema for agent actions is the boring infrastructure that makes safety portable — and it’s the same schema you’d want for observability and replay anyway. The HF paper page points to the artifacts. Open question I keep coming back to: if the guard reads the normalized event stream, does it belong inside the loop as a blocking check, or beside it as an async auditor that can only kill the session? Your latency budget probably answers that before your threat model does.