Compliance NIST AI RMF

NIST AI RMF and the Generative AI Profile

Not legal advice, and not a statement that Tracekit meets any outcome (about these pages).

Scope

The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, released 26 January 2023) is a voluntary framework from the US National Institute of Standards and Technology for managing the risks of AI systems. It has four functions, GOVERN, MAP, MEASURE and MANAGE, each split into categories and subcategories. Subcategories are outcomes an organisation reaches with people, process and technology together, not controls a product meets. The Generative AI Profile (NIST AI 600-1, July 2024) applies the framework to generative AI: it lists 12 risks and suggests actions, each with an ID tied to a subcategory (MG-4.3-002 is the second suggested action for MANAGE 4.3). Neither binds anyone who hasn't adopted it, through a contract, a policy or a regulator's expectation. NIST says AI RMF 1.0 is being revised; this page maps 1.0. Each row below names the part Tracekit can contribute.

Mapping: AI RMF 1.0

Requirement	What Tracekit provides	Evidence to show	Your responsibility / limits
GOVERN 1.4. The risk management process and its outcomes are set through transparent policies, procedures and other controls, based on organisational risk priorities.	The policy is a file. tracekit policy lint reports every error, the signer refuses to start on one, and tracekit policy compile prints its canonical form and policy_hash. Every decision carries the policy_hash it was made under, so which policy applied to a call is part of the record (policy).	The policy file and its hash; policy_hash on each policy.decision.	The policies and procedures themselves, and which risks the rules address. Rules match text: they are tripwires (limits).
GOVERN 1.5. Ongoing monitoring and periodic review of the risk management process are planned, with roles and the review frequency defined.	Records to review: decisions by rule, approvals and gaps. tracekit policy backtest runs a changed detection policy over recorded runs, and mode: shadow records what a response would have done before you enforce it (experimental, policy).	Verify reports over time; backtest output.	The review plan, its frequency and its owners.
GOVERN 3.2. Policies and procedures define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.	signer.yaml names who may answer approvals, who may answer any approval with a reason (break-glass), which identities are one person, and which identities are agent approvers (experimental), which may answer only within bounds the policy sets. The signer enforces these roles (approvals).	The approvals section of signer.yaml; approver identity and approver_kind on each approval; report lines approvals by people and approvals by agents, printed when a bundle holds an agent approver's answer.	Defining the roles and training the people. An agent approver's judgment is model output that the requesting agent can steer within the bounds (limits).
GOVERN 4.3. Organisational practices enable AI testing, identification of incidents and information sharing.	Detection opens signed incidents, and shadow mode tests a response before it is enforced (experimental). Bundles can be shared with anyone and checked offline against keys they pin themselves (auditor guide).	incident.opened records; bundles shared, with their verify reports.	The practices, and what you share with whom.
GOVERN 6.1, MANAGE 3.1. Policies address AI risks from third parties; risks from third-party resources are monitored, and controls are applied and documented.	The MCP gateway and the tool executor (experimental) run third-party MCP servers and APIs with credentials the agent never holds, decide every call in the signer and record it (MCP gateway, executor). The LLM gateway (experimental) records tools the model provider runs itself and can refuse requests that enable them (gateway).	T2 records naming the service in via; model.exchange tool uses with executed_by: provider; provider_executed on run.final.	Vetting suppliers and models, and the contracts with them. Tracekit doesn't assess a third party, and covers only calls routed through those services (limits).
MAP 3.5. Processes for human oversight are defined, assessed and documented, following the organisation's policies.	Oversight is part of the policy: ask rules, and approvals that need a passkey for high-risk calls (experimental). The approval records show who answered each held call, and when. For agent approvers, shadow mode records their suggestions next to what people decided (experimental).	ask rules in the policy; approval.request, approval and approval.suggested records.	Defining the processes and assessing whether they work.
MAP 4.2. Internal risk controls for the system's components, including third-party AI technologies, are identified and documented.	The policy maps each tool to a class and names the rules that apply to it; lint rejects a class rule that no tool maps to. The shipped packs list every rule with its id (packs).	The policy file; the packs reference.	Controls for components other than tool calls.
MEASURE 2.4. The functionality and behaviour of the system and its components are monitored in production.	Every tool call routed through Tracekit is decided and recorded. Through the LLM gateway, model exchanges too; through the egress observer, the hosts each run reached (both experimental). Reconciliation flags a call one capture layer saw and another didn't (gateway).	Bundles; report lines coverage, coverage matrix and tiers.	Monitoring output quality and model behaviour. Actions no capture path sees leave no record (limits).
MEASURE 2.7. The system's security and resilience are evaluated and documented.	Records of what the policy stopped (denied and held calls by rule), signed tamper records and gaps. For Tracekit itself: published threat models and experiments (server threat model, evaluation).	Decisions; trace.tamper records; the verify report.	Evaluating your system's security. Tracekit's experiments are its authors' own, small and synthetic, and don't test your deployment.
MEASURE 2.8. Risks associated with transparency and accountability are examined and documented.	For each agent action: which identity acted, for which principal (attested, which needs an OIDC issuer and is experimental, or app-asserted), what tool, which rules matched, under which policy, approved by whom. Anyone can verify it offline against keys they pin (identity, verdicts).	run.registered (caller identity, principal and whether it is attested), decisions, approvals; verify reports.	Examining these risks, and transparency of the system's outputs to the people they affect.
MEASURE 3.1. Approaches, personnel and documentation are in place to regularly identify and track existing, unanticipated and emergent risks, based on performance in deployed contexts.	Detection sequences and limits over the signed records (experimental); hosts no call explains, from the egress observer (experimental); flag rules; and, in the server pack, tools the policy doesn't know held for a person (unknown_tools: ask).	incident.opened, flagged decisions, reconcile.unexplained_effect.	The personnel and documentation. Detection catches the patterns it describes, nothing else (limits).
MANAGE 1.3. Responses to high-priority risks are developed, planned and documented; options include mitigating, transferring, avoiding or accepting.	Responses written in the policy, under its hash: deny a call, hold it for a person, flag it and let it run, and on a trigger hold or quarantine a run or notify (experimental).	The policy; decisions and incidents under it.	Choosing the responses.
MANAGE 2.3. Procedures are followed to respond to and recover from a previously unknown risk once identified.	An operator holds or quarantines runs, suspends identities and resolves incidents, each a signed record of who did it and the reason given (experimental, incidents). A changed policy shows as a new policy_hash. tracekit why (experimental) finds which input caused an action by replaying the run without it.	run.held, run.quarantined, incident.resolved; the new policy_hash; why.finding.	The procedures, and recovery of the systems the agent acted on.
MANAGE 2.4. Mechanisms, with assigned responsibilities, supersede, disengage or deactivate systems whose performance or outcomes are inconsistent with intended use.	Quarantine (final), suspension of an identity, and the switch that turns off every agent approval (all experimental). Operator calls are explicit grants, never defaults, and the signer refuses to start when one authorize entry grants both registering runs and an operator call (incidents).	run.quarantined, identity.suspension and approval.agents records; the authorize section of signer.yaml.	Deciding when to use them. They are enforced only where the signer decides each step, and don't stop the agent's process (limits).
MANAGE 4.1. Post-deployment monitoring plans are implemented, including mechanisms for input from users and other actors, appeal and override, decommissioning, incident response, recovery and change management.	Override: approvals and their refusals. Incident response: incidents and containment (experimental). Change management: every decision names its policy's hash, so a policy change shows in the records.	Approval records; incident records; policy_hash across decisions.	The plan; channels for user input and appeal; decommissioning.
MANAGE 4.3. Incidents and errors are communicated to relevant actors, including affected communities; processes for tracking, responding to and recovering from them are followed and documented.	Incidents are signed records that cite the records behind them and say who resolved them and why. Webhooks deliver them at least once to a SIEM (experimental, webhooks). Bundles can go to whoever needs them.	incident.opened, incident.updated, incident.resolved; webhook deliveries; bundles.	Telling affected people and other actors. Tracekit notifies no one outside your own systems.

