ISO/IEC 23894 Risk Assessment Checklist for AI Agents with Tool Access

How the standard applies to an agent that calls tools

ISO/IEC 23894:2023 provides guidance for organizations that develop, produce, deploy or use AI systems on managing AI-specific risk, and on integrating that risk management into AI-related activities. It describes a process. It does not tell you how to scope an OAuth token or when a tool call needs a human approver. That translation is the work of the assessment team.

For a tool-enabled agent, the risk surface differs from a text-only model. The model decides which tools to invoke, when, and with what parameters. Risk therefore sits in four places: the permissions each tool holds, the parameters the model supplies, the data that flows into those parameters, and the points where a human can intervene. Current OWASP and NIST material documents the main risk sources: excessive agency, over-scoped permissions, prompt injection that leads to unintended tool calls, supply chain attacks, and confused deputy problems in MCP deployments.

The checklists below follow the process stages. Each item pairs a question with the artifact a reviewer would expect to see. Stage-level wording should be confirmed against the standard itself, since this page is a practical mapping rather than a restatement of its clauses.

Assessment-time documents versus runtime evidence

Two kinds of artifact serve different claims. Assessment-time documents (context, criteria, risk register, treatment decisions) show that risks were identified and a response was chosen. Runtime records show what the agent was allowed to do and what happened on each call. A reviewer evaluating a treatment claim will generally want both, and a gap in either weakens the other.

Not every operational log qualifies as durable evidence. When assessing a control on agent tool calls, apply criteria such as these. Does it record decisions per individual call rather than per session? Does it capture the fields listed above, including the policy version and approval identifier? Is the record produced by the enforcement point itself, rather than reported by the agent? Does a human approval link to the specific action it authorized? Can retention and data residency be configured to your obligations? These are practical selection criteria, not an audit standard, so confirm them with your assurance function.

Evidence of enforcement also needs the enforcement to sit in the right place. A control reviewed after the fact can show what happened. A control in the execution path can show what was prevented, redacted or escalated before it happened.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For each individual interaction or tool call, it can allow, redact, block, rate limit or escalate for human approval. These decisions are enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence mapped to frameworks including NIST, HIPAA, NAIC, NYDFS and the EU AI Act. It can be self-managed in the customer cloud, with configurable retention and data residency.

This supports the treatment and monitoring items above: it gives you per-call records that show a treatment operated. It does not replace the assessment itself. Context, risk criteria, evaluation and residual risk acceptance remain the risk team's work. Its scope is individual interactions and tool calls, not end-to-end tracing of agentic workflows. Trussed has run continuously for 18+ months in production at a regulated enterprise and generates 30+ GB of audit evidence per day. When evaluating any control, including this one, test it against the criteria in the previous section.