A narrow note on action-layer evidence that AAES may contribute to an organization's own AI management system. This is not a mapping of the whole standard.
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 standard's content. The organization's approved policies and control records define its control position.
Instrument identity
- Title
- ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
- Publication
- Edition 1, December 2023
- Issuing body
- Published jointly by ISO and IEC; developed by ISO/IEC JTC 1, Subcommittee SC 42 (Artificial intelligence)
- Instrument type
- A management-system standard (MSS) with requirements and guidance; organizations can be certified against it by an accredited body
- Official source
- ISO/IEC 42001:2023 on iso.org
The standard specifies requirements for an AI management system (AIMS) and provides guidance for deploying applicable controls. It follows the harmonized structure shared with other management-system standards, so it sits beside an existing ISO/IEC 27001 ISMS rather than replacing one.
Question
Where an AIMS requires documented information and control over AI system operation, which action-layer records can a reviewer inspect?
The inspection can focus on accountable human managers, named approvers, permitted capabilities, approval rules, routed spending limits, and the sealed records AAES produces for each governed 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
An AIMS requires the organization to keep documented information about how AI systems are operated and controlled. The following AAES controls and records may be usable as operational documented information within the client's own AIMS. Their scope is the action layer, not the standard as a whole.
| Control or record | What a reviewer can examine | Boundary |
|---|---|---|
| Accountability assignment | Every registered agent has at least one accountable human manager. Approvers are named. An agent cannot approve itself. Actions classified as irreversible require approval by an authorized person; policies can require approval for other actions. | Recorded assignment does not establish that the underlying decision was correct. |
| Operational authorization rules | Agents only see permitted capabilities. Grants are task-scoped and have a time to live. Policies and their versions are inspectable. | Enforcement depends on control of the agent's credential path. |
| Resource limits | 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, and committed amounts are authorization charged against configured ceilings, not a guarantee of final vendor charges. |
| Operational records | AAES produces one sealed, hash-chained record per action. Exports can be checked offline against a key AAES does not hold, so records can be tendered as documented information with integrity properties. | Integrity does not prove a complete action history or a successful external outcome. |
| Fail-closed behavior | 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. |
Preconditions and gaps
- AAES is not a certified product. No ISO/IEC 42001 certificate exists for AAES, and product records are one input to an AIMS, not an AIMS themselves. Organizations may seek accredited certification of their own scoped AIMS; that does not certify AAES as a product.
- 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.
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 owns the AIMS. It defines scope, policy, risk assessment and control selection, and it determines how action-layer evidence fits its documented information.
AAES is not an AIMS implementation. 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/iso-iec-42001.html
Controls: https://aaes.ai/library/controls.html
NIST AI RMF: https://aaes.ai/library/frameworks/nist-ai-rmf.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