NornGate Trust Topology & DigitalOcean Infrastructure

SBS-AI-Security-Report
1. Document Control
Field
Value
Title
SBS AI Security Report: NornGate Trust Topology & DigitalOcean Infrastructure
Date
August 21, 2026
Version
21.0
Scope
norngate-core application, NornGate Light Paper topology, DigitalOcean Infrastructure, Legacy Data Ingestion, Business Unit Compartmentalization, and 3rd-Party Audit Manifest
Audience
SBS Executive Leadership, Board of Directors, Security/Compliance Teams, and Authorized 3rd-Party Auditors
Classification
Confidential — restricted distribution
Purpose: To establish NornGate's and SBS's underlying infrastructure security posture as a verifiable contract — what controls exist, what is missing, and what work is committed — ensuring every claim is understood by executive stakeholders and technically verifiable by external auditors.
Threat Model Summary: (a) External unauthenticated attacker against public endpoints; (b) Prompt-injected AI agent or hostile content processed by agents running on the host; (c) Malicious/compromised third-party npm plugin or adapter (supply chain); (d) Cross-tenant actor; (e) Malicious or compromised board operator (insider); (f) Attacker with host/LAN/backup access; (g) Lateral movement between Dev and Prod environments; (h) Lateral movement between internal business units (Compartments); (i) Malicious data injected via legacy system ingestion (Data Poisoning).
2. List of Acronyms
Acronym
Expansion
AI
Artificial Intelligence
API
Application Programming Interface
AuthN/Z
Authentication and Authorization
BCDR
Business Continuity and Disaster Recovery
CCPA
California Consumer Privacy Act
CORS
Cross-Origin Resource Sharing
CSP
Content Security Policy
CSRF
Cross-Site Request Forgery
CVE
Common Vulnerabilities and Exposures
DB
Database
DLQ
Dead-Letter Queue
DLP
Data Loss Prevention
DoS
Denial of Service
DoW
Denial of Wallet
DR
Disaster Recovery
GDPR
General Data Protection Regulation (EU)
HITL
Human-in-the-Loop
HSTS
HTTP Strict Transport Security
IaC
Infrastructure as Code
JWT
JSON Web Token
LHN
Ledger Hub Networks, LLC
LGPD
Lei Geral de Proteção de Dados (Brazil)
LLM
Large Language Model
MCP
Model Context Protocol
npm
Node Package Manager
OCR
Optical Character Recognition
OWASP
Open Web Application Security Project
PII
Personally Identifiable Information
RBAC
Role-Based Access Control
RCE
Remote Code Execution
RLS
Row Level Security
RPO
Recovery Point Objective
RTO
Recovery Time Objective
SBS
Spanish Broadcasting System, Inc.
SCA
Software Composition Analysis
SQL
Structured Query Language
SQLi
SQL Injection
SSRF
Server-Side Request Forgery
SOW
Scope of Work
TLS
Transport Layer Security
VPC
Virtual Private Cloud
XSS
Cross-Site Scripting
3. Executive Summary
NornGate is a multi-gated AI orchestrator with strong, well-implemented design invariants. The architecture is defined by the 5-Gate Taxonomy (G0-G4) and the Realm Trust Topology (Asgard to Jotunheim). Core application strengths include:
Credential Starvation: AI agents never hold raw credentials. G1 (Tyr) resolves the minimum-scope credential for an approved action, injects it at execution, and revokes it on completion. A prompt-injected agent has nothing durable to exfiltrate.
Origin Isolation: Untrusted code and agent-rendered content execute in Jotunheim and are served from a separate registrable domain, preventing cookie theft against the control plane in Asgard.
Deterministic Gates: Every consequential action transits an explicit, deterministic gate. Deterministic means decided by policy code, never LLM judgment. Fail-closed means an unreachable or erroring gate results in denial.
Telemetry Substrate (The Norns): Every gate decision writes to Urd (audit log/past) before execution, monitored by Verdandi (real-time metrics/present), with Skuld (forecasting/future) ensuring system health.
Build Phase Context & Audit Commitment: It is critical to note that The Dash platform is currently in its foundational deployment phase. The gaps identified in this report—particularly those related to DigitalOcean infrastructure and host access—are "Day 0" findings discovered during the active build process. These gaps are scheduled to be fully remediated before the platform processes live production data.
Upon completion of the foundational installation and gap remediation, Ledger Hub Networks will conduct rigorous internal and external security audits. Furthermore, SBS retains the option to engage an independent third-party security firm (such as Certek) to perform a comprehensive penetration test and compliance validation prior to production go-live.
Infrastructure Context (DigitalOcean As-Built): While NornGate's application-layer architecture is robust, the underlying DigitalOcean infrastructure is currently in a "Day 0" remediation state. Critical environmental gaps were identified during infrastructure auditing, including: plaintext credentials committed to operational changelogs, shared flat VPC networking between Dev and Prod, absent cloud/host firewalls on production droplets, unmitigated egress paths, and shared root SSH access. All infrastructure findings are tracked in the Build Register with active remediation workstreams.
4. The NornGate Trust Topology (Realms & Gates)
Subdomain = Realm. The marketing metaphor and the routing topology are the same diagram. Trust gradient runs from Asgard (highest privilege) to Jotunheim (zero standing privilege).
4.1 The 5-Gate Execution Model
A gate is a deterministic, fail-closed checkpoint. No execution path produces an external side effect without transiting these gates:
Gate
Name / Owner
Enforces
Placement
G0
Ingress — The Gate / Warden
AuthN/Z, tenant resolution, rate limits, schema validation
System edge; nothing enters unauthenticated
G1
Policy — Tyr
Deterministic pre-execution policy: tool permissions, credential scope, RBAC
Before every tool call, every realm crossing
G2
Approval — HITL
Human approval for side effects above a configured risk class
Before external side effects (writes, spend, sends)
G3
Sandbox — Jotunheim Boundary
Egress control, no standing credentials, origin isolation
Around all untrusted code and tool calls
G4
Quality — Forseti
Consensus/judging on contradictory agent outputs; structured-output validation
Before results leave the system
4.2 Realms → Trust Zones
Midgard (
norngate.com): User-facing tier. Humans live here; sessions terminate here.
Asgard (
asgard.): Control plane / governance. Policy, scheduling, admin. Zero-trust access only.
Vanaheim (
vanir.): Federated external integrations. Third-party APIs with negotiated trust.
Jotunheim (
jotun.): Sandboxed / untrusted execution. Unvetted code + untrusted agent tool-calls. Outside Asgard control by design.
Valhalla (
valhalla.): Success archive. Immutable audit trail of completed jobs.
Helheim (
hel.): Dead-letter queue (DLQ). Jobs that did not "die gloriously."
4.3 Failure Semantics & Business Continuity (BCDR)
Two Afterlives: Valhalla (immutable success archive) and Helheim (DLQ). A job is in exactly one afterlife, keeping the audit append-only and completion metrics honest.
Hermod (DLQ Reprocessor): Classifies before retrying. Transient failures get capped exponential backoff. G1/G2 denials surface to a human queue — retrying a denial is an escalation attempt, not resilience.
Ragnarök (DR Drill): The scheduled DR/chaos drill. The myth ends in rebirth — exit criterion is verified recovery: state restored from checkpoints, gates re-armed fail-closed, Norn telemetry confirming steady state.
BCDR Targets: The infrastructure is designed for an RPO (Recovery Point Objective) of < 24 hours via nightly encrypted database backups to SFO3, and an RTO (Recovery Time Objective) of < 4 hours for critical control plane restoration via infrastructure-as-code (IaC) redeployment.
5. Operational Context — Closed System
The organization declares NornGate operates as a Closed System:
System Closed: NornGate is not exposed directly to the internet; all access is mediated through gateway-type connections.
Data Non-Exposed: Data managed by the system is never exposed outside the operational perimeter.
Risk Modulation: This deployment model reduces the probability of exposure for most breaches. Realistic exploitation scenarios concentrate on insider threats, supply chain (npm packages), and lateral movement, rather than direct external attack.
Technical Honesty Note: The closed system context is a declared risk factor, not a code-implemented control. It modulates probability but does not alter the intrinsic severity of the documented gaps. Critical and High findings remain in active remediation as part of the foundation build-out.
6. Layered Security Architecture
"[committed]" = exists in 
doc/plans or spec; "[recommendation]" = proposal from this report.
Layer
Name
Status
Dominant Risk
0
Host & Deployment (DigitalOcean)
🔴 Gap (Day 0)
Shared root SSH, plaintext creds in changelog (SBS-33, SBS-34)
1
Network & Transport (VPC & Firewalls)
🔴 Gap (Day 0)
Shared flat VPC, missing firewalls, open egress (SBS-35, SBS-36, SBS-39)
2
Auth & Authz (G0/G1)
🟡 Partial
No rate limiting; shared dev secret (SBS-05, SBS-07)
3
Multi-Tenant & Compartment Isolation
🟡 Partial
No RLS: second line of defense absent (SBS-11)
4
Execution & Containment (G3/G4)
🟡 Partial
Untrusted code without real sandbox; open host egress; hallucination risk (SBS-01, SBS-02, SBS-03)
5
Secrets, Data & PII (G1)
🟡 Partial
Leakage to 
server.log; key co-located with backups (SBS-04, SBS-10)
6
Audit & Observability (The Norns)
🟡 Partial
Falsifiable log, no integrity/retention (SBS-15)
Layer 0 — Host & Deployment (DigitalOcean) — 🔴 Gap (Day 0)
Present: Dedicated SBS-owned DigitalOcean account; phishing-resistant MFA enforced at account root; Docker 29.1.3 / Compose 2.40.3 deployed; Prod application server isolated via jump-host/bastion pattern through monitor-servers.
Gaps: Root SSH login enabled fleet-wide with a single shared SSH keypair (SBS-33); shared 
sbsRoot account with 
NOPASSWD:ALL and docker group equivalence (SBS-33); plaintext credentials (shared root, GitHub, Wiki, Grafana) discovered in 
SERVER_CHANGELOG.md (SBS-34); production OS standardization pending (mix of Ubuntu 24.04 and 26.04).
Roadmap: [committed] Rotate all compromised credentials and migrate to Vault; strip credentials from changelog history; create per-person named SSH users with scoped sudo; disable direct root login.
Layer 1 — Network & Transport (VPC & Firewalls) — 🔴 Gap (Day 0)
Present: DigitalOcean VPCs utilized for private networking; Prometheus/Grafana internal services bind to 
127.0.0.1 behind nginx TLS; Wiki TLS live via Let's Encrypt.
Gaps: Dev and Prod environments share a flat VPC (
default-nyc2), breaking the Dev↔Prod isolation rule (SBS-35); No Cloud Firewalls or host firewalls (ufw/nftables) exist on Prod or Dev droplets—public interfaces are protected solely by service bind addresses (SBS-36); Wiki droplet is in NYC1 (cross-region), forcing unencrypted metric scraping over the public internet (SBS-37); Production apex DNS (
sbsdash.com) currently resolves to an undocumented Dev-Gitlab-server, not Prod (SBS-38).
Roadmap: [committed] Rebuild fleet into dedicated 
prod-vpc-nyc2 and 
dev-vpc-nyc2; deploy 4 tag-scoped Cloud Firewalls immediately; repoint apex DNS to 
sbsdash-server-prod; rebuild Wiki in NYC2.
Layer 2 — Auth & Authz (G0 / G1) — 🟡 Partial
Present: Better Auth with required secret; 
boardMutationGuard anti-CSRF; API keys 192 bits hashed (SHA-256); JWT HS256 with strict 
alg/
exp checks; timing-safe comparisons.
Gaps: No rate limiting on auth/keys/invites (SBS-05); sign-up open by default in private (SBS-16); shared dev secret signs JWTs (SBS-07); agent keys lack expiration (SBS-19).
Roadmap: [committed] Tier 2/3 agent auth; [recommendation] Global rate limiting; independent JWT secret with entropy validation.
Layer 3 — Multi-Tenant & Compartment Isolation — 🟡 Partial
Present: 
company_id and 
compartment_id NOT NULL with 
assertCompanyAccess / 
assertCompartmentAccess enforced at application layer; cross-tenant boundary tests; object storage prefixed with 
${companyId}/${compartmentId}/ anti-traversal. SBS internal business units (HR, Finance, Sales) are isolated into distinct Compartments.
Gaps: Isolation only at application layer — no RLS (Row Level Security) (SBS-11). A single missed filter or SQLi exposes the whole instance.
Roadmap: [recommendation] Postgres RLS or scoped DB roles as a second line of defense. (See Appendix D for Business Unit mapping).
Layer 4 — Execution & Containment (G3 Jotunheim Boundary) — 🟡 Partial
Present: 
low_trust_review preset with fail-closed resolution; runtime containment requiring 
sandbox driver + isolated workspace; quarantine of output with source-trust tagging; sandbox callback bridge with allowlist.
Gaps: Local CLI agents run unsandboxed on host inheriting server env, using 
--dangerously-skip-permissions (SBS-02); plugin workers lack real OS isolation (SBS-03); external adapters load in-process via 
import() (SBS-01); built-in sandbox provider 
fake is a no-op but accepted by containment check (SBS-25); No egress control exists on any droplet, allowing potential LLM01 exfiltration (SBS-39).
Hallucination & Liability Containment: All outward-facing AI generation (Sol Vega scripts, automated client communications) must transit G4 (Forseti - Output Arbitration). G4 enforces structured-output validation and fact-checking against the 40-year model baseline. Any AI output lacking sufficient grounding confidence is routed to the Helheim DLQ for human review, preventing brand-damaging hallucinations from executing.
Roadmap: [committed] Centralized low-trust enforcement; 
adapter_managed/
cloud_sandbox modes; deploy nftables default-deny outbound with strict allowlists. [recommendation] Block 
fake provider for low-trust; run workers in microVMs (gVisor/Firecracker).
Layer 5 — Secrets, Data, & PII (G1 Credential Starvation) — 🟡 Partial
Present: AES-256-GCM encryption at rest; master key 0600 with health check; AWS provider with SigV4; no reveal endpoint (100% board-only management); just-in-time secret injection as env vars before spawn; redaction in logs/transcripts.
PII & Privacy Controls: Listener data ingested via the LaMusica app and geofence engine is subject to strict data minimization. NornGate enforces CCPA/LGPD/GDPR compliance by design through anonymized cohort targeting (no targeting an audience of one) and just-in-time data resolution, ensuring personal identifiers are never persistently stored alongside behavioral profiles.
Gaps: 
reqBody with secrets leaks to 
server.log on HTTP ≥400 errors (SBS-04); master key co-located with DB/backups (SBS-10); plugin configs stored in clear while secret-refs disabled (SBS-22); backups unencrypted (SBS-23).
Roadmap: [committed] Company-scoped plugin secret-refs; [recommendation] Structural logger redaction; master key rotation; encrypted backups.
Layer 6 — Audit & Observability (The Norns) — 🟡 Partial
Present: Activity log company-scoped with ~239 instrumentation points and structural sanitization; transactional approvals; budget hard-stop; run logs confined with sha256; telemetry opt-out with hashed private refs.
Gaps: Activity log falsifiable by board (manual POST, no hash-chain) (SBS-15); no retention/rotation for 
activity_log or 
server.log (SBS-18); unaudited read access to run logs.
Roadmap: [committed] "Immutable audit" for escalation routes; pluggable 
RunLogStore. [recommendation] Hash-chain/sign log entries + end-to-end request-ID; restrict manual activity POST; configurable retention.
7. Prioritized Findings Matrix
Remediation States: 🔄 Active Remediation · 📋 Planned · 🔎 Under Evaluation. All Critical and High findings have active remediation work in progress to be resolved before production go-live.
ID
Sev.
State
Domain
Description
Recommendation
SBS-01
Critical
🔄 Active
Supply Chain
External adapters: 
import() in-process + 
npm install without 
--ignore-scripts → RCE
--ignore-scripts, out-of-process worker, integrity pinning
SBS-02
Critical
🔄 Active
Execution
Local CLI agents unsandboxed on host, inherit env, use 
--dangerously-skip-permissions
Dedicated user/seccomp/sandbox; env denylist; restrict 
--allowedTools
SBS-03
Critical
🔄 Active
Plugins
Plugin workers lack real sandbox (fs/net open); VM sandbox dead code; 
http.outbound doesn't limit process net
OS isolation/microVM; document as "trusted code" if not sandboxed
SBS-04
High
🔄 Active
Secrets/Logging
reqBody (with secrets) logged to 
server.log on ≥400 errors; only 
authorization redacted
Structural redaction of 
reqBody/
reqQuery in logger
SBS-05
High
🔄 Active
Auth/API
No rate limiting on login, invites, claim, webhooks (SPEC §16 requires it)
Global + endpoint-specific rate limiting
SBS-06
High
🔄 Active
Deploy/DB
Fixed PG credentials 
norngate/norngate + port 5432 published to host
Random credentials per install; do not publish 5432
SBS-07
High
🔄 Active
Secrets/Auth
Dev secret 
norngate-dev-secret signs sessions and JWTs (shared fallback)
Mandatory independent JWT secret; entropy validation
SBS-08
High
🔄 Active
Webhooks
Plugin webhooks public, no host-level signature verification or rate limit
Optional HMAC at host + ingestion throttling
SBS-09
High
🔄 Active
SSRF
Native HTTP adapter: 
fetch arbitrary URLs without private IP filtering; cloud metadata reachable
Reuse plugin SSRF guard in HTTP adapter
SBS-10
High
🔄 Active
Secrets
Master key co-located with DB and backups
Key outside data volume; encrypted backups; fix guide
SBS-11
High
🔄 Active
Multi-tenant
Isolation only at app layer: no RLS, single DB user with total access
Postgres RLS or scoped DB roles
SBS-12
High
🔄 Active
Auth
Cloud tenant token provisions 
instance_admin to any user; replayable
Per-request nonce/timestamp; declared roles
SBS-13
Medium
📋 Planned
HTTP
Guards trust 
X-Forwarded-Host without 
trust proxy
Configure 
trust proxy or validate real 
Host
SBS-14
Medium
📋 Planned
HTTP
No CORS or global security headers; SPA lacks CSP/HSTS
helmet + restrictive CSP
SBS-15
Medium
📋 Planned
Audit
Activity log falsifiable by board; no hash-chain or request-ID
Integrity (hash-chain), request-ID, restrict manual POST
SBS-16
Medium
📋 Planned
Auth
Sign-up open by default; browser claim available in 
authenticated/private
DISABLE_SIGN_UP=true by default; claim notification
SBS-17
Medium
📋 Planned
SSRF
Portability import accepts arbitrary HTTPS hostnames
Host allowlist + private IP blocking
SBS-18
Medium
📋 Planned
Logging
Workspace-operation and plugin logs lack secret redaction
Apply 
redactSensitiveText to both pipelines
SBS-19
Medium
📋 Planned
Creds
Agent API keys never expire; JWT lacks 
jti/revocation
Key expiration/rotation; short TTL + denylist
SBS-20
Medium
📋 Planned
Containers
Main container starts as root; no 
cap_drop; image not reproducible
USER in image, hardening, digest pinning
SBS-21
Medium
📋 Planned
Invites
Invite tokens ~41 bits vs 192 bits elsewhere
Increase entropy to ≥128 bits
SBS-22
Medium
📋 Planned
Secrets/Plugins
Sensitive plugin config in clear while secret-refs disabled
Complete company-scope redesign
SBS-23
Medium
📋 Planned
Data
Sessions/OAuth tokens in clear in DB; backups unencrypted
Hash session tokens; encrypt backups
SBS-24
Medium
📋 Planned
Telemetry
Telemetry allows arbitrary dimensions from plugins (exfil channel)
Sanitize/limit plugin dimensions
SBS-25
Medium
📋 Planned
Low-trust
Containment check accepts 
fake (no-op) sandbox provider
Reject 
fake for low-trust runs
SBS-26
Medium
📋 Planned
Low-trust
Possible boundary escape via PATCH 
executionPolicy
Deny 
executionPolicy mutation to low-trust actors
SBS-27
Low
🔎 Eval
Realtime
WS accepts 
?token= in URL; credential bypass in 
local_trusted
Header/Sec-WebSocket-Protocol only
SBS-28
Low
🔎 Eval
CLI/MCP
CLI tokens in plain JSON; MCP static bearer in env
OS keyring; short-lived tokens
SBS-29
Low
🔎 Eval
Audit
x-norngate-run-id trusted without validation → attribution forgery
Validate runId or ignore for 
none actors
SBS-30
Low
🔎 Eval
Disclosure
openapi.json public; 
/api/health exposes mode/status
Require auth for openapi; minimize public health
SBS-31
Low
🔎 Eval
Plugins
Plugin manifest executed in-process during discovery
Declarative JSON manifest or isolated discovery
SBS-32
Low
🔎 Eval
Integrations
openclaw-gateway allows 
ws://; private key in clear config
Require 
wss:// outside loopback; move key to secret-ref
SBS-33
Critical
🔄 Active
Host Access
Root SSH enabled fleet-wide; single shared SSH keypair for root/sbsRoot; 
sbsRoot has 
NOPASSWD:ALL and docker group
Per-person named users; disable root SSH; scoped sudo; restrict 
sbsRoot to break-glass
SBS-34
Critical
🔄 Active
Secrets/Ops
Plaintext credentials (root, GitHub, Wiki, Grafana) committed to 
SERVER_CHANGELOG.md
Rotate all credentials; migrate to Vault; purge git history; enforce distinct per-service creds
SBS-35
High
🔄 Active
Network
Dev and Prod share flat VPC (
default-nyc2), breaking required Dev↔Prod isolation
Rebuild droplets into dedicated 
prod-vpc-nyc2 and 
dev-vpc-nyc2
SBS-36
Critical
🔄 Active
Firewalls
No Cloud Firewalls or host firewalls (ufw/nftables) active on Prod or Dev droplets
Deploy 4 tag-scoped DO Cloud Firewalls; activate host firewalls mirroring admit set
SBS-37
Medium
🔄 Active
Network
Wiki droplet in NYC1 cannot join NYC2 VPC; scraped over public internet unencrypted
Rebuild Wiki in NYC2 to rebind to private VPC networking
SBS-38
High
🔄 Active
DNS
Prod apex DNS (
sbsdash.com) points to undocumented Dev-Gitlab-server, not Prod
Repoint A record to 
sbsdash-server-prod (107.170.72.145) upon proxy/TLS readiness
SBS-39
High
🔄 Active
Egress
No egress control on any droplet; all outbound traffic open (LLM01 exfiltration risk)
Deploy nftables default-deny outbound with strict allowlists (Anthropic, GitHub, OS mirrors)
8. Security Roadmap & Incident Response
Committed in Project (Sources: 
doc/plans/, specs, LH-SBS-INF-001; state 🔵):
Agent Auth Tier 2/3: JWT signing key rotation, invite expirations, long-lived credential renewal.
Low-Trust Enforcement: Centralized enforcement layer, content-trust tagging, denial regression tests.
Plugin Secret-Refs: Company-scoped end-to-end (post-PAP-2394 redesign).
Immutable Audit: Hash-chained, signed action records for escalation routes (Valhalla archive integrity).
Ragnarök DR Drills: Scheduled chaos drills with verified recovery (Trickster running destruction in Jotunheim under G3).
Infrastructure Remediation (LH-SBS-INF-001): Rebuild fleet into dedicated VPCs; deploy Cloud Firewalls; migrate to per-person SSH users; deploy Vault; deploy nftables egress control.
Pre-Launch Security Audits: Upon completion of the foundational installation and gap remediation, conduct rigorous internal and external security audits. SBS retains the option to engage an independent third-party security firm (such as Certek) to perform a comprehensive penetration test and compliance validation prior to production go-live.
Incident Response (IR) & AI Containment:In the event of a confirmed breach or agent compromise, NornGate supports an instant "Kill Switch" revocation of all agent JWTs and API keys. The IR playbook mandates immediate isolation of the Jotunheim sandbox realm, followed by forensic extraction of the Urd (audit log) to determine blast radius. SBS IT Leadership will be notified within 24 hours of any Critical-severity security event.
Recommended by this Report (Mapped to findings):
Immediate: Global rate limiting (SBS-05); structural logger redaction (SBS-04); 
--ignore-scripts + out-of-process adapter loading (SBS-01).
High Priority: helmet/CSP/HSTS (SBS-14); independent JWT secret (SBS-07); random PG credentials (SBS-06); block 
fake sandbox in low-trust (SBS-25); anti-SSRF in HTTP adapter (SBS-09).
Medium Priority: Audit log hash-chain (SBS-15); Postgres RLS (SBS-11); master key rotation & encrypted backups (SBS-10, SBS-23); CI security scanning.
9. Shared Responsibility Model
Security and compliance are jointly shared between Ledger Hub Networks (LHN) and Spanish Broadcasting System (SBS) IT.
Entity
Responsibilities
Ledger Hub Networks (LHN)
NornGate application architecture (G0-G4 gates); IaC code generation and maintenance; AI agent sandboxing and containment logic; audit logging (Urd) generation; cryptographic secret vault architecture.
SBS IT Infrastructure
DigitalOcean account-level security (MFA); execution of IaC firewalls and VPC segmentation; physical backup retention validation; enforcement of per-person SSH access; network-level egress enforcement.
10. Appendix A — Audit Scope & Technical Manifest
(This appendix is provided specifically for third-party security auditors and AI red-team firms to define the technical attack surface, rules of engagement, and testing scope.)
10.1 Technology Stack & Attack Surface
The Dash and NornGate platform are composed of the following authorized technologies. Auditors should focus vulnerability scanning and exploitation attempts against these specific frameworks and versions.
Cloud Infrastructure: DigitalOcean (Droplets, VPCs, Cloud Firewalls).
Operating Systems: Ubuntu 24.04 LTS / 26.04 LTS.
Containerization: Docker 29.1.3, Docker Compose 2.40.3.
Web Servers / Proxies: Nginx 1.28.3, Caddy 2.11.
Backend Application Stack: Node.js (Express), Rust (Cargo), Python (scripts/adapters).
Frontend Application Stack: React (NornGate Console), Vue 3 / Vite (SBS Intranet).
Databases: PostgreSQL, MongoDB, Redis.
Authentication: Better Auth (Session management), JWT HS256 (Agent auth).
AI/LLM Integration: Anthropic API (High-end reasoning), Open-Weight Models via OpenRouter / DigitalOcean GPUs (Kimi/Z.ai for routine orchestration).
AI Tooling: Model Context Protocol (MCP) for agent-tool communication.
Legacy Data Ingestion: WideOrbit, Oracle, WideOrbit Automation, MusicMaster, SIMS TV, CounterPoint, ADP, and unknown Digital Systems. Ingestion methods include MCP, direct API, Raw Data Dumps (SFTP/DB exports), and Report OCR Scraping.
10.2 Target Environment & Access Points
The audit scope is limited to the following SBS-owned operational surfaces.
In-Scope URLs:
sbsdash.com / 
admin.sbsdash.com / 
clients.sbsdash.com (Primary Tenant Surfaces)
solvega.sbsdash.com (Public Sol Vega splash site / video delivery)
monitor.sbsdash.com (Grafana / Prometheus observability stack)
wiki.sbsdash.com (BookStack documentation portal)
In-Scope Infrastructure:
DigitalOcean Droplets residing in the NYC2 region (Prod, Dev, Monitor).
The NornGate application codebase (White-Box access to be provided via private GitHub repository invitation).
10.3 Rules of Engagement (RoE)
The auditor agrees to the following constraints to protect SBS's production environment and live broadcast capabilities:
Testing Methodology: White-Box testing is authorized. Source code, IaC configurations, and infrastructure access (via jump host) will be provided.
No Denial of Service (DoS): Auditors are prohibited from executing volumetric DDoS attacks or aggressive fuzzing that degrades the availability of 
solvega.sbsdash.com or the underlying DigitalOcean droplets. Resource exhaustion tests must be coordinated and throttled.
No Cloud Provider Attacks: Attempts to compromise the underlying DigitalOcean hypervisor, control plane, or physical infrastructure are strictly out of scope.
Third-Party API Safety: Auditors must not attempt to breach, overwhelm, or extract data from third-party LLM providers (e.g., Anthropic, OpenRouter). Prompt injection tests must be self-contained and not designed to elicit harmful content from the foundational LLM itself, but rather to test NornGate's G1/G3 containment boundaries.
Data Handling: Any PII, API keys, or secrets discovered during the audit must be handled under strict confidentiality, not exfiltrated, and securely destroyed at the conclusion of the engagement.
10.4 AI Red-Team Mandate
While traditional web application testing (OWASP Top 10) is required, SBS mandates that a minimum of 40% of the auditor's effort be focused on AI-specific threat vectors (OWASP LLM Top 10). The auditor must specifically attempt to:
G1 Policy Bypass (Tyr): Attempt to craft prompts that trick Workflow Agents into executing tool calls or data mutations outside their assigned RBAC scope.
G3 Sandbox Escape (Jotunheim): Attempt to break out of the agent execution environment to access the host server's filesystem, environment variables, or the Asgard control plane.
Credential Starvation Circumvention: Attempt to force the AI to leak injected just-in-time credentials or API keys to the console, logs, or external endpoints.
Denial of Wallet (DoW): Attempt to trigger infinite agent loops or excessive token consumption to test the effectiveness of the NornGate 
budget hard-stop auto-pause mechanism.
Data Poisoning (Skuld/Mimir): Analyze how historical data is ingested. Attempt to inject anomalous or malicious data via legacy API ingestion to see if it degrades the 40-Year Model's targeting intelligence.
Hallucination Exploitation (G4 Forseti): Attempt to generate outward-facing content (e.g., Sol Vega scripts, automated emails) that bypasses structured-output validation to produce brand-damaging or legally liable statements.
11. Appendix B — Data Flow & Trust Boundary Architecture
(This appendix maps the logical flow of data across the NornGate Realms, explicitly identifying trust boundaries and the gates that enforce them. Auditors should use this to plan cross-boundary penetration tests.)
11.1 Trust Boundaries & Data Flow Map
Boundary 1: The Edge (Internet → Midgard)
Flow: User/Client Request (HTTP/HTTPS) → 
api.norngate.com / 
sbsdash.com.
Gate Enforced: G0 (The Gate / Warden) — AuthN/Z, tenant resolution, rate limits, schema validation.
Data State: Untrusted input. No access to internal services until G0 passes.
Boundary 2: Control Plane Entry (Midgard → Asgard)
Flow: Authenticated User Request → Yggdrasil (Orchestrator Core).
Gate Enforced: G1 (Tyr) / G0 (Warden) — RBAC verification, session validation.
Data State: Trusted session context. User can view dashboards and trigger workflows, but cannot execute code or access raw data directly.
Boundary 3: Agent Execution (Asgard → Jotunheim)
Flow: Orchestrator dispatches task to AI Agent (Odin/Thor) → Agent spawns in Sandbox.
Gate Enforced: G1 (Tyr) / G3 (Jotunheim Boundary) — Pre-execution policy check, tool permission validation, sandbox initialization.
Data State: Agent is provided with minimum-scope, just-in-time credentials (Credential Starvation). Agent output is tagged as 
quarantined if 
low_trust_review is active.
Boundary 4: External LLM Communication (Jotunheim → Vanaheim)
Flow: AI Agent requires reasoning → API call to Anthropic / OpenRouter.
Gate Enforced: G3 (Egress Control) — nftables/firewall allowlist permits traffic only to approved LLM endpoints (e.g., 
api.anthropic.com).
Data State: Data leaves the SBS perimeter. PII is minimized/redacted prior to payload construction by G1. Return payload is treated as untrusted hostile content.
Boundary 5: Data Persistence (Jotunheim/Asgard → Niflheim/Database)
Flow: Agent or Orchestrator writes result to PostgreSQL/MongoDB → Audit event written to Valhalla/Urd.
Gate Enforced: G1 (Tyr) / G4 (Forseti) — Structured output validation, SQL sandbox keyword banlist, 
company_id enforcement.
Data State: Data is encrypted at rest (AES-256-GCM for secrets). Audit log entry is append-only.
Boundary 6: External Side Effects (Jotunheim → Vanaheim/Internet)
Flow: AI Agent attempts to send email, post to social media, or modify a third-party API (e.g., Audacy invoice generation).
Gate Enforced: G2 (HITL Approval) — Action is parked. Human Board member must explicitly approve the prepared action.
Data State: Zero execution occurs until human approval token is provided.
11.2 Legacy System Ingestion Boundary (SBS Internal Systems → Jotunheim/Asgard)
The Dash aggregates 40 years of SBS historical and operational data. This data lives in disparate, legacy systems (WideOrbit, Oracle, WideOrbit Automation, MusicMaster, SIMS TV, CounterPoint, ADP, and unknown Digital Systems). Data is collected via four distinct ingestion paths, all strictly governed by G1/G3:
MCP / API Integration: For modern systems (WideOrbit, Oracle, ADP), NornGate utilizes Model Context Protocol (MCP) and direct APIs. G1 enforces read-only, minimum-scope credentials just-in-time. The API connection is terminated in Jotunheim.
Raw Data Dump: For systems that only support scheduled exports (e.g., MusicMaster logs, SIMS TV traffic), CSV/SQL dumps are pushed via SFTP to an isolated staging directory in Jotunheim. A Low-Trust Agent parses the file, strips PII, and validates the schema before writing to Asgard.
Report OCR Scraping: For legacy systems with no API or export capability (e.g., unknown Digital Systems, legacy CounterPoint reports), PDF/visual reports are ingested. OCR processing is executed by a Low-Trust Agent in Jotunheim. The raw report is quarantined, and only the extracted, structured JSON data passes G4 validation to enter the Asgard data lake.
Data Poisoning Prevention: Because legacy ingestion is a primary vector for Data Poisoning (Threat AI-T4), all ingested data is compared against historical baselines (Skuld). Anomalous data (e.g., a sudden 500% spike in a specific demographic) triggers a G1 denial, quarantining the data in Helheim for human review before it can degrade the 40-Year Model.
12. Appendix C — Role-Based Access Control (RBAC) Matrix
(This matrix defines the strict least-privilege access model for all human and non-human actors within NornGate. Auditors should use this to write automated tests attempting to escalate privileges or cross tenant boundaries.)
Actor / Role
Environment / Realm
Permissions & Capabilities
Explicit Denials (Fail-Closed)
SBS Board / Admin
Midgard / Asgard
Read dashboards, approve G2 actions, manage user invites, rotate secrets metadata (no view), configure budget limits.
Cannot view raw secret values. Cannot bypass G1 policy. Cannot execute code directly.
SBS IT / System Admin
Asgard / Host Layer
SSH access (per-person named users), Docker container management, firewall rule deployment via IaC, database backup restoration.
No access to tenant data payloads. No access to NornGate application root without break-glass.
Human User (Employee)
Midgard
Read assigned compartment data, submit tasks to Workflow Agents, view personal audit history.
Cannot create new agents. Cannot alter G1 policies. Cannot access other compartments' data.
Workflow Agent
Jotunheim
Execute approved tool calls, read/write to assigned DB schema, call allowlisted external APIs (via G3 egress).
No standing credentials. Cannot mutate 
executionPolicy. Cannot access host filesystem. Cannot bypass G4 output validation.
Guardian Agent
Jotunheim / Asgard
Enforce policy (Tyr), tag output trust levels, quarantine low-trust content.
Cannot execute external side effects. Cannot approve its own generated content.
Low-Trust Agent
Jotunheim (Isolated)
Process untrusted external content (e.g., support tickets, social media scraping, OCR report ingestion).
Output strictly quarantined. No direct DB write access. No access to secrets vault. Egress restricted to specific endpoints.
13. Appendix D — Business Unit Compartmentalization & Data Movement Policy
(This appendix details how SBS internal departments and external end-users are contained, how cross-department data movement is restricted by an Orchestrator traffic blacklist, and the specific Read/Write mappings enforced by G1 (Tyr).)
13.1 Business Unit Containment (Compartments)
SBS does not operate on a flat internal network. Internal business units (HR, Finance, Sales, Traffic, Marketing) are isolated into distinct Compartments within the NornGate control plane (Asgard).
Network Isolation: Each Compartment operates on its own dedicated Docker Compose network. Cross-Compartment traffic is denied by network non-membership. An agent in the Sales Compartment cannot natively route traffic to the HR Compartment's database container.
Schema Isolation: Data services (PostgreSQL, MongoDB, Redis) enforce per-Compartment separation. A Compartment can only read/write to its explicitly assigned database schema.
Agent Containment: Workflow Agents are scoped strictly to their assigned Compartment. An HR Agent processing onboarding cannot execute tool calls against the Traffic/Continuity ad log.
13.2 Orchestrator Traffic Blacklist (Data Loss Prevention)
To prevent lateral movement of sensitive data between departments, the Orchestrator Core (Yggdrasil), enforced by G1 (Tyr), operates a strict Data Movement Blacklist. This acts as an internal Data Loss Prevention (DLP) layer.
Policy-as-Code: G1 evaluates every attempted data transfer or tool call between Compartments against a deterministic policy file.
Denied Transfers (Examples):
HR → Marketing: PII (Employee SSNs, home addresses) is blacklisted from being passed into Marketing campaign generation agents.
Finance → Sales: Raw GL/banking credentials are blacklisted from being passed into Sales media deck generation.
Traffic → Marketing: Unrevealed advertising rate cards are blacklisted from Marketing's promotional output.
Enforcement: If an agent attempts to cross a Compartment boundary with blacklisted data payloads, G1 denies the action, logs the violation to Urd, and routes the job to Helheim (DLQ) for administrative review.
13.3 Business Unit Read/Write Access Matrix
Access to data within Compartments is strictly governed by RBAC. The following matrix maps the Read (R) and Read/Write (RW) permissions for SBS core business units.
Business Unit
HR Data
Finance/GL
Sales/CRM
Traffic/Inventory
Marketing Ops
HR
RW
R (Budget codes only)
Deny
Deny
Deny
Finance
R (Payroll metadata)
RW
R (Revenue tracking)
R (Billing reconciliation)
Deny
Sales
Deny
R (Client billing status)
RW
R (Avails/Inventory)
R (Campaign performance)
Traffic
Deny
R (Invoicing)
R (Client spots)
RW
Deny
Marketing
Deny
Deny
R (Audience targets)
Deny
RW
(Note: "R" requires G1 policy validation. "RW" requires G1 validation for reads, and G2 (Human-in-the-Loop) approval for writes that impact external systems or financial state.)
13.4 End-User Containment (Credential Rights)
External end-users (LaMusica app listeners, SBS Intranet viewers, Sol Vega interactors) are strictly contained by scoped credential rights enforced at G0 (The Gate).
Authentication: End-users authenticate via Better Auth (OAuth/Email) or receive scoped, short-lived JWTs.
Realm Restriction: End-users exist exclusively in Midgard. Their credentials explicitly deny access to the Asgard control plane, Jotunheim agent execution environments, and all internal Business Unit Compartments.
Data Scope: An end-user JWT only permits access to their own individual behavioral profile and interaction history (e.g., their chat history with Sol Vega, their location fence data). They cannot query global audience data, advertiser metrics, or other users' PII.
Action Constraint: End-users can submit input (e.g., song requests, chat messages) which are routed to Low-Trust Agents in Jotunheim. End-users possess zero direct execution credentials; all side effects (ad insertion, content generation) are handled by agents acting on their behalf, strictly governed by G1-G4.
14. Appendix E — AI Compute & Inference Strategy
(This appendix outlines the tiered AI compute architecture for auditors. Understanding this 80/20 split is critical for testing Denial of Wallet (DoW) and egress control mechanisms.)
14.1 The 80/20 Inference Split
To balance high-end AI reasoning with strict cost control (AI Unit Economics), NornGate does not route all traffic to premium external APIs. Compute is split across two distinct tiers:
80% Routine Orchestration (Open-Weight Models): The vast majority of agent execution—including log reconciliation, DAI assembly, traffic routing, and standard content generation—is handled by open-weight LLMs (specifically GLM / Kimi). These models are hosted in-house, meaning inference costs drop to near-zero (just compute electricity).
20% Complex Reasoning (Premium API): High-stakes, nuanced tasks—such as Sol Vega scriptwriting, complex contextual ad arbitration, and meta-reasoning (Odin agent)—are routed via API to Anthropic (Claude).
14.2 Infrastructure Scaling Roadmap
The hardware hosting the 80% open-weight tier scales deliberately across three phases to protect SBS's capital expenditure:
Phase 0/1 (Agility - Current): Initial deployment routes traffic through OpenRouter. This allows rapid integration and testing of multiple models without heavy upfront capital expenditure.
Phase 2/3 (Scaling): As inference volume grows, compute migrates to rented DigitalOcean GPU clusters. This lowers marginal costs, secures data processing environments within the VPC, and tests sustained load before hardware is purchased.
Phase 4+ (Maturity): Once usage patterns are proven and optimized, SBS will acquire dedicated H200 GPU infrastructure. This drives inference costs to the floor and ensures complete sovereign control of the 40-Year Model and the 80% open-weight tier.
14.3 Auditor Implications
Denial of Wallet (DoW) Testing: Auditors testing DoW (Threat AI-T2) should understand that infinite loops targeting the Anthropic API will trigger the 
budget hard-stop (Hermod). However, loops targeting the open-weight tier (GLM/Kimi) will primarily consume local DigitalOcean GPU resources, testing the container resource limits (CPU/RAM) rather than token budget.
Egress Testing: Egress allowlists (G3) must explicitly permit traffic to OpenRouter, Anthropic, and DigitalOcean internal GPU endpoints, but deny all other external AI APIs.
15. Appendix F — AI-Specific Threat Vector Matrix
(While NornGate addresses the OWASP LLM Top 10, this matrix maps the specific AI attack vectors relevant to SBS’s deployment of The Dash. Auditors must specifically target these vectors during the Red-Team engagement.)
Threat ID
OWASP LLM Mapping
Attack Vector Description
NornGate Mitigation (Gate)
Auditor Testing Goal
AI-T1
LLM01: Prompt Injection
Attacker submits malicious input via LaMusica app chat or social media scraper, instructing the agent to ignore previous rules and exfiltrate data.
G1 (Tyr) / G3 (Jotunheim): Agents have zero standing credentials (Credential Starvation). Even if tricked, they lack API keys to exfiltrate data. Egress is firewalled.
Attempt to trick Sol Vega into returning DB connection strings or API keys via the chat interface.
AI-T2
LLM08: Excessive Agency / DoW
Attacker triggers a recursive loop in a Workflow Agent (e.g., infinite podcast generation), draining the Anthropic API token budget (Denial of Wallet).
G1 (Tyr) / Hermod: 
budget hard-stop auto-pause. Scheduler skips invocation if agent is paused or over budget.
Attempt to trigger an infinite agent loop and verify that the budget hard-stop terminates the process before exceeding the $12k/mo cap.
AI-T3
LLM02: Insecure Output Handling
LLM returns a payload containing malicious script (XSS) or SQL injection, which the system executes without sanitization.
G4 (Forseti): Structured-output validation and consensus/judging. Output must match strict JSON schema before leaving Jotunheim.
Inject a payload via LLM response designed to drop a database table or execute XSS in the admin console.
AI-T4
LLM04: Data Poisoning
Attacker slowly feeds anomalous data into the 40-Year Model via legacy API ingestion (e.g., WideOrbit, SIMS TV) or OCR scraping, skewing ad targeting to benefit a competitor.
G1 (Tyr) / Skuld: Continuous data-integrity monitoring. Anomalous data fed via legacy APIs or OCR is flagged and quarantined before model degradation.
Attempt to push malformed audience demographic data via the WideOrbit API adapter or a crafted OCR report and verify it is quarantined.
AI-T5
LLM05: Supply Chain Vulnerability
A third-party npm plugin or adapter is compromised (typosquatting) and attempts to execute malicious code inside the NornGate host.
G0/G1 / Host Hardening: 
npm install --ignore-scripts enforcement. External adapters load out-of-process. Plugin capability gating denies unknown operations.
Submit a mock malicious plugin with a 
postinstall script and attempt to execute it via the adapter loader.
AI-T6
LLM06: Sensitive Info Disclosure
LLM accidentally includes PII or secrets from its training context/prompt in its generated response to a user.
G1 (Tyr) / Layer 5: PII data minimization. Just-in-time credential injection. Redaction pipelines in run logs and transcripts.
Attempt to trick the agent into repeating the system prompt or revealing the just-in-time Anthropic API key.
16. Closing & Next Steps
The transition of Spanish Broadcasting System into an AI-native media ecosystem is a monumental undertaking that requires an uncompromising commitment to security. This report outlines the robust architectural design of NornGate—anchored by the 5-Gate Taxonomy, Credential Starvation, and strict Business Unit Compartmentalization—which provides a fundamentally secure foundation for The Dash.
While the "Day 0" infrastructure and application gaps identified herein are inherent to an active foundational deployment, they are explicitly tracked, actively remediated, and will be fully closed before any live production data transits the platform. The closed-system deployment model further mitigates exposure during this critical build phase.
Security is not a static achievement but a continuous operational discipline. Upon completion of the foundational installation, Ledger Hub Networks will execute comprehensive internal and external security audits. We fully support and welcome SBS's option to engage an independent third-party security firm (such as Certek) to perform final penetration testing, AI Red-Team validation, and compliance certification prior to production go-live.
The Dash is designed to be the strongest amplifier SBS has ever had; NornGate ensures that this amplification never comes at the cost of data integrity, listener privacy, or operational security. We are committed to delivering a platform that is not only intelligent and profitable but inherently trustworthy.
Document End.Confidential — Ledger Hub Networks, LLC × Spanish Broadcasting System, Inc.