ISO/IEC 23894 vs OWASP Agentic Top 10: Mapping AI Risk Sources to Agent Tool-Call Threats

What each framework is designed to do

ISO/IEC 23894:2023 is titled "Information technology, Artificial intelligence, Guidance on risk management." It is guidance, not a threat catalogue. ISO also describes it as covering processes for the effective implementation and integration of AI risk management. That makes it a natural fit for the risk register: it gives you a structured way to identify risk sources, assess them and select treatments, and to embed that work in how the organization operates.

The OWASP Top 10 for Agentic Applications 2026 serves a different purpose. OWASP released it on Dec. 10, 2025 as a globally peer-reviewed framework identifying the most critical security risks facing autonomous and agentic AI systems. It was further evaluated by the Agentic Security Initiative Expert Review Board, which includes representatives from NIST, the European Commission and the Alan Turing Institute. It tells you what attacks and failures look like when an agent has tools, permissions and some autonomy.

Neither document replaces the other. A process standard with no threat vocabulary produces abstract register entries. A threat list with no process produces findings that have no owner, no treatment decision and no review cycle. The OWASP list is a security framework, not a regulatory requirement, so treat it as an input to your risk process rather than as a compliance obligation.

Side-by-side comparison

The two artifacts differ in nature, unit of analysis and output. These differences explain why they need to be joined deliberately.

• Nature: ISO/IEC 23894: guidance on AI risk management and its implementation. OWASP Agentic Top 10: a peer-reviewed list of critical agentic security risks.
• Primary question: ISO/IEC 23894: how do we identify, assess and treat AI risk consistently? OWASP: which agent threats are most critical and how do they appear?
• Unit of analysis: ISO/IEC 23894: risk sources, risks and treatments across the organization. OWASP: attack and failure patterns involving tools, identity, memory, reasoning and human oversight.
• Typical output: ISO/IEC 23894: a risk register with treatment decisions. OWASP: a threat checklist that informs design, testing and controls.
• Versioning: ISO/IEC 23894: published as the 2023 edition. OWASP: labelled 2026 and actively maintained, so record the version and retrieval date you use.
• Where they overlap: Both apply to the same agent deployment. The OWASP threats become concrete risk entries, and the standard's treatment concepts decide what to do about them.

Mapping risk sources to tool-call threats

The table below shows a working mapping approach for threats that arise at the tool-call boundary. The first two rows are OWASP Agentic Top 10 items as OWASP defines them. The remaining rows are common tool-call threat patterns; match each to the corresponding OWASP item in the version of the list you record. Risk source labels are working categories for your register, and treatment layers are suggestions to validate against your own risk criteria.

• ASI04 Agentic Supply Chain Vulnerabilities: Risk source: runtime components in dynamic MCP and A2A ecosystems that can be poisoned. Treatment: snapshot approved tool and prompt definitions and require re-approval on change (change control). Runtime: block calls to servers or definitions outside the approved set.
• ASI05 Unexpected Code Execution: Risk source: natural-language paths to code execution, and weak tool input validation and sandboxing. Treatment: input validation and sandboxing (design). Runtime: block or escalate calls that carry code or system actions beyond the permitted scope.
• Excessive agency: Risk source: permissions broader than the task requires. Treatment: least-privilege tool scoping (design). Runtime: allow or block by tool and action, with rate limits on sensitive operations.
• Tool misuse: Risk source: a legitimate tool used in unintended ways. Treatment: defined permitted use per tool. Runtime: evaluate each call and its arguments against that definition; rate limit repeated use.
• Prompt-injection-driven actions: Risk source: untrusted content steering the agent. Treatment: design and testing reduce likelihood. Runtime: enforce policy on the resulting action, and escalate high-impact calls for human approval.
• Data exfiltration through tool arguments: Risk source: sensitive data placed in outbound arguments. Treatment: default restrictions on credential stores and sensitive local files. Runtime: redact or block arguments that contain protected data.

What runtime policy can treat, and what it cannot

A mapping is only useful if each row records where the treatment lives. Some mitigations act on definitions and configuration. Snapshotting MCP tool and prompt definitions at approval time and requiring re-approval when they change is a design-time and change-control measure. It is not a per-call decision, although a runtime check can confirm that a call matches the approved version. Restricting agents from reading credential stores and other sensitive local files by default is a configuration baseline.

Other mitigations act on tool input. Validation and sandboxing address the weakness that lets unintended code or system actions execute. These need to exist as explicit controls, and a per-call policy decision can add a further check on what is sent to the tool. Policy at the tool-call boundary is well suited to deciding whether a specific call, with specific arguments, from a specific agent, should proceed. It is poorly suited to compensating for a tool that was never scoped or sandboxed properly.

Human approval needs separate attention. If escalation is a treatment, the approval and threshold logic becomes an attack surface. OWASP's agent security guidance lists decision and approval manipulation as a key risk, where attackers influence risk scores, model confidence or approval thresholds to bypass safeguards. Keep threshold values and risk-score inputs outside the agent's influence, and treat changes to them as controlled events.

Organizational and testing controls remain necessary. Prompt injection in particular is reduced by design and testing work, and runtime enforcement limits the consequences rather than eliminating the cause.

Evidence at the level of the individual tool call

A risk register entry says a treatment exists. An auditor will want to see that it operated. For tool-call treatments, that means a record per interaction showing what the agent was permitted to do and what it did. Define the evidence requirements internally and validate them with your auditors rather than assuming a fixed expectation.

A practical record includes the agent identity and the tool or MCP server addressed, the arguments after any redaction, the policy version applied, the decision taken (allow, redact, block, rate limit or escalate), and the outcome. For escalations, include who approved and when. For change-controlled items, keep the approved snapshot of each MCP tool and prompt definition and the record of re-approval.

This evidence should be generated by the enforcement itself, not reconstructed from application output afterward. Evidence that is a by-product of the decision is consistent by construction. Evidence assembled later depends on what each system happened to keep.

Enforcing mapped treatments in the execution path

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence continuously. That evidence is mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

In the mapping above, this covers the rows whose treatment is a per-call decision. It does not replace design-time scoping, sandboxing, testing or the organizational processes that surround the risk register.