Skip to content

Gates and Attributes

Frank Yglesias Bertheau edited this page Jul 7, 2026 · 1 revision
<h1>ᚾ&nbsp;NornGate — Gates &amp; Attributes</h1>

Gates decide on attributes, not on the agent's word. Every verdict is a function of who is asking, what they want to touch, which action, and under what conditions — evaluated as rules, deterministically, default-deny. This page is the attribute model those rules run on.


ᛏ ABAC + RBAC

NornGate combines RBAC (a coarse role check — is this agent even in a category permitted here?) with ABAC (fine-grained rules over the full context). RBAC narrows; ABAC decides. The policy gate (G1) is the primary consumer, but every gate reads some slice of the same attribute set.

The model follows the standard ABAC decomposition (NIST SP 800-162): a decision is f(subject, resource, action, environment) against a policy. NornGate adds the platform constraints — deterministic evaluation, default-deny, and authoritative attribute sources.


ᚨ Attribute categories

Category Attributes (examples) Source
Subject agent identity, role, tenant, deliberation budget Signed SPIFFE SVID + registry
Resource type, id, owner, realm, sensitivity (e.g. pii) Authoritative resource registry
Action the verb (read / write / delete / execute) The request, normalized
Environment time, source network, request risk tag, budget state The gateway (not the caller)

References. NIST SP 800-162 (ABAC), OASIS XACML (deny-overrides combining), SPIFFE/SPIRE (subject identity). Deterministic rules over LLM judgment — Assury. Naming doctrine: Prose Edda / Poetic Edda, per Norse Cosmology & Platform Design.

ᚾ NornGate — Gates & Attributes

Gates decide on attributes, not on the agent's word. Every verdict is a function of who is asking, what they want to touch, which action, and under what conditions — evaluated as rules, deterministically, default-deny. This page is the attribute model those rules run on.


ᛏ ABAC + RBAC

NornGate combines RBAC (a coarse role check — is this agent even in a category permitted here?) with ABAC (fine-grained rules over the full context). RBAC narrows; ABAC decides. The policy gate (G1) is the primary consumer, but every gate reads some slice of the same attribute set.

The model follows the standard ABAC decomposition (NIST SP 800-162): a decision is f(subject, resource, action, environment) against a policy. NornGate adds the platform constraints — deterministic evaluation, default-deny, and authoritative attribute sources.


ᚨ Attribute categories

Category Attributes (examples) Source
Subject agent identity, role, tenant, deliberation budget Signed SPIFFE SVID + registry
Resource type, id, owner, realm, sensitivity (e.g. pii) Authoritative resource registry
Action the verb (read / write / delete / execute) The request, normalized
Environment time, source network, request risk tag, budget state The gateway (not the caller)
{
  "subject":  { "id": "spiffe://norngate.com/ns/midgard/sa/huginn",
                "role": "retrieval-agent", "tenant": "acme" },
  "resource": { "type": "user-record", "id": "4471", "owner": "acme",
                "realm": "midgard", "sensitivity": "pii" },
  "action":   "write",
  "environment": { "time": "2026-07-07T10:30:00Z", "risk": "high", "approvalBudget": 12 }
}

ᛉ Attribute provenance — why they cannot be forged

This is the security core of the model: attributes are authoritatively sourced, never self-asserted.

  • Subject attributes are bound to the caller's signed SPIFFE SVID and the identity registry — an agent cannot claim a role it was not issued.
  • Resource attributes (owner, realm, sensitivity) come from the resource registry — an agent cannot mark a pii record as non-sensitive by editing its request body.
  • Environment attributes (risk tag, budget, source) are stamped by the gateway, not the agent.

Why it matters: the classic ABAC attack is attribute forgery — escalate by asserting a better role, or downgrade a resource to dodge a rule. NornGate closes it structurally: the attributes that decide a request come from signed identity and authoritative registries, so the decision does not trust anything the agent says about itself. This is the attribute-level face of credential starvation and total mediation ([Security & Fail-closed](Security-and-Fail-Closed)).


