Framework Mapping
NIST AI RMF
supported by runtime controls.
The NIST AI Risk Management Framework organizes AI risk into four functions. Most tooling addresses them as documentation exercises. The mapping below shows where each function is supported by controls that execute on every call.
Context
What the framework is, and what this page claims
The NIST AI Risk Management Framework is a voluntary framework published by the US National Institute of Standards and Technology. It organizes AI risk management into four functions: Govern, Map, Measure, and Manage.
It is a framework, not a certification scheme. There is no certifying body and no compliance badge — organizations adopt it as a structure for their own risk practice.
This page maps KriftAI's runtime controls onto those four functions. It describes which capabilities support which activities. It does not assert certification, and no such certification exists to assert.
Function 1
GOVERN — culture, policy, and accountability
The Govern function asks for policies, accountability structures, and documented decision rights around AI use.
Policy as configuration
Content-logging mode and availability behaviour are set per organization and take effect immediately, so policy is an operating parameter rather than a document describing intent.
Accountability structure
Three access layers — organization, workspace, and group — establish who holds authority over budgets, settings, access, and exports.
Documented decision rights
Override authority is explicit: escalations require an admin decision, and reviewer identity is captured with the outcome.
Policy portability
Governance configuration exports as a versioned JSON document and re-imports with validation, making policy reviewable and transferable between instances.
Function 2
MAP — context, scope, and where AI is actually used
The Map function asks organizations to establish where AI is deployed, in what context, and with what expected impact.
Capture-point coverage
The coverage map enumerates every AI capture point in the platform with live counts and last-seen timestamps, distinguishing active points from those instrumented but not yet triggered.
Use-case registry
Usage is tracked per use case, giving a live inventory of where AI is operating rather than a periodically refreshed spreadsheet.
Model and provider visibility
Because every call routes through one entry point, the platform records which models and providers are actually being invoked.
Function 3
MEASURE — analysis, tracking, and metrics
The Measure function asks for quantitative and qualitative assessment of identified risks, tracked over time.
Per-call verdict capture
Every governed call records whether input validation found threats and whether output validation passed, flagged, or blocked — giving a continuous measurement series rather than sampled review.
Flagged and blocked rates
Flagged and blocked counts are aggregated per use case and per organization, making guardrail activity a tracked metric.
Derived consumption metrics
Token consumption is aggregated from ledger rows rather than stored separately, so measurement cannot drift from what executed.
Exportable evidence
Full audit-trail export as JSON or CSV supports external analysis and independent verification.
Function 4
MANAGE — response, mitigation, and resource allocation
The Manage function asks that identified risks be acted on, with responses prioritized and resourced.
Automated mitigation
High-severity input threats block before model invocation. Output violations block, redact, or flag according to configured severity — mitigation executes rather than being scheduled.
Human escalation path
Break-glass review lets a person override a block with a documented reason, with the decision written to the same immutable record.
Resource allocation
Token budgets at organization and use-case scope, with alert thresholds and optional hard caps, apply consumption limits as an operational control.
Failure posture
Availability behaviour is configurable per organization — fail-closed blocks when a validator cannot run, fail-open proceeds — making the response to control failure an explicit decision.
Framework functions, supported by executing controls
See how the governance layer produces the measurement and management evidence the framework asks for.