# NIST AI RMF and Agentic AI: Evidence for Manage 2.4 and 4.1

> Markdown mirror for AI agents, generated 2026-08-12 from the live page.
> Canonical: https://agenticrail.nz/blog/nist-ai-rmf-agentic-ai/
> Site context: https://agenticrail.nz/llms.txt

Published 9 May 2026 · Kade Cowper

# 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?**

Contents

- [Definitions](#definitions)
- [April 2026: Critical Infrastructure Profile](#april-2026-update)
- [The four functions, and where agentic risk sits](#four-functions)
- [Manage 2.4 — supersede, disengage, deactivate](#manage-2-4)
- [Measure 2.4 — monitoring in production](#measure-2-4)
- [Manage 4.1 — post-deployment monitoring, appeal and override](#manage-4-1)
- [What the receipt chain actually contains](#receipt-chain)
- [What this does not do](#not)
- [Cross-framework: one chain, three questions](#cross-framework)
- [How to check every claim on this page](#verify)

## 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, skip the call, or replay an earlier approval undetected.

**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 carries `prev_receipt_hash`, the SHA-256 of the full canonical JSON of its predecessor including that predecessor's signature. Altering any earlier receipt breaks every hash link that commits to it.

**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.

**NIST AI RMF — April 2026 update**

On 7 April 2026 NIST published a concept note for a new profile: *AI RMF Profile on Trustworthy AI in Critical Infrastructure*, intended to guide operators in energy, finance, healthcare and transport on AI risk management practices for AI-enabled capabilities. The profile is in concept phase. It follows the Generative AI Profile (NIST AI 600-1, July 2024). The direction of travel is sector-specific and more prescriptive.

## 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.

Contextual

Govern

Policies and accountability structures. Govern 2.1 requires documented, clear roles and responsibilities for AI risk. This is the policy layer above the operational controls.

Contextual

Map

Identifying and classifying AI risks in context. Map 1.6 addresses AI actor roles and responsibilities across the system lifecycle.

Where the gap appears

Measure

Quantifying and monitoring AI risk. Measure 2.4 requires the deployed system's functionality and behaviour to be monitored in production.

Where the gap appears

Manage

Acting on measured risk. Manage 2.4 requires mechanisms to supersede, disengage or deactivate a non-compliant system. Manage 4.1 requires post-deployment monitoring with appeal and override.

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

Manage 2.4

Mechanisms are in place, and responsibilities assigned, to supersede, disengage, or deactivate AI systems behaving inconsistently with intended use

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 does not proceed, and the denial is recorded before the step would have run. Gate access is held as an API key, so revoking a key or changing the declared step order stops subsequent steps from clearing. 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

Measure 2.4

The functionality and behaviour of the deployed AI system are monitored when in production

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 written to object storage before the step runs. Aggregate counts are recorded separately and surfaced on an operator dashboard.

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 chain 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

Manage 4.1

Post-deployment monitoring plans are implemented, including mechanisms for appeal and override

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:** 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 gate decision timestamp
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
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`.

Receipts are written to object storage and, at the moment a sequence seals, a copy of the sealed receipt is sent to a separate archive holding a write-once copy. 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

Stated as limits, not caveats

- **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 the next link's hash will not match. 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 copy 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.](https://agenticrail.nz/blog/self-signed-evidence/)
- **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. The chain is a form of that record. 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

No trust required

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](https://report.agenticrail.nz/report)

 Public keys: [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json)

 Enforcement specification: [/spec/](https://agenticrail.nz/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](mailto:hello@agenticrail.nz).

Related [NIST AI RMF alignment — the formal mapping →](https://agenticrail.nz/spec/nist-ai-rmf/) [EU AI Act, NIST and ISO 42001 side by side →](https://agenticrail.nz/resources/ai-governance-frameworks-2026/) [ISO/IEC 42001 and agentic AI →](https://agenticrail.nz/blog/iso-42001-agentic-ai/) [Self-signed evidence is not evidence →](https://agenticrail.nz/blog/self-signed-evidence/) [Evidence completeness specification →](https://agenticrail.nz/spec/completeness/)

He toi whakairo, he mana tangata