Skip to content

The Five Pillars

Jump to bottom
Frank Yglesias Bertheau edited this page Jul 7, 2026 · 1 revision
<h1>ᚾ&nbsp;NornGate — The Five Pillars</h1>

Five rules that do not change. They govern routing, policy, execution, and audit across the runtime; every agent, request, and side effect extends from them. The governing rule: if a request cannot be explicitly approved, it stops.

The pillars are the Spine, the Realms, the Gates, Determinism, and Auditability. This page covers all five; each links to its deep page.

ᛖ The Spine — one control path

Every request moves through one shared enforcement path — between users, agents, and internal services. There is no side route around it.

  • Myth — Yggdrasil, the single trunk connecting the worlds.
  • Implementation — a service mesh with uniform routing, identity, and policy enforcement.

What it guarantees: one place to authenticate, authorize, meter, and trace; no hidden side channels between trust zones; consistent policy across every realm.

Runtime characteristics

  • Data plane — Envoy sidecars on every workload pod.
  • Control plane — Istio (in Asgard) distributes routing and policy config via xDS; the five gates are an ordered Wasm filter chain that fails closed.
  • Identity — mTLS on every hop with SPIFFE/SPIRE short-lived SVIDs; no anonymous caller.
  • Routing — subdomains map requests into realm-specific backends.
  • Egress control — per-realm NetworkPolicies plus a brokered egress proxy: no workload can open a channel out of the mesh.
  • Observability — traces follow the same path as enforcement; the trace ID is the request's identity into Urd.

Why one spine. If there is exactly one path between realms, that path can be measured, denied, and audited. The runtime never depends on hidden convenience paths — a side channel would be a second, ungoverned spine. Read more in The Spine.

ᛟ The Realms — trust zones map to topology

Each realm has its own security posture, scaling pattern, and retention model. Routing is part of the threat model, not just a networking detail. (Ten realms — the nine Eddic worlds plus Valhalla, the archive.)

  • Myth — the Nine Worlds, each with distinct boundaries.
  • Implementation — subdomain routing, namespace isolation, per-realm policy.

What it guarantees: clear boundaries between workloads of different risk levels; predictable network paths; isolation for untrusted execution, storage, and control-plane services.

Isolation stack

  • Network — realm-specific NetworkPolicies (default-deny) restrict ingress and egress.
  • Resource — CPU/memory/GPU/storage quotas per realm.
  • Service — mesh authorization rules (Istio AuthorizationPolicy) narrow service-to-service access by SPIFFE identity.
  • Secrets — each realm gets its own scoped credentials; none are standing in untrusted realms.

Example posture — Jotunheim (untrusted execution)

  • Ingress only from approved internal services; no public ingress.
  • Egress only to required storage and audit systems.
  • No privileged containers; read-only root filesystem.
  • Sandboxed runtime; zero standing credentials.

The realm model turns the trust model into infrastructure: a reader should be able to infer risk boundaries from topology alone. Read more in The Nine Worlds (Trust Zones).

ᚦ The Gates — every action, the same five checks

Before side effects commit, every request crosses the same gate sequence — users, agents, and internal automation alike.

  • Myth — every crossing is watched.
  • Implementation — a five-gate pipeline with fail-closed behavior.
Gate What it checks Typical denial
G0 Ingress Identity, rate limits, request shape 401 / 429
G1 Policy Access rules against context and attributes 403
G2 Approval Explicit consent for higher-risk actions 403 / 408
G3 Sandbox Runs the action in isolation before commit 500
G4 Arbitration Resolves conflicts into one final outcome 409

References. Mesh identity — SPIFFE/SPIRE. Signed hash-chained ledger — Kaman (see Security & Fail-closed). Naming doctrine — Prose Edda / Poetic Edda, per Norse Cosmology & Platform Design.

ᚾ NornGate — The Five Pillars

Five rules that do not change. They govern routing, policy, execution, and audit across the runtime; every agent, request, and side effect extends from them. The governing rule: if a request cannot be explicitly approved, it stops.

