NIST AI RMF
The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023) is a voluntary framework organized around four core functions: Govern, Map, Measure, and Manage. This page documents how chio's shipped primitives map onto those functions and their subcategories. It is a mapping, not a certification claim.
Framing
The Four Functions
The RMF organizes controls into four functions. Chio contributes to each one differently. At a glance:
| Function | What RMF Expects | Chio Contribution |
|---|---|---|
| Govern | Organizational culture, policies, roles, accountability. | Policy-as-code artifacts, signed policy hashes embedded in receipts, workload identity attribution, revocation and decommissioning mechanics. |
| Map | Context identification, risk scoping, inventory, control cataloging. | Signed tool manifests, capability-scoped grants, guard catalog, per-invocation receipts with full provenance. |
| Measure | Quantitative risk analysis, tracking, reporting. | Receipt query API, aggregation surfaces, denial rates, guard trigger counts, cost aggregates. |
| Manage | Prioritization, risk response, monitoring, supersession. | Capability revocation, scope reduction, step-up approval, monetary bonds, evidence export for remediation. |
Chio's strongest contribution is to Map and Manage: capabilities, guards, receipts, and revocation are the tool-layer implementation of context identification, control cataloging, and risk response. Govern subcategories are largely organizational; chio contributes where policy-as-code and workload identity touch organizational artifacts. Measure is partially covered: chio emits the raw data but leaves risk scoring to the operator's analytics stack.
Coverage Legend
| Level | Meaning |
|---|---|
supports | Chio's shipped controls directly implement the subcategory at the tool-governance layer. |
evidence-for | Chio supplies relevant evidence or partial enforcement; the organization must add procedural work. |
org-owned | Subcategory is organizational or process-level; chio does not implement it. |
out-of-scope | Subcategory addresses concerns outside chio's governance boundary (e.g., model training, workforce composition). |
Function: GOVERN
Govern is primarily organizational. Chio aligns with the subcategories that describe signed policies, risk tolerance encoded as configuration, and lifecycle mechanics like decommissioning.
| Subcategory | Requirement | Chio Mapping | Coverage |
|---|---|---|---|
| GOVERN-1.1 | Legal and regulatory requirements for AI are understood and managed. | Capability tokens carry issuer, not_before, not_after; policy hash appears in every receipt. | evidence-for |
| GOVERN-1.2 | Risk-management roles and responsibilities are documented. | Issuer and delegation chain on every capability attribute technical authority; workload identity metadata tags the actor. | evidence-for |
| GOVERN-1.3 | Processes defined to determine risk tolerance. | Velocity config plus max_total_cost and max_cost_per_invocation encode tolerance as executable configuration. | evidence-for |
| GOVERN-1.5 | Ongoing monitoring and review are in place. | Receipt store, checkpoint monitor, trust-control dashboard, SIEM export. | supports |
| GOVERN-1.6 | Mechanisms to inventory AI systems. | Signed ToolManifest per tool server, WorkloadIdentity metadata per capability. | evidence-for |
| GOVERN-1.7 | Decommissioning processes defined. | Capability revocation runtime, grant expiry, delegation revocation. | supports |
| GOVERN-2.1 | Roles and responsibilities for AI risk are documented. | Issuer and delegation chain attribute authority at the protocol layer; human roles live outside chio. | evidence-for |
| GOVERN-2.2 | Workforce equipped with AI knowledge. | Not applicable at the protocol layer. | org-owned |
| GOVERN-4.1 | Organizational risk culture supports AI risk management. | Fail-closed kernel evaluation, deny receipts on every error path. | evidence-for |
| GOVERN-4.3 | Information sharing across stakeholders. | Signed evidence bundles via the export envelope support portable audit exchange. | evidence-for |
| GOVERN-5.1 | Policies for addressing AI risk exist. | Policy-as-code artifacts compiled from chio-policy; guard configurations and chio.yaml. | supports |
| GOVERN-6.1 | Policies to address third-party AI risk. | Capability scoping restricts which third-party tools are reachable; delegation attenuation prevents authority amplification. | supports |
Signed policy hashes are your audit anchor
Function: MAP
Map is where chio's evidence posture shines. Every action produces a signed receipt. Every tool is described by a signed manifest. Every capability has typed constraints. The result is that the organization never has to reconstruct context after the fact.
| Subcategory | Requirement | Chio Mapping | Coverage |
|---|---|---|---|
| MAP-1.1 | Intended purposes and context are documented. | Tool manifest descriptions, workload identity metadata on capability tokens. | evidence-for |
| MAP-1.5 | Organizational risk tolerances are determined. | Velocity config, budget caps, GovernedAutonomyTier on capability tokens. | evidence-for |
| MAP-2.1 | Task and method are identified and defined. | Tool definitions within the signed manifest: parameter schema, description, and typed constraints. | supports |
| MAP-2.3 | AI capabilities, targeted usage, and assumptions are documented. | Tool manifests plus agent passports that carry receipt roots and reputation signals. | evidence-for |
| MAP-3.2 | Potential costs are examined. | Financial metadata on every receipt; budget enforcement inside the kernel. | supports |
| MAP-3.4 | Processes for human-AI configurations are established. | DPoP binds an agent keypair to every invocation; capability subject identifies the responsible agent. | evidence-for |
| MAP-3.5 | Processes for human oversight are defined. | DPoP proofs and GovernedApprovalToken for step-up review at higher autonomy tiers. | supports |
| MAP-4.1 | Approaches for mapping AI risks are identified. | Guard pipeline produces structured verdicts; receipt analytics surfaces aggregates. | evidence-for |
| MAP-4.2 | Internal risk controls are identified and documented. | Named guards: velocity, egress allowlist, secret leak, path allowlist, data-flow, response sanitization, patch integrity. | supports |
| MAP-5.1 | Likelihood and magnitude of each impact are identified. | Raw data available via receipt store; risk scoring layer is operator-owned. | evidence-for |
Function: MEASURE
Measure asks for quantitative tracking of risks, mitigations, and outcomes. Chio emits the raw data: every invocation, every denial, every guard trigger, every cost event is a signed, queryable record. Scoring itself is left to the operator, because scoring requires taxonomy choices that are organization-specific.
| Subcategory | Requirement | Chio Mapping | Coverage |
|---|---|---|---|
| MEASURE-1.1 | Approaches and metrics for measurement are selected. | Receipt query API exposes counts, denial rates, cost aggregates, and guard-trigger frequencies. | evidence-for |
| MEASURE-2.3 | Performance metrics are tracked. | Receipt store records timing, outcome, and cost; SIEM export streams these to downstream analytics. | evidence-for |
| MEASURE-2.4 | Measurement results are documented. | Signed evidence bundles and session compliance certificates. | supports |
| MEASURE-2.5 | Robustness, reliability, resilience are evaluated. | Fail-closed pipeline, checkpoint integrity verification, archival of signed receipts. | evidence-for |
| MEASURE-2.6 | Safety risks are evaluated. | Content-safety guards (prompt-injection, secret leak), egress allowlist, forbidden path, response sanitization. | supports |
| MEASURE-2.7 | Security and resilience are evaluated. | Signed receipts, Merkle checkpoints, DPoP, capability revocation. | supports |
| MEASURE-2.8 | Privacy violation risks are examined. | PII-oriented response sanitization, query-result guard, column constraints on data guards. | evidence-for |
| MEASURE-3.2 | Risks are tracked at scale. | Merkle checkpoints enable scalable tamper-evident aggregation; receipt query pagination keeps analytics tractable. | supports |
| MEASURE-4.2 | Risks from deployment environments are evaluated. | Internal network and egress allowlist guards limit environmental reach of governed agents. | evidence-for |
Scoring is not shipped
Function: MANAGE
Manage covers prioritization, treatment, and post-deployment response. Chio's capability-plus-revocation model is precisely the primitive the Manage function needs at the tool boundary.
| Subcategory | Requirement | Chio Mapping | Coverage |
|---|---|---|---|
| MANAGE-1.1 | Purpose and impacts are prioritized. | Underwriting tiering plus GovernedAutonomyTier on capability tokens. | evidence-for |
| MANAGE-1.2 | Treatment of documented risks is prioritized. | Guard pipeline verdicts, deny receipts, scope reduction, grant expiry. | evidence-for |
| MANAGE-1.3 | Responses are developed, planned, documented. | Revocation runtime, scope reduction, approval tokens. | evidence-for |
| MANAGE-2.1 | Resources are allocated to risks. | Budget enforcement through per-grant caps and monetary receipts. | supports |
| MANAGE-2.2 | Mechanisms to supersede, disengage, deactivate AI. | Capability revocation, token expiry, delegation revocation at any parent in the chain. | supports |
| MANAGE-2.3 | Procedures to respond to risks. | Guard pipeline deny, step-up approval via GovernedApprovalToken, evidence export for downstream investigation. | supports |
| MANAGE-2.4 | Post-use processes and procedures are applied. | Evidence retention archives signed receipts past deactivation; archived receipts still verify against stored checkpoints. | supports |
| MANAGE-3.1 | Resources are allocated to identified AI risks. | Financial metadata per receipt tracks monetary allocation by risk category. | evidence-for |
| MANAGE-4.1 | Post-deployment AI monitoring is applied. | Receipt stream plus checkpoint integrity checks. | supports |
| MANAGE-4.2 | Actionable feedback about AI risks is captured. | Guard evidence in every receipt, SIEM event stream. | evidence-for |
Evidence Collection Example
A common review question is: "show me the evidence that covers MAP-2.1 and MANAGE-2.2 for the past quarter." Chio gives that as a queryable bundle.
# Pull the signed manifest that defines the tool surface (MAP-2.1).
$ chio manifest verify \
--manifest-file ./tool-manifest.json > manifest-verified.json
# Export the quarter's receipts for revocation activity (MANAGE-2.2).
$ chio receipts query \
--since 2026-01-01T00:00:00Z \
--until 2026-03-31T23:59:59Z \
--kind revocation \
--receipt-db ./receipts.sqlite3 > q1-revocations.json
# Bundle into an auditor-facing evidence envelope.
$ chio evidence export \
--policy ./policy.yaml \
--receipt-db ./receipts.sqlite3 \
--include manifest-verified.json \
--include q1-revocations.json \
--output ./q1-rmf-evidence-bundleThe resulting bundle carries signed manifests, filtered receipts, and the embedded policy hash. An auditor can verify the bundle's signatures, verify each included receipt's checkpoint, and pull inclusion proofs for any subset of interest, without needing runtime access to the live kernel.
Gaps and Non-Goals
- Risk scoring: chio emits the raw data for MEASURE, but scoring is operator-owned.
- Residual-risk register: MANAGE-1.4 requires tracking residual risk. Chio does not model residual risk explicitly; operators build that register from receipt aggregates.
- Fairness, bias, environmental impact: MEASURE-2.9 through MEASURE-2.12 concern model-layer properties that a tool-governance layer cannot observe.
- Workforce-related Govern subcategories: roles, training, leadership commitment, and stakeholder culture are organizational and not implementable in code.
Not a certification artifact
Cross-References
- Capabilities for the scoping model referenced in Map and Manage.
- Receipts for the evidence record format used by Measure.
- Guards for the named controls that implement Map-4.2.
- EU AI Act for the parallel mapping against Article 19 logging.