# SG/Sentinel Consolidated Addendum: Prior Art, Cross-Cutting Observations, And Gap Resolutions

**version** v0.27.58
**date** 18 May 2026
**from** Human (project lead)
**to** Architect, Developer (lead), Security, AppSec, @Dev
**type** Addendum (to the SG/Sentinel series)

---

## What This Is

A consolidated addendum to the SG/Sentinel series, written after the tabletop simulations and a fresh round of prior-art research. Rather than retrofit fourteen briefs, this single document captures three things: **the prior art the series should position against (OPA, Detection-as-Code/Sigma, deception technology, zero-trust), the cross-cutting observations that span multiple briefs, and the resolutions to the tabletop gaps.** It is the bridge between the design series and the MVP build.

The series body stays intact (it preserves the design history); this addendum is where the consolidation, the external grounding, and the gap resolutions live. The companion future-research document holds what is deliberately parked for later.

## Part 1: Prior Art And Positioning

The SG/Sentinel design converged independently on several patterns that are established, named disciplines in the industry. This is reassuring (the design is sound) and useful (we can learn from mature implementations and position deliberately). Three bodies of prior art matter most.

### OPA / Rego: Policy-As-Code As The Rules-Engine Precedent

The Open Policy Agent (OPA) is a CNCF-graduated, general-purpose policy engine, and it is almost exactly our rules-engine model, independently validated and battle-tested. OPA decouples policy decision-making from policy enforcement: software queries it with structured JSON input, and it returns a decision. Critically, OPA decisions are not limited to allow/deny; policies can return arbitrary structured data. Its policy language, Rego, is declarative and purpose-built for fast evaluation over structured data like API requests.

What our series got right that OPA confirms:

| SG/Sentinel Concept | OPA Equivalent |
|---------------------|----------------|
| Rules are everything; tiny core engine | OPA's small core + Rego policies as the substance |
| Per-rule least privilege; structured in/out | OPA's structured JSON input and arbitrary structured output |
| Rules-as-vault, versioned | OPA's centralised, version-controlled policy library |
| Decisions beyond allow/block | OPA decisions return arbitrary structured data |
| Substrate-independent (edge, Lambda, container) | OPA runs as service, sidecar, CLI, or Lambda |

What we should learn and apply:

1. **Adopt the decision-point / enforcement-point (PDP/PEP) split explicitly.** OPA's rigour is the clean separation: the policy *decision* (what should happen) is distinct from the *enforcement* (making it happen). Our layers blur this; naming it sharpens the design. Layer 1/2 enforce; the rule engine decides.
2. **Decisions return structured data, not verdicts.** We already lean this way (verdict plus reason plus next-rules); OPA validates going further: a rule decision can carry rich structured output that downstream layers act on.
3. **The positioning question: adopt Rego, or build our own?** OPA/Rego is mature, but Rego has a notable learning curve and is a separate language (against our Python-same-code-everywhere killer feature). The likely answer: **build our own Python-native rule engine, but cite OPA as prior art and borrow its PDP/PEP discipline and structured-decision model.** We keep same-code-everywhere; we inherit OPA's architectural lessons.

### Detection-As-Code / Sigma: The Rule-Development Discipline

Our rules-as-vault plus LLM-assisted rule development is, independently, the named discipline of **Detection-as-Code (DaC)**, with Sigma as its canonical rule format. In DaC, every rule lives in a version-controlled Git repository, changes go through pull-request peer review, and rules are tested against labelled data before deployment. Sigma is a vendor-agnostic YAML rule format compiled to specific backends, avoiding vendor lock-in.

What this confirms and adds:

| SG/Sentinel Concept | DaC / Sigma Equivalent |
|---------------------|------------------------|
| Rules-as-vault, RFD-versioned | Rules in Git, PR-reviewed |
| Rule testing in isolation | Rules tested against labelled data |
| LLM-assisted rule development | DaC's codify-and-automate workflow |
| Substrate-portable rules | Sigma's vendor-agnostic compile-to-backend model |
| ATT&CK-tagged rules | DaC's MITRE-organised rule libraries |

Two sharp lessons we had not captured:

1. **Rule retirement: the detection library is living infrastructure, not a trophy cabinet.** Mature DaC practice retires rules when they are no longer useful, and crucially: *if a control covers a behaviour more efficiently than a rule, implement the control and save the compute and storage*. Our series only ever adds rules; it never retires them. **We need a rule-retirement discipline and a "is this better as a control than a rule?" review.** This connects to the art-of-the-possible reduction: many rules become unnecessary once the valid space is constrained.
2. **The Sigma compile-to-backend model is how we stay multi-CDN.** Rather than write rules per-substrate, write rules in our canonical format and compile to CloudFront Functions / Cloudflare Workers / Fastly. Sigma proves the pattern. This is the concrete mechanism for the substrate-independence principle.

