sgit newsroom v0.1.29 · snapshot 2026-09-24

Reading room · sg-sentinel.sgit.ai

On this page

Reading room / sg-sentinel.sgit.ai · raw text · live ↗

From sg-sentinel.sgit.ai, the page as fetched on 2026-09-25 · open the live page ↗Everything on this sheet is the source site's own text; the newsroom's chrome is outside it.

sg-sentinel.sgit.ai — Layer 1 decides and signals; Layer 2 acts and writes

⚠ Not built. SG/Sentinel is a published design — research documents and ideas from May 2026, presented as "this is how I would build it" in the hope that somebody builds it. The project lead would really like to use this next generation of WAF security layer in his projects, but has no plans to build it unless somebody funds it. The full note↗.

SG/Sentinel is a design for an app-coupled edge security and logging layer built on your own primitives instead of rented AWS WAF + CloudWatch/Firehose. Because the app knows what a valid request looks like, the edge allowlists rather than denylists — no invalid request reaches the origin. Rules are data, versioned in git, carrying their own metadata.

Source: https://sg-sentinel.sgit.ai/index.html↗ · site v0.1.1 · markdown twin of the front page.


The problem

Renting your own blind spot: no real-time view of traffic, logging as a major cost line (CloudWatch + Firehose per-GB), and a rule-opaque WAF priced like rent. Under it all, one fear: a client-side bug once caused runaway redirect traffic, and nothing at the edge would catch the next one before the bill did.

The idea

Generic WAFSG/Sentinel
PostureDenylist known-badAllowlist known-good
Knows the app?NoYes — coupled to routes, schemas, contracts
RulesVendor-configured, rentedData in git with attack/confidence/compliance metadata
Every blockOften unexplainableHas a logged, inspectable reason
LoggingCloudWatch → FirehoseClean, replayable records straight to S3

The architecture

Slow analysis, fast enforcement, in three layers. Layer 1 (CloudFront Function, no I/O — it cannot write and must not enforce) decides and emits a structured signal, Schema__Sentinel__Signal. Layer 2 (Lambda@Edge, the sole actor and sole I/O owner) validates the signal, enforces pass / 403 / 404, and writes one replayable log record to the sink. Layer 3 (deferred) thinks asynchronously — never inline. The signal envelope is byte-identical across all targets; only the transport and the sink swap. The full architecture ↗.

The proof

Same rule engine across three targets — local Node, local Docker (CloudFront-environment simulation), live AWS — with a parity matrix asserting identical decisions across all of them. 149 unit tests passing; both MVP use cases (logging to S3, blocking obvious-bad) working end to end. Status, precisely: local-direct and local-docker are proven and tested; the live AWS path is code-complete and unit-tested via in-memory doubles but has not yet been run against a real CloudFront distribution. Try it ↗ · Roadmap ↗.

The method

Designed over 68 days of iterative briefs, pressure-tested with tabletop simulations that surfaced 25 gaps before any code was written — fast-track redesigned as zero-trust acceleration, honeytokens as an intent signal, per-IP keying dropped against residential proxies. The research ↗ · all 23 documents, readable in-page ↗ · the code snapshot ↗.

Site