The NIST AI Risk Management Framework helps organizations organize their AI risk work. AAES Govern contributes controls and records for tool actions routed through it. This page explains what a reviewer can inspect; it does not map the whole framework.
These pages describe the product. They are not a certification or a legal opinion.
Reading this note
This note describes selected AAES Govern controls and records. The official source instrument is authoritative for the framework's content. The organization's approved policies and control records define its control position.
Instrument identity
- Title
- NIST AI Risk Management Framework (AI RMF 1.0)
- Publication
- NIST AI 100-1, January 2023. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan; on October 29, 2026, its framework page still offered AI RMF 1.0 as the download.
- Issuing body
- National Institute of Standards and Technology
- Instrument type
- Voluntary guidance (not a law)
- Official sources
- NIST AI Risk Management Framework overview and NIST AI 100-1, official PDF.
The four functions are Govern, Map, Measure, and Manage.
Question
Before authorizing an agent to act, which action-layer controls and records can a reviewer inspect?
The inspection can focus on accountable human managers, named approvers, permitted capabilities, approval rules, routed spending limits, and the conditions under which AAES Govern denies an action. A scoped evaluation can then produce records from the client's test tenant for review.
AAES Govern governs registered tool calls and actions. Application payloads may contain prompt, completion, or personal data.
Selected contribution
The following selected design themes and records may be usable as operational evidence within the client's own AI RMF activities. This table does not map controls to individual AI RMF subcategories; that association belongs in the organization's documented assessment. Its scope is the action layer, not the framework as a whole.
| Control or record | What a reviewer can examine | Boundary |
|---|---|---|
| Named approval | Every registered agent has at least one accountable manager, ultimately answerable to a person. Approvers are named in AAES Govern. An agent cannot approve itself. Actions classified as irreversible require approval by an authorized person; policies can require approval for other actions. | Recorded authorization does not establish that the underlying decision was correct. |
| Permitted capabilities | An agent can discover callable tools only within its current permissions. The capability catalog may also show tools it can request permission to use. Grants are task-scoped and have a time to live. | Enforcement depends on control of the agent's credential path. |
| Budgets | AAES Govern can commit budget when authorizing a routed action. Requests that exceed the configured ceiling are blocked before dispatch; refusals are recorded when the journal is available. | This does not cap vendor spending outside AAES. |
| Fail-closed denial | If the decision journal cannot be written, AAES Govern issues no new grant. Confirm the denial via the daemon response; there will not be a journal row for that denial. | Grants issued before a journal failure remain valid until their expiry, at most 15 minutes from issue. |
| Sealed records | AAES Govern produces one sealed, hash-chained record per action. Exports can be checked offline against a public key held by the client. In a client-operated deployment, AAES, the company, holds no copy of the private key. For an AAES-hosted deployment, the client agreement defines key custody and access. | Integrity does not prove a complete action history or a successful external outcome. |
Preconditions and gaps
- Credential-path control is required. Activity outside AAES Govern is visible only where telemetry is supplied. Observation is not enforcement.
- No independent witnesses are configured by default. Independent attestation requires a configured external witness or timestamp authority and trust material obtained separately from the export.
- Adapter testing is not live-tenant verification. Native adapters are tested against local servers speaking vendor API formats. Live tenant validation happens during a design partnership.
- No production adoption as of this review. Clients operate their own deployments; AAES does not offer a hosted deployment. Internal checks do not establish production validation or independent certification.
Use the verification guide to check an export and understand its limits. Checking retained records cannot establish a complete action history or prove the underlying events.
Record formats and integrity checks
The public aaesverify CLI checks export integrity: projected entry fields, record-hash commitments, the chain, signed tree head and anchors under the supplied trust material. Checking stored authorization scope, approver attribution or other fields against those commitments also requires the aaes.records/v1 sidecar and its separate binding check with aaesctl evidence verify. Neither check proves completeness, truth of recorded inputs, absence of omitted or bypassed actions, legal non-repudiation, decision correctness, or that a dispatched call achieved its intended outcome. Reproducing a recorded decision does not reproduce model behavior or an external-world outcome.
For implementation and testing details beyond this note, use Security and implementation posture and the evaluation page. Results from a client's test tenant are produced during a scoped evaluation.
Client responsibility
The organization applies AI RMF. It determines how action-layer evidence fits its risk management activities, approved policies, and control records.
AAES is not an AI RMF implementation or a management system. The client remains the regulated entity.
Choose the tool actions to test, identify who holds their credentials, and list the questions the decision records should answer.