AgenticRail Enforcement Specification

This document specifies the AgenticRail deterministic enforcement gate: its decision architecture, enforcement rules, receipt structures, sequence enforcement mechanism, and cryptographic verification model. It is a technical specification, not a marketing document. Every claim here is verifiable without login or operator involvement: run a test sequence at agenticrail.nz/demo/, verify the receipt chain at report.agenticrail.nz/report, or watch live enforcement at dashboard.agenticrail.nz.

1. Decision Architecture

AgenticRail sits between an AI agent's intent and the action's execution. Before any step runs, it must pass the gate. The gate returns one of three decisions. No other outputs exist.

Every decision — including DENY — produces a cryptographic receipt written before the action executes. A DENY receipt is forensic evidence of enforcement. It proves the gate ran and refused. This is the architectural distinction from post-execution logging systems, which have no mechanism to receipt a step that was stopped before it ran.

2. Enforcement Rules

Rules are evaluated in order. The first failure terminates evaluation and returns DENY with the corresponding denial code. All eight rules must pass for ALLOW.

• 1Unknown function → DENY:POLICY_VIOLATION
• 2action_type not permitted for function → DENY:POLICY_VIOLATION
• 3step !== function → DENY:POLICY_VIOLATION
• 4Sequence already sealed → DENY:SEALED_SEQUENCE
• 5Nonce already used → DENY:REPLAY_NONCE
• 6Step out of order → DENY:SEQUENCE_VIOLATION
• 7|ts_ms − now| > 300s → DENY:STALE_TIMESTAMP
• 8All pass → ALLOW

Rule 7 closes the replay-with-fresh-nonce-after-delay attack vector. A valid nonce does not help an attacker whose timestamp window has expired. Rules 5 and 7 together mean a step cannot be replayed at any time: not immediately (nonce), not later (timestamp).

3. Enforcement Architecture

Client / Agent
  → Wrapper Worker     (auth, rate limit, D1 key store)
  → Gate Worker        (hardening, poison check, internal secret injection)
  → Core Worker        (policy map, timestamp, sequence position)
  → Durable Object     (nonce uniqueness, step counter — per sequence_id)
  → R2                 (HMAC-signed receipts, immutable storage)
  → KV                 (stats index, fast read for report generator)

The Gate is the only public entry point. The Core Worker is not publicly callable — it receives requests exclusively via service binding from the Gate, which injects an internal secret before forwarding. This means the enforcement logic cannot be bypassed by calling Core directly.

4. Payload Contract

{
  "schema_version": "1.0",
  "model_id":       "MSMD",
  "sequence_id":    "<unique sequence identifier>",
  "step":           "<step name>",
  "function":       "<function name — must equal step>",
  "action_type":    "<permitted action type for this function>",
  "action":         "<human readable label>",
  "inputs":         { "signal": "..." },
  "nonce":          "<uuid — unique per step, never reused>",
  "ts_ms":          1775262544154
}

The invariant step === function is an ontological constraint, not a validation rule. A step cannot be what it is not. The gate does not attempt to reconcile a mismatch — it denies immediately.

5. Sequence Spines

The gate enforces ordered sequences called spines. Steps must execute in the defined order. No skipping. No replay. The sequence is sealed permanently at the final step — no unsealing mechanism exists.

The architecture is spine-agnostic. Any ordered sequence of named steps can be enforced with the same gate mechanism. The spine defines the permitted order; the Durable Object enforces it per sequence_id.

6. Receipt Structure — ALLOW

On ALLOW, an HMAC-signed receipt is written to R2 immutable storage before the action executes. Receipt fields are listed in canonical order (alphabetically sorted — the same order used to compute pack_id).

7. Receipt Structure — DENY

Every denied step produces a DENY receipt. This is the critical distinction from post-execution logging: the gate receipts what it stopped, not just what it allowed. A DENY receipt is forensic evidence of an enforcement event — proof the gate was active and refused a non-compliant step.

8. Cryptographic Model

pack_id is computed as SHA-256 of the receipt's canonical JSON — keys alphabetically sorted, values as-stored. This makes the fingerprint deterministic regardless of key insertion order. Any verifier can reproduce it independently.

prev_receipt_id links every receipt to the previous receipt in the sequence. Tampering with any receipt in a chain breaks the hash of every subsequent receipt. The chain is self-verifying without a trusted third party.

signature is HMAC-SHA256 computed at gate level with key k1_2026-02-22_01. Multi-generation verification logic covers both canonical JSON and JSON.stringify forms to handle Gen-1 and Gen-2 receipts.

