ISO/IEC 42001 specifies an AI management system: the organization's policies, responsibilities, risk assessment, and controls for AI. AAES Govern records decisions about registered tool actions, such as who was authorized to act. These records may support the organization's own review; this page does not map 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 Govern 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 Govern produces for each governed 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
An AIMS requires the organization to keep documented information about how AI systems are operated and controlled. The following AAES Govern 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 manager, ultimately answerable to a person. 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 | 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. Policies and their versions are inspectable. | Enforcement depends on control of the agent's credential path. |
| Resource limits | 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 Govern, and committed amounts are authorization charged against configured ceilings, not a guarantee of final vendor charges. |
| Operational records | AAES Govern produces one sealed, hash-chained record per action. In a client-operated deployment, the signing key is created and held inside the client's deployment, and AAES, the company, holds no copy of the private signing key. For an AAES-hosted deployment, the client agreement defines key custody and access. Reviewers obtain the public key from the deployment operator through a separate, trusted channel and check exports offline. The public Apache-2.0 aaesverify v0.3.0 source and release binaries verify the aaes.export/v3 exports that current AAES Govern deployments write, and retained aaes.export/v2 exports such as the public sample. The earlier v0.2.0 release reads v2 only. No external timestamp authority or independent witness is wired by default, so the integrity check alone does not establish independence from the record producer. | Integrity does not prove a complete action history or a successful external outcome. |
| Fail-closed behavior | 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. |
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. 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.
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.
Choose the tool actions to test, identify who holds their credentials, and list the questions the decision records should answer.