Mapping ISO/IEC 23894 Risk Sources to Runtime Controls and an Audit-Ready Evidence Trail

Runtime enforcement is one treatment layer

ISO/IEC 23894:2023, titled Guidance on risk management for artificial intelligence, describes processes for implementing and integrating AI risk management. It is the framework for identifying, assessing and treating risk. Runtime enforcement is one way to carry out a treatment. It is not a substitute for the framework or for the other treatments in your plan.

Most regulated enterprises already hold a risk register and a set of policies. The gap is usually between the two: a register entry says a risk will be mitigated, but nothing shows that the mitigation operates on live model calls, agent actions and tool calls. An auditor then cannot trace from the identified risk to a control decision and the evidence it produced.

The method below closes that gap in three moves. First, decide which risk sources can be treated in the execution path. Second, map each of those to a control, an action and an evidence record. Third, record explicitly where runtime controls stop. The categories and record fields in this guide are a working method, not text from the standard, so adapt them to the taxonomy in your licensed copy of ISO/IEC 23894.

Step 1: Decide which risk sources are runtime-treatable

Runtime enforcement acts on individual interactions and tool calls. The test for each register entry is simple: can a policy decision made at the moment of an interaction reduce this risk? Record the answer and the reason, so the decision itself is auditable.

A practical way to apply the test is to sort entries into working categories. Where an entry spans two categories, split it so each part has one owner and one treatment.

• Access and authorization: Tools, agents or MCP servers acting without verified identity or sufficient permission. Runtime-treatable.
• Data exposure: Sensitive data entering prompts, tool arguments or outputs. Runtime-treatable by inspecting and acting on content in transit.
• Resource abuse: Excessive calls, runaway agent loops or denial of service. Runtime-treatable through rate limits, quotas and timeouts.
• High-impact actions: Agent actions whose consequences warrant a person's decision. Runtime-treatable through escalation for human approval.
• Lineage and provenance: Model lineage and dataset provenance. Outside the execution path.
• Pre-deployment quality: Issues found through testing and validation before release. Outside the execution path.

Step 2: Map each runtime-treatable source to a control, action and artifact

For every runtime-treatable entry, fill in five fields: risk source, control objective, enforcement point, action and evidence artifact. The enforcement point is the specific place a policy is evaluated, such as a model call, an agent step, a tool invocation or an MCP server interaction.

OWASP guidance on MCP security supports this style of control. It suggests choosing controls according to risk, including explicit user confirmation, narrowly scoped authorization and policy checks enforced at execution time. It also suggests per-session or per-tenant rate limits, quotas and timeouts. OWASP lists insufficient authentication and authorization as an MCP risk and notes it is amplified in agentic and model-chaining scenarios. These options correspond to the actions most teams need: allow, redact, block, rate limit and escalate.

The examples below show the shape of a completed mapping. They are illustrative, not prescriptive.

• Unauthorized tool invocation: Objective: only permitted identities call permitted tools. Enforcement point: tool call. Action: block, or allow when authorized. Evidence: decision record with identity and policy version.
• Sensitive data in a prompt: Objective: restricted data does not reach the model. Enforcement point: model call. Action: redact or block. Evidence: record of the rule matched and the action taken.
• Call volume abuse: Objective: bound consumption per session or tenant. Enforcement point: model and tool calls. Action: rate limit. Evidence: record of the threshold and the throttled request.
• Consequential agent action: Objective: a person decides before execution. Enforcement point: agent action. Action: escalate for human approval. Evidence: request, approver and outcome.

Step 3: Define what the evidence record must contain

An evidence trail is audit-ready when an auditor can start from a register entry and arrive at specific enforcement decisions, or start from a decision and arrive at the register entry that justified the policy. No source mandates a schema, so the fields below are recommended. They are the minimum needed to support that two-way trace.

The linkage matters more than the field count. Each record should reference the risk register ID and the treatment plan item, because without that reference a decision is just an event. Allowed interactions need records too, not only blocked ones. A control that only records its refusals cannot show it was evaluated on everything else.

The evidence store is itself a controlled asset. OWASP RAG guidance advises restricting access to logs and setting retention limits, so decide who can read the evidence and for how long before volumes grow. Do not assume a retention period; set it from the obligations that apply to your organization.

• Risk register ID and treatment plan item: The link from decision to identified risk.
• Policy identifier and version: Which rule was in force when the decision was made.
• Decision and action taken: Allow, redact, block, rate limit or escalate, with the rule that triggered it.
• Timestamp: When the decision was made.
• Actor or system identity: The user, agent, tool or MCP server involved.
• Retention and access: The retention period and who is permitted to read the record.

Where runtime controls stop

Runtime enforcement cannot treat a risk that exists before an interaction begins. Model lineage, dataset provenance and pre-deployment testing results are properties of how a system was built and validated. For these entries, record the runtime scope decision as "not treatable at runtime" and link the entry to the lifecycle control that covers it. In a RAG pipeline, stages such as ingestion and embedding happen before any individual interaction, so make the scope decision per stage.

Runtime controls also work alongside containment, not in place of it. OWASP pairs rate limits and quotas with sandboxing, which is a useful reminder that a policy decision and an isolation boundary address different failure modes.

Third-party components need register entries of their own. NIST AI RMF MAP 4.2 expects internal risk controls for system components, including third-party AI technologies, to be identified and documented, and MANAGE 3.1 expects third-party risks to be monitored with controls applied and documented. Tools and MCP servers are third-party dependencies in this sense. MEASURE 1.2 calls for regular assessment of control effectiveness, and runtime decision records are a natural input to that review. As of November 2026, AI RMF 1.0 is being updated, so treat subcategory references as subject to change. A community-submitted crosswalk between ISO/IEC 23894 and the AI RMF exists as a starting aid, but verify it against both documents.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions including allow, redact, block, rate limit and escalate for human approval. Enforcement generates continuous audit-ready evidence, and deployment is self-managed in the customer cloud with configurable retention and data residency. Its scope is individual interactions and tool calls, so it does not address model lineage or dataset provenance.