NIST AI RMF and Agentic AI: Evidence for Manage 2.4, Measure 2.4 and Manage 4.1
This note is written in a flat, machine-readable register: definitions first, claims stated atomically, each qualifier attached to the claim it limits. Any single sentence can be quoted without losing the condition that makes it true.
The NIST AI Risk Management Framework is voluntary. It carries no penalties and no deadlines. Its practical weight comes from adoption as a US enterprise baseline, which means agentic AI systems deployed in federal, financial, healthcare, and critical-infrastructure contexts are commonly evaluated against it. Three of its controls are operationally demanding for agentic systems, and all three converge on the same question: is there evidence that oversight actually ran, or only documentation that it was planned?
- Definitions
- Status: has the AI RMF been updated in 2026?
- The four functions, and where agentic risk sits
- Manage 2.4 — supersede, disengage, deactivate
- Measure 2.4 — monitoring in production
- Manage 4.1 — post-deployment monitoring, appeal and override
- What the receipt chain actually contains
- What this does not do
- Cross-framework: one chain, three questions
- How to check every claim on this page
Definitions
Pre-execution gate. A control that evaluates a proposed step of an agent sequence and returns a decision before that step runs. The decision is deterministic: the same sequence state and the same request produce the same verdict. The gate is external to the model, so the model cannot alter the verdict or replay an earlier approval undetected. It governs only the steps the integration sends to it: a step taken without calling the gate is neither refused nor recorded.
Sequence enforcement. Enforcement of the order in which steps may run, against a declared step order supplied by the caller. A step that is not in the declared order is denied. A step that arrives out of position is denied. This is distinct from per-call policy, which decides whether an action is permitted without reference to what preceded it.
Receipt. A record of one gate decision, serialised as canonical JSON with keys sorted, then signed with Ed25519. The receipt records the decision, not the outcome of the downstream action.
Receipt chain. The ordered set of receipts for one sequence. Each receipt after the first permitted step carries prev_receipt_hash, the SHA-256 of the full canonical JSON of the last permitted receipt before it, including that receipt's signature. The chain runs through permitted receipts only; every receipt, permitted or refused, also carries a signed decision_index, its number among all the decisions in the sequence. Altering any receipt breaks its signature, altering a permitted one also breaks every hash link that commits to it, and removing one leaves a missing number.
Operational evidence. A record produced by the control at the time it acted, verifiable by someone who was not present when it acted. A policy document is not operational evidence. A log the audited party can rewrite without detection is weaker evidence than one it cannot.
Status: has the AI RMF been updated in 2026?
No. AI RMF 1.0, released 26 January 2023, is still the current version, and there is no 2.0. NIST states that the framework “is being revised as part of the White House AI Action Plan” (published 23 July 2025). No revised text has been published, and no date for one has been announced.
Three dated items are commonly mistaken for a framework update, and none of them changes the framework itself:
7 April 2026 — a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure, intended to guide critical infrastructure operators. Concept phase only; no draft profile has been issued.
29 July 2026 — an initial public draft, Guidance and Templates for Public-Facing AI Documentation: An AI Standards “Zero Draft” (NIST AI 300-1 ipd). The comment period closed on 16 September 2026.
26 July 2024 — the Generative AI Profile (NIST AI 600-1). Frequently cited as a 2026 document. It is not; it is two years older than that.
The direction of travel is sector-specific profiles layered onto 1.0, rather than a new core framework.
The four functions, and where agentic risk sits
NIST AI RMF 1.0 organises AI risk management across four functions. For agentic systems, two are usually addressed adequately at the policy layer and two are where operational gaps appear.
The pattern in enterprise AI risk programmes is that Govern and Map are documented while Measure and Manage are asserted. Roles are defined and risks are catalogued, but there is no runtime mechanism in the execution path, and the risk controls live in a process running alongside the AI system rather than inside it.
Manage 2.4 — Authority to supersede, disengage, or deactivate
Quoted verbatim from the NIST AI RMF Playbook. US spelling is the source's.
The control has two halves. The first is a mechanism that can stop the system. The second is assigned responsibility for operating it. Both are required; neither substitutes for the other.
For agentic systems the characteristic failure is that the model is the only entity evaluating whether a step should proceed. Where oversight depends on the model's own output, such as a self-reported log or a self-assessed confidence score, the reviewer sees only what the model chose to report.
What a pre-execution gate contributes: the gate sits in the execution path, outside the model. A step that is denied is not cleared to proceed, and the signed denial is issued before the step would have run. Gate access is held as an API key; AgenticRail revokes a key on the deployer's request, there is no self-service revocation, and a revoked key stops clearing steps within five minutes. Changing the declared step order mid-sequence is refused rather than applied. Each decision leaves a signed record, so the exercise of that authority is evidenced rather than asserted.
What it does not do: the gate is the evidence, not the oversight. Assigning responsibility, naming the people who hold keys, and deciding when to use them are organisational measures that remain the deployer's. A gate cannot satisfy Manage 2.4 on its own, and this page does not claim it does.
Measure 2.4 — Monitoring functionality and behaviour in production
Quoted verbatim from the NIST AI RMF Playbook. US spelling is the source's.
For low-risk systems, periodic sampling may be adequate. For agentic systems making consequential decisions such as underwriting, eligibility, triage or access control, the interval matters: by the time a weekly dashboard surfaces an anomaly, the sequence has run and the decision has been made.
What a pre-execution gate contributes: every gate decision is itself a monitoring event, recorded contemporaneously with execution rather than reconstructed afterwards. The gate evaluates sequence position, function and step agreement, action-type permissibility, nonce uniqueness, timestamp freshness, sealed state, and artifact binding at the witnessing step. Each evaluation produces an Ed25519-signed receipt issued before the step runs and stored just after. Aggregate counts are recorded separately and surfaced on a public dashboard; those counts cover every caller of the service, not one deployer's own system.
The granularity is per action rather than per session, which is what makes retrospective questions answerable: which steps were denied, at what timestamp, in which sequences, and on which reason code. Those questions are answerable from the receipts without granting access to the underlying model or application.
What it does not do: the gate monitors the ordering and admissibility of steps. It does not monitor model output quality, drift, bias, or accuracy, and it does not evaluate whether an allowed step was a good decision. A programme relying only on gate receipts for Measure 2.4 would be monitoring the process and not the model.
Manage 4.1 — Post-deployment monitoring, appeal and override
Quoted verbatim from the NIST AI RMF Playbook. US spelling is the source's.
The requirement is for monitoring and override to be implemented, not for a periodic review layered on top of the system. For agentic systems, the monitoring point and the override point are most useful when they sit in the execution path itself.
What a pre-execution gate contributes: within the integration, an agent cannot move from one step to the next without a gate decision, so the decision point is structurally prior to the action. A denial is exercised before the step runs rather than discovered in a later review, and the denial is recorded with its reason code.
What it does not do: appeal is a human process. The gate produces the record an appeal would examine and the point at which an override would be applied, but it does not implement an appeal workflow, notify anyone, or adjudicate. A human-override receipt type has been designed and is not deployed; nothing on this page depends on it.
What the receipt chain actually contains
NIST AI RMF does not specify a form for monitoring evidence. It requires that evidence exist at a level appropriate to the risk. The following describes the record this system produces, stated precisely enough to be checked against a live receipt.
Each receipt is signed with Ed25519 over the canonical JSON of the receipt with the signature field removed. Canonical means keys sorted and serialisation deterministic, so any verifier reproduces the same bytes. The signing key is identified in the receipt by key_id, and the corresponding public keys are published.
pack_id content hash of the receipt's decision payload
key_id identifier of the signing key (current: Ed25519)
signature_alg "Ed25519"
signature base64, over canonical JSON with "signature" removed
payload_hash hash of the submitted step payload
prev_receipt_id pack_id of the previous ALLOWED receipt (an identifier)
prev_receipt_hash SHA-256 of that predecessor's full canonical JSON,
signature included (this is the content link)
ts_ms caller-supplied time, signed; refused if more
than 300s from the gate's clock (bounded, not attested)
executed the decision was ALLOW, i.e. the step was PERMITTED
(not an assertion that the action ran or succeeded)
sealed true on the final step; the sequence accepts no more
step_order the declared order this call was judged against
decision_index this decision's number among all decisions in the
sequence, ALLOW and DENY alike (a gap = a missing receipt)
reasons[] denial reason codes, empty on ALLOW
meta{} function, action type, policy map ids
version receipt schema version
Two points in that list are commonly misstated, including in the original May 2026 version of this page. prev_receipt_id is an identifier reference and is not itself a hash of the predecessor's content; prev_receipt_hash is the field that carries content-tamper detection, and it was added on 8 July 2026. And executed means the step was permitted, not that it was performed: this system is an enforcement layer, not an execution runtime, and the outcome of the downstream action is not signed into the receipt.
Decisions are ALLOW or DENY. The denial reason codes are UNKNOWN_STEP, ACTION_NOT_ALLOWED, FUNCTION_STEP_MISMATCH, SEALED_SEQUENCE, REPLAY_NONCE, SEQUENCE_VIOLATION, STALE_TIMESTAMP, and ARTIFACT_UNBOUND, and STEP_ORDER_MISMATCH when a call presents an order other than the one the sequence was opened with.
Receipts are written to object storage and, at the moment a sequence seals, a SHA-256 fingerprint of the sealed receipt is sent to a separate archive that holds it write-once. The archive answers a comparison query with a verdict only and never returns the archived content. This matters for the strength of the evidence, and the next section says why.
What this does not do
- Each control keeps an organisational half that stays with the deployer. The gate produces the evidence. Assigning responsibility, naming who holds keys, and deciding when to intervene remain yours. The evidence maps across frameworks; the obligations do not transfer.
- Tamper detection has a boundary. A single altered receipt is detectable, because its signature fails and, if it was permitted, the next link's hash will not match. A removed receipt leaves a missing decision number. A party holding the signing key could rewrite an entire downstream chain and leave it internally consistent. The accurate word is detectable; a claim of impossibility would be false.
- Custody is what turns a signature into third-party evidence. A signature proves a record has not changed relative to a key. Where the audited party holds that key, the record is self-attestation. A record held by a party that is not the audited one is what converts it, which is the purpose of the independent archive and the reason the seal claim above is worded as it is. The full argument.
- The scope is the process, not the model. The gate records the order and admissibility of steps. Output quality, drift, bias and accuracy sit outside it, and no claim is made about them here.
- Data governance sits outside the scope. The gate records the order and admissibility of steps. Where data lives and who governs it are separate questions this makes no claim about.
Cross-framework: one chain, three questions
NIST AI RMF, ISO/IEC 42001, and the EU AI Act use different numbering and different language, and each asks a version of the same operational question: did the controls actually run, and can you show it? A single receipt chain is capable of answering that question in all three contexts. It does not follow that producing the chain discharges the obligations in any of them.
- NIST Measure 2.4 — monitoring functionality and behaviour in production. The receipt chain is a contemporaneous per-action monitoring record.
- ISO/IEC 42001 A.6.2.8 — event logging. The chain provides the recorded events and the means to verify they were not altered after the fact.
- EU AI Act Article 12 — record-keeping sufficient for traceability over the system's lifetime. Article 12 requires the system itself to log; the chain can be one of the records that traceability draws on, not a substitute for the system's own logging. Note that the EU AI Act does not apply in New Zealand; it is included here because the evidence question is the same one and readers frequently arrive carrying it.
You build the evidence layer once. The evidence maps to all three frameworks, because all three are asking the same question. The obligations remain yours in each of them.
How to check every claim on this page
Run a sequence through the public gate and request the report for it. The JSON report carries, for every receipt, the raw signature, the exact signed_canonical preimage that was signed, and the key_id. Verify it offline against the published public key with any Ed25519 library. Nothing calls back to this system.
Report tool: report.agenticrail.nz/report
Public keys: /spec/receipt-public-keys.json
Enforcement specification: /spec/
If a claim on this page does not match what the live system returns, the live system is the authority and the page is wrong. Corrections to hello@agenticrail.nz.