It supplies a method, not a mandate. ISO/IEC 23894:2023 is guidance on managing AI risk: how to set context, identify risks, analyse and evaluate them, treat them, and keep watching. It applies to any organisation using AI, agents included, but it is not certifiable and sets no limits itself. You use it to decide which controls an agent needs.
What does ISO/IEC 23894 actually provide?
ISO/IEC 23894 adapts general risk management practice to AI. Its process, in substance:
- Scope, context and criteria: what you are assessing, who is affected, and how much risk you will accept.
- Risk assessment: identify risks, analyse their likelihood and consequences, and evaluate them against your criteria.
- Risk treatment: choose options to reduce, avoid, share or accept each risk, and implement controls.
- Monitoring and review: check that risks and controls stay as assessed.
- Recording, reporting, communication and consultation throughout.
It also describes sources of risk specific to AI, such as the system's level of automation, the quality of data, lack of transparency, and changes in the environment it operates in. A fuller treatment is in ISO/IEC 23894 AI risk management for AI agents.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What changes when the AI is an agent?
Risk sources that are minor for a scoring model become central for an agent.
Automation becomes action. An agent not only produces an output; it calls tools that change records or move money. Consequence analysis must ask what happens if the action is wrong and whether it can be undone.
The environment talks back. An agent reads emails, documents and web pages. Some of those may contain instructions designed to steer it. A risk assessment that treats inputs as data, not as possible commands, misses this.
Context shifts quietly. A model provider's update, a new source or a wider limit changes the agent's risk profile without a new project. 23894's monitoring step needs triggers for these.
Concretely, assess risk per capability, not per agent. An agent that can read account balances and also initiate transfers has two very different risk profiles.
Concrete examples: what may the agent do, and what stays with a person?
| Capability | Risk identified | Treatment | Stays with a person |
|---|---|---|---|
| Read customer records | Disclosure to the wrong customer | Authentication; access per customer | Disputes over identity |
| Draft customer letters | Misstatement of terms | Grounding in approved templates; sampling | Letters outside templates |
| Execute refunds | Wrong or duplicate payments | Limits; duplicate checks | Refunds above limit |
| Process emailed instructions | Planted instructions | External content cannot authorise action | Any instruction to change payee details |
| Coordinate other agents | Errors multiplying across agents | Narrow orchestration scope | Changes to the workflow itself |
An illustrative example
Take a building society running its first 23894-style assessment on an agent that handles mortgage overpayment requests. The team starts with a single risk entry: "agent makes an error". It tells them nothing.
They restart per capability. Reading the mortgage account: low consequence. Calculating the effect of an overpayment on the term: medium, because a wrong figure misleads the customer. Applying the overpayment: higher, because reversal is slow and may trigger charges. Accepting instructions from an emailed letter: high, because a forged letter could redirect funds. Treatments follow from the analysis: the agent calculates and drafts, applies overpayments only from verified sources of funds, and holds any request that arrived by email for a person. The risk register now explains each control.
How does 23894 relate to other standards?
ISO/IEC 23894 is guidance. ISO/IEC 42001 is a certifiable AI management system that expects AI risk assessment; 23894 is a natural way to do it. The difference is explored in ISO/IEC 23894 vs ISO/IEC 42001: guidance or certifiable system?, and the certifiable standard is introduced in what ISO/IEC 42001 is. Security risks to the agent itself fall to your ISMS; see whether ISO/IEC 27001 covers AI agents. The cross-regulation map is in AI agent regulation, mapped to controls.
Which controls show you have applied it?
- A risk register per agent capability, with likelihood, consequence and reversibility.
- Risk criteria approved by management, stating what level is acceptable for each kind of action.
- Treatments linked to controls: limits, holds, provenance rules, testing.
- Monitoring triggers for model updates, new sources and changed limits.
- Records of each assessment and its review.
Questions people ask
Can we be certified to ISO/IEC 23894?
No. It is guidance. Organisations that want certification use ISO/IEC 42001 and can use 23894 to carry out the risk work it requires.
Does 23894 tell us what depth an agent may have?
No. It helps you decide by assessing consequences and treatments. The decision on how far an agent may act is yours, based on that assessment and your testing.
Who should run the assessment?
The agent's business owner, with risk, compliance and technical staff. People who know the process the agent works in usually spot consequences that technical teams miss.