ISO/IEC 23894 Risk Sources for Generative AI and AI Agents

What ISO/IEC 23894 covers, and what it does not

ISO/IEC 23894:2023 provides guidance on how organizations that develop, produce, deploy or use AI products, systems and services can manage risk specifically related to AI. It also describes processes for integrating AI risk management into AI-related activities and functions. It is voluntary guidance, not a law.

The standard is general. It was not written around tool-using agents, and a separate document, ISO/IEC DTS 25568 on addressing risks in generative AI systems, is still under development as of November 2026. It should not be cited as an adopted standard. A community-submitted crosswalk between 23894 and the NIST AI RMF, hosted by NIST, can help align terminology across frameworks, but it is neither an ISO nor a NIST publication.

That leaves a practical gap. A risk register that says "AI model risk" without naming a risk source gives an auditor nothing to test. The mapping below is the author's analysis, not text from the standard. It uses the source categories most teams start with: data quality, model behavior, transparency, automation level and system complexity. Confirm the wording against your copy of the standard before putting it in a register.

Mapping risk sources to generative AI and agent behavior

The NIST Generative AI Profile notes that generative AI risks vary by lifecycle stage, by scope (model, system, application) and by source of risk (design, training or operation). The same variation applies here. Each source can show up at the level of a single interaction, in the lifecycle, or both. The table separates the two.

• Data quality: Per interaction: sensitive or untrusted content in prompts, retrieved documents and outputs. Lifecycle: training data quality and poisoning, which runtime enforcement cannot fix.
• Model behavior: Per interaction: unreliable or unsafe outputs, generated code, and unintended tool actions. Lifecycle: model evaluation and change management.
• Lack of transparency: Per interaction: the reader cannot tell what was requested, allowed or changed. Runtime records answer this. They do not explain model internals.
• Automation level: Per tool call: how much an agent can do without a person. Treated through per-tool scoping and human approval for high-risk actions.
• System complexity: Per tool call: many tools, MCP servers and external content sources. Unknown tools can fail closed. Supply chain compromise and workflow-wide behavior need other treatment.

Runtime treatments and the evidence each should produce

Current agent guidance from OWASP names prompt injection (direct and indirect), tool abuse and privilege escalation, and decision and approval manipulation as key risks. It recommends per-tool permission scoping, failing closed on unknown tools, human approval for high-risk actions, and structured decision metadata for those actions. For MCP-style integrations it advises enforcing authorization scope for sensitive tool calls at execution time.

The guidance names scoping, fail-closed handling, approval and execution-time checks. Framing them as allow, redact, block, rate limit and escalate is the author's analysis. The evidence listed for each treatment is a design recommendation to confirm with your auditor. The only evidence type the guidance explicitly supports is structured decision metadata for high-risk actions.

• Allow: Permit a call that matches an explicit per-tool scope (read-only or write, specific resources). Evidence: the policy rule matched, the tool, the scope and the decision.
• Redact: Remove sensitive content from a prompt or output before it moves on. Evidence: the content category, the action taken and the policy version.
• Block: Stop an out-of-scope call, an unknown tool or content that violates policy. Evidence: the request context, the rule that fired and the reason.
• Rate limit: Cap call volume, which also limits denial of service from adversarial prompts. Evidence: the threshold, the counter state and the action taken.
• Escalate for human approval: Hold a high-risk action until a person decides. Evidence: the approver, the time, the decision and the structured metadata of the action.

Risks that runtime enforcement does not treat

Enforcement on individual interactions and tool calls cannot reach risks that arise before or around the execution path. Training data poisoning and intentionally placed model backdoors arise at the training stage. Supply chain compromise of third-party tools, APIs and data sources needs supplier and release controls. Model lineage, dataset provenance and end-to-end tracing of agentic workflows are separate capabilities, and per-call enforcement does not provide them.

OWASP describes one lifecycle control that complements runtime enforcement: block releases when high-risk tool policies, approval logic or credential scopes change without updated tests. NIST SP 800-218A also recommends including model-specific threat types in risk modeling, such as poisoning, malicious content in inputs and outputs, adversarial-prompt denial of service and supply chain attacks.

The tradeoff is that a runtime control is only as good as the policy behind it. A well-scoped policy limits what a compromised or misaligned model can do. It does not make the model reliable, and output review for validity and safety remains a distinct control point, as NIST's action on reviewing generated outputs and code indicates.

Making the register auditable

Each register entry should name a risk source, the control that treats it, and whether that treatment is runtime, lifecycle or organizational. An entry for indirect prompt injection through emails or documents might cite system complexity, name the content-handling and tool-scope policies enforced at runtime, and record the owner and the evidence those policies produce. An entry for training data poisoning should name the lifecycle control and its owner instead.

Document accepted residual risk and the compensating control for each entry, as OWASP recommends. Marking which entries rely on runtime treatment is the author's suggestion. It lets an auditor sample decisions from the evidence for the runtime entries and review other artifacts for the rest.

A short review list helps. For each agent tool, what is the permission scope, and what happens when the tool is unknown or the scope changes? Which actions require approval, and what metadata is recorded? Which risks sit outside runtime enforcement, and who owns them?

Enforcing policy in the execution path with Trussed

Trussed is one way to implement the runtime treatments described above. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not provide model provenance, model lineage, dataset provenance or end-to-end tracing of agentic workflows. Those risks need other treatment, as described above. Trussed makes no claim of certification against ISO/IEC 23894. It supplies runtime enforcement and evidence that can support the register entries you assign to that treatment.