# SG/Sentinel As An Extension Of The Codebase: Type-Safe Validation, Agentic Development, And Security Zones

**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 sixth brief in the SG/Sentinel security-tools series, zooming in on what the voice memo called **"the bit that makes everything work, which is the code."** Where the previous briefs covered the architecture, the rules engine, and the deployment lifecycle, this one is about the development philosophy: **SG/Sentinel should be treated as an extension of the existing codebase, not a separate bolted-on security tool.**

Three ideas anchor this brief:

- **Sentinel is continuous with the application code.** The same codebase, the same type-safety discipline, the same agentic development workflow. Security logic is not a separate thing written by a separate team in a separate tool; it is part of the code.
- **Type-safe runtime validation reduces complexity.** Our Type_Safe capability (from osbot-utils) does runtime validation, which reduces code complexity because once data is validated at a point, downstream code does not have to worry about it. This same discipline applies to Sentinel.
- **Horses for courses.** Do the right thing at the right altitude, at the right location. Authorization, validation, sanitization each belong at a specific layer; the security-zones / trust-boundary concept from threat modelling is the frame.

This brief covers why agentic development makes a codebase-integrated security layer possible now (when it never worked before), how type-safety reduces the complexity that security logic usually adds, the horses-for-courses placement principle, and the security-zones framing that gives it structure.

## Why This Never Worked Before

The voice memo named something important: **a security layer that is genuinely part of the codebase, developed collaboratively by multiple agents and people, never worked before.** The blame, per the voice memo: **licensing, deployment friction, and security tools not being as easy to deploy locally as in production.**

The historical failure modes:

| Barrier | Why It Blocked Codebase-Integrated Security |
|---------|----------------------------------------------|
| **Licensing** | Commercial WAFs and security tools were licensed products, not code you could integrate and modify freely |
| **Deployment friction** | Security tools were hard to deploy, especially locally; you could not run the WAF on your laptop |
| **Local-production gap** | The security layer in production was not the security layer you could develop against locally; they diverged |
| **Separate ownership** | Security was a separate team's separate tool, not the developers' code |

These barriers meant security was always external to development. You wrote code; then a separate security layer, owned by someone else, deployed somewhere you could not easily reach, tried to protect it without understanding it. The result is the bolted-on-and-weakened failure mode from the previous brief.

What changed:

- **Agentic development** means the AppSec agent, the developer agent, and the QA agent can all work on the same code, with the intersection of skills the voice memo named.
- **Local-everywhere** (from the interactivity brief) means the security layer runs on your laptop identically to production.
- **Our own code, not a licensed product** means we can integrate, modify, and refactor freely.

The voice memo: **"this is something that never worked before... we can have this intersection of skills, the AppSec agent can be involved, and the developer agent, and the QA."** The combination of agentic development plus local-everywhere plus owned code is what makes a codebase-integrated security layer possible now.

## Sentinel As An Extension Of The Codebase

The core principle: **SG/Sentinel is an extension of the existing codebase, developed the same way, with the same disciplines, by the same (agentic) team.**

This is the opposite of the traditional model where security is a separate concern handled by separate tooling. In the SG/Sentinel model:

- Sentinel's rules are code, written and reviewed like other code
- The same type-safety discipline applies
- The same testing framework applies
- The same agentic development workflow applies (AppSec + developer + QA agents)
- The same version control and deployment discipline applies
- Security logic is continuous with application logic, not separated from it

The benefit is the coupling principle from earlier briefs, realised at the development level. Because Sentinel is part of the codebase, it understands the application. Because it understands the application, it can protect it precisely. The understanding comes from being part of the same code, developed by the same team, with the same knowledge.

## Type-Safe Validation Reduces Complexity

A specific and important technical point the voice memo made: **a lot of code complexity comes from data validation, authorization, and sanitization logic. Type-safe runtime validation reduces this complexity.**

Our Type_Safe capability (part of osbot-utils) does runtime validation. The key insight: **once you know that data has been validated at a particular point, downstream code does not have to re-validate or worry about it.** The validation happens once, at the boundary; everything past the boundary can trust the data.

The voice memo: **"that actually reduces the complexity of code, because you know that at a particular point the code is already going to be validated, so you don't have to worry about it."**

This matters enormously for a security layer, because security logic is disproportionately validation logic. Consider what a WAF does: it validates that requests are well-formed, that parameters are within bounds, that data matches expected shapes, that authorization is correct. **All of this is validation.** If the validation is expressed as type-safe runtime checks at the boundary, then:

- The validation is declarative (the type defines what valid means)
- The validation happens once, at the edge
- Downstream code (the application) can trust validated data
- The complexity is concentrated at the boundary, not scattered through the code

This is why Sentinel-as-codebase-extension and Type_Safe go together. **Sentinel is, in large part, the type-safe validation boundary for the whole application.** It validates at the edge, using the same Type_Safe discipline the application uses internally, and everything past Sentinel can trust the data.

The complexity reduction is real and compounding. Traditional architectures scatter validation through every layer because no layer can trust the others. A type-safe boundary at Sentinel means the application's internal code can be simpler, because it can trust that what reaches it has already been validated. **Security at the edge reduces complexity everywhere behind the edge.**

## Horses For Courses: The Right Thing At The Right Altitude

The voice memo named a principle it called **"horses for courses"**: do the right thing at the right altitude, at the right location. This generalises the optimise-at-the-right-altitude principle from the MVP brief into a placement philosophy for all of Sentinel's logic.

Different security functions belong at different layers:

| Function | Right Altitude | Why |
|----------|----------------|-----|
| Block known-bad IP | Layer 1 (fast, edge) | Cheap lookup; reject before any cost |
| Reject malformed request | Layer 1 (fast, edge) | Fast structural check; no need for more |
| Validate request shape | Layer 1-2 | Type-safe validation at the boundary |
| Authorize against complex policy | Layer 2 | Needs context, possibly a lookup |
| Deep authorization with external data | Layer 2 | Needs network/file access |
| Analyse attack pattern | Layer 3 (async) | Slow analysis, off the hot path |
| Generate new rules from traffic | Layer 3 (async, LLM) | LLM work, never inline |

The horses-for-courses principle is the placement discipline: **for each function, ask what the right altitude and location is, and put it there.** Do not do at Layer 2 what could be done at Layer 1. Do not do inline what should be async. Do not use an LLM where a type-check suffices.

This connects to the rules-engine brief's rule spectrum (deterministic to LLM-driven) and the execution-model brief's layers. The horses-for-courses principle is how you decide which rule type and which layer a given security function belongs to. **The right altitude is a first-class design decision for every piece of security logic.**

## Security Zones And Trust Boundaries

The voice memo reached for a threat-modelling concept it could not quite name: **security zones, or trust boundaries.** The idea: in threat modelling, you define trusted zones, and once data crosses the boundary into a trusted zone, it is trusted. The boundary is where validation and authorization happen; past the boundary, code can assume the data is good.

This is the **trust boundary** concept (sometimes called trust zones or security zones in threat-modelling frameworks like STRIDE). The classic pattern: untrusted input crosses a trust boundary, where it is validated and sanitized; inside the boundary, the validated data is trusted.

SG/Sentinel is, architecturally, **the trust boundary for the whole application.** Everything outside Sentinel is untrusted. Sentinel validates, authorizes, and sanitizes at the boundary. Everything inside (the application) can trust what Sentinel has passed through.

This gives the whole architecture a clean threat-modelling structure:

| Zone | Trust Level | What Happens |
|------|-------------|--------------|
| **Outside Sentinel** | Untrusted | The internet; anything can arrive |
| **Sentinel (the boundary)** | The validation point | Validate, authorize, sanitize, log; the type-safe boundary |
| **Inside Sentinel** | Trusted | The application; can trust what reached it |

The voice memo's instinct connects directly to the type-safe-validation point. **The trust boundary is where the type-safe validation happens.** Sentinel is the trust boundary; the type-safe validation at Sentinel is what establishes the trust; everything inside the boundary can rely on that trust.

This is the threat-modelling formalisation of the coupling principle and the no-invalid-request principle. Sentinel knows what valid looks like (coupling); it validates at the boundary (type-safe); it drops what is invalid (no-invalid-request); everything past the boundary is trusted (security zones). The principles from the earlier briefs all converge at the trust boundary that Sentinel is.

## The Agentic Development Model

Worth being explicit about how the multi-agent development works, since the voice memo named it as the thing that makes this possible now.

The agents involved in Sentinel development:

| Agent Role | Contribution |
|------------|--------------|
| **Developer agent** | Writes the rules and engine code |
| **AppSec agent** | Threat-models the rules; identifies what each should defend against; reviews for security |
| **QA agent** | Generates tests, adversarial inputs, validates behaviour |
| **Architect agent** | Designs rule structure, composition, layer placement |

The voice memo named the intersection of skills: **"we can have this intersection of skills, the AppSec agent can be involved, and the developer agent, and the QA."** This is the LLM-heavy-at-development-time pattern from the rules-engine brief, realised as a multi-agent collaboration.

The key point: because Sentinel is part of the codebase and runs locally, all these agents can work on it together, locally, with fast feedback. The AppSec agent can threat-model a rule, the developer agent can implement it, the QA agent can test it, the architect agent can place it at the right altitude, all in the local environment, all before anything goes to production. **The intersection of agent skills, applied to a locally-runnable codebase-integrated security layer, is what makes high-quality security development possible at speed.**

## How This Composes With The Series

| Brief | Relationship |
|-------|--------------|
| Principles brief | Substrate independence enables the local development this brief relies on |
| Execution-model brief | The layers the horses-for-courses principle places logic across |
| MVP brief | The optimise-at-the-right-altitude principle this brief generalises |
| Rules-engine brief | The rules this brief says are developed as codebase extensions |
| Interactivity brief | The local-everywhere property this brief's development model relies on |
| **This codebase-extension brief** | **The development philosophy that ties the technical model to how it is built** |

This brief is the development-philosophy capstone of the series: it explains why Sentinel is built as part of the codebase, how type-safety reduces the complexity security usually adds, how horses-for-courses governs placement, and how the trust-boundary framing gives it threat-modelling structure.

## What This Asks For

Concrete next steps:

1. **Treat Sentinel as part of the main codebase**, not a separate project, with the same disciplines.
2. **Apply Type_Safe runtime validation** as the core mechanism of Sentinel's request validation.
3. **Establish the trust-boundary architecture**: Sentinel is the validation boundary; inside is trusted.
4. **Document the horses-for-courses placement framework**: how to decide the altitude for each function.
5. **Set up the multi-agent development workflow** (developer, AppSec, QA, architect agents) for rules.
6. **Make security-zone / trust-boundary modelling explicit** in the rule design process.
7. **Measure the complexity reduction** from type-safe boundary validation versus scattered validation.
8. **Ensure the application's internal code can trust Sentinel-validated data**: realise the complexity reduction.

Estimated effort: this is largely a discipline and workflow brief; the effort is in adopting the practices (type-safe boundary, multi-agent development, trust-boundary modelling) as Sentinel is built, rather than a separate work item.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not a separate security codebase.** The whole point is that Sentinel is part of the main codebase.
- **Not a replacement for the rules-engine model.** This is the development philosophy around it.
- **Not a new validation library.** It uses the existing Type_Safe / osbot-utils capability.
- **Not a formal threat-modelling methodology.** It uses the trust-boundary concept pragmatically, not as a heavyweight process.
- **Not a claim that agents replace human review.** The agentic development is collaborative; human judgement remains in the loop for security-critical decisions.

## Honest Risks

Three risks:

**Risk 1: Treating security as codebase-continuous could blur important boundaries.** Security code sometimes needs stricter review than feature code. Mitigation: the AppSec agent and human security review remain first-class; codebase-continuous does not mean review-light; the trust-boundary code is the most-reviewed code.

**Risk 2: Over-reliance on type-safe validation could miss non-type security issues.** Not every security concern is a type-validation concern (logic flaws, authorization bugs, timing attacks). Mitigation: type-safe validation is one layer; the AppSec agent and rule design address the rest; do not assume type-safety is sufficient alone.

**Risk 3: The multi-agent development could produce inconsistent or conflicting rules.** Multiple agents working on rules could create overlap or conflict. Mitigation: the architect agent owns coherence; rule composition is explicit; the testing framework catches conflicts; human review for significant changes.

## Open Questions

| Question | Notes |
|----------|-------|
| How much of Sentinel's validation can Type_Safe express directly? | Likely most request validation; measure |
| Where exactly is the trust boundary drawn? | At Sentinel; but some internal boundaries may also matter |
| How do the multiple agents coordinate on rule development? | The architect agent owns coherence; needs a workflow |
| Does codebase-continuity create a too-large trusted computing base? | Watch this; the tiny-core-engine principle counterbalances |
| How is the complexity reduction measured? | Compare validation code before and after the type-safe boundary |
| Should the trust-boundary model be formalised in threat-modelling docs? | Lightweight; connect to the AppSec mini-tools (StrideGPT) work |
| How do human reviewers stay in the loop on agent-developed rules? | Review gates for security-critical rules; the RFD process |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__arch-brief__sg-sentinel-interactivity-and-deployment-phases.md` | The local-everywhere development model this brief's philosophy relies on |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | The rules this brief says are developed as codebase extensions |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The optimise-at-the-right-altitude principle generalised here as horses-for-courses |
| 18 May | `v0.27.58__arch-brief__edge-layer-execution-model-layered-responders.md` | The layers the horses-for-courses principle places logic across |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | Substrate independence enables the local development |
| 16 May | `v0.27.45__strategy-brief__appsec-mini-tools-on-top-of-vaults.md` | The AppSec agent and trust-boundary modelling connect to StrideGPT |
| 16 May | `v0.27.45__arch-brief__vault-testing-framework.md` | The testing discipline applied by the QA agent |
| 14 May | `v0.27.41__arch-brief__vaults-of-vaults-self-contained-mini-apps.md` | The codebase-integration pattern |
| 13 May | `v0.27.40__arch-brief__cli-first-agent-architecture.md` | The agentic development model this brief extends to security |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Sentinel is developed as part of the main codebase | Same repo, disciplines, workflow |
| 2 | Type_Safe runtime validation is the core request-validation mechanism | Validation is type-safe at the boundary |
| 3 | The trust-boundary architecture is explicit | Sentinel is the boundary; inside is trusted |
| 4 | The horses-for-courses placement framework is documented | Each function has a justified altitude |
| 5 | The multi-agent development workflow operates (dev, AppSec, QA, architect) | Agents collaborate on rules |
| 6 | Security-zone / trust-boundary modelling is part of rule design | Threat-modelling structure exists |
| 7 | The complexity reduction from type-safe boundary validation is demonstrated | Internal code trusts validated data |
| 8 | Human review remains in the loop for security-critical rules | Review gates exist |
| 9 | The trusted computing base stays small (tiny-core-engine counterbalance) | TCB audited |
| 10 | Application internal code is simplified by trusting Sentinel validation | Measurable complexity reduction |

---

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