CNRT Vanguard
You cannot defend against an attack path nobody has walked. Vanguard walks them, against systems you own and have authorised in writing, and hands back what it found and how it got there.
It will not run without your written authorisation
Before a campaign starts, the customer has to supply a signed authorisation naming the systems in scope. No token, no run. That gate exists because testing a system you do not own is not a grey area, and because a security vendor that treats consent as optional is not one you should let near your network.
Every campaign runs in its own disposable machine
Each engagement spins up a fresh, isolated virtual machine, does its work inside that boundary, and is torn down afterwards. Nothing from one campaign can reach another, and nothing persists between them. Concurrency is capped deliberately rather than stretched, and work beyond the cap queues.
The attack library tracks the field, not a release cycle
Vanguard draws its techniques from a public, actively maintained catalogue of adversarial methods rather than a list frozen at ship time, so coverage moves as the field does. Defensive modules are being added alongside the offensive ones so the same engine can report what would have stopped each path.
The record behind it.
Vanguard runs only against targets the customer has authorised in writing. Deployed standalone, with access restricted to provisioned accounts.
| Position | Standalone product, deliberately separate from the CNRT dashboard |
|---|---|
| Authorisation | Written pre-engagement consent required before any campaign |
| Isolation | One disposable virtual machine per campaign |
| Access | Provisioned accounts only, no self-service sign-up |
| Languages | English and Japanese |
Tell us the program
and the problem.
We reply from San Jose, usually within two working days.