ISO/IEC 42001 for AI Agents: Mapping the Standard to Runtime Enforcement

ISO/IEC 42001 tells you how to manage AI. It does not tell you what happens when an agent takes an unauthorised action in production. This is the bridge between the standard and the runtime.

An AI agent does not read your AI policy. At 02:00, when it calls an external API, deletes a record or moves money, it acts on whatever controls are actually enforced at that moment. Applying ISO 42001 to AI agents means closing the distance between a documented management system and enforced runtime behaviour. That distance is where most AI agent risk now sits.

ISO/IEC 42001:2023 is the international standard for AI management systems, published by ISO and IEC in December 2023 and described by ISO as the first of its kind. It sets requirements for establishing, implementing, maintaining and continually improving an AI management system, and it applies to any organisation that provides or uses products or services that utilise AI systems. What it does not ship is a runtime enforcement engine.

This article maps the clauses that bear on agent behaviour to the controls you have to operate to meet them. Where a control is named, it points to OpenBox (docs.openbox.ai), positioned as designed to support the relevant clause, not to certify it.

What ISO/IEC 42001 actually covers at the runtime level

ISO/IEC 42001 covers runtime indirectly. It requires operational control, monitoring and corrective action for AI systems, but specifies management outcomes rather than enforcement mechanisms. Cast into agent terms, that means behaviour has to be controlled and evidenced. That framing is this article’s synthesis, not ISO wording. It leaves the how to the organisation implementing it.

The standard uses the harmonised structure common to ISO management-system standards, running from Clause 4 (context) to Clause 10 (improvement). Its Introduction singles out AI that learns continuously and “changes its behaviour during use” as needing special consideration. For an autonomous agent, that behaviour is not fixed at design time. It emerges at execution.

Clause 8 (Operation) requires an organisation to plan, implement and control the processes needed to meet its AI requirements and to carry out risk treatment. Clause 9 (Performance evaluation) requires monitoring, measurement, analysis and evaluation. Both describe required outcomes rather than the runtime mechanisms that achieve them. How you enforce those outcomes in production is your design choice.

Certification does not change that. ISO does not certify organisations; independent certification bodies do, and certification is voluntary. A certificate attests that your management system meets the requirements, not that every agent action was correct. The runtime controls still have to exist and produce evidence.

The ISO/IEC 42001 clauses that most directly govern AI agent behaviour

Three clause areas bear most directly on what an AI agent does at runtime: Clause 6 (Planning), Clause 8 (Operation) and Clause 9 (Performance evaluation). Clause 6 sets risk assessment and treatment. Clause 8 turns those into operational control over live processes. Clause 9 requires you to monitor, measure and evaluate the result.

Clause 6 covers planning. Its sub-clauses include AI risk assessment (6.1.2), AI risk treatment (6.1.3) and AI system impact assessment (6.1.4). For an agent, this is the work done before it acts: establishing its inherent risk, deciding which controls apply, and assessing the impact its actions could have on individuals, groups and wider society.

Clause 8 covers operation. It mirrors Clause 6 at execution time, with operational planning and control (8.1), AI risk assessment (8.2), AI risk treatment (8.3) and AI system impact assessment (8.4). In practice, this is where an organisation turns a documented plan into operational control over live processes, including what an agent does in production.

Clause 9 covers performance evaluation, starting with monitoring, measurement, analysis and evaluation (9.1) and extending to internal audit (9.2) and management review (9.3). Translated to agents, that means watching behaviour in production, measuring whether controls work, and generating evidence an auditor can examine.

ISO/IEC 42001 clauses mapped to agent runtime: a reference table

The table below maps each governing clause to how it applies to an AI agent at runtime and to the OpenBox (docs.openbox.ai) capability designed to support it. Read it as an alignment aid, not a certification claim. ISO 42001 certification is issued only by independent bodies, never by a vendor.

One detail matters for auditors: governance decisions are enforced in precedence order, HALT over BLOCK over REQUIRE_APPROVAL over ALLOW. A single critical rule can therefore stop a session regardless of what other policies would allow.

The evidence behind those decisions is built from SHA-256 event hashes combined into a Merkle tree, then signed with an ECDSA NIST P-256 key through AWS KMS by default. Each session produces one Proof Certificate, which makes the record tamper-evident for later inspection.

How Trust Score and the Trust Lifecycle address ISO/IEC 42001 Clause 8

Clause 8 (Operation) requires an organisation to plan, implement and control the processes that meet its AI requirements and to carry out risk treatment. OpenBox’s Trust Lifecycle and Trust Score are designed to operationalise that control for agents: risk is scored, controls are applied by tier, and every operation receives a governance decision at execution.

