ISO/IEC 5338 for AI Agents: Lifecycle Processes for Tool-Using Systems

How to read ISO/IEC 5338 for agents

ISO/IEC 5338:2023, "Information technology — Artificial intelligence — AI system life cycle processes", is published within the ISO/IEC JTC 1/SC 42 catalogue. It is a lifecycle framework, not a certification checklist, and it should be interpreted rather than ticked off.

The standard does not describe agents that select and call tools, including MCP servers, at runtime. That gap matters because an agent's effective behavior is set by two things the traditional lifecycle often treats loosely: the permissions granted to its tools, and the decisions it makes at runtime within those permissions.

The mapping in this guide is the author's interpretation. It uses generic lifecycle stage names (requirements, design, verification, validation, operation, monitoring, maintenance) and should be checked against the text of the standard and your own process documentation before you cite it internally.

Two related developments are worth tracking. ISO/IEC CD 25704, a draft process assessment model, builds on the processes defined in ISO/IEC 5338:2023. ISO/IEC DIS 42007, a draft framework for developing conformity assessment schemes for AI systems, is also in development. Neither is a published standard, but both suggest that assessment-style evaluation of lifecycle processes is becoming more formal. Evidence produced now should be structured so it can support that kind of review later.

Why tool access changes the lifecycle

In a conventional AI system, the system's outputs are the main object of control. In a tool-using agent, outputs can be actions: reading a record, writing to a system, sending a message, running code. The consequence of a decision depends on which tools were reachable and what they were permitted to do.

This makes tool-call authority a first-class lifecycle concern. Authority should be stated as a requirement, implemented as a design decision, tested like any other behavior, enforced during operation, and revisited whenever a tool, model, prompt or connected server changes.

When authority is left undefined, operation-stage controls tend to default to whatever the tool itself allows. Monitoring then reports what happened after the fact, but nothing in the execution path determined whether the action should have happened. An auditor asking what the agent was allowed to do receives a list of credentials rather than a policy.

The processes most affected are requirements definition, design, verification, validation, operation and monitoring, and maintenance. Others, such as acquisition or disposal, matter too but change less when tools are introduced.

Stage-by-stage mapping: policy and evidence

The table below sets out, for each affected stage, the policy requirement for tool-using agents and the evidence the stage should produce. This is recommended practice, not content taken from the standard.

• Requirements definition: Policy: state the tasks the agent may perform, the tools and MCP servers it may call, the data classes it may touch, and the actions that need human approval. Evidence: an approved tool-authority register with named owners.
• Design: Policy: assign permission scopes per tool, choose where decisions are enforced in the execution path, and define behavior when a call is blocked or escalated. Evidence: an architecture record and version-controlled policy definitions.
• Verification: Policy: test that enforcement matches the specification, including allow, redact, block, rate limit and escalation cases. Evidence: test results tied to a specific policy version.
• Validation: Policy: confirm the agent achieves its intended use within its authority under realistic scenarios, including attempts to act outside scope. Evidence: scenario results and documented acceptance by the system owner.
• Operation and monitoring: Policy: apply policy to each interaction and tool call as it happens. Evidence: a record per decision showing agent, tool, action requested, policy version, outcome and any approver.
• Maintenance: Policy: treat changes to tools, servers, models, prompts or policies as triggers for re-review. Evidence: change records, policy differences and repeat verification results.

Where runtime enforcement supports operation-stage processes

Operation is the stage where the earlier definitions either hold or fail. A policy written during requirements has no effect unless something applies it when the agent attempts a call. Enforcement therefore has to sit in the execution path, so that a decision is made before the action completes. A review after the fact cannot prevent the action.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. The available actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Because enforcement is where decisions are made, it also generates audit-ready evidence of what the agent was allowed to do and what it did. That evidence is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer's cloud, with configurable retention and data residency. In production, Trussed has run continuously for more than 18 months in a regulated enterprise.

The scope is deliberately narrow. Runtime enforcement supports the operation and monitoring processes and gives maintenance a record to review. It does not replace requirements definition, design, verification or validation, which remain engineering and governance work. It does not provide model or dataset lineage, and it does not trace an entire agentic workflow end to end. Those needs require other controls, and the lifecycle mapping should name them explicitly rather than assume one layer covers them.

Regulatory context and practical next steps

Evidence design should account for regulation as well as standards. Regulation (EU) 2024/1689, the EU AI Act, lays down harmonised rules on AI. As of November 2026, the European Commission's Digital Omnibus on AI, proposed on 19 November 2025, would set fixed application dates for delayed high-risk rules: 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. These dates are a proposal and apply only if it is adopted. Whether a given agent deployment is high-risk is a separate classification question that this guide does not answer.

A workable starting sequence is short. Inventory the tools and MCP servers each agent can reach. Write the authority for each as policy, with owners and approval conditions. Decide where that policy is enforced in the execution path. Test the enforcement against the specification, then define which evidence each stage retains and for how long. Finally, tie tool, model and prompt changes to a re-review step so the authority register does not drift from what the agent can actually do.