MatrixGuard.
1 Matrix Systems Innovations Ltd, Cardiff CF10
Abstract
MatrixGuard is a policy-as-reasoning runtime that takes a natural-language specification of a security or bot-management policy, compiles it deterministically into enforcement, validates the compiled policy against the last 30 days of production traffic in a simulator, and emits a per-block explanation at runtime. We argue that the gain over regex WAFs is not throughput — both are fast — but readability, simulator-grounded promotion, and an audit trail an analyst can defend in a post-mortem.
Specification → compiler → simulator → runtime.
A regex WAF answers one question well: does this request match this string? It answers a great many other questions only by accident. The policy author writes one regex per case, never reads them again, and learns six months later that the rule that was meant to block credential-stuffing also, accidentally, blocks an internal monitoring tool. Nobody can quite remember why.
MatrixGuard treats policy as a specification, in English, augmented by a small domain-specific language for the bits English is bad at (rate windows, set membership, cryptographic predicates). The compiler is deterministic: the same specification yields the same enforcement bytecode on every build. The simulator runs the compiled bytecode against the last 30 days of your production traffic, on the WebMatrix data model. The promotion gate is the simulator's output — false positives, false negatives, the delta versus the currently-enforced policy. If the simulator says the new policy would, in the last week, have blocked 2.4 % more legitimate sessions, the promotion does not happen.
What MatrixGuard catches.
The cases for which the specification approach is clearly worth it are the ones where the rule reads, in English, as a sentence — and where a regex would read as a wall of escaped characters. Three examples from production:
- Credential-stuffing across rotated sessions — "block any session in which the session token has been rotated more than three times in the last 60 seconds and where the request user-agent is on the rotating-UA list."
- Geographic-impossibility on session resumption — "block any session resumption whose source ASN is more than 1,500 km from the session establishment ASN, unless the session carries an operator-issued geo-skip token."
- Inventory enumeration — "block any session whose request rate on /products/* exceeds the 99.5th percentile of human sessions for that route, sustained for 90 seconds."
| Class | Spec readability | Simulator catch | Runtime explanation |
|---|---|---|---|
| SQL injection (classical) | Medium · DSL helps | Yes · pattern set | Pattern matched, request quarantined |
| Credential stuffing (rotated) | High · reads as sentence | Yes · session graph | Three rotations in 60 s; UA on rotating-UA list |
| Geo-impossibility | High | Yes · ASN map | ASN delta > 1,500 km; no skip token |
| Inventory enumeration | High | Yes · route percentile | Rate > p99.5 for /products/*, 90 s sustained |
| Novel zero-day exploit | — | No | (out of scope · §next) |
Table 1 Policy classes for which MatrixGuard is clearly worth it. The last row is the honest negative: a never-before-seen exploit reads, in the spec, like nothing.
What MatrixGuard will not do
- Catch a zero-day with no precedent in the simulator window. There is no model that does this; we will not claim that there is.
- Auto-promote a policy that the simulator says raises false positives, however small. The gate is the gate.
- Use customer traffic to train models we then sell to other customers. The simulator runs on your data, in your tenancy.
- Replace your incident-response team. The runtime explains every block; the post-mortem is still yours.
Fifteen months at a Cardiff retailer.
One of our earliest customers — a Cardiff-headquartered specialty retailer — moved their WAF policy from a regex stack to MatrixGuard in January 2025. Over the fifteen months that followed, the operations team rewrote eleven of their twenty-eight enforced rules into specifications. We have, with their permission, made the rewrites and the simulator outputs available in the customer note linked from the changelog.
The headline numbers are these. False-positive blocks on the rewritten eleven rules fell by 73 % in the first quarter post-rewrite, and stayed there. Time to author a new policy fell from "afternoon" to "half an hour, including reading the simulator output". The number of policies the team felt comfortable enforcing — not authoring, enforcing — rose from twenty-eight to forty-one over the fifteen months.
The number we do not lead with: the customer's overall block rate did not change, end-of-quarter to end-of-quarter. The point of the rewrite was not to block more; it was to know what was being blocked, and why.
An engineering call against your policy file.
Bring your hardest-to-read policy, the one your security analyst keeps meaning to refactor. Forty-five minutes, against the WebMatrix simulator on your last seven days of traffic. Written note same day. The note tells you which rules MatrixGuard would clearly improve, which it would clearly not, and the false-positive budget at which promotion would not pass the gate.