sg-sentinel.sgit.ai / roadmap
What the design covers, what it defers — honestly
First, the frame: SG/Sentinel has not been built — there is a May 2026 design and a prototype exercise, and no plans to take it further unless somebody funds it. Within that frame, this page is the precise status of the prototype the design exercise produced: a deliberate tiny core with an explicit deferred list. It never claimed to replace a commercial WAF.
What the May 2026 prototype exercise produced
| Piece | Status | Evidence |
|---|---|---|
| L1 JS engine — six deterministic rules, decide + signal only | built | unit + parity tests; the file itself |
| L2 Python actor — enforce + build record + write sink | built | unit tests; identical logic across targets |
| Use case 1 — logging: replayable record per request, S3-style key layout | built | end to end on targets B and C |
| Use case 2 — blocking: 403/404 with a logged reason for every block | built | end to end on targets B and C |
| Target B — local-direct (node), fully offline | proven | the always-on parity baseline |
| Target C — local-docker CF-env simulation | proven | B↔C parity assertion |
| Deploy lifecycle — create/destroy/teardown, mutation-gated, no orphans | code-complete | unit-tested via in-memory doubles |
| Target A — live AWS (CloudFront Function + Lambda@Edge, cache-disabled) | code-complete | unit-tested via in-memory doubles; not yet run against a real CloudFront distribution |
| Operator TUIs (rules/logs/blocks/status/traffic) + TUI API + read-only chat | built | the testing manual §6–7 |
| Traffic generator + httpget echo origin (impact measurement) | built | the testing manual §8 |
| Test suite | 149 passing | unit + in-memory lifecycle + parity baseline |
What a builder would do first
If somebody picks this up — the hope this site is published in — these are the open items the briefs put in front of everything else:
- Run the live AWS leg. Deploy the ephemeral distribution, run the parity matrix's AWS leg and the live smoke test (deploy → curl each canonical path → assert 403/404/200 and a log object per request → teardown, no orphans). Until then the honest status stays "code-complete, not proven live". Tracked as comms T2.
- Measure the cost. The founding argument — writing directly to S3 avoids per-request WAF and Firehose pricing — is qualitative until the live path is measured against the Firehose + WAF baseline. The briefs flag this as acceptance criterion 12; no numbers are claimed anywhere on this site until it is done.
- Measure propagation. How fast a CloudFront Function update propagates shapes the whole reaction model (how quickly a ban takes effect). Flagged as a must-measure from the execution-model brief onward.
Designed, documented, deliberately not built
Everything here has a brief behind it. Deferring is sequencing, not abandoning — the MVP proves the spine; these build on a proven spine.
| Deferred | What it is | Where it's designed |
|---|---|---|
| Fingerprint / fast-track | Signed-token, zero-trust acceleration: identity-verified users skip the identity-establishment cost, never authorisation; honeytoken touch revokes trust | time brief, addendum |
| Anomaly scoring & opinion rules | CRS-style accumulated scores combining low-confidence signals; paranoia-level tuning; any rule evaluation at L2 at all | rule architecture |
| Layer 3 — the async/LLM tier | Out-of-band analysis, LLM interpretation of ambiguous traffic, rule generation feeding the fast layers; never inline | execution model, rules engine |
| Known-good profile validation | The full no-invalid-request allowlist generated from routes/OpenAPI, deployed atomically with the app, observe-mode first | execution model, tabletop 1 |
| The fractal rule graph & rules-as-vault | Rule packs activated by triggering rules; per-rule RFD versioning; phase-aware minimal bundles | rule architecture, interactivity |
| The unified evidence-and-compliance graph | One typed semantic graph: rule prevents technique, satisfies requirement, observed as evidence; compliance posture computed from the deployed rule-set | evidence graph, compliance, addendum |
| Deception layer | Honeytokens as a rule type; wild-goose-chase / tarpit block actions | addendum |
| Threat-intel integration | AbuseIPDB / GreyNoise / STIX-TAXII on the async timelines; reputation as context, never verdict | research brief |
| Multi-CDN | The Sigma-style compile-to-backend path to Cloudflare Workers / Fastly | research brief, addendum |
| Cache-hit logging | Needs a viewer-response path; the MVP distribution runs cache-disabled instead (GAP 4.1) | MVP architecture |
| Smaller items | Log batching (one object per record for now); IP-escrow privacy mode (hash/plain/omit today); SSL termination; auth-outcome reverse coupling | the planning brief's parked list |
The honest limits
- In-profile exploits pass structural validation. A valid-shape request with a malicious payload is not caught by the allowlist; the designed answer is content rules + async interpretation + a secure application. Sentinel is defence in depth, not a sole defence.
- The tiny core blocks the obvious, only the obvious. Six deterministic rules catch probes, scans and traversal — not a general attack corpus. That is the point of a tiny core, and the reason the deferred list exists.
- No content or malware inspection, ever, by design. Zero-knowledge means Sentinel never holds file contents or keys; it does traffic, IP and behavioural intelligence only.