ISO/IEC 5338 Applied to AI Agents With Tool Access

What the standard covers and how to read it here

ISO/IEC 5338:2023, "Information technology, Artificial intelligence, AI system life cycle processes", is a voluntary international standard. As of November 2026 it is listed in the ISO/IEC JTC 1/SC 42 catalogue. It is not a law, and it carries no operative date.

The standard does not address agents that invoke tools at runtime. This guide therefore uses requirements definition, design, verification, operation, monitoring and maintenance as reading headings. Everything that connects those headings to tool access is architectural interpretation. It is not a reproduction of the standard's process outcomes, and it should be checked against the standard text before it is used in an audit or conformance claim.

That distinction matters in regulated enterprises. A mapping that reads like standard text invites a false sense of coverage. A mapping labelled as interpretation can be reviewed, challenged and adjusted.

Why tool access changes the life cycle problem

An AI agent system can be described as at least one generative model plus scaffolding software that gives the model tools to take discretionary actions. Once tools are attached, model output is no longer only text for a person to read. A tool call can write a record, send a message, move data or trigger a downstream system.

Three consequences follow for architects. First, the unit of risk becomes the individual call, with its arguments, target and caller. Second, behavior can change without a new model release, because a changed prompt, tool definition, retrieval source or policy alters what the agent does. Third, evidence of what was permitted and what happened has to exist per call, since a regulator or auditor will ask about actions, not intentions.

These consequences shape how each process area is interpreted below.

Process areas mapped to tool-enabled agents (architectural interpretation)

Each row separates what depends on runtime control of individual calls from what depends on work outside the execution path, and names the evidence the area would call for. The tool-scoping, re-testing and human-oversight practices come from community security guidance, such as OWASP's agent guidance, not from ISO/IEC 5338.

• Requirements definition: Runtime: little. Outside the path: defining permitted actions, which actions are high-impact, and who approves them. Evidence: documented action requirements and an approved tool inventory per agent.
• Design: Runtime: the policy model that call decisions will use. Outside the path: least-privilege tool scoping, separate tool sets by trust level, sandboxing, no wildcard permissions. Evidence: a justification for each tool grant and design records.
• Verification: Runtime: enforcement behavior can be exercised against policy. Outside the path: test planning and structured security testing before production and after material change. Evidence: test records tied to the change that triggered them.
• Operation: Runtime: allow, redact, block, rate limit or escalate for human approval before the action executes. Outside the path: approver staffing and incident procedures. Evidence: per-call decision records and approval outcomes.
• Monitoring: Runtime: capture of every decision with caller identity and delegation context. Outside the path: reviewing patterns and judging whether behavior is acceptable. Evidence: retained decision records and review records.
• Maintenance: Runtime: policy updates take effect in the path. Outside the path: change control, re-verification triggers, retiring unused tools. Evidence: policy version history and change records linked to re-tests.

Where runtime enforcement fits

Operation and monitoring are the areas where execution-path control does the most work. A control that sits in the path can evaluate a call before it runs and return one of a small set of decisions. Allow lets the call proceed. Redact removes sensitive content from the request or response. Block stops the call. Rate limit bounds how often a tool is used. Escalate holds the call for human approval. Enforcing these decisions at runtime is different from reviewing logs after the fact, because the consequence has already occurred by the time a log is read.

The same control is a natural source of evidence. If the decision is made in the path, the record of the decision can be produced at the same point: what was requested, which policy applied, what was decided, and who or what was acting. Current NIST NCCoE discussion on agent identity and authorization treats verifiable action records and links between user identities and agents as open questions. That suggests records should carry caller identity and delegation context. This is not an ISO/IEC 5338 requirement.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls, and produces audit-ready evidence from that enforcement. It does not replace the design, verification and governance work described here.

What the execution layer cannot satisfy

Several outcomes cannot be met by an enforcement point alone. Deciding which actions an agent should ever perform is a requirements decision. Choosing which tools to grant is a design decision, and a runtime control can only enforce the scope it is given. Accepting residual risk is a management decision. Testing after a change to prompts, tools, memory, retrieval, policies or model providers is a verification activity that happens before and around the path, not within it.

This is also where related standards divide the work. ISO/IEC 23894:2023 provides guidance on AI risk management and describes processes for implementing and integrating it, so decisions about tool-access risk belong there or in a management system, not in life cycle process execution alone. ISO/IEC 42001 is read here as the management-system layer. That division is interpretation, and this guide makes no statement about certification scope or compliance outcomes under either standard.

Crosswalks, such as the community-submitted INCITS-AI crosswalk between the NIST AI RMF and ISO 5338/5339, are useful aids. They are not official mappings to agent tool use, and the NIST AI RMF is voluntary and use-case agnostic. Treat both as input to your own mapping.