The Trust Score is a 0 to 100 measure. It is calculated as (Risk Profile Score × 40%) + (Behavioral × 35%) + (Alignment × 25%), aggregating inherent risk, runtime policy compliance and goal alignment into one number that drives how strictly the agent is controlled.

The score maps to five Trust Tiers. Tier 1 (Trusted, 90 to 100) is the most autonomous, with minimal constraints. Tiers 3 and 4 attract enhanced monitoring, stricter policies and human-in-the-loop review, and an Untrusted band (0 to 24) suspends the agent. Lower trust means tighter operational control, aligning with the proportionate control Clause 8 expects.

At execution, each operation returns one of four governance decisions: ALLOW, REQUIRE_APPROVAL, BLOCK or HALT. REQUIRE_APPROVAL pauses the operation and routes it to a human approval queue, providing a human-oversight mechanism for actions an organisation determines require review. The standard sets the outcome; this is one way to enforce it at runtime.

Alignment is measured continuously. OpenBox scores how closely an agent’s actions match its stated goal and logs a drift event when the score falls below the configured threshold, 70 percent by default. That running record of goal alignment is operational evidence that behaviour stayed within intent, which is the kind of measurement Clause 9.1 expects and Clause 8 control relies on.

Tiers move as behaviour changes. A score crossing a boundary triggers an immediate tier change, and promotion into Tier 1 additionally requires admin approval. Keeping control current as an agent’s behaviour evolves is consistent with Clause 8’s expectation to plan and control changes, not to set controls once and leave them.

Building an AI incident register for ISO/IEC 42001 Clause 10.2

ISO/IEC 42001 does not mandate a document called an “AI incident register,” and it does not define “AI incident.” It requires, under Clause 10.2 (Nonconformity and corrective action), that you react to nonconformities, correct them, address their root causes through corrective action, and retain documented information. An incident register is a practical way to meet that requirement for agents.

Clause 10.2 sits under Improvement, alongside Clause 10.1 (Continual improvement). The register feeds both: it records nonconformities so they can be corrected, and it supplies the pattern data that drives improvement. A defensible entry captures what the agent did, when, the governance decision and its reason, the correction, the root cause, the corrective action, and evidence the fix worked.

OpenBox (docs.openbox.ai) supplies the evidence substrate rather than the register itself. Its organisation audit log records every governance event with a timestamp, the agent, the verdict, the reason and the workflow or run identifier, and exports to CSV or Excel. Session Replay reconstructs the operation timeline for investigation.

For an auditor, provenance matters as much as content. Each session is cryptographically signed into a Proof Certificate, so the incident record is tamper-evident and can be shown to have gone unaltered after the fact. OpenBox’s own guidance recommends exporting audit logs regularly and documenting the rationale for any policy change, which maps onto Clause 10 and the evidence expectations of Clause 9.

Frequently asked questions

Does ISO/IEC 42001 apply to companies using AI agents built on third-party models like GPT-4 or Claude?

Yes. ISO/IEC 42001 applies to any organisation that provides or uses products or services utilising AI systems, regardless of who trained the underlying model. If you deploy an agent built on a third-party model, your organisation falls within scope as an organisation using an AI system. The standard’s requirements then apply to your management system.

What is the difference between ISO 42001 and the EU AI Act, and do I need to comply with both?

ISO/IEC 42001 is a voluntary, certifiable management-system standard. The EU AI Act (Regulation (EU) 2024/1689) is binding law, generally applicable from 2 August 2026 with obligations phased in. ISO does not replace regulation; it supports compliance. If your system is in scope of the EU AI Act, you must comply with it whether or not you hold ISO 42001 certification.

How does ISO 42001 define an AI incident, and what does a compliant incident register look like?

ISO/IEC 42001 does not define “AI incident” or mandate an incident register by name. It requires, under Clause 10.2, that you react to nonconformities, correct them, address root causes and retain documented information. A defensible register captures each event, the agent, the decision, the cause, the corrective action, and evidence it worked.

Can a company be ISO 42001 certified without addressing AI agent runtime behaviour?

It depends on scope. Certification assesses the AI management system within the boundaries the organisation defines under Clause 4.3. If agents operate inside that scope, their runtime risks fall under Clauses 6, 8 and 9, which require that behaviour be controlled and evidenced. The certificate covers the system, not each individual agent action.

The takeaway

ISO 42001 for AI agents comes down to one translation: management-system requirements become controls that act at runtime. The standard defines the outcome. Your platform enforces it. For the wider programme context, OpenBox’s guide to AI agent governance for enterprise teams sets out how these controls fit together.

Mapped to the clauses, OpenBox is designed to support the operational and evidentiary requirements: Trust Score and governance decisions for Clause 8, monitoring for Clause 9, and attestation with audit export for Clause 10. Certification remains the work of an independent body. The runtime, and the evidence it produces, is yours to build.