Quick Overview
NornGate is a gated runtime for AI agent fleets. It places policy, approval, and isolation in front of every consequential action, so a side effect only happens after an explicit, recorded decision.
This is the fast path — the model before the details. For depth: The Five Gates, Security & Fail-closed, Norse Cosmology & Platform Design.
Every request crosses five gates before any side effect occurs. Each gate checks a different control dimension; if any gate cannot return an explicit ALLOW, execution stops. NornGate is fail-closed — a gate that times out, errors, or is misconfigured denies, it does not pass.
- G0 Ingress validates the source.
- G1 Policy evaluates allowed behavior.
- G2 Approval confirms required consent.
- G3 Sandbox tests execution safely.
- G4 Arbitration/Commit resolves contention, then commits.
| Gate | What it checks | Denial (HTTP → logged to Urd) |
|---|---|---|
| G0 Ingress | Authentication (SPIFFE SVID), rate limits, IP allowlists, request shape | 401 Unauthorized / 429 Too Many Requests |
| G1 Policy | ABAC + RBAC, resource type, agent role, context constraints | 403 Forbidden with a policy reason |
| G2 Approval | Human-in-the-loop or rule-based automated consent for high-risk actions | 403 pending, or denied on approval timeout |
| G3 Sandbox | Isolated execution, output validation, invariant/exception handling | 500 with sandbox-failure detail |
| G4 Arbitration/Commit | Write-conflict detection, deterministic resolution, commit + outcome record | 409 Conflict with the resolution outcome |
Further reading. The Five Gates · Security & Fail-closed · Urd Ledger · Error Codes. Naming doctrine: Prose Edda / Poetic Edda, per Norse Cosmology & Platform Design.
NornGate is a gated runtime for AI agent fleets. It places policy, approval, and isolation in front of every consequential action, so a side effect only happens after an explicit, recorded decision.
This is the fast path — the model before the details. For depth: [The Five Gates](The-Five-Gates), [Security & Fail-closed](Security-and-Fail-Closed), [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).
Every request crosses five gates before any side effect occurs. Each gate checks a different control dimension; if any gate cannot return an explicit ALLOW, execution stops. NornGate is fail-closed — a gate that times out, errors, or is misconfigured denies, it does not pass.
- G0 Ingress validates the source.
- G1 Policy evaluates allowed behavior.
- G2 Approval confirms required consent.
- G3 Sandbox tests execution safely.
- G4 Arbitration/Commit resolves contention, then commits.
| Gate | What it checks | Denial (HTTP → logged to Urd) |
|---|---|---|
| G0 Ingress | Authentication (SPIFFE SVID), rate limits, IP allowlists, request shape |
401 Unauthorized / 429 Too Many Requests
|
| G1 Policy | ABAC + RBAC, resource type, agent role, context constraints |
403 Forbidden with a policy reason |
| G2 Approval | Human-in-the-loop or rule-based automated consent for high-risk actions |
403 pending, or denied on approval timeout |
| G3 Sandbox | Isolated execution, output validation, invariant/exception handling |
500 with sandbox-failure detail |
| G4 Arbitration/Commit | Write-conflict detection, deterministic resolution, commit + outcome record |
409 Conflict with the resolution outcome |
Every denial is written to the [Urd](Urd-Ledger) ledger with the gate name, reason, and trace ID — so a denial is a queryable fact, not a dropped request. Full status list: [Error Codes](Error-Codes).
// GET /v1/audit?decision=deny → a G1 denial
{ "gate": "policy", "decision": "deny",
"reason": "agent.role 'user' cannot access resource type 'model'",
"requestId": "req_abc", "trace": "9f3c…", "http": 403 }Why fail-closed by HTTP semantics matters: the caller gets a precise, actionable status (403 vs 409 vs 429) instead of a generic failure, and the same verdict is recorded server-side — the client and the ledger never disagree about what happened.
Deterministic decisions. A verdict is a pure function of (request, policy_snapshot, state_snapshot) — the same input and state produce the same result, so evaluations are reproducible and replayable against their recorded snapshots. Why: you can re-derive any historical decision for audit or debugging. ([Security & Fail-closed](Security-and-Fail-Closed))
Fail-closed enforcement. Missing or ambiguous approval means denial; silence never becomes an implicit allow. Why: a policy-store outage locks the fleet down loudly rather than opening it silently.
Append-only audit trail. Every gate decision is written to Urd — a centralized, append-only, Ed25519-signed hash chain: tamper-evident and queryable, with PII-bearing payloads held separately and crypto-shreddable for erasure. Why: the ledger is both the audit record and the basis for per-outcome billing. ([Urd Ledger](Urd-Ledger))
Framework-agnostic integration. Bring agents in Python, Node, Rust, Go, or Java; integrate over gRPC, HTTP, or WebSocket. The control lives at the execution boundary (key custody), not in your agent code — which is why it holds in front of any framework. ([Security & Fail-closed](Security-and-Fail-Closed))
- Multi-agent orchestration with strict controls — coordinate fleets across trust zones ([realms](The-Nine-Worlds)) with clear policy enforcement and deterministic conflict handling at G4 (no racing writes).
- Regulated workflows with human approval — require explicit G2 consent before model deploys, data deletions, or financial actions; every approval is recorded to Urd.
- High-risk automations with full traceability — G1/G3 catch misconfigurations and malicious inputs in policy and sandbox before they reach production systems.
- [Introduction](Introduction) — the full story.
- [Getting Started](Getting-Started) — setup and access.
- [Quickstart](Quickstart) — your first call.
- [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design) — the architecture model.
Section glyphs are Elder Futhark runes (Unicode Runic block, U+16A0–U+16FF) — not emoji. Full set on [Home](Home#iconography):
| Rune | Name | Gloss | Marks |
|---|---|---|---|
| ᚾ | Nauðiz | need, constraint | the platform mark |
| ᚦ | Thurisaz | thorn, gateway | the five gates |
| ᛜ | Ingwaz | enclosure, completion | key benefits |
| ᛃ | Jera | harvest, fruitful yield | typical use cases |
| ᚱ | Raidō | the ride, the road | next steps |
Further reading. [The Five Gates](The-Five-Gates) · [Security & Fail-closed](Security-and-Fail-Closed) · [Urd Ledger](Urd-Ledger) · [Error Codes](Error-Codes). Naming doctrine: Prose Edda / Poetic Edda, per [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).