ᛁ The rule model

A policy is a set of rules; each rule is (effect, match, obligations?). Evaluation is deterministic and follows two safe defaults:

  • Default-deny — no matching allow means deny.
  • Deny-overrides — a matching deny beats any allow (the conservative XACML combining algorithm).
{
  "id": "pii-write-needs-approval",
  "effect": "allow",
  "match": { "resource.sensitivity": "pii", "action": "write", "subject.role": "retrieval-agent" },
  "obligations": ["require:approval"]
}
{
  "id": "deny-cross-tenant",
  "effect": "deny",
  "match": { "resource.owner_ne_subject_tenant": true }
}

Obligations let an allow be conditional — the rule above permits the PII write but obliges a G2 approval, so the decision and the downstream requirement are one recorded unit. Evaluation is a pure function of (request, policy_snapshot, state_snapshot) with no LLM in the loop ([Deterministic Execution](Deterministic-Execution)) — a model policing a model is jailbreakable (Assury).


ᚦ How each gate uses attributes

Gate Attributes it reads What it does with them
G0 Ingress subject identity, environment (rate, source) Authenticate; rate-limit; reject bad shape
G1 Policy all four categories Evaluate ABAC + RBAC → allow / deny / allow-with-obligation
G2 Approval environment.risk, subject.approvalBudget Require consent for high-risk; debit budget
G3 Sandbox resource.sensitivity, action Pick sandbox class; validate the prepared effect
G4 Arbitration resource.id (the conflict key) Lease the resource; resolve contention

The same attribute set flows through the whole pipeline; each gate reads the slice it needs, and none re-derives attributes from the agent's claims.


ᚷ Stateful attributes — risk and budgets

Two attributes are stateful — they change as the system runs, and they are the levers that keep the expensive gates rare:

  • Risk tag (environment.risk) — assigned from resource sensitivity + action + context. Drives whether G2 requires approval and which sandbox class G3 uses.
  • Deliberation budget (subject) — the knowledge/token allowance enforced at G1 (Mimir's well); exceeding it denies or escalates.
  • Approval budget (subject) — debited at G2; the mechanism that keeps human transits under ~5% of traffic (standing automated-consent policies cover most high-risk actions).

Because budgets are attributes, their state is snapshotted with every decision — so a budget-based denial is as replayable as any other.


ᛈ Recording — attributes to Urd

Every verdict records which attributes it evaluated (by snapshot ID) and which rules matched, to Urd. That is what makes a decision reproducible: replay loads the same attribute snapshots and re-derives the same verdict.

{
  "requestId": "req_7f3a2b",
  "gate": "policy",
  "decision": "allow",
  "matchedRules": ["pii-write-needs-approval"],
  "obligations": ["require:approval"],
  "attributes": { "policy": "pol_20260706_01", "state": "st_88f2" },
  "timestamp": "2026-07-06T10:32:00Z"
}

Full record format and verifiable receipts: [Urd Ledger](Urd-Ledger).


ᚱ 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
Tiwaz Týr — law, order ABAC + RBAC
Ansuz the word, the naming attribute categories
Algiz protection, warding provenance — no forgery
Isa ice, the fixed the rule model
Thurisaz thorn, gateway how each gate uses attributes
Gebo the granted allowance stateful risk & budgets
Perthro the well of Urd recording
Raidō the ride, the road next steps

References. [NIST SP 800-162](https://csrc.nist.gov/pubs/sp/800/162/final) (ABAC), OASIS XACML (deny-overrides combining), [SPIFFE](https://spiffe.io/)/SPIRE (subject identity). Deterministic rules over LLM judgment — Assury. Naming doctrine: Prose Edda / Poetic Edda, per [Norse Cosmology & Platform Design](Norse-Cosmology-and-Platform-Design).

Clone this wiki locally