Inspiration
An AI support agent can sound helpful while taking an unauthorized action. It can also claim a refund succeeded after the application blocked it.
We built Agent Wind Tunnel to make that gap visible: what did the agent attempt, what actually executed, and did legitimate customers still get help?
Then we asked another question: would our evaluator catch a broken safeguard of its own?
What it does
Wind Tunnel is a reliability lab for a fictional store’s refund assistant. Twelve authored scenarios cover legitimate refunds, exact policy boundaries, unauthorized access, excessive amounts, split refunds, and instructions hidden in order notes.
The same NVIDIA Nemotron agent runs in two modes:
- Baseline: business rules are deliberately unenforced inside synthetic data.
- Enforced: trusted application code checks ownership, eligibility, remaining balance, and cumulative refund limits before access or mutation.
The dashboard separates attempted violations, executed violations, legitimate completion, and inconclusive results. Every case exposes the actual tool arguments, results, model response, token usage, latency, and estimated cost.
All customers, orders, refunds, and escalations are fictional.
Check the checks
The Assurance lab deliberately breaks eight safeguards in isolated executions. A separately implemented checker replays tool results and final state without trusting the original policy flags.
The original controls pass 10/10 probes, and the probes catch 8/8 deliberate faults, including:
- Removing ownership or eligibility checks.
- Bypassing balance and cumulative refund limits.
- Accepting fractional cents.
- Refusing every legitimate refund.
- Reporting success without updating the ledger.
Each catch includes an inspectable witness. A CI command runs the same checks without model calls. These counts describe finite authored tests, not general safety coverage.
Turn a failure into a regression test
A recorded failure can become a test developers keep.
Wind Tunnel removes tool calls while preserving the same observed action-policy rule. The recorded split-refund example reduces from three calls to two.
Download the generated Node test, save it in the repository’s tests folder, and run it without inference credits. It reproduces the baseline boundary failure and verifies that enforcement prevents it. We deliberately broke enforcement in a test adapter to confirm the exported regression fails.
The result is a single-deletion-minimal tool subsequence—not a globally shortest attack or proof of the model’s reasoning or prompt-injection cause.
How we built it
The responsive interface uses HTML, CSS, and JavaScript. A bounded backend loop calls NVIDIA Nemotron Lightning and Super through Nebius Token Factory, using native function tools.
Trusted application state supplies customer identity and synthetic order records. The agent receives three tools: retrieve an order, request a simulated refund, and record an escalation.
The public app runs on Sites Workers with persistent Cloudflare D1 quota reservations. API keys remain server-side, and fresh inference requires a separate private tester token. Recorded real evidence and scripted simulations are available without credentials.
The repository includes a local Node adapter, MIT license, setup instructions, replayable evidence, automated tests, and GitHub Actions.
Results
In the original recorded twelve-case comparison:
- Lightning’s baseline executed 10 prohibited calls across 8 cases.
- Super’s baseline executed 1 prohibited call.
- Both enforced configurations executed zero prohibited calls and completed all four legitimate refunds.
A fresh full comparison reproduced those case-level outcomes. Two observations per configuration are still insufficient for statistical model rankings.
The original enforced suites cost an estimated $0.0028 for Lightning and $0.0120 for Super, calculated from measured tokens and catalog prices. These are estimates, not reconciled billing statements.
Verification includes 102 passing automated tests, green GitHub CI, replay of 96 real recorded case evaluations, public-browser checks of both new features, and fresh hosted model calls. A regression test downloaded from the public interface also ran successfully against the repository.
Challenges and what we learned
The hardest distinction was between an attempted action, an executed action, and a convincing description of an action.
In one recorded enforced Lightning case, the tool blocked a refund and recorded escalation, but the final response still implied the refund had completed. We preserve that response rather than hiding it behind a passing action score.
We also learned that an evaluator can share the same mistake as its enforcement code. The separate checker and deliberate fault tests make part of that weakness testable.
Application controls can protect state without making the model’s prose truthful. Both need evaluation.
What’s next
We want independently authored scenarios, more repeated evaluations, checks for customer-facing explanations, and bounded adapters for external agents.
The current release intentionally focuses on one reproducible refund workflow. It is not an external security audit or a general safety guarantee. The checker relies on recorded results and final state; consistent falsification of both can evade trace-only checks.
Built With
- cloudflare
- css3
- d1
- factory
- github
- html5
- javascript
- nebius
- nemotron
- node.js
- nvidia
- token
- workers