Mapping: Generative AI Profile (NIST AI 600-1)

Five of the profile's 12 risks concern what Tracekit records or controls.

Requirement	What Tracekit provides	Evidence to show	Your responsibility / limits
Information Security (§2.9). Generative AI lowers the barrier to offensive cyber operations, and widens the attack surface, for example to prompt injection and data poisoning.	Gating of the tool calls an injected or misaligned agent makes: the packs deny or hold risky calls (packs), and provenance rules (experimental) hold calls whose target only untrusted content brought in. Tamper-evident records.	Denied and held calls by rule id; the verify report.	Model and application security. Rules are tripwires; Tracekit doesn't reduce what a model can help an attacker do.
Human-AI Configuration (§2.7). Arrangements between people and AI can lead to anthropomorphising, algorithmic aversion, automation bias, over-reliance or emotional entanglement.	Held calls go to named people, who see the signer's copy of the arguments, not what the agent shows; their answers are recorded (approvals).	Approval records; approvals: self and break-glass approvals lines.	Automation bias in approvers: a person can approve whatever is put in front of them, and an agent can persuade them (guarantees).
Value Chain and Component Integration (§2.12). Upstream third-party components can be integrated without transparency or traceability.	Records of calls to third-party tools, MCP servers and provider-run tools, as for GOVERN 6.1 above (experimental services).	T2 records with via; executed_by: provider tool uses.	Supplier vetting and the provenance of models and data.
Data Privacy (§2.4). Personal or sensitive data can leak, or be used, disclosed or de-anonymised without authorisation.	Records hold salted commitments to arguments and results, not content. The signer redacts known secret patterns before it commits to a result. Policy rules can deny secrets in arguments and, with provenance (experimental), hold mail to recipients that only untrusted content brought in (privacy).	redaction manifests on tool.result; denied calls (TK-S002, TK-S003).	Data protection as a whole. Redaction is pattern-based and misses secrets it doesn't recognise; commitments hide content, not timing, sizes or counts (limits).
Information Integrity (§2.8). Content that doesn't distinguish fact from opinion or fiction, and large-scale mis- and disinformation.	Integrity of the record of the agent's actions only: who did what, under which policy, unchanged since it was signed.	Bundles and verify reports.	The integrity of generated content. Tracekit doesn't check outputs for truth.

