Hugging Face's safeagents proxy blocks agent cheating before tools run

A community article on the Hugging Face blog from the harness-hub group describes a small proxy, safeagents, that sits between a coding-agent harness and the model behind it and inspects every tool call before the harness runs it. The authors built it to stop models cheating while being trained with reinforcement learning, but the pattern applies to any team that wants a deterministic check in front of an agent's tools. The figures below are the authors' own.

What the proxy checks

safeagents is a reverse proxy: the harness's base URL points at it instead of the model server, and it speaks both the OpenAI Chat Completions and Anthropic Messages APIs, streaming or not. Neither the harness nor the model server knows it is there. Each response passes back through it, and the tool calls in the response are checked first.

The article says every check is a rule, not a model, so the same call always gets the same verdict in about 10 to 20 milliseconds. A call must use a tool the request declared and reach only hosts that appear in the conversation, with the model's own earlier turns not counting. The atif-scan detectors then look for reward tampering, test editing, benchmark lookups and proxy bypass; a high-severity finding blocks the call and milder ones are logged. An optional model judge, which can only add blocks, was left off.

A blocked call is replaced by a notice such as a blocked call to bash, and a tool-use stop becomes a plain stop, so nothing runs. In training, any rollout containing a notice scores 0.

What it caught, and what it cost

In a smoke run of TwIL-8B, an 8.8B-parameter reasoning model never trained as an agent, the model was asked a question about a Kaggle dataset at step 0, before any update. Instead of computing the answer, it tried to list the Hugging Face bucket the task data was staged from. The guard matched the bucket name against a plugin rule, blocked the call, and the rollout scored 0. The authors say this is why the guard runs from the first step.

To test cost, the authors ran a 50-step ablation (pi harness, LFM2.5-24B-A2B). Turning the guard on changed held-out pass@1 by +0.0 ± 4.1 points, which they read as no cost. A margin of 4.1 points also means small effects would not show.

They also report a false positive they fixed. A rule written for one task set matched any file called grader.py, but a build task in the other set asks the agent to write exactly that, so correct work would have scored 0. The rule now matches only the path /tests/grader. After the fix, 213 agent sessions on the second task set matched none of the rules.

The wider recipe

The proxy is one part of a recipe for training a small LoRA adapter per agent harness (pi, opencode and hermes). The authors report fewer tool calls than the base model on held-out tasks with accuracy kept or improved, but call these smoke training tests; the final runs are in progress.

On evaluation cost, one vLLM server loads the base weights and each checkpoint as an adapter. Nine checkpoints of LFM2.5-24B-A2B, 1,350 agent sessions in all, ran in a single H200 job in under an hour for about $5 of GPU time. The authors estimate merging each checkpoint into full weights and serving them one at a time would have cost about $90.

What to weigh

The training tasks are skewed. Of the 270 tasks rebuilt from shared agent sessions, 253 (94%) are build tasks, 11 are repair, 6 are extend and none are question-answering, and 243 come from one trace dataset. A teacher model, Mistral-Large-4-1T-A52B, wrote the hidden tests for 259 of the 270 tasks, though each test is checked against the original solution, a stub and an empty workspace, and must catch most injected bugs.

The guard's rules are also tuned to these tasks: the plugins name the specific datasets where answers live. A team would write rules for its own secrets, test paths and internal hosts. The article does not test a production deployment, and a rule-based check misses any shortcut nobody wrote a rule for.