### Deception Technology And Zero-Trust: The Missing Signal

This is the most valuable find, because it resolves a real tabletop gap. Our "make the site hostile / wild goose chase / don't play ball with attackers" instinct is the mature field of **deception technology** (honeytokens, decoys, tarpits), and it directly closes the fast-tracked-user-turns-malicious gap (tabletop GAP 9.3).

The key insight from the field: **while IAM verifies identity, it cannot confirm intent. Deception provides the missing signal.** If a verified, fast-tracked user accesses a decoy or touches a honeytoken, that is a high-fidelity indication the session is compromised, allowing trust to be revoked automatically at machine speed.

This is precisely the answer to GAP 9.3. A fast-tracked user is identity-verified, but Sentinel cannot read their intent. A honeytoken (a decoy endpoint or resource that no legitimate flow ever touches) is the intent signal: if a fast-tracked fingerprint touches it, the session is compromised, and fast-track is revoked instantly.

What to add to the design:

1. **Honeytokens as a rule type.** Add a deception rule category: decoy endpoints, decoy resources, honeytokens placed where only reconnaissance would find them. A request to one is a near-zero-false-positive compromise signal.
2. **Honeytoken-touch revokes fast-track.** The highest-fidelity use: a fast-tracked (identity-verified) fingerprint touching a honeytoken instantly revokes trust and flags the session. This resolves GAP 9.3 with an industry-proven mechanism.
3. **Deception as the active form of "wild goose chase".** Our deflection action becomes a deliberate deception layer: make deceptive assets appear production-real, disrupting the attacker's ground truth, while real assets are protected. This is a richer, named version of the instinct.

And the zero-trust connection, which reframes fast-track correctly:

**Fast-track, post-tabletop, is zero-trust continuous verification, not perimeter trust.** The BeyondCorp model moved enforcement from the network perimeter to strong identity verification applied everywhere, treating all access as untrusted by default with context-aware controls. This is exactly what fast-track must become (per tabletop GAP 9.1/9.2): not "trusted users skip checks" but "identity-verified users skip the expensive identity-establishment cost, while authorisation is always enforced and trust is continuously re-verified". Fast-track is zero-trust acceleration, not perimeter trust. The honeytoken is the continuous-verification signal.

## Part 2: Cross-Cutting Observations

Observations that span multiple briefs and are worth stating once, explicitly.

### Observation 1: The Three Graphs Are One Graph

The series describes three semantic graphs: the **evidence graph** (developer-friendliness brief), the **compliance graph** (compliance brief), and the **rule graph** (rule-architecture brief). Plus the attack-tree mapping (research brief).

These are almost certainly one unified graph, not four. A rule maps to the attack-trees it prevents, which map to the compliance-requirements they satisfy, and the evidence accumulated is the runtime instances of those rules firing. They share nodes:

```
RULE ──prevents──► ATTACK-TREE (ATT&CK technique)
  │                      │
  satisfies              observed-as
  │                      │
  ▼                      ▼
COMPLIANCE-REQ      EVIDENCE (runtime instances)
```

**Recommendation: unify them as one semantic graph with typed nodes (rule, attack-technique, compliance-requirement, evidence-instance) and typed edges (prevents, satisfies, observed-as).** This is a significant simplification: one graph infrastructure, one query model, one storage substrate (the vault). The MVP need not build all of it, but the data model should assume one graph from the start, not four to be reconciled later.

### Observation 2: Replay-From-S3 Is The Test Corpus

Logs land in S3 (the architecture brief). Detection-as-Code tests rules against labelled sample logs. **These are the same thing.** Production traffic stored in S3 is the regression-test corpus for new rules.

This is an almost-free, powerful capability: before deploying a new rule, replay it against last week's real traffic from S3 and answer **"would this rule have blocked anything legitimate?"** This is the differential-testing capability (interactivity brief) applied to real history, and it directly de-risks the false-positive concern that runs through the series.

**Recommendation: design the log format in S3 to be replayable (enough fidelity to re-run rules against it), and build replay-from-S3 as the rule-testing mechanism.** This connects logging (use case 1) and rule development into one loop.

### Observation 3: Sentinel Must Guard Its Own Control Plane

The two-way conversation API (MVP brief) and the admin interface are a high-value attack surface. Nothing in the series says Sentinel guards its own control plane the way it guards everything else.

