A narrow note on action-layer evidence that AAES may contribute to an organization's own AI risk management activities. This is not a mapping of 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 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
- 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 denies an action. A scoped evaluation can then produce records from the client's test tenant for review.
AAES governs tool use and actions routed through it. It is not a model gateway: prompts and model completions are not on the brokered path.
Selected contribution
The following controls and records may be usable as operational evidence within the client's own AI RMF activities. Their 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 human manager. Approvers are named in AAES. 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 | Agents only see permitted capabilities. Grants are task-scoped and have a time to live. | Enforcement depends on control of the agent's credential path. |
| Budgets | Budgets can be committed at decision time for spending routed through AAES. Over the ceiling, the call never leaves and the refusal is recorded. | This does not cap vendor spending outside AAES. |
| Fail-closed denial | If the decision journal cannot be written, AAES issues no new grant and no credential is minted. Confirm the denial via the daemon response; there will not be a journal row for that denial. | Outstanding grants remain valid for up to 15 minutes. |
| Sealed records | AAES produces one sealed, hash-chained record per action. Exports can be checked offline against a key AAES does not hold. | Integrity does not prove a complete action history or a successful external outcome. |
Preconditions and gaps
- Credential-path control is required. Work that bypasses AAES is invisible. 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 is claimed. AAES is client-operated only. There is no AAES-hosted cell today. Internal checks do not establish production validation or independent certification.
A valid record establishes integrity of recorded authorization, scope, named approver, and sealed bytes. It does not prove 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.
Identify the credential path, actions, and evidence questions to examine in a client test tenant.
Related pages:
This note: https://aaes.ai/library/frameworks/nist-ai-rmf.html
Controls: https://aaes.ai/library/controls.html
AIUC-1: https://aaes.ai/library/frameworks/aiuc-1.html
Evaluation: https://aaes.ai/library/evaluation.html
Security: https://aaes.ai/legal/security.html
Scoped appendix: https://aaes.ai/contact.html?ref=library-appendix
Scope an evaluation: https://aaes.ai/contact.html?ref=library-evaluation