Suggested actions where Tracekit's records are an input (each is an action for your organisation, not for a tool):

Requirement	What Tracekit provides	Evidence to show	Your responsibility / limits
MG-4.3-002. Record and track reported errors, near-misses and negative impacts.	Denied and held calls, signed gaps and incidents are near-misses already on the record.	Decisions, gaps, incident records.	Errors and impacts outside agent actions; the tracking process.
MS-4.2-004. Monitor and document instances where people or other systems override the system's decisions.	Every rejection of a held call, and every decision that denied a call the agent asked for, is a signed record.	approval records with decision reject; policy.decision with deny.	Evaluating why overrides happen.
GV-4.3-002. Identify the minimum criteria for incident reporting (system id, title, reporter, date, description, impacts, ...).	An incident record carries its id, trigger, rule ids, scope, the records it cites and the time; incident.resolved adds who resolved it and why.	incident.* records.	Defining the criteria, and the fields Tracekit doesn't hold (impact, affected stakeholders).
MG-4.3-001. After-action assessments of incidents check that response and recovery processes were followed and effective.	Bundles of the runs involved, with the verifier's check that each containment response was honoured (incidents line, incidents).	Bundles; verify reports.	The assessment.
GV-6.2-002. Document incidents involving third-party GAI data and systems.	Incidents and records of calls through the MCP gateway and executor name the upstream tool (experimental).	Incident records; T2 records.	Documenting the third party's role and contacting it.

Not covered by Tracekit

• MAP 1 and MAP 3.1–3.4: context, intended purpose, benefits and costs. Tracekit doesn't establish context.
• MEASURE 2.1–2.3, 2.5, 2.6, 2.9–2.13: test sets, validity, reliability, safety evaluation, explainability, privacy risk evaluation, fairness and bias, and environmental impact. Tracekit doesn't evaluate models.
• GOVERN 2 (training and accountability structures), GOVERN 5 (external feedback) and MEASURE 3.3 (feedback from end users).
• AI 600-1 risks it doesn't address: CBRN Information or Capabilities; Confabulation; Dangerous, Violent, or Hateful Content; Environmental Impacts; Harmful Bias and Homogenization; Intellectual Property; Obscene, Degrading, and/or Abusive Content.
• Content provenance for generated content (AI 600-1's primary consideration of that name): Tracekit records where an argument's values came from within a run, not where generated media came from.

Sources

Checked on 2026-10-18.

• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (doi:10.6028/NIST.AI.100-1)
• NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf (doi:10.6028/NIST.AI.600-1)
• NIST AI RMF page, with the revision notice: https://www.nist.gov/itl/ai-risk-management-framework