**Recommendation: the Sentinel admin/API surface is itself behind Sentinel rules.** The control plane is a protected application like any other: no-invalid-request applies, the API is allowlisted, access is fingerprinted and authorised, and admin actions are the most-audited events. The guard guards itself. This should be explicit in the MVP (the admin API is API-key-protected from the start, per the MVP brief, but it should also be behind the same rule discipline).

### Observation 4: Rule Retirement Is Missing

Per the DaC lesson: the series only adds rules. A mature rule library retires rules that are no longer useful or that a control now covers more efficiently. Without retirement, the rule graph grows unboundedly and accumulates dead rules.

**Recommendation: add a rule-retirement discipline.** Rules carry usage metrics (how often they fire, what they catch); rules that never fire or are superseded by a control are flagged for retirement; the "is this better as a control than a rule?" question is part of rule review. This keeps the rule library lean (the minimal-bundle principle over time).

### Observation 5: The Fingerprint Is The Spine

After the tabletop, the fingerprint emerges as the central object more than any brief credited. It is the key for fast-track (time brief), the trust-revocation target (deception), the evidence-graph key when IP is escrowed (tabletop GAP 3.2), the per-user authorisation anchor (tabletop GAP 9.1), and the multi-dimensional correlation key (tabletop GAP 8.2/10.3).

**Recommendation: treat the fingerprint as a first-class, well-specified object early in the MVP**, because so much depends on it. Its definition (which signals, how combined, how validated, how time-bounded) is foundational, and the tabletop showed several gaps trace back to it being under-specified.

## Part 3: Tabletop Gap Resolutions

The resolutions to the major tabletop gaps, consolidated as the corrections that fold into the behavioural spec before MVP coding.

| Gap | Resolution |
|-----|------------|
| **2.1 / 9.1 / 9.2 Fast-track** | Fast-track is zero-trust acceleration: identity-verified users skip the expensive identity-establishment cost; authorisation is ALWAYS enforced (per-user profile); trust is continuously re-verified. Use a signed token (cryptographic, stateless) carried by the user, validatable at Layer 1 without a lookup, not an IP-based allowlist. |
| **9.3 Trust revocation** | Honeytokens (deception) provide the compromise signal: a fast-tracked fingerprint touching a honeytoken instantly revokes fast-track and flags the session. |
| **5.1 / 5.2 Symmetry blocks deploys** | The known-good profile is a deploy artefact, generated from the app's routes/OpenAPI, deployed atomically with the app, owned by the deploy pipeline. Observe-mode first (flag unknown paths, do not block) until the profile is trusted. |
| **7.1 Banned-list update speed** | A fast-updating banned-list store that Layer 2 checks (or a fast Layer 1 data channel), separate from the slow-changing embedded list refreshed by redeploy. |
| **8.2 / 10.3 Per-IP insufficient** | Multi-dimensional evidence keying: source, target (per-account), and behavioural signature, not just per-IP. Rate-limiting is per-target as well as per-source. |
| **8.3 Auth-outcome blindness** | The application reports auth outcomes (login success/failure) to Sentinel: a reverse-coupling so Sentinel can detect-before-damage on brute-force. |
| **11.1 / 11.2 In-profile exploits** | No-invalid-request is necessary but not sufficient. CRS-pattern content rules inspect valid-shape requests for injection; LLM interpretation (async) catches obfuscated attacks; and the app must also be secure (Sentinel is defence in depth, not sole defence). Honest limit, documented. |
| **3.1 / 3.2 IP-logging privacy vs attribution** | "IP escrowed" mode (capture but encrypt, decryptable only under defined threat conditions), not binary on/off. The evidence graph keys on fingerprint, coupled with the anonymity mode. |
| **1.1 / 1.2 / 4.x Logging and cache** | Define the log-finalisation owner per path (the terminal-decision layer writes the final log). Layer 1 always runs; Layer 2 on cache miss; Layer 1 must suffice for cached static content. Log schema distinguishes cache-hit from cache-miss. |
| **6.1 Block actions** | Define block actions at the HTTP level (drop = 403 empty or connection close; deflect = 404; wild-goose-chase = deception/tarpit). |

These resolutions are the corrected behavioural spec for the MVP. The behavioural-spec brief should be read with these applied.

## What This Addendum Does Not Do

- **It does not rewrite the series.** The briefs stand as the design history; this is the consolidation.
- **It does not resolve everything.** The future-research document holds what is parked.
- **It does not mandate adopting OPA/Sigma.** It positions against them; the build decisions (own engine vs Rego, canonical-format-then-compile) are made at MVP design.

## Relationship To The Series

This addendum consolidates across all fourteen prior SG/Sentinel briefs plus the three tabletop/spec documents. It is the single reference for prior-art positioning, cross-cutting observations, and gap resolutions, and the bridge to the MVP.

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).