The signature_alg field on every receipt records the algorithm used (hmac-sha256 or Ed25519). Ed25519 signing and verification are fully implemented in the codebase via SubtleCrypto; when activated, receipts carry an Ed25519 signature verifiable against a published public key without calling any AgenticRail endpoint. HMAC remains the active algorithm pending key provisioning.

payload_hash is SHA-256 of the raw request body — independent verification that the payload the gate evaluated matches what was submitted.

9. Article 12 Mapping — EU AI Act

10. Live State — 2026-05-17

11. SC 27 Security Evidence Brief

A formal evidence brief mapping AgenticRail's production security mechanisms to four gaps in ISO/IEC 27090 (FDIS, February 2026) not covered by the standard's current threat taxonomy — sequence replay, pre-execution cryptographic receipts, tamper-evident chain integrity, and permanent sequence sealing. Prepared for ISO/IEC JTC 1 SC 27 consideration.

agenticrail.nz/spec/sc27-brief/ — includes gap analysis, mechanism descriptions, production evidence, and references. Prints to two pages.

12. NIST AI RMF Mapping

A formal mapping of AgenticRail's pre-execution enforcement gate to NIST AI Risk Management Framework 1.0 subcategories: Govern 1.2 (designated personnel with structural authority to intervene), Measure 2.5 (per-action monitoring contemporaneous with execution), and Manage 4.2 (risk controls integrated into the critical execution path). Includes the evidence package available for US enterprise and federal AI risk programme documentation.

agenticrail.nz/spec/nist-ai-rmf/ — gap analysis, subcategory mapping table, mechanism descriptions, evidence available, cross-framework alignment. Prints to two pages.

13. Formal Receipt Schema

A machine-readable JSON Schema (Draft 2020-12) for the slp8_receipt_v2 enforcement receipt is published at agenticrail.nz/spec/receipt-schema.json.

The schema formally specifies three objects:

• 1Receipt (slp8_receipt_v2) — the signed enforcement decision written to R2 before the action executes. Fields: ts_ms, pack_id, version, decision, reasons, executed, sealed, meta, attestation, payload_hash, prev_receipt_id, key_id, signature_alg, signature. additionalProperties: false on all objects — the schema is closed.
• 2Pack (slp8_pack_1.0) — the enforcement decision object whose SHA-256 canonical hash becomes pack_id. The minimal authoritative record of the decision, independent of receipt metadata. Defined at $defs.pack.
• 3Request Payload — the client payload submitted to POST /v1/evaluate. Eight required fields; the raw body is hashed to produce receipt.payload_hash. Defined at $defs.request_payload.

Relation to DIS 24970. ISO/IEC DIS 24970 (AI system transparency and traceability, targeting Q4 2026 finalisation) contains no receipt structure for pre-execution enforcement decisions — no specification of what an ALLOW or DENY record must carry, how denial codes map to enforcement rules, or how receipts chain across a sequence. The slp8_receipt_v2 schema addresses this gap directly: a production schema with over one million signed enforcement decisions predating the standard's finalisation. The seven reason codes (SEQUENCE_VIOLATION, REPLAY_NONCE, SEALED_SEQUENCE, NO_POLICY_MATCH, FUNCTION_STEP_MISMATCH, ACTION_NOT_ALLOWED, STALE_TIMESTAMP) enumerate the enforcement failure taxonomy in machine-readable form.

The schema is dated 2026-05-17. Future revisions carry new $id URIs and retain prior versions at their original URLs.

14. DIS 24970 Gap Analysis — Evidence Brief

A formal gap analysis identifying three structural absences in ISO/IEC DIS 24970 (AI system transparency and traceability) that are consequential for agentic AI deployments: the absence of a receipt structure for pre-execution enforcement decisions, the absence of an enforcement failure taxonomy for ordered agent sequences, and the absence of a chain integrity specification. Prepared for ISO/IEC JTC 1 / SC 42 consideration. Related to SIP0001245 submitted to the EU AI Office 2026-05-17, Priority 2 High.

agenticrail.nz/spec/dis-24970/ — gap analysis, slp8_receipt_v2 reference implementation, mapping to DIS 24970 transparency requirements, EU AI Act alignment, live evidence. Fingerprinted. Published 2026-05-26.

The v1.0 fingerprint above is permanent and unchanged. The amendment below records a later development — the activation of Ed25519 signing — as a separate, independently-fingerprinted record. v1.0 is not edited; it is superseded.