The pillars are the Spine, the Realms, the Gates, Determinism, and Auditability. This page covers all five; each links to its deep page.

ᛖ The Spine — one control path

Every request moves through one shared enforcement path — between users, agents, and internal services. There is no side route around it.

  • Myth — Yggdrasil, the single trunk connecting the worlds.
  • Implementation — a service mesh with uniform routing, identity, and policy enforcement.

What it guarantees: one place to authenticate, authorize, meter, and trace; no hidden side channels between trust zones; consistent policy across every realm.

Runtime characteristics

  • Data plane — Envoy sidecars on every workload pod.
  • Control plane — Istio (in Asgard) distributes routing and policy config via xDS; the five gates are an ordered Wasm filter chain that fails closed.
  • Identity — mTLS on every hop with SPIFFE/SPIRE short-lived SVIDs; no anonymous caller.
  • Routing — subdomains map requests into realm-specific backends.
  • Egress control — per-realm NetworkPolicies plus a brokered egress proxy: no workload can open a channel out of the mesh.
  • Observability — traces follow the same path as enforcement; the trace ID is the request's identity into [Urd](Urd-Ledger).

Why one spine. If there is exactly one path between realms, that path can be measured, denied, and audited. The runtime never depends on hidden convenience paths — a side channel would be a second, ungoverned spine. Read more in [The Spine](The-Spine).

ᛟ The Realms — trust zones map to topology

Each realm has its own security posture, scaling pattern, and retention model. Routing is part of the threat model, not just a networking detail. (Ten realms — the nine Eddic worlds plus Valhalla, the archive.)

  • Myth — the Nine Worlds, each with distinct boundaries.
  • Implementation — subdomain routing, namespace isolation, per-realm policy.

What it guarantees: clear boundaries between workloads of different risk levels; predictable network paths; isolation for untrusted execution, storage, and control-plane services.

Isolation stack

  • Network — realm-specific NetworkPolicies (default-deny) restrict ingress and egress.
  • Resource — CPU/memory/GPU/storage quotas per realm.
  • Service — mesh authorization rules (Istio AuthorizationPolicy) narrow service-to-service access by SPIFFE identity.
  • Secrets — each realm gets its own scoped credentials; none are standing in untrusted realms.

Example posture — Jotunheim (untrusted execution)

  • Ingress only from approved internal services; no public ingress.
  • Egress only to required storage and audit systems.
  • No privileged containers; read-only root filesystem.
  • Sandboxed runtime; zero standing credentials.

The realm model turns the trust model into infrastructure: a reader should be able to infer risk boundaries from topology alone. Read more in [The Nine Worlds (Trust Zones)](The-Nine-Worlds).

ᚦ The Gates — every action, the same five checks

Before side effects commit, every request crosses the same gate sequence — users, agents, and internal automation alike.

  • Myth — every crossing is watched.
  • Implementation — a five-gate pipeline with fail-closed behavior.
Gate What it checks Typical denial
G0 Ingress Identity, rate limits, request shape 401 / 429
G1 Policy Access rules against context and attributes 403
G2 Approval Explicit consent for higher-risk actions 403 / 408
G3 Sandbox Runs the action in isolation before commit 500
G4 Arbitration Resolves conflicts into one final outcome 409

Why uniform gates. No special cases for privileged callers; no production bypass for maintenance work; no later gate can override an earlier denial. There is no path that skips gates in production — uniformity is what makes the enforcement analyzable. Read more in [The Five Gates](The-Five-Gates) and [Gates & Attributes](Gates-and-Attributes).

ᛁ Determinism — same input and state, same result

A verdict is a pure function of (request, policy_snapshot, state_snapshot, config). Determinism matters because retries, audits, and conflict resolution all depend on stable outcomes — if the same request can drift, the platform becomes hard to reason about.

  • Myth — the Norns weave one fate from known inputs.
  • Implementation — idempotency, stable ordering, replayable records, no hidden randomness.

