Certification Scope Governance requires that all certifications and attestations of conformance are bound to specific system boundaries, software versions, infrastructure configurations, and operating modes. A certification that says "Organisation X is conformant" without specifying what system, what version, in what operating mode, and at what point in time provides no actionable assurance. The certification scope MUST be a formally defined, versioned artefact that unambiguously identifies the assessed system boundary, making it possible to determine whether a given agent deployment is within or outside the certification's coverage. Without scope governance, certifications become marketing claims rather than assurance instruments.
Scenario A — Unbounded Certification Conceals Non-Assessed Components: An organisation obtains a conformance certification for its "AI Agent Platform." The certification statement does not specify which components were assessed. The platform comprises: an orchestration layer, 6 specialised agents, a shared inference service, a configuration store, and a monitoring dashboard. The assessment actually covered only the orchestration layer and 2 of the 6 agents. The organisation presents the certification to a client as evidence that "the platform is certified." The client deploys one of the 4 non-assessed agents for payment processing. When an incident occurs, the client discovers that the payment agent was never within the certification scope.
What went wrong: The certification scope did not specify system boundaries. "AI Agent Platform" was treated as a monolithic entity when it comprised independently deployable components with different risk profiles. Consequence: Client reliance on a certification that did not cover the deployed component, £1.4 million payment processing incident, contractual dispute between the organisation and the client, certification body reputation damaged.
Scenario B — Version Drift Invalidates Certification: An organisation certifies its customer-facing agent at version 3.2.1 in March. Between March and September, 47 deployments are made (versions 3.2.2 through 3.4.0), including a major model upgrade in version 3.3.0 that changes the agent's decision-making architecture. The organisation continues to reference the March certification for all versions. In September, a regulatory review asks: "Is the currently deployed version covered by this certification?" The organisation cannot answer because the certification did not specify version boundaries or define under what conditions recertification is required.
What went wrong: The certification was bound to the system at a point in time but did not define version scope boundaries or recertification triggers. 47 subsequent deployments were treated as within scope without verification. Consequence: Regulatory finding for misrepresentation of certification scope, requirement to recertify the current version, 3-month deployment freeze pending recertification.
Scenario C — Operating Mode Not Specified Creates False Assurance: An organisation certifies its trading agent operating in "supervised mode" where a human operator approves every trade above £50,000. The certification scope does not explicitly state the operating mode. Six months later, the organisation enables "autonomous mode" (trades up to £250,000 without human approval) to improve execution speed. The certification is still referenced as evidence of conformance. The autonomous mode was never assessed and does not satisfy the conformance profile's human oversight requirements. A rapid series of autonomous trades accumulates £3.1 million in losses before the monitoring system flags the pattern.
What went wrong: The certification scope did not specify the operating mode. "Supervised mode" and "autonomous mode" have fundamentally different risk profiles, but the certification was treated as covering both. Consequence: £3.1 million in trading losses, regulatory finding for operating in a non-certified mode, personal liability risk for the compliance officer who signed the operating mode change.
Scope: This dimension applies to every certification, attestation, or formal conformance declaration issued against the Agent Governance Standard. This includes: self-assessment declarations, second-party assessments (by clients or partners), and third-party certifications (by accredited certification bodies). The scope covers the definition of what is within the certification boundary, how versions are handled within that boundary, and what conditions trigger reassessment or recertification. Informal or internal-only assessments are excluded from mandatory scope governance but are encouraged to adopt it.
4.1. A conforming system MUST define a certification scope document for every certification or formal conformance declaration, specifying: the system boundary (components, services, and infrastructure included and excluded), the software version or version range assessed, the infrastructure configuration assessed, and the operating modes covered.
4.2. A conforming system MUST bind each certification to the specific conformance profile (AG-222) against which the assessment was conducted, with a versioned reference to the profile definition.
4.3. A conforming system MUST define recertification triggers — specific conditions under which the existing certification is invalidated and reassessment is required — including at minimum: major version changes, architecture changes, operating mode changes, conformance profile changes, and elapsed time (maximum 12 months without reassessment).
4.4. A conforming system MUST maintain a certification register listing all active certifications with their scope definitions, assessment dates, expiry dates, and recertification trigger status.
4.5. A conforming system MUST reject or flag any reference to a certification for a system, version, or operating mode that is outside the certification's defined scope.
4.6. A conforming system SHOULD implement automated scope validation — comparing the deployed system's current version, configuration, and operating mode against the certification scope to determine whether the deployment is within the certified boundary.
4.7. A conforming system SHOULD define a materiality threshold for version changes that distinguishes changes requiring recertification (material changes) from changes that remain within the certification scope (non-material changes), with explicit criteria for materiality.
4.8. A conforming system MAY implement continuous certification — an approach where the certification scope is maintained dynamically through continuous assessment rather than point-in-time evaluation, with automated scope tracking and incremental reassessment.
Certification is a trust instrument. Stakeholders — regulators, clients, partners, the public — rely on certifications to make decisions about trust, risk acceptance, and engagement. A certification that does not precisely define its scope is a trust instrument with undefined terms. It creates a gap between what the stakeholder believes is certified and what was actually assessed.
This gap matters because AI agent systems are not monolithic. They comprise multiple components (agents, services, infrastructure, models) that are independently deployable, independently versioned, and independently configurable. An assessment of one component does not extend to others. An assessment of one version does not extend to subsequent versions. An assessment of one operating mode does not extend to other modes. Without explicit scope governance, stakeholders have no way to determine whether the certification covers their specific concern.
The velocity of AI agent development exacerbates this problem. Organisations deploying AI agents may release updates weekly or daily. Each update potentially changes the system's behaviour, risk profile, and conformance status. Without version-aware scope governance, a certification issued on day one may be referenced on day 100 for a system that has undergone 50 material changes.
Certification scope governance makes the boundaries of assurance explicit, traceable, and verifiable. It protects the certification's credibility, protects stakeholders from relying on inapplicable certifications, and protects the certifying organisation from liability for scope misrepresentation.
The certification scope should be a structured document (or structured data artefact) that is published alongside the certification itself. It should include: a system architecture diagram showing the boundary of assessment, an explicit list of included and excluded components, version identifiers for all assessed components, infrastructure configuration parameters relevant to conformance, and a list of assessed operating modes.
Recommended patterns:
Anti-patterns to avoid:
Basic Implementation — Every certification has a scope document specifying system boundaries, versions, and operating modes. A certification register lists all active certifications with assessment dates and expiry dates. Recertification triggers are defined and monitored manually. Scope validation is performed manually before referencing a certification.
Intermediate Implementation — Certification scopes are defined at the component level with version ranges and materiality criteria. The certification register is automated with expiry alerts and recertification trigger monitoring. Scope validation is integrated with the deployment pipeline — deployments outside certified scope are flagged automatically. Materiality criteria are formally defined and applied consistently to version changes.
Advanced Implementation — All intermediate capabilities plus: continuous certification through ongoing assessment and automated scope tracking. Scope changes are detected in real-time and trigger incremental reassessment. Cross-organisation scope validation enables supply-chain certification — clients can verify that the specific components they use are within the supplier's certification scope. The certification scope system is independently audited. Scope governance is integrated with AG-158 (Standard Evolution) to trigger scope review when the standard itself changes.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Scope Document Completeness
Test 8.2: Certification-to-Profile Binding
Test 8.3: Recertification Trigger Detection
Test 8.4: Out-of-Scope Reference Prevention
Test 8.5: Certification Expiry Enforcement
Test 8.6: Scope Version Immutability
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 43 (Conformity Assessment) | Direct requirement |
| EU AI Act | Article 48 (CE Marking) | Supports compliance |
| ISO 42001 | Clause 9.2 (Internal Audit — Scope) | Supports compliance |
| ISO/IEC 17021-1 | Clause 8.2 (Audit Scope) | Direct requirement |
| NIST AI RMF | GOVERN 1.4 (Documentation and Transparency) | Supports compliance |
| SOX | PCAOB AS 2201 (Scope of Internal Control Audit) | Supports compliance |
| FCA | SM&CR (Scope of Regulated Activities) | Supports compliance |
Article 43 requires conformity assessment of high-risk AI systems against defined requirements. The conformity assessment must have a defined scope — what system, in what configuration, is being assessed. AG-223 provides the governance mechanism for defining and maintaining that scope, ensuring that conformity declarations are precise and verifiable. Without scope governance, conformity declarations under Article 43 are vulnerable to regulatory challenge.
ISO/IEC 17021-1 governs the certification process itself, requiring that audit scope is defined before the audit begins and that the certification is limited to the assessed scope. AG-223 aligns with this requirement by making scope definition a governed artefact with its own versioning, change control, and validation.
PCAOB Auditing Standard 2201 requires external auditors to define the scope of their internal control audit, including which entities, locations, and processes are covered. For AI agent governance, AG-223 provides the equivalent scope definition — specifying which system components, versions, and operating modes are assessed. Without it, the auditor cannot bound the audit, and the resulting opinion may be qualified for scope limitation.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Cross-organisation — affects all parties relying on the certification's assurance |
Consequence chain: Without certification scope governance, certifications become untethered from specific systems, versions, and operating modes. The immediate failure mode is scope ambiguity — stakeholders cannot determine what is actually certified. The downstream consequence is misplaced reliance — clients, regulators, or partners trust that a specific deployment is certified when it is not. The ultimate business consequence surfaces when an incident occurs in a non-certified component or version: the certification provides no defence, the stakeholder who relied on it faces unexpected exposure, and the certifying organisation faces liability for scope misrepresentation. In regulated sectors, this maps to potential findings for misrepresentation of compliance status.
Cross-references: AG-222 (Conformance Profile Governance) defines the profiles against which certifications are assessed. AG-219 (Control Taxonomy Governance) provides the control set referenced in scope documents. AG-221 (Assurance Evidence Schema Governance) standardises the evidence produced during certification assessments. AG-157 (External Conformance Assessment) conducts the assessments that produce certifications. AG-007 (Governance Configuration Control) governs the version control that scope definitions depend upon.