SG/Sentinel is a design for an edge guard that replaces rented AWS WAF + CloudWatch/Firehose with a layer you own. Because the app knows what a valid request looks like, the edge can allowlist rather than denylist — no invalid request reaches the origin. Rules are data, versioned in git, carrying their own metadata. The design was taken all the way to a prototype exercise: the same rule engine across three targets, with a parity matrix asserting identical decisions.
SG/Sentinel does not exist as a product or a running system. What you are reading is a set of research documents and ideas created by the project lead in May 2026 — 19 design briefs (18 May), two implementation briefs and a prototype exercise (23 May) — published here as "this is how I would build it."
It is published in the hope that somebody builds this. In the project lead's words: "I really would like to use this next generation of WAF security layer in my projects" — but there are no plans to build it at the moment, unless somebody wants to fund it. If that's you, or you're building something in this direction, open an issue on GitHub.
What the site's status language means in that light: the design exercise included an agent-built prototype — the code snapshot published here, whose testing manual reports 149 passing tests on the local targets. That prototype is a design artefact from May 2026: it is not deployed anywhere, not in production use, not maintained, and not packaged for you to install. Every "built" or "proven" on this site refers to that prototype exercise, nothing more.
Edge security and logging today means AWS WAF plus CloudWatch and Kinesis Firehose. Three problems converge — and underneath them, one fear: a single client-side bug once caused runaway redirect traffic, and nothing at the edge would catch the next one before the bill did.
Who is requesting what, how often, from where — logs arrive minutes later through a pipeline you don't control. An operational blind spot for cost, security and performance.
CloudWatch + Firehose is per-GB ingestion, processing and delivery. The bill scales with your success, for a job that is fundamentally "write a clean record to S3".
AWS WAF is priced per web-ACL, per rule, per million requests — and you can't reason about why a request was blocked. It feels like rent, not like a tool you own.
A generic WAF is blind to the application it protects, so it denylists known-bad and lets everything else through. An app-coupled guard inverts that: because we control both client and server, the edge knows the valid request space — and it is tiny. Anything outside it is an attack, a bug, or noise. None of those deserve origin resources.
| Generic WAF | SG/Sentinel | |
|---|---|---|
| Posture | Denylist known-bad, allow the rest | Allowlist known-good, drop the rest |
| Knows the app? | No — generic signatures | Yes — coupled to routes, schemas, contracts |
| Rules | Vendor-configured, opaque, rented | Data in git, versioned, carrying attack technique, confidence, compliance metadata |
| Every block | Often unexplainable | Has a logged, inspectable reason |
| Logging | CloudWatch → Firehose → per-GB pricing | Clean, replayable records written directly to S3 |
| Cost shape | Rent that scales with traffic | Your compute at the edge; avoids per-request WAF and Firehose pricing† |
† The cost argument is qualitative until measured — measurement against the Firehose + WAF baseline is an explicit open item on the roadmap. No invented numbers here.
The load-bearing idea: a CloudFront Function has no network and no filesystem, so it physically cannot write — and by design it must not enforce. Layer 1's whole job is to decide and emit a structured signal. Layer 2 is the sole actor and sole I/O owner. Blocking is just a logged action with an enforcement side-effect.
The signal spine. The envelope — Schema__Sentinel__Signal — is byte-identical across all three targets; only the transport and the sink swap. The full architecture, including the three targets →
The May 2026 design exercise didn't stop at documents — it produced a prototype: the same L1 JS engine and the same L2 Python actor running three ways, with a parity matrix asserting identical signals, log records and enforcement across all of them. A design artefact, not a product — but proof the design is buildable.
The real L1 engine via node, the real Python L2 in-process, local-FS sink. Fully offline, zero AWS. proven
The same JS file behind an HTTP listener under CloudFront-like Node constraints. Catches CF-runtime surprises before AWS. proven
CloudFront Function on viewer-request, Lambda@Edge on origin-request, cache disabled so L2 sees every hit. code-complete
All of the following describes the May 2026 prototype exercise, per its testing manual — not a live or maintained system (see the note above): 149 unit tests passing; both MVP use cases — logging to S3 and blocking obvious-bad — working end to end on the local-direct and local-docker targets. The live AWS path was code-complete and unit-tested via in-memory doubles, but was never run against a real CloudFront distribution. The parity matrix's AWS leg is written and skip-guarded, waiting for a run that hasn't happened.
$ sg sentinel rules test Method Path Source IP Verdict Rule Action GET /index.html 198.51.100.2 allow 0001 pass GET /etc/passwd 185.10.10.10 block 0012 drop_403 GET /wp-login.php 91.20.20.20 block 0018 deflect_404 GET /.env 77.30.30.30 block 0014 deflect_404 GET /index.html 10.0.0.6 block 0003 drop_403 GET (empty) 203.0.113.5 block 0007 drop_403
The canonical request set — the same six requests every target must decide identically. Run it yourself →
SG/Sentinel was designed over 68 days of iterative briefs — 19 documents on day 68 alone — then pressure-tested with two tabletop simulations that traced requests through the paper architecture and surfaced 25 gaps before any code was written, resolved in a consolidated addendum. The design process is part of the system.
Fast-track was redesigned as zero-trust acceleration, honeytokens became the intent signal, and per-IP keying died against residential proxies — all before implementation.
The stories → Prior artOPA's decision/enforcement split, Sigma's compile-to-backend model, OWASP CRS anomaly scoring, deception technology, zero-trust — learned from deliberately.
What was borrowed → The corpusAll 23 documents — the design series, the implementation briefs, the testing manual — captured verbatim and rendered in-page, raw markdown as the source of truth.
The documents →The MVP is a deliberate tiny core. Fingerprint/fast-track, anomaly scoring, the Layer 3 async/LLM tier, the unified evidence-and-compliance graph, and multi-CDN are designed but not built — and the site says so plainly rather than implying otherwise.