Applying ISO/IEC 23894 Risk Treatment to LLMs and AI Agents

Where risk treatment fits

ISO/IEC 23894:2023, titled Guidance on risk management for artificial intelligence, is guidance for organizations that develop, produce, deploy or use AI-based products, systems and services. It is guidance, not a certifiable requirements standard, so a treatment plan built on it demonstrates a managed process rather than a certification outcome. This page makes no compliance claim.

Risk treatment is the step where analysis becomes action. The working vocabulary is avoid, mitigate, share and accept. The NIST AI RMF uses a close parallel (mitigate, transfer, avoid, accept) and adds useful practice. Treatment is prioritized by impact, likelihood and available resources, responses to high-priority risks are planned and documented, and residual risk is documented for downstream acquirers and end users.

The common failure is that these decisions live in a register while the system behaves the same regardless. For LLMs and tool-calling agents, a decision such as "mitigate excessive tool permissions" only matters if something applies it when an agent calls a tool. The rest of this guide closes that gap.

Build the treatment plan

Start with the risks that are specific to LLMs and agents and are already prioritized: sensitive data exposure, prompt injection, excessive tool permissions and unreviewed high-impact actions. For each one, complete the same record. Keep it short enough that engineers will read it.

• 1. Treatment decision: Avoid, mitigate, share or accept, with the rationale and the prioritization basis (impact, likelihood, resources).
• 2. Named owner: One accountable person for the decision and for reviewing it.
• 3. Control and control type: The specific control, classified as runtime enforceable, design-time or organizational.
• 4. Policy reference: For runtime controls, the policy and version that implements the decision.
• 5. Evidence definition: What record proves the control operated, and how long it is kept.
• 6. Residual risk statement: What remains after treatment, measured against documented risk tolerance, with a review date.

Mapping LLM and agent risks to treatment and enforcement

The mapping below is a practical interpretation, not text from the standard. The same risk often needs more than one treatment, and the runtime column describes only what can be decided on a single interaction or tool call.

• Sensitive data exposure: Mitigate; avoid for data classes that must never reach a given model. Runtime: redact or block on interactions, based on data class and destination. Outside runtime: data classification and approved-model decisions.
• Prompt injection: Mitigate, then accept residual risk explicitly. Runtime: restrict what a manipulated agent can do by evaluating each tool call. Outside runtime: testing, and design that limits the impact of injected instructions.
• Excessive tool permissions: Mitigate through least privilege. Runtime: allow or block each tool call against per-tool scope, such as read-only versus write. Outside runtime: minimal tool sets and credential scoping at design time.
• Unreviewed high-impact actions: Mitigate with approval; avoid for actions that must never be autonomous. Runtime: escalate for human approval or block. Outside runtime: defining which actions are high impact.

What runtime enforcement can and cannot treat

Runtime controls act on one interaction or one tool call at a time. Typical outcomes are allow, redact, block, rate limit, or escalate for human approval. This fits mitigation and avoidance well, because a policy can state that a category of action or data is never permitted, or permitted only with approval. For agents, OWASP guidance supports the underlying controls: minimal tools, per-tool permission scoping, autonomy boundaries based on action risk, and human approval for high-risk actions. Evaluating these at the point of each tool call is a straightforward way to enforce them. A prerequisite is an explicit, reviewed mapping of tools to risk tiers, because the policy can only apply a tier that someone has assigned.

Fail-closed behavior belongs in the treatment decision. If policy lookup, approval validation or audit recording fails, the action should not proceed. Otherwise a control failure silently becomes risk acceptance.

Prompt injection shows the limits. Instructions and data share one channel in common LLM designs, so the problem cannot be fully separated by design. Detection can miss attacks and can block benign actions. Treat it as mitigation with documented residual risk, not as a solved problem.

Several treatments sit outside the execution path. Setting and recalibrating risk tolerance, testing and evaluation before deployment, resourcing decisions, risk transfer through contracts or insurance, and communicating residual risk to downstream users are organizational or design-time. Releases that change high-risk tool policies, approval logic or credential scopes should be gated on updated tests, which is a pipeline control. Each of these needs its own evidence.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. It covers the runtime column of the table above, not the organizational one.

Evidence that supports residual risk acceptance

A residual risk decision is only as defensible as the proof that the treatment operated. For tool calls, a workable record for high-risk actions follows OWASP agent guidance: action classification, risk score where applicable, authorization outcome, approval identifier, execution result and policy version. The policy version is what ties a runtime event back to a specific treatment decision, so a reviewer can follow the chain from register entry to policy to individual events.

For accepted risks, add measures that show whether the residual level stays within tolerance. For prompt injection, that means the rate of blocked benign actions and any missed attacks found through testing or incidents. For escalations, it means approval volumes and outcomes. Review these against documented tolerance on a schedule, and re-test when tool policies, approval logic or credentials change.

Evidence also needs to be durable. Decide retention and data residency up front, and keep the records outside the application that produced them. Trussed generates audit-ready evidence from enforcement itself, mapped to frameworks including NIST and the EU AI Act, and can be self-managed in the customer cloud with configurable retention and data residency. Evidence from runtime enforcement does not replace the testing, tolerance and ownership records described above. It complements them.