# SG/Sentinel Delegation And Choke-Points: Designing Code To Run Behind The Gate

**version** v0.27.58
**date** 18 May 2026
**from** Human (project lead)
**to** Architect, Developer (lead), Security, AppSec, @Dev
**type** Arch brief

---

## What This Is

The seventh brief in the SG/Sentinel series, and the deeper continuation of the codebase-extension brief. The fuller version of that memo went substantially further than the first capture, and this brief picks up the additional concepts: **choke-points between trust zones, designing application code to delegate to Sentinel, Python as the same-code killer feature, progressive lock-down, and deploy-time parity.**

The core thesis the memo built toward, stated plainly: **from the code's point of view, Sentinel is not a spectator sport.** The LLM and the architect developing the application code must be aware of Sentinel, control it, write its rules, and in some ways execute those rules themselves. The application is designed knowing it runs behind Sentinel, and can delegate responsibilities to it. This is what makes the whole architecture work, and it is what guarantees that deployment holds no surprises.

This brief covers the choke-point placement model, the delegate-to-Sentinel design principle, why Python being the same code everywhere is the killer feature, the progressive lock-down from permissive to minimal, and the deploy-parity requirement that any difference between QA and production behaviour is a major bug.

## Choke-Points Between Trust Zones

The codebase-extension brief introduced the trust-boundary / security-zones concept. The fuller memo completed it with the **choke-point** idea: **the points between one trust zone and another are the critical places to put security checks. You do not validate and authorize everywhere, all the time; you do it at the choke-points.**

The voice memo: **"these choke points between one zone and the other are super critical, because that's the place to put the security checks. You don't want to be validating the function all the time, you don't want to be authorizing the code all the time."**

This is a refinement of the trust-boundary model. A naive reading of "validate at the boundary" could lead to validating everywhere defensively. The choke-point model says the opposite: **identify the specific points where data crosses from one trust zone to another, and concentrate the checks there.** Between choke-points, within a zone, code does not re-validate, because the data is already trusted.

| Anti-Pattern | Choke-Point Pattern |
|--------------|---------------------|
| Validate in every function defensively | Validate at the zone boundaries only |
| Authorize at every layer redundantly | Authorize at the choke-points |
| Scattered checks everywhere | Concentrated checks at critical transitions |
| No clear trust model | Clear zones with explicit choke-points between them |

The voice memo was careful to note this is not absolute: **some authorization should still be done as deep as possible in the code** (defence in depth for the most sensitive operations). That is a different, complementary pattern. But the primary placement of validation, authorization, and sanitization is at the choke-points, with Sentinel being the most important choke-point of all: the one between the untrusted outside and the trusted application.

### The Pragmatic Placement Debate

The voice memo framed the placement of checks as a **pragmatic, dynamic conversation**: who executes which rules at what moment, and who is responsible for what. This is not fixed; it depends on the evolution of the code.

The questions to ask for each check:

- **Who executes it?** Sentinel, or a deeper layer of the application?
- **At what moment?** At the edge (Sentinel), at the API layer, deep in the business logic?
- **Who is responsible for it?** Which part of the system owns this check?

The voice memo: **"we can have a very pragmatic conversation and debate, and even dynamic, depending on the evolution of the code, where the question is who executes the rules at what moment in time, and who is responsible for what."**

This is the horses-for-courses principle from the codebase-extension brief, applied to security checks specifically and treated as an ongoing, evolving decision rather than a one-time design. As the code matures, checks may move: something validated deep in the application early on may move to Sentinel once the pattern is understood. The placement is not static; it is refined as understanding grows.

## The "No 404s At The API Layer" Correctness Signal

A concrete and clever consequence the voice memo named: **if Sentinel is supposed to block invalid requests, then you should never see a 404 at the API layer.** A 404 deep in the system means a request that should have been blocked at the gate got through.

This turns the layered architecture into a self-checking system. The voice memo: **"we shouldn't see any 404 at the API layer, if the Sentinel is supposed to block it."** If the API layer is seeing requests for things that do not exist, either Sentinel's rules are incomplete (it should have blocked them) or there is a coupling gap (Sentinel does not know about a valid endpoint).

This generalises into a powerful principle: **errors at a deeper layer that should have been caught at a shallower layer are signals that the shallower layer's rules are incomplete.** Every such error is information about where the security model has a gap.

| Deep-Layer Error | What It Signals |
|------------------|-----------------|
| 404 at the API layer | Sentinel should have blocked the invalid path, or does not know a valid one |
| Malformed-data error in business logic | Sentinel's validation missed a case |
| Authorization failure deep in the code | The choke-point authorization was incomplete |
| Unexpected input crashing a handler | Sentinel let through something it should have caught |

Each of these is a bug in the security model, surfaced by the deeper layer. This is the "hostile to our own applications" principle from the principles brief, made concrete: the deeper layers act as a check on whether Sentinel is doing its job.

## Every Request Makes The System Better

A framing the voice memo offered: **every request, every action, becomes a way to make the system better.** This is a self-improvement workflow where the system continuously validates and cross-checks that checks are happening at the correct place, at the correct altitude.

The loop:

1. A request arrives and flows through the layers
2. If a deeper layer catches something Sentinel should have caught, that is a signal
3. The signal informs a rule improvement (move the check to Sentinel)
4. The system gets progressively tighter
5. Over time, the checks settle at their correct altitudes

The voice memo: **"every request that happens, every action becomes a way to make the system better, and you have this self-improvement workflow where we're validating and cross-checking and testing everything to make sure the checks are being done at the correct place at the correct altitude."**

This connects to the Layer 3 async analysis from earlier briefs. The async layer can analyse the flow of requests, detect where checks are misplaced, and propose rule changes that move checks to their correct altitude. **The system learns where its checks belong by observing where errors actually occur.**

## Designing Code To Delegate To Sentinel

The most important design principle in the fuller memo: **application code should be designed knowing it runs behind Sentinel, so it can delegate responsibilities to Sentinel.**

This inverts the usual relationship. Normally, application code defends itself because it cannot trust anything in front of it. But if the code knows it runs behind Sentinel, and Sentinel is part of the same codebase and controllable by the same team, then **the code can delegate validation, authorization, and sanitization to Sentinel and trust that they have been done.**

The voice memo: **"the LLM or the architecture of the code of the function should take into account that it is going to be running behind a Sentinel, so you can delegate to the Sentinel."**

This requires communication between the application design and Sentinel:

- **What schemas** does the application expect? Sentinel validates against them.
- **What architecture** does the application have? Sentinel knows its shape.
- **What designs** does the application use? Sentinel is designed to complement them.
- **What datasets** does the application need? Sentinel can be given them to be more efficient.

The voice memo: **"what kind of schemas, what kind of architecture, what kind of designs, what kind of communication, what kind of datasets can we give to the Sentinel that will make it more efficient?"**

Because we control both the application and Sentinel, this delegation is safe. The application delegates a check to Sentinel; Sentinel performs it; the application trusts the result. The two are designed together, so the delegation is reliable. **The application's design and Sentinel's rules are co-designed; the application offloads what Sentinel can do better at the edge.**

## Python As The Same-Code Killer Feature

A specific technical advantage the voice memo identified: **if Sentinel's code is Python, and the application is Python, then the same code runs in the developer's environment, in the application, and in Sentinel.**

This is the killer feature for Python in this context. The voice memo: **"there is an advantage of doing this in Python, because the code will be the same... this is probably the killer feature for Python, because we can then have a situation where the developer and even our code could also run the rules."**

The consequence is profound for the development workflow:

- The developer can run the rules locally (in Python)
- The application code can run the rules (same Python)
- Sentinel runs the rules (same Python, in production)
- The rules are developed locally, pushed to a local Sentinel, pushed to a live Sentinel
- **No surprises, because it is the same code at every step**

The voice memo: **"that allows us to develop the rules locally, and then push the rules to a Sentinel locally, and then push the rules to a Sentinel live, and make sure that there's no surprises."**

This connects to the local-everywhere principle from the interactivity brief, but with a specific reason: **Python being the same code everywhere means the rule that runs in the developer's test is byte-for-byte the rule that runs in production.** There is no translation, no reimplementation, no edge-runtime-specific rewrite. The same Python rule, everywhere.

The caveat (acknowledged in the earlier briefs): performance. If Python is fast enough at the edge (especially Layer 1, sub-millisecond), it is the clear choice for same-code-everywhere. If not, the performance-critical layers may need Go or Rust, sacrificing the same-code property at those layers. The voice memo's framing suggests: prefer Python for the same-code advantage; measure; use lower-level languages only where performance genuinely demands it (per the optimise-at-the-right-altitude principle).

## Progressive Lock-Down: From Permissive To Minimal

A development-lifecycle principle the voice memo named: **start permissive, then progressively lock down as you discover what should actually happen.**

The voice memo: **"like everything, you start with quite permissive permissions and activities, and then as you discover, as you now know what is supposed to happen, you can really lock it down, and you can reduce the privileges required all the way to the requests."**

The progression:

| Phase | Posture | What Happens |
|-------|---------|--------------|
| **Early** | Permissive | Observe what valid traffic looks like; do not block much yet |
| **Learning** | Tightening | As patterns become clear, add rules; move toward allowlist |
| **Mature** | Minimal | Lock down to exactly what is valid; drop everything else |

This is the path to the no-invalid-request principle. You cannot start with a perfect allowlist because you do not yet know exactly what valid looks like. So you start permissive (observe-mode from earlier briefs), learn the valid profile, and progressively lock down until only valid requests are allowed.

The voice memo tied this back to the core principle: **"there should be no request made to the backend servers that is not a valid request, so we should be blocking everything at the gate."** Progressive lock-down is how you get there safely: observe, learn, tighten, until the gate allows only what is valid.

This connects to the dev/main/prod phase model from the interactivity brief and the observe-before-enforce pattern from the execution-model brief. Progressive lock-down is the same discipline viewed over the lifetime of an endpoint: it starts permissive and ends minimal, with the tightening happening as understanding grows.

## Deploy-Parity: Any QA-Versus-Production Difference Is A Major Bug

The thesis the voice memo closed on, and a strong one: **if production ever behaves differently from QA, unit tests, and integration tests, that is a major bug that must be addressed.**

The voice memo: **"if you ever deploy and you have a different side-effect on live than you have on our QA and unit tests and integration tests, that's a major bug which needs to be addressed."**

This is the deploy-parity requirement, and it follows directly from the same-code-everywhere property. If the rules are the same code in QA and production (Python everywhere), and the deployment is the same bundle (the phase model), then production must behave identically to QA. Any divergence means something is different that should not be, and that difference is itself the bug.

This is a high bar, and deliberately so. It is enabled by:

- **Same code everywhere** (Python, byte-for-byte identical rules)
- **Local-everywhere** (the whole stack runs locally identically)
- **Main equals production** (the phase model; no gap between tested and shipped)
- **Phase-aware bundles** (the production bundle is exactly the tested rule-set)

When all of these hold, deploy-parity is achievable: what you tested is what you ship, running the same code, so it behaves the same. **A divergence is not "just a deployment quirk"; it is a bug in one of these guarantees, and it gets fixed.**

## The Core Thesis: Not A Spectator Sport, From The Code's Point Of View

Pulling it together, the memo's core thesis: **from the code's point of view, Sentinel is not a spectator sport.** The voice memo: **"the LLM that is helping, and the architect that's helping to develop the actual code that the Sentinel is going to call, needs to be aware, needs to control, needs to write the rules, and in some ways execute the rules that will be executed by Sentinel."**

The application developers (human and agent) are not passive recipients of a security layer someone else manages. They:

- Are **aware** of Sentinel (the code is designed knowing it runs behind it)
- **Control** Sentinel (they write and adjust its rules)
- **Write** the rules (Sentinel's rules are part of their codebase)
- **Execute** the rules (the same Python rules run in their environment)

This is what makes deployment safe. Because the developers control and test the exact rules that Sentinel will run, deployment holds no surprises. The security layer is not a separate thing that might behave unexpectedly; it is the developers' own code, tested by them, running identically in production.

This is the culmination of the whole series. SG/Sentinel works because it is owned, app-coupled, type-safe, locally-runnable, rule-defined, co-designed with the application, the same code everywhere, and controlled by the developers who write the application it protects. **The security layer and the application are one system, developed together, deployed together, behaving identically everywhere.**

## How This Composes With The Series

| Brief | Relationship |
|-------|--------------|
| Principles brief | The no-invalid-request and hostile-to-own-apps principles this brief deepens |
| Execution-model brief | The observe-before-enforce pattern progressive lock-down extends |
| MVP brief | The optimise-at-the-right-altitude this brief applies to check placement |
| Rules-engine brief | The rules this brief says the application developers write and execute |
| Interactivity brief | The local-everywhere and phase model deploy-parity relies on |
| Codebase-extension brief | The first capture of this memo; this brief is its fuller continuation |
| **This delegation brief** | **The deeper development principles: choke-points, delegation, Python same-code, lock-down, deploy-parity** |

## What This Asks For

Concrete next steps:

1. **Define the choke-points** in the architecture (where trust zones meet) and concentrate checks there.
2. **Establish the delegate-to-Sentinel design principle** so application code is written knowing it runs behind Sentinel.
3. **Build the application-to-Sentinel communication** (schemas, datasets, designs that make Sentinel efficient).
4. **Commit to Python for same-code-everywhere** where performance allows; measure and use lower-level languages only where needed.
5. **Implement the no-deep-layer-errors check** (e.g. no 404s at the API layer if Sentinel should block them).
6. **Build the self-improvement loop** (deep-layer errors inform rule placement at the correct altitude).
7. **Implement progressive lock-down** (permissive to minimal as the valid profile is learned).
8. **Enforce deploy-parity** (any QA-versus-production behaviour difference is a tracked, fixed bug).
9. **Make rule authorship part of application development** (developers write the Sentinel rules for their code).

Estimated effort: largely discipline and integration rather than standalone build; the practices are adopted as Sentinel and the application are co-developed.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not a removal of defence in depth.** Choke-points are primary, but the deepest operations still get deep checks.
- **Not Python-only mandate.** Python preferred for same-code; lower-level languages where performance demands.
- **Not a claim that delegation removes all application-side checks.** Delegation is for what Sentinel can do better; critical checks may be duplicated.
- **Not a static placement model.** Check placement is dynamic, refined as the code evolves.
- **Not a replacement for the codebase-extension brief.** This is its deeper continuation.

## Honest Risks

Three risks:

**Risk 1: Delegating checks to Sentinel could create a false sense of safety.** If the application trusts Sentinel for a check Sentinel does not actually do, there is a gap. Mitigation: the delegation contract is explicit; the no-deep-layer-errors check surfaces gaps; defence in depth for the most critical operations.

**Risk 2: Python performance at the edge may not hold.** If Python is too slow at Layer 1, the same-code-everywhere advantage breaks for the fast layers. Mitigation: measure; accept lower-level languages at the performance-critical layers; keep same-code where it matters most (the developable rule logic).

**Risk 3: Deploy-parity is a high bar that could be violated subtly.** Edge-runtime quirks could cause production to differ from local in ways that are hard to detect. Mitigation: the lambda-as-container equivalence; test the equivalence regularly; treat any divergence as a P1 bug.

## Open Questions

| Question | Notes |
|----------|-------|
| Where exactly are the choke-points in our architecture? | Sentinel is primary; internal zone boundaries need mapping |
| How does the application declare what it delegates to Sentinel? | A delegation contract; format TBD |
| Is Python fast enough at Layer 1? | Must measure; CloudFront Functions are JS, so Layer 1 may be JS regardless |
| How is the no-deep-layer-errors check implemented? | Monitor deep-layer errors; alert when Sentinel should have caught them |
| How aggressive is progressive lock-down? | Per-endpoint; observe until confident, then tighten |
| How is deploy-parity verified? | Compare QA and production behaviour; any difference is a bug |
| Who owns rule authorship: the app developers or a security team? | The app developers (agent and human), with AppSec review |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__arch-brief__sg-sentinel-as-codebase-extension.md` | The first capture of this memo; this brief is its fuller continuation |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-interactivity-and-deployment-phases.md` | The local-everywhere and phase model deploy-parity relies on |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | The rules the application developers write and execute |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The optimise-at-the-right-altitude applied to check placement |
| 18 May | `v0.27.58__arch-brief__edge-layer-execution-model-layered-responders.md` | The no-invalid-request and observe-before-enforce this brief deepens |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | The hostile-to-own-apps principle made concrete here |
| 16 May | `v0.27.45__strategy-brief__appsec-mini-tools-on-top-of-vaults.md` | AppSec review of the rules; threat-modelling the choke-points |
| 16 May | `v0.27.45__arch-brief__vault-testing-framework.md` | The testing discipline deploy-parity depends on |
| 13 May | `v0.27.40__arch-brief__cli-first-agent-architecture.md` | The agentic development model |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Choke-points are identified and checks concentrated there | Trust-zone boundaries mapped |
| 2 | Application code is designed to delegate to Sentinel | Delegation contract exists |
| 3 | Application-to-Sentinel communication (schemas, datasets) works | Sentinel is given what makes it efficient |
| 4 | Python same-code runs in dev, application, and Sentinel | Same rule everywhere where perf allows |
| 5 | No deep-layer errors that Sentinel should have caught (e.g. no API-layer 404s) | Monitored; gaps surfaced |
| 6 | The self-improvement loop moves checks to the correct altitude | Errors inform rule placement |
| 7 | Progressive lock-down works (permissive to minimal) | Endpoints tighten as profile is learned |
| 8 | Deploy-parity holds (QA behaviour equals production) | Any difference is a tracked bug |
| 9 | Application developers author the Sentinel rules for their code | Rule authorship is part of dev |
| 10 | Defence in depth retained for the most critical operations | Deep checks coexist with choke-point checks |

---

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