Liability Classification Methodology

AETHER classifies every detected AI vendor and every aggregated tenant into one of five liability classes — A through E — that bracket the realistic financial exposure if that vendor's grant were breached, mis-used, or non-compliant under EU AI Act / GDPR enforcement.

The output is directional, not predictive. A Class B classification does not predict that the customer will lose the Class B amount. It states that, against published industry benchmarks, the population of breaches with this vendor profile clusters in that range. The number is intended for board-level prioritisation, insurance underwriting, and compliance triage — not for accounting accruals.

This is the single feature that distinguishes a CFO-grade governance product from a CISO-grade scanner. False precision destroys insurance adoption; absence of any number destroys CFO adoption. The five-class abstraction keeps both audiences honest.

• No point estimates. AETHER does not quote a specific figure against any vendor. The unit is a class.
• No future-loss prediction. The classes describe historical breach distributions. They are not Monte Carlo loss simulations.
• No vendor-specific liability claim. A Class A vendor is not "liable for $5M+." The class describes the customer's exposure window if that vendor became the breach vector. Vendor liability is a separate legal question.
• No replacement for an underwriter. Insurers price using their own loss data, sector multipliers, and policy structure. AETHER is the evidence layer underwriters consume; it is not the underwriter.
• No DLP or content inspection. AETHER classifies the access surface, not what flows through it. DLP belongs to a separate product.

The model is anchored in USD for the class boundaries because every primary loss-data source AETHER cites (IBM, Ponemon, Coalition, Beazley, Hiscox) publishes in USD. Anchoring in any non-USD currency would require a hidden FX conversion at the methodology level.

Regulatory citations remain in their native currency— EU AI Act and GDPR fines in EUR (Article 83 / Article 99), UK ICO enforcement in GBP. Converting these would be incorrect.

Per-tenant display. The AETHER UI renders bands in the tenant's preferred currency. Use the switcher above to change the displayed currency for the table below. FX rebase: 1 USD = 0.79 GBP = 0.8 EUR (ECB reference rates, 1 May 2026).

For reference, the IBM 2024 global-mean breach cost is $4.88M (US dollars (USD)). That figure anchors the Class B range below.

Every class definition states the canonical USD range, the breach profile typical of that range, the specific public sources whose loss distributions support that range, and the AETHER-detectable signal that places a vendor into the class.

For each vendor granted by users with a scope set, the class assignment uses four deterministic inputs:

The function lives at lib/blast-radius/compute.js. It is pure — same inputs always yield same class. Every classification carries a reasoningChain array recording each modifier applied, so the chip tooltip in the UI shows the full derivation.

Worked example — Greenhouse, granted to 35 employees out of 500

• Scope sensitivity: Critical (writes employee records including PII; hiring decisions). Anchors Class B floor.
• AI Act class × role: high_risk × Provider per Annex III §4 (employment-context AI). Escalate one → Class A floor.
• User concentration: 35 / 500 = 7%. No escalation (threshold 10%).
• Compliance: SOC2 Type 2 + ISO27001 attested + GDPR-compliant. De-escalation one → Class B.
• Final: Class B (High).

The tenant-level aggregated class is not an arithmetic sum of per-vendor classes. Sums of order-of-magnitude classes are misleading. Instead:

1. Take the top 3 vendors by individual class (ties broken by user concentration).
2. The aggregated class is the highest individual class among the top 3, escalated by one if at least two of the top 3 are within one class of each other (concentration risk), capped at A.
3. The reasoning chain records which vendors and which escalation rule fired.

• The model version (liability-model-v1) is stored on every per-grant blast-radius row.
• When the model bumps to v2, the reclassify route re-runs against rows whose model version lags.
• Public benchmarks are reviewed at least annually against the most recent IBM, Ponemon, Coalition, Beazley, and Hiscox releases. Range shifts >25% trigger a model version bump.
• FX rebase happens annually with benchmark refresh, or earlier if cross-rates move >5%.

• Currency. All canonical bands are USD. GBP/EUR equivalents are rebased annually using ECB reference rates.
• Vendor catalog coverage. The v1 catalog covers ~70 high-priority vendors. Vendors not in the catalog default to unclassified and contribute nothing to the aggregated class.
• Self-attestation gap. AI Act roles for the customer's own internal tools (Apps Scripts, internal OAuth apps) cannot be derived from the catalog. They default to deployer/unclassified and are flagged for tenant self-attestation in the UI.
• Insurer-specific calibration. Carriers consuming AETHER's signed evidence export may apply their own multipliers. The class is the abstraction; the multiplier is the carrier's intellectual property.
• No legal advice. This methodology does not constitute legal advice on AI Act compliance, GDPR posture, or insurance coverage. Customers are responsible for engaging qualified counsel.

All sources cited are publicly available as of 2026-05-07.

1. IBM Security, Cost of a Data Breach Report 2024. ibm.com/reports/data-breach
2. IBM Newsroom, IBM Report: Escalating Data Breach Disruption Pushes Costs to New Highs (30 July 2024). newsroom.ibm.com
3. Coalition, 2024 Cyber Claims Report. coalitioninc.com
4. Coalition, Mid-Year Claims Report 2024. coalitioninc.com
5. Coalition, 2025 Cyber Claims Report. coalitioninc.com
6. Information Commissioner's Office (UK), Enforcement action register. ico.org.uk
7. Regulation (EU) 2024/1689 — Artificial Intelligence Act. eur-lex.europa.eu
8. Regulation (EU) 2016/679 — General Data Protection Regulation. eur-lex.europa.eu
9. ECB euro reference exchange rate. ecb.europa.eu

Internal audit conducted 2026-05-07 against primary sources. Corrections applied:

If a customer or auditor disputes a class assignment, AETHER provides:

1. The reasoning chain — every modifier applied to the vendor, with the input value and the rule that fired. Available via the UI tooltip and via the underwriting evidence export.
2. The catalog version — manual-curation-v1 in the v1 model. Captured on every row.
3. The model version — liability-model-v1 in the v1 model. Captured on every row.
4. The benchmark sources — every range on this page cites the public report it was derived from, with a URL.

Disputes that produce a class change in v1.x trigger a catalog or model version bump in v1.(x+1). Rows are then automatically re-classified.

12.1 Autonomy tier

Four tiers, each with a defined modifier on the v1 base class:

• T1 — Read-only. Pure observation/reporting. Signal: read-only scopes only, or vendor catalog flag. Modifier: -1 class (de-escalate).
• T2 — Suggestion. Generates content; human approval required before any action. Signal: vendor catalogagent.autonomy: suggestion OR flow definition with mandatory Approval step. Modifier: 0.
• T3 — Scoped autonomy. Acts autonomously within a documented scoped surface; audit-only intervention. Signal: write/send scopes with single-vendor target. Modifier: +1 class.
• T4 — Unconstrained. Multi-system action capability with no per-action human gate. Signal: application-level permissions (via Graph /appRoleAssignments) OR Power Automate flow with no Approval step + cross-system actions. Modifier: +2 classes (capped at A).

12.2 Action capability (multi-valued)

A tag set populated from scope analysis + vendor catalog. Severity weights derived from MITRE ATLAS (Adversarial Threat Landscape for AI Systems):

• read · suggest — weight 0.0 each
• modify · send — weight 0.5 each
• decide · external_action — weight 0.75 each (decision-making + external-API surfaces are the regulator- defined high-risk per AI Act Article 6 + Annex III)

Capability modifier capped at +1.5 to avoid runaway escalation when many tags fire simultaneously.

12.3 Human intervention model

What gate exists before the agent acts. Maps to EU AI Act Article 26(2) — the deployer's obligation to maintain human oversight:

• none — no human in the loop; modifier +1 class
• audit_only — action logged, no real-time gate; modifier 0
• post_notification — human notified after action; modifier 0
• approval_gate — single human must approve; modifier -1 class
• multi_party_approval — two or more must approve; modifier -2 classes

12.4 Control attestation

Five evidenced governance controls per agent, mapped to specific Article 26 obligations:

Each attested control contributes -0.2 to the modifier (fully-attested agent de-escalates ~1 class). Attestation is only ever de-escalation, never escalation.

12.4b ICO AI Governance & Accountability Framework — control coverage

The five methodology v2 attested controls (above) are mapped not only to EU AI Act Article 26 but also to the UK Information Commissioner's Office (ICO) AI Governance and Accountability framework, which sets eleven control measures DPOs and senior compliance roles are already being audited against. AETHER's product surface aligns directly with five of the eleven. (Section 12.4c below covers the specifically ADMoverlay — UK GDPR Articles 22A–22D as amended by the Data (Use and Access) Act 2025, and the four key concepts the ICO's March 2026 consultation is clarifying.)

Five of eleven controls map at strong or very strong. Two controls (7 and 8) are explicitly out of scope by design — they are paper-and-process controls owned by the customer's DPO and counsel. The honesty-discipline labelling carries through: AETHER claims alignment only where the product genuinely produces the evidence in question.

12.4c ADM, Meaningful Human Involvement, and the four DUAA safeguards

The Data (Use and Access) Act 2025 (DUAA) replaced UK GDPR Article 22 with Articles 22A–22D, moving the UK's automated-decision-making (ADM) regime from a prohibition-based model to a safeguards-based regime. The ICO opened a public consultation in March 2026 on draft guidance updating four key concepts: the definition of a decision, what counts as “solely automated”, what counts as a legal or similarly significant effect (L/SSE), and what constitutes meaningful human involvement (MHI).

Methodology v2's five dimensions were architected, before the DUAA, against precisely these four concepts. The alignment is now explicit:

The four DUAA safeguards (Articles 22A–22D) — what AETHER evidences

• Information to the data subjectabout the automated decision — AETHER's per-agent inventory plus signed evidence pack documents which agents process which user identities and under what authorisation.
• The right to obtain human intervention — the human intervention model field shows whether such a route exists technically. Where the model is none on an L/SSE agent, AETHER flags the configuration as DUAA-exposed.
• The right to express a point of view — paired with the human intervention model and the control attestation fields, AETHER documents the technical surface that supports expression of view; the customer DPO attests the operational workflow.
• The right to contest the decision — same substrate: the audit-trail and documented-approval attestations evidence the technical capability to reconstruct the decision after the fact, which is the precondition of contestation.

Methodology v2's autonomy tier and human intervention model are reproducible — re-deriving them on the same input yields the same output. This is the defining property the ICO consultation calls for: assessments of solely-automated decisions and MHI must withstand supervisory examination, which probabilistic LLM-generated assessments cannot.

12.5 Agent persona

Whose identity does the agent act under:

• user_impersonating — delegated OAuth grant. Modifier 0.
• service_identity — application-level grant; acts under its own identity. Modifier +0.5.
• hybrid — both delegated AND application permissions for the same client_id. Modifier +1 class. Hybrid agents are the highest-risk persona class because they can act independently of any user being signed in.

12.6 Modifier formula

Final class = saturating clamp of (v1 base class + sum of modifiers), capped at [E, A]:

baseClass = v1.computeClass(scopeSensitivity, aiActClass,
                             usersGranted, workforceSize, compliance)

modifier = autonomyTierDelta(profile.autonomyTier)        // -1 to +2
         + interventionDelta(profile.humanInterventionModel) // -2 to +1
         + personaDelta(profile.agentPersona)              // 0 to +1
         + capabilityDelta(profile.actionCapability)       // 0 to +1.5
         - controlAttestationDelta(profile.controlAttestation) // 0 to -1

finalClass = saturate(baseClass + round(modifier))         // [E, A] clamp

Round half-toward-zero so a net modifier of 0.5 doesn't escalate but 0.6 does. Saturating arithmetic prevents Class beyond A or below E.

12.7 Sources for v2 modifier weights

No constant in v2.0's formula is hand-tuned. Each traces to a public source — same defensibility discipline as v1:

• Autonomy tier escalation curve — NIST AI RMF Profile 1.0 Sec 5 (autonomy axis), AI Act Article 14 (human oversight levels).
• Action capability weights — MITRE ATLAS (Adversarial Threat Landscape for AI Systems) action taxonomy.
• Human intervention modifier — EU AI Act Article 26(2), IEEE 7000-2021 (transparency standards for autonomous systems).
• Persona modifier — CISA Zero Trust Maturity Model 2.0 (service identities classified higher-risk than user identities).
• Control attestation de-escalations — SOC 2 Trust Services Criteria CC7.x (system operations), ISO/IEC 27001:2022 Annex A.5 (organizational controls).

12.8 What v2 does NOT do

Documenting the negative space is part of being defensible. v2 does not:

• Measure agent quality, accuracy, or performance. Out of scope. AETHER measures governance and risk, not capability.
• Predict actual financial loss. The blast-radius class maps to a published benchmark range; AETHER cites the range, the customer (or their underwriter) picks the point estimate.
• Certify regulatory compliance. AETHER evidences what's observed in the customer's tenant; the customer's counsel decides compliance.
• Run prompts, test alignment, or characterize model behavior. Surface-coverage of access is the unit of measurement.
• Detect agents entirely outside the OAuth + Power Platform + appRoleAssignments enumeration surface (e.g. a bespoke agent running on a developer's laptop calling OpenAI directly). Endpoint telemetry is deliberately out-of-scope for AETHER.