ISO/IEC 42001 and event logging for AI agents (A.6.2.8)

ISO/IEC 42001 is the management-system standard for AI. Annex A control A.6.2.8 is its event-logging control: AI systems must record events so that what the system did can be traced and held accountable after the fact. This page covers what the control asks for and how verifiable execution receipts satisfy its intent.

This is an engineering explainer, not a certification determination. For a conformity assessment, work with an accredited ISO/IEC 42001 auditor. Control references are to ISO/IEC 42001:2023 Annex A.

What A.6.2.8 asks for

The control’s core requirement is short: the organization shall determine when event log record-keeping should be enabled for its AI systems. The purpose is traceability, transparency, and accountability across the AI lifecycle — from training through deployment and production inference. In practice, auditors expect logs that capture the events that matter: system access, configuration and model changes, deployment activity, critical inference events, errors, and — balanced against privacy — the inputs and outputs of consequential actions.

For an AI agent that calls tools, moves money, or reads records on a user’s behalf, the accountability question A.6.2.8 is really asking is: for any given action, who or what initiated it, under what authority, and can that account be trusted by someone outside the operator?

Where ordinary logging falls short

Most agent stacks already write event logs, so it is tempting to treat A.6.2.8 as already handled. The gap is not whether events are recorded but whether the record can be trusted after the fact. A log that lives in the operator’s own database is editable and deletable by the operator. An auditor reviewing it has to trust the very party whose system they are assessing, and a record that can be silently rewritten is weak audit evidence. The control’s stated goals — traceability and accountability — are exactly the properties an editable log cannot guarantee.

How verifiable receipts map to the control

A signed execution receipt turns “we have logs” into “here is a record you can verify without trusting us.” The bilateral receipt pattern — normative guidance in the OWASP Agentic Skills Top 10 (AST09) — emits two signed records per action:

• Admission receipt: the agent, the intended action, the authorized scope, and the policy version in effect at that moment — the “who initiated it, under what authority” A.6.2.8 is after.
• Outcome receipt: what actually happened, linked to the admission by a content-derived hash (action_ref).

Both are canonicalized with JCS (RFC 8785), signed with Ed25519, and hash-chained. That gives the three properties the control’s traceability and accountability goals imply:

• Automatic: receipts are emitted around each action by the runtime, not written by hand — the “record keeping enabled” the control asks you to decide on becomes a property of the system, not a manual habit.
• Tamper-evident: editing a record invalidates its signature; deleting one leaves a gap in the chain. The log retains integrity across the lifecycle rather than being silently rewritable.
• Independently verifiable: an internal auditor or an external assessor checks a receipt offline with just the receipt and a public key — the accountability does not depend on trusting the operator.

What this looks like in code

Instrumenting an agent action to emit A.6.2.8-friendly records is one decorator:

from nobulex import track

@track(agent_id="billing-bot")
def charge(invoice_id: str, amount_cents: int):
    ...  # your existing code, unchanged

Verification is offline — no callback to the operator, the platform, or Nobulex:

from nobulex.agent import Agent

agent = Agent("billing-bot")
receipt = agent.act("charge", scope="invoice:042")
assert receipt.verify()  # recomputes action_ref, checks the signature, offline

How A.6.2.8 fits the wider standard

A.6.2.8 does not sit alone. The event records it calls for feed the monitoring and review obligations in Clause 9 (performance evaluation) and support the documentation controls elsewhere in Annex A. The same receipts also map cleanly onto the EU AI Act, Article 12 (automatic logs for post-hoc traceability) and the NIST AI RMF (Measure 2.4 monitoring and Manage 4.x incident tracking) — so one implementation serves a certifiable management system, an EU regulation, and a US risk framework at once. ISO/IEC 42001 does not mandate cryptography; it requires records that are reliable enough to demonstrate accountability, and signed receipts are the strongest form of that evidence.

Getting started

pip install nobulex
# or
npm install @nobulex/core

Nobulex is the open-source (MIT) reference implementation of the bilateral receipt pattern. For the AST09 background, see OWASP AST09 execution receipts; for a step-by-step build, the verifiable audit trail guide; for where this sits in the market, the accountability landscape.

Get started Star