How it is enforced

  • Idempotency keys stop duplicate execution from producing different results.
  • Deterministic request IDs keep ordering stable across retries.
  • Monotonic clocks back timeout and elapsed-time checks inside the runtime.
  • No hidden randomness in gate logic — a verdict never depends on an unrecorded input.
  • Replayable records — snapshot IDs stored beside each verdict make the exact decision path re-derivable.
{
  "requestId": "req_7f3a2b",
  "status": "approved",
  "gates": ["ingress", "policy", "approval", "sandbox", "arbitration"],
  "snapshot": { "policy": "pol_20260706_01", "state": "st_88f2" },
  "timestamp": "2026-07-06T10:32:00Z"
}

Why it matters: Debugging — replay a failure with the same inputs. Security — an attacker cannot rely on random drift between gates. Testing — CI and load tests produce stable outcomes. Compliance — decisions stay explainable after the fact. Read more in [Deterministic Execution](Deterministic-Execution).

ᛈ Auditability — every decision recorded and replayable

Each gate writes its outcome to Urd — a chain of custody for every request, including approvals, denials, timeouts, and errors.

  • Myth — Urd's well preserves memory.
  • Implementation — a centralized, append-only audit ledger with durable storage and tamper evidence.

Ledger characteristics

  • Append-only — gate outcomes are written, never edited.
  • Durable — retained outside the execution path (Kafka log, S3/Niflheim backup).
  • Tamper-evident — entries are hash-chained and Ed25519-signed; the signing key lives in an HSM in Asgard, off the worker path, so a compromised node cannot forge history.
  • Erasable payloads — PII-bearing fields sit in a separate per-subject-encrypted store and are crypto-shreddable (the chain stays intact and still verifies).
  • Queryable — filter by gate, decision, or time (GET /v1/audit).
{
  "id": "audit_7f3a2b",
  "gate": "policy",
  "decision": "deny",
  "reason": "agent role cannot access this resource type",
  "requestId": "req_abc123",
  "snapshot": { "policy": "pol_20260706_01", "state": "st_88f2" },
  "prev_hash": "sha256:9876zyxw...",
  "sig": "ed25519:3b9f...",
  "timestamp": "2026-07-06T10:32:00Z"
}

Why replay matters. It supports incident review, denial analysis, and state reconstruction after failure — first-class requirements, not add-ons. Read more in [Urd Ledger](Urd-Ledger) and [Security & Fail-closed](Security-and-Fail-Closed).

ᛜ In practice

The pillars push the runtime toward explicit control over hidden convenience:

  • Explicit approval over implicit permission.
  • Auditable decisions over opaque automation.
  • Deterministic outcomes over probabilistic shortcuts.
  • Isolated trust zones over flat network access.
  • One enforcement path over flexible but invisible bypasses.

This adds setup cost. It also makes behavior easier to trust in production — which, for a runtime that takes real actions, is the trade worth making.

ᚱ Next steps

Iconography

Section glyphs are Elder Futhark runes (Unicode Runic block, U+16A0–U+16FF) — semantic, not emoji. Full set on [Home](Home#iconography):

Rune Name Gloss Marks
ᚾ Nauðiz need, constraint the platform mark
ᛖ Ehwaz conveyance, movement between the Spine
ᛟ Othala enclosed estate, boundary the Realms
ᚦ Thurisaz thorn, gateway the Gates
ᛁ Isa ice, the fixed and immovable Determinism
ᛈ Perthro the lot-cup, the well of Urd Auditability
ᛜ Ingwaz enclosure, foundation in practice
ᚱ Raidō the ride, the road next steps

References. Mesh identity — SPIFFE/SPIRE. Signed hash-chained ledger — Kaman (see [Security & Fail-closed](Security-and-Fail-Closed)). Naming doctrine — Prose Edda / Poetic Edda, per [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).

Welcome

Getting Started

Core Concepts

Guides

Reference

Silence means no.

Clone this wiki locally