The last control metric:
does your WAF/NGFW/EDR actually block?
Continuously verified — which device, which control failed, detection without blocking = P0, drift after upgrades stays visible.
Fire one yourself (30 s, no signup) How billing works
Live blocking status (canary): checking
Which device, which control
The ledger goes to named device and named control — not an unactionable “security score 87”.
Detection ≠ blocking
A rule hit in the logs is not a stopped attack. “Detected only” is pinned red and never pushed into the green.
Drift after upgrades
Replay the same plan around a ruleset or firmware upgrade; verdict diffs are listed line by line — no changelog babysitting.
Every claim reproducible on the spot
Nothing untestable on this site: next to every claim there is a public link that shows the same verdict in your browser. Evidence is downloadable and replayable (same plan, same fingerprint inputs).
FAQ
How is this different from my WAF's built-in tests?
Self-tests answer “did the rules load”. aibas answers “when a real payload arrives from the public internet, did this control on this device block it” — with two-sided evidence you can pin and replay.
Where does the attack traffic come from?
Only from the published, bounded scope (see the ROE page). Payloads are known samples from a closed corpus and hit only your own range assets.
What if it is detected but not blocked?
P0. A log line does not mean the attack was stopped — detection without blocking is never green.
How do I know an upgrade did not make things worse?
Fingerprints are read back and archived on every run; replay the same plan before and after and the verdict diff is listed line by line.