This page is the versioned document. The same rules in their shorter, current form are at the methodology, which is the page to cite for day to day reference. This text was corrected on 1 October 2026; every material change is listed in the corrections log.
The EU AI Omnibus entered into force on 27 July 2026. High risk obligations under Regulation (EU) 2024/1689 now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems. The Article 5 prohibitions have applied since 2 February 2025 and Article 50 transparency from 2 August 2026. The articles this methodology maps did not change in substance, and the methodology is unchanged.
1. Purpose and scope
Why certification exists for AI agents
Autonomous AI agents are moving into production across European organisations. They write and run code, transact for businesses, process personal data at scale, advise on medical and financial matters and run operational workflows with little human review. Deployment has moved faster than the governance meant to contain it.
Three gaps follow. Insurers writing cover for AI related liability have no consistent signal for the risk posture of an agent deployment, so policies rest on proxies instead of evidence of controls. Regulators and supervisors reviewing deployer obligations under the EU AI Act need structured artefacts to attach their assessments to; a point in time declaration is not enough for a system whose behaviour keeps changing. Boards, procurement teams and counterparties need a readable, defensible benchmark for the agents they rely on or buy, without the technical capacity to build one themselves.
Agent Certified exists to close those gaps. The methodology produces a scored, evidence backed result that each of these parties can read, cite and rely on.
What this methodology covers
It applies to autonomous AI agents and agentic systems deployed in production by professional operators. An autonomous AI agent, for this framework, is a system that:
- uses a large language model or equivalent generative model as its main reasoning component;
- has access to one or more external tools, APIs, data sources or execution environments;
- takes actions or produces outputs with real consequences in an organisational or commercial setting; and
- operates with at least partial autonomy, so that not every action needs explicit human approval first.
Classification under the EU AI Act does not change scope. The methodology applies to agents that meet the Act's definition of a high risk system and to agents below that threshold alike. An operator of a general purpose agentic tool is as much in scope as one deploying a system classified as high risk under Annex III.
What it does not cover
- Research models that are never deployed.
- AI systems that produce outputs but take no actions and have no tool access.
- General purpose chat interfaces with no autonomous action or retrieval pipeline.
- Systems deployed by providers where the deployer has no meaningful ability to configure safety controls.
- AI embedded in regulated medical devices, where the Medical Device Regulation (EU) 2017/745 is primary. Such systems may use this methodology as a supplementary governance layer.
Editorial principles
Four principles govern the methodology. Independence: no carrier, vendor, model provider or operator pays for placement, score adjustment or favourable framing. Transparency: the methodology is published openly and in full. Reproducibility: two assessors working from the same evidence should land within one point of each other on any dimension. Fairness: every scored party receives its evidence file and a right of reply before any public disclosure.
2. The seven dimensions
Every agent is evaluated on seven dimensions, each scored from 0 to 10 and each weighted for its contribution to operational safety and regulatory exposure. Dimensions and weights are fixed for the life of a major version; changing a weight needs a new major version and public consultation.
Dimension 1. Trust and Safety, weight 18, the highest
Definition
The measurable prevention of unsafe, unauthorised or harmful actions by the agent in production, and the discipline with which unsafe outputs are detected, contained and remediated. It carries the highest weight because a failure here is of a different kind: it can harm end users, third parties or the operator's own systems before any other control can act.
Why it matters
Articles 9, 14 and 15 of the EU AI Act require high risk systems to be built with risk management, human oversight, and accuracy, robustness and cybersecurity, and Article 26 obliges deployers to use them accordingly. Outside the high risk class, the revised Product Liability Directive, Directive (EU) 2024/2853, creates exposure wherever an unsafe output causes damage. The Manage function of the NIST AI RMF addresses harm response and corrective action directly, and ISO/IEC 42001 Clause 8.4 asks for an AI system impact assessment. An underwriter cannot read the risk of an agent without knowing what stops it.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | No safety consideration. The agent acts up to its technical capability with no documented limit. No detection, no containment, no playbook. |
| 3 | Safety is left entirely to model defaults. No organisation level guardrails, no red team exercise, no misuse monitoring beyond provider telemetry. |
| 6 | Guardrails documented and deployed. At least one red team exercise, with findings tracked. Detection is ad hoc. A containment playbook exists but has not been drilled. |
| 8 | Guardrails tested quarterly. Continuous detection alerting an on call function. Kill switch verified and accessible to non engineering staff. Incident response drilled within the prior six months. |
| 10 | Layered guardrails covering prompt injection, jailbreak, data exfiltration and unsafe tool use. Continuous adversarial testing linked to a remediation register. Real time misuse detection tied to automatic containment. An incident record with at least one real, contained safety event and a documented retrospective. |
Evidence required
- Guardrail specification, with scope of coverage and update cadence.
- Red team report with dated findings and remediation evidence.
- Monitoring dashboard or alert configuration showing real time misuse detection.
- Incident response playbook with named roles and verified kill switch access.
- Incident log, or confirmation that no material safety event has occurred together with the method for judging materiality.
Common failure modes
- Treating model level content filters as if they were organisation level guardrails.
- A single red team exercise at launch and none after.
- Kill switches that need engineering access, out of reach when time matters.
- No distinction between safety incidents and product defects in the incident log.
Underpinning standards
NIST AI RMF 1.0: Govern 1.1, Manage 4.1, Manage 4.2. ISO/IEC 42001:2023: Clause 8.4, Annex A.6. EU AI Act: Articles 9, 14 and 15. EIOPA Opinion on AI governance and risk management, 6 August 2025.
Dimension 2. Context Integrity, weight 14
Definition
The quality of the information the agent reasons over. An agent's output is only as reliable as its inputs. The dimension covers provenance, freshness and lineage, and the controls that keep poisoned, stale or unauthorised data out of the agent's working memory or retrieval pipeline.
Why it matters
An agent reasoning over unverified or wrongly attributed information produces outputs with hidden liability. Article 10 of the EU AI Act sets data governance requirements, and they reach by extension into retrieval pipelines where an agent reasons over external documents. Indirect prompt injection through retrieved content is a recognised attack surface, listed by OWASP. ISO/IEC 42001 Annex A.7 addresses data for AI systems. An insurer asked to stand behind an agent's factual claims needs to know they can be traced.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | Context sources unknown to the operator. No inventory, no provenance, no staleness detection. |
| 3 | Sources implicit or informally understood. No provenance metadata. Staleness undetected. User supplied content reaches the agent unvalidated. |
| 6 | Sources catalogued in a documented inventory. Manual, periodic refresh. Provenance for primary sources but not every retrieval. Basic validation of user supplied content. |
| 8 | Full provenance on every retrieved document. Automated freshness checks with staleness alerts. Validation of external and user supplied content. Lineage documented from source to decision. |
| 10 | End to end lineage from source to decision trace, verified by tooling. Tested resistance to prompt injection through retrieved content. Automatic quarantine of untrusted sources. Source integrity monitored in production. |
Evidence required
- Inventory of every knowledge source and retrieval surface the agent uses.
- Provenance metadata specification or schema for retrieved documents.
- Refresh cadence policy and evidence of staleness alerts in production.
- Input validation configuration for user supplied content.
- Version controlled lineage diagram from source to reasoning output.
Common failure modes
- Retrieval pipelines that do not record a document's origin, so a wrong output cannot be traced.
- Live sources without freshness checks, so outdated information is presented as current.
- User context passed into retrieval or reasoning without sanitisation, opening the door to indirect injection.
- No distinction between primary sources and synthesised summaries in the context window.
Underpinning standards
NIST AI RMF 1.0: Map 1.6, Map 3.1, Govern 6.1. ISO/IEC 42001:2023: Annex A.7 (data for AI systems). EU AI Act: Article 10 (data and data governance). OWASP Top 10 for LLM Applications: LLM02 (insecure output handling), LLM06 (sensitive information disclosure).
Dimension 3. Distribution Control, weight 12
Definition
The controls that decide who can invoke the agent, under what authority, and how its downstream actions are bounded. It is where identity, authorisation and blast radius meet. A weak position means the agent can be called by parties who should not reach it, with more scope than they are entitled to authorise.
Why it matters
Article 26 of the EU AI Act sets the obligations of deployers, including use within the intended scope. The GDPR principle of data minimisation translates, inside an agent, into limiting blast radius. ISO/IEC 42001 Annex A.9 covers the use of AI systems. For an underwriter, an undifferentiated invocation model is like leaving the keys in the ignition: the probable maximum loss cannot be assessed without knowing who can call the agent and what they can make it do.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | Open invocation. No authentication. No per caller limits. Anyone with network access can call the agent at full capability. |
| 3 | Basic authentication with shared credentials. No per caller rate limits. Environments not segregated. |
| 6 | Authenticated calls with individual credentials. Basic rate limits. Development and production separated. Blast radius understood informally. |
| 8 | Role based authorisation tied to the identity provider. Per caller spend caps and tool quotas enforced. Blast radius documented and measured for every tool. Segregation enforced by infrastructure, beyond convention. |
| 10 | Zero trust invocation. Real time quota enforcement. Blast radius for every tool tested through controlled chaos exercises. Per call audit trails in an immutable log. Least privilege enforced at the level of each tool as well as at invocation. |
Evidence required
- Identity and access configuration for invocation, including credential type and rotation policy.
- Role based access policy mapped to organisational roles.
- Rate limit and spend cap configuration per caller type.
- Environment segregation architecture diagram.
- Blast radius assessment for each tool, with maximum impact quantified.
Common failure modes
- API keys shared between callers, so misuse cannot be attributed to anyone.
- Development instances holding production level tool access.
- Blast radius assessed on paper and never tested against real tool behaviour.
- Rate limits set so high they contain neither cost nor abuse.
Underpinning standards
NIST AI RMF 1.0: Govern 1.7, Map 2.2. ISO/IEC 42001:2023: Annex A.9 (use of AI systems). EU AI Act: Article 26 (obligations of deployers). NIST SP 800-207, Zero Trust Architecture: Section 2.1 (tenets of zero trust).
Dimension 4. Product Maturity, weight 14
Definition
The degree to which the agent behaves as a production grade system. It covers reliability, regression discipline, evaluation coverage and the engineering practice that keeps behaviour predictable. A high scoring operator can state, with evidence, what the agent does, how reliably it does it and how changes are managed.
Why it matters
Article 15 of the EU AI Act requires high risk systems to reach appropriate levels of accuracy, robustness and cybersecurity, and the same expectation applies in practice wherever counterparties, insurers or boards rely on an agent's outputs. ISO/IEC 42001 Clause 9 requires performance to be evaluated against defined criteria. Without versioning or regression testing, a coverage decision made at binding may not hold for the system actually running three months later.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | Prototype. No versioning, no uptime measurement, no evaluation suite. Behaviour unmonitored between deployments. |
| 3 | Code under version control, prompts and model configuration not. Uptime tracked informally. No formal regression suite. |
| 6 | Prompts and model versions under change control. Uptime measured. Partial regression suite on major changes. Change log kept reactively. |
| 8 | Published service level objectives. Regression evaluation on every change. Observability at the reasoning trace level. Behaviour changes communicated to stakeholders in advance. |
| 10 | Objectives enforced with automated alerts. Canary or staged release for all changes. Evaluation coverage reviewed quarterly. Drift detection across outputs, with distributional shifts flagged automatically. |
Evidence required
- Version history for prompts, model configuration and tool definitions, with change attribution.
- Uptime and latency for the prior 90 days, with the service level objective defined.
- Regression suite specification: test case count, coverage rationale, run frequency.
- Observability configuration showing trace level monitoring.
- Behaviour change log with dated entries for the prior twelve months.
Common failure modes
- Prompts left unversioned while code is versioned, so the most consequential setting is uncontrolled.
- Regression suites that test the happy path and miss edge and adversarial cases.
- Logging at the response level only, which makes reasoning errors undiagnosable in production.
- Provider model upgrades applied automatically without an operator side regression run.
Underpinning standards
NIST AI RMF 1.0: Measure 1.1, Measure 2.5, Manage 2.2. ISO/IEC 42001:2023: Clause 9.1 (monitoring, measurement, analysis and evaluation), Annex A.6 (AI system life cycle). EU AI Act: Article 15 (accuracy, robustness and cybersecurity), Article 12 (record keeping). IEEE 7000-2021.
Dimension 5. Governance, weight 16, the second
Definition
The institutional scaffolding around the agent: evidence that it is known to the board, owned by a named accountable senior role, bound by written policy and logged in a way that will survive an audit. Governance does not make an agent safe by itself. It makes sure that when something goes wrong the right people know at once, the right authorities can act, and a complete record exists for investigation, remediation and regulatory response.
Why it matters
Article 9 of the EU AI Act requires a risk management system for high risk AI, Article 12 requires automatic logging, and Article 27 requires certain deployers of high risk systems to carry out a fundamental rights impact assessment. The NIS2 Directive, Directive (EU) 2022/2555, makes management bodies accountable for cybersecurity risk. ISO/IEC 42001 addresses governance in Clause 5 (leadership) and Clause 6 (planning). For insurers, EIOPA's Opinion on AI governance and risk management, published on 6 August 2025, sets supervisory expectations for how AI is governed in the sector; it is guidance and does not carry the force of law.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | No formal ownership. No policy referring to the agent. The board unaware of its scope or risk. |
| 3 | Known to management but not to the board. No named owner. No risk register entry. Incomplete audit trail. |
| 6 | Named senior owner with documented accountability. An AI risk policy that refers to the agent or to agentic systems. Board informed at least annually. Audit trail partial but consistent. |
| 8 | Risk register entry with current rating and mitigations, reviewed at least twice a year. Board review on a defined cadence. Supplier and model due diligence documented and current. Audit trail meets sector retention requirements. |
| 10 | AI governance embedded in enterprise risk management. Quarterly board review with written minutes. Independent assurance already performed by an external party. A full audit trail, retained, tested and available to regulators on request. |
Evidence required
- Named accountable owner, role title and scope of accountability.
- AI risk policy addressing agentic systems, with effective date and review history.
- Board or risk committee minutes referring to the agent or AI risk category within the prior twelve months.
- Risk register extract showing the agent as an active entry with rating and mitigations.
- Vendor and model supplier due diligence, current within twelve months.
- Audit trail specification: retention period, access controls and evidence of completeness.
Common failure modes
- Accountability given to the team that built the agent instead of a senior business owner who answers for its operation.
- A generic AI policy that never addresses autonomous agent behaviour.
- Board minutes that mention AI without recording what was reviewed or decided.
- Audit trails that capture outputs but not reasoning steps, ruling out root cause analysis.
Underpinning standards
NIST AI RMF 1.0: Govern 1.1, 1.2, 4.1, 5.1. ISO/IEC 42001:2023: Clause 5 (leadership), Clause 6 (planning), Annex A.2 (policies related to AI). EU AI Act: Article 9 (risk management system), Article 12 (record keeping), Article 27 (fundamental rights impact assessment). NIS2 Directive (EU) 2022/2555: Article 20 (governance). EIOPA Opinion on AI governance and risk management, 6 August 2025.
Dimension 6. AI Integration, weight 12
Definition
How the agent sits inside the organisation's existing systems of record, identity, approval and escalation. Integration decides whether the agent extends institutional memory or bypasses it. A well integrated agent reads in an audit like a trusted internal operator: its actions attributed, its escalations on the right channels, its outputs in systems of record with full provenance.
Why it matters
Legal and regulatory risk from an agent's actions grows with how hard those actions are to trace to a responsible party. An agent writing to systems of record under a shared service account makes attribution impossible after the fact. Article 26 of the EU AI Act requires deployers to assign human oversight to people with the competence and authority to exercise it. Under the revised Product Liability Directive, Directive (EU) 2024/2853, a court can order disclosure of evidence, and a failure to disclose leads to a presumed defect; that presupposes the evidence exists, and an unintegrated agent leaves none. The proposed AI Liability Directive, which earlier versions of this text cited here, was withdrawn by the European Commission in 2025.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | The agent runs entirely parallel to core systems. Writes go to shadow systems or nowhere. One service account for every action. No escalation path. |
| 3 | Some outputs reach systems of record without attribution. Escalation paths informal. Agent logs separate from the organisation's observability stack. |
| 6 | Partial integration. Most writes attributed. Approval flows with bypass paths. Escalations to a named team. Logs partly centralised. |
| 8 | Integration follows the authority chain. Identity carried end to end. Escalations to named individual reviewers. Logs in the central observability stack. |
| 10 | Full integration: every write, approval, escalation and decision attributed, timestamped and kept with the organisation's records. Tested through a simulated audit within the prior twelve months. |
Evidence required
- Integration architecture diagram: systems of record, identity provider, approval workflow.
- Proof that writes carry agent identity, timestamp and action provenance.
- Escalation routing with named reviewers and verified notification paths.
- Evidence that agent logs sit with the organisation's observability stack.
- An audit trail extract from a real agent initiated action, attributed end to end.
Common failure modes
- Agent actions in a proprietary log the compliance or risk function cannot reach.
- Escalations to generic mailboxes, so nobody in particular is accountable.
- Identity that collapses at the API boundary, so downstream systems see one service identity.
- Approval workflows with an unconditional bypass for the agent.
Underpinning standards
NIST AI RMF 1.0: Govern 6.2, Measure 4.1, Manage 3.1. ISO/IEC 42001:2023: Annex A.8, Annex A.9. EU AI Act: Article 14 (human oversight), Article 26 (obligations of deployers). Directive (EU) 2024/2853, revised Product Liability Directive: disclosure of evidence.
Dimension 7. Autonomy Envelope, weight 14
Definition
The explicit, documented boundary between what the agent may do without human confirmation and what needs a human in the loop. It is the clearest single determinant of an agent's operational risk and the first element insurers and regulators examine. Without a defined envelope an agent has no meaningful risk boundary: its scope is limited only by its technical capability and its access to tools.
Why it matters
Article 14 of the EU AI Act requires human oversight measures proportionate to the risk of a high risk system. A general statement that humans can override the agent does not meet it; documented thresholds, accessible controls and evidence that oversight is exercised do. For agents outside the high risk class, Article 26 still asks deployers to keep oversight where appropriate, and the Manage function of the NIST AI RMF addresses human oversight thresholds. For an insurer, the envelope is the closest available proxy for probable maximum loss: a tightly drawn envelope limits the damage the agent can do on its own.
Scoring rubric
| Score | Anchor |
|---|---|
| 0 | No envelope. The agent acts up to its technical capability. Autonomy is assumed unless a technical error prevents an action. |
| 3 | An informal understanding of what the agent should not do alone, undocumented, unenforced and unreviewable by non technical stakeholders. |
| 6 | Autonomy policy written and referenced in governance documents. Some thresholds enforced in code. Revocation needs engineering access. Rollback possible but untested. |
| 8 | Envelope enforced in code as well as policy. Named non technical roles can revoke within two minutes. Rollback tested for at least one action class. Hard stops documented with rationale. |
| 10 | The envelope is the operating contract: reviewed and signed off each quarter, tied to insurance policy wording, every action class classified as fully autonomous, threshold gated or permanently prohibited, the rationale version controlled. |
Evidence required
- Written envelope classifying every action class as fully autonomous, threshold gated or permanently prohibited.
- Configuration showing thresholds enforced in code.
- Revocation procedure available to named non technical roles, with access time verified.
- Rollback procedure and at least one test of it against a real action class.
- Hard stop register of permanently prohibited actions, with rationale.
- Quarterly review: dated sign off by the named accountable owner.
Common failure modes
- A policy too abstract to map onto actual tool capabilities, and so unenforceable.
- Thresholds set for convenience instead of impact, letting consequential actions through.
- Revocation that needs an engineer, out of reach for an incident outside office hours.
- No line between actions never delegated and actions delegated with controls.
- An envelope reviewed at launch and never again, stale once new tools arrive.
Underpinning standards
NIST AI RMF 1.0: Govern 1.4, 1.5, Manage 1.3, 4.1. ISO/IEC 42001:2023: Annex A.8. EU AI Act: Article 14 (human oversight), Article 26 (obligations of deployers). Council of Europe Framework Convention on Artificial Intelligence (CETS No. 225): Article 14.
3. Scoring and weighting
Each dimension is scored on a whole number scale from 0 to 10. A 0 is reserved for cases where no controls or evidence exist. A 10 requires positive evidence of good practice and tested effectiveness. Assessors record the evidence cited for every score next to the score.
Dimension weights
Weights reflect each dimension's share of operational risk exposure. They are fixed for the duration of a major version and are not adjusted for sector, agent type or operator size.
| Dimension | Weight | Maximum weighted points |
|---|---|---|
| Trust and Safety | 18 | 180 |
| Context Integrity | 14 | 140 |
| Distribution Control | 12 | 120 |
| Product Maturity | 14 | 140 |
| Governance | 16 | 160 |
| AI Integration | 12 | 120 |
| Autonomy Envelope | 14 | 140 |
| Total | 100 | 1,000 |
Score formula
Each raw score is multiplied by its weight and the seven products are summed. The maximum is 1,000. The overall score is that sum divided by 1,000 and multiplied by 100, rounded to the nearest whole number.
Overall score = (Σ rawd × weightd) ÷ 1,000 × 100, where rawd is a whole number from 0 to 10.
The floor rule
Each tier also sets a minimum raw score on every dimension: 2 for In Progress, 4 for Certified, 6 for Advanced, 8 for Elite. An agent whose overall score indicates a tier but which falls below that tier's floor on any single dimension is placed in the tier below until the floor is met. The rule keeps a tier from overstating the control position in any assessed area.
Three illustrations
These are constructed to show the arithmetic. None describes a real deployment.
| Dimension | A. Customer service agent with structured escalation | B. Financial recommendation agent with limited oversight | C. Autonomous trading agent with strong controls |
|---|---|---|---|
| Trust and Safety (18) | 6, 108 | 4, 72 | 9, 162 |
| Context Integrity (14) | 5, 70 | 6, 84 | 9, 126 |
| Distribution Control (12) | 7, 84 | 5, 60 | 10, 120 |
| Product Maturity (14) | 6, 84 | 7, 98 | 9, 126 |
| Governance (16) | 7, 112 | 5, 80 | 10, 160 |
| AI Integration (12) | 6, 72 | 4, 48 | 9, 108 |
| Autonomy Envelope (14) | 7, 98 | 4, 56 | 9, 126 |
| Overall | 62.8, so 63 | 49.8, so 50 | 92.8, so 93 |
| Tier | Certified: the total indicates Advanced, but Context Integrity at 5 is below the Advanced floor of 6 | Certified: every dimension at 4 or above | Elite: every dimension at 8 or above |
4. Certification levels
Every scored agent is placed in one of five tiers, by overall score and subject to the floor rule. The tier gives the parties who rely on the agent a shared vocabulary that does not require them to follow the scoring mechanics.
Elite, 75 to 100
Overall score 75 or above, and at least 8 on every dimension. A deployment at or near the frontier of responsible practice. Controls are present, documented, tested and effective, with evidence from real production. Governance sits inside institutional risk management, and the Autonomy Envelope is reviewed formally every quarter. Sector overlays, once they exist, are most likely to matter here, particularly for agents that advise on medical, legal or financial questions. The result is valid for twelve months from issue, with immediate review on any trigger event in Section 6.
Advanced, 55 to 74
Overall score 55 to 74, and at least 6 on every dimension. Strong foundational controls and a clear path toward Elite. The gap to Elite usually reflects missing continuous monitoring, quarterly review or independent assurance rather than missing controls. Valid for twelve months; an interim self assessment at six months is encouraged.
Certified, 35 to 54
Overall score 35 to 54, and at least 4 on every dimension. The essential controls and governance are in place: policy exists, ownership is assigned and the agent works within a defined scope. Gaps at this tier usually concern continuous monitoring, regression discipline and the maturity of the Autonomy Envelope. Certified is the entry threshold for the right to carry the Agent Certified mark. Valid for twelve months; operators in the lower half of the band are advised to plan an interim review at six months.
In Progress, 20 to 34
Overall score 20 to 34, and at least 2 on every dimension. The mark is not awarded. Foundational work has begun, but essential controls in one or more dimensions are absent or not yet evidenced. The report names the dimensions below the Certified floor and the evidence or action that would lift them, as a prioritised remediation plan. In Progress is an accurate picture of where the operator stands and what comes next.
Pre Assessment, below 20
Overall score below 20. No mark is issued. The evidence base for a full assessment is not yet in place, which may mean an early deployment, an agent moving from research to production, or foundations still to be laid. The result comes with a gap analysis of the minimum steps to reach In Progress. Operators at this stage are encouraged to use the methodology as a design checklist from the start.
5. The assessment process
The standard assessment runs six weeks from engagement to the scored report, combining the operator's own disclosure with independent review. A certification issued on self disclosure alone is not valid under this methodology.
Phase 1. Self assessment, weeks 1 and 2
The operator completes the readiness questionnaire, which maps to the criteria under each dimension in Section 2. For each criterion the operator answers yes, partial or no and names the document, configuration artefact or operational record behind the answer. Operators do not propose scores; the assessor scores from the evidence. Evidence must be current: produced within the prior twelve months or, for continuously updated artefacts such as risk registers, as of the submission date. Older evidence may support context but does not replace current evidence.
Phase 2. Evidence collection, week 3
The assessor reviews the submission and notifies the operator of gaps within five business days. A supplementary request covers any criterion where the evidence cannot support a score above 3, and the operator has five business days to answer. There is no second request: if the evidence is still insufficient, the assessor applies the rubric to what is available, which usually means 0 to 3 for the criterion. Evidence types expected across all dimensions include policies with effective dates and named owners, versioned architecture diagrams, timestamped configuration exports, evaluation suite specifications, audit trail extracts, board or risk committee minutes, vendor due diligence records, and incident logs or a confirmation of no material incident with the method for judging materiality.
Phase 3. Independent review, weeks 4 and 5
The assessor scores each dimension against its rubric, at dimension level, and records the score, the evidence cited and any evidence noted but not decisive. Where evidence is inconsistent, the most conservative reading applies and the inconsistency is noted. The operator reviews the draft score and citations before the report is final and may submit factual corrections within three business days, without new evidence.
Phase 4. The scored report, week 6
The report sets out the overall score and tier, every dimension score and weight, the evidence cited for each, any inconsistencies noted, any floor that caps the tier, and a prioritised remediation plan where the operator did not reach the tier it sought. It goes to the operator and is retained by Agent Certified. The operator may authorise publication of the tier and overall score; the full report needs the operator's consent to be published.
Phase 5. Continuous monitoring
Holders notify any trigger event under Section 6 within 30 days. Advanced and Elite holders attest every quarter that no trigger event has occurred and that the evidence behind the last report remains materially accurate. A missed attestation suspends the result until it is received.
| Week | What happens |
|---|---|
| 1 | Operator completes the readiness questionnaire and submits the primary evidence package. |
| 2 | Assessor reviews the submission, identifies gaps and issues the supplementary request. |
| 3 | Operator submits supplementary evidence. Evidence collection closes. |
| 4 | Assessor completes dimension scoring. Internal quality review. |
| 5 | Draft score shared with the operator. Correction window of three business days. |
| 6 | Final report issued. The mark is released at Certified or above. |
6. Re assessment and drift
An agent's behaviour changes continuously: through model updates, prompt revisions, new tools, changes to retrieval pipelines and drift in its inputs. A result issued against one configuration may not describe the same agent six months later. This section sets the triggers for re assessment and the monitoring that keeps a result accurate between scheduled reviews.
Triggers
Each of these events requires the operator to notify Agent Certified and begin a re assessment within 90 days:
- A change of underlying model, including a provider update where the operator could have stayed on the previous version and chose not to.
- A new tool, API or integration that widens the agent's action surface or data access.
- A new data source or knowledge base in the retrieval pipeline.
- A material change in the population of users or callers.
- A change of deployment context that materially alters the scope or consequence of the agent's actions.
- A regulatory change that directly affects a dimension, where operator and assessor agree that re assessment is needed.
- A material safety, data or operational incident attributable to the agent.
- A change of named senior owner where governance continuity cannot be shown.
Continuous monitoring
- Logging at the level set in the report, with retention meeting sector requirements.
- Red team or adversarial testing at least quarterly for Advanced and Elite, at least every six months for Certified.
- Regression evaluation on every material change to prompts, model configuration or tool definitions.
- Quarterly review of the Autonomy Envelope, signed off by the named owner.
- Annual refresh of vendor and model supplier due diligence.
- Quarterly self attestation for Advanced and Elite.
A point in time score and continuous assurance
The methodology produces a score from the evidence available at assessment. The monitoring duties extend its value by keeping the controls in place between assessments, much as an annual financial audit relates to the internal controls an audited company runs all year. Insurers and regulators relying on a result should note the date of the report and the attestation record. A score more than twelve months old without re assessment is not current under this methodology, whatever the operator says about the stability of its deployment.
7. Crosswalk to standards
The seven dimensions are grounded in the main international standards and regulatory instruments for AI governance and risk management. The table maps each to the NIST AI RMF 1.0, ISO/IEC 42001:2023 and the EU AI Act, with the nearest pillar of AIUC-1.
| Dimension | NIST AI RMF 1.0 | ISO/IEC 42001:2023 | EU AI Act | Nearest AIUC-1 pillar |
|---|---|---|---|---|
| Trust and Safety | Govern 1.1, Manage 4.1, 4.2 | Clause 8.4, Annex A.6 | Articles 9, 14, 15 | Safety, security |
| Context Integrity | Map 1.6, 3.1, Govern 6.1 | Annex A.7 | Article 10 | Data and privacy |
| Distribution Control | Govern 1.7, Map 2.2 | Annex A.9 | Article 26 | Security |
| Product Maturity | Measure 1.1, 2.5, Manage 2.2 | Clause 9.1, Annex A.6 | Articles 12, 15 | Reliability |
| Governance | Govern 1.1, 1.2, 4.1, 5.1 | Clauses 5, 6, Annex A.2 | Articles 9, 12, 27 | Accountability |
| AI Integration | Govern 6.2, Measure 4.1, Manage 3.1 | Annex A.8, A.9 | Articles 14, 26 | Accountability |
| Autonomy Envelope | Govern 1.4, 1.5, Manage 1.3, 4.1 | Annex A.8 | Articles 14, 26 | Safety, accountability |
A note on AIUC-1
AIUC-1 is the AI agent standard published by the Artificial Intelligence Underwriting Company (AIUC), an underwriting company and standards body. It sets 51 requirements and 130 controls across six pillars: data and privacy, security, safety, reliability, accountability and societal risks. The pillar column is our own reading of where each dimension sits closest; AIUC has not reviewed it, and Agent Certified has no relationship with AIUC. The NIST AI RMF and ISO/IEC 42001 mappings remain the primary references.
8. Independence
The methodology is only as credible as the independence of the assessments it produces. These policies hold for the life of this version and change only through a major revision with public consultation.
No paid placement
No carrier, vendor, model provider, technology partner or operator pays for placement, score adjustment or favourable framing in any assessment or publication. The rubric is applied the same way to every agent, whatever the operator's commercial relationship with Future Proof Intelligence.
Open methodology
The complete methodology, including every rubric, weight, evidence requirement and tier definition, is published at agentcertified.eu/methodology-v2 under CC BY 4.0. Anyone may use, reproduce or build on the text with attribution. The certification mark is reserved and may only be used with a current, valid assessment issued by Agent Certified.
Consultation on revisions
Major revisions, including changes to weights, tier thresholds or the assessment process, go through 30 days of public consultation before taking effect. Minor revisions that leave the scoring structure intact may take effect without consultation, with 14 days' notice.
Conflicts of interest
An assessor with a current or prior commercial relationship with the operator declares it before the assessment begins. If the relationship is material, another assessor takes the assessment. Declared conflicts are kept in an internal register reviewed every quarter.
Right of reply
Every organisation whose agent is scored may reply before any public disclosure, within three business days of receiving the draft report. A factual correction the assessor accepts changes the score. One the assessor rejects is noted in the final report with the reasoning. Disagreement about how the methodology should be interpreted is not a ground for changing a score, and may be sent as feedback for the next version.
9. Versions and review
Version history
This is version 2.0, published on 24 April 2026. Version 1.0 was published on 17 April 2026. This text was corrected on 1 October 2026 without changes to weights, thresholds or process; the changes are listed in the corrections log.
Major and minor versions
The number before the decimal marks a major version. A major change revises weights, tier thresholds, the assessment process or anything else that affects whether scores under different versions can be compared. Major versions follow an annual review that begins the quarter before and includes 30 days of public consultation. The number after the decimal marks a minor version: quarterly updates for regulatory or market developments, clearer rubric language, or added evidence requirements with unchanged criteria. Minor versions are published with 14 days' notice.
Changes from v1.0 to v2.0
- Fuller dimension text. Each dimension now states why it matters, with references to regulatory and insurance obligations. v1.0 gave criteria and rubrics only.
- The formula. v1.0 used a denominator of 720 from an early scoring model. v2.0 uses 1,000, consistent with a 0 to 10 scale and weights totalling 100. Scores under v1.0 are indicative only and should be reassessed under v2.0.
- The floor rule. Implicit in v1.0, explicit in v2.0, with floors for each tier.
- The process. v2.0 sets the six week timeline, the supplementary request and the correction window.
- Triggers. v2.0 lists eight trigger events and the 90 day notification and re assessment duty.
- Crosswalk. v2.0 maps to NIST AI RMF functions and ISO/IEC 42001 clauses.
- Independence. v2.0 writes down policies that were practised but unwritten.
- Illustrations. v2.0 adds three scored examples of the formula.
The v3.0 review
Dates for the v3.0 consultation and publication will be announced on this page; until v3.0 is published, v2.0 remains in force. Areas identified for the review are sector overlays for medical, financial and legal advice agents, a method for multi agent pipelines, revised Autonomy Envelope anchors informed by incident data as it becomes available, and alignment with any harmonised technical standards adopted under the EU AI Act.
10. Limitations
Assessor judgement
Fixed rubrics and evidence requirements aim at reproducibility, yet some decisions need judgement that cannot be fully written down in advance: whether a guardrail is effective in fact (Trust and Safety), or whether an envelope's classification is reasonable for the agent's action surface (Autonomy Envelope). Internal quality review before issue limits the variance, and two assessors may still differ by one point where judgement is required. An operator who believes a score rests on an unreasonable reading can use the right of reply in Section 8.
Sectors
There are no sector overlays yet. An agent advising on medical treatment carries risks of a different kind from one summarising legal precedent or recommending financial products, even with identical scores. Until overlays exist, operators in regulated sectors should treat the score as necessary but not sufficient, and consult sector guidance directly.
Multi agent architectures
The methodology assesses a single agent or agentic system. In a pipeline each agent can be assessed on its own, but the risks that emerge between agents, such as trust propagation, instruction injection between agents and accountability split across owners, are not yet addressed.
Model and deployment
The methodology assesses the controls the operator puts around the deployment. It does not assess the underlying model or the adequacy of the provider's safety measures. A model that passed provider evaluations can still sit inside a deployment that scores poorly on Trust and Safety, and a strong score says nothing about the model itself. For the model, readers should consult model evaluation work such as METR's evaluations or the EU AI Office's methodology under the AI Act.
11. Citation and use
How to cite
Future Proof Intelligence (2026). The Agent Certified Methodology: A Published Framework for AI Agent Certification, 2026 Edition. Version 2.0. Agent Certified, agentcertified.eu. Published 24 April 2026. https://agentcertified.eu/methodology-v2
Short form for legal or regulatory filings: Agent Certified Methodology v2.0 (Future Proof Intelligence, 24 April 2026).
Licence
The text is published under the Creative Commons Attribution 4.0 International licence. Anyone may reproduce, adapt, translate or build on it, including commercially, with attribution to Agent Certified and Future Proof Intelligence, a link to the licence and an indication of any changes. The licence does not cover the Agent Certified mark or any scored report, which may not be reproduced without written consent.
Enquiries
Questions on applying the rubric, feedback for the v3.0 review, press enquiries and requests about the mark all go through the request page. Say in the message what it concerns.