AI Dispatch
The wirereportAug 25, 2026

The Trust Gap, Vol. 4: our own liability field was 87.5% wrong, and the absence rate did not actually improve

The headline absence rate fell from 77.90% to 73.37% this week. We changed the denominator; the industry did not move. Plus a complete census of our liability_cap field, seven of whose eight values turned out to be misfiled — in our favour.

Across 1,704 published entities the AI Dispatch Index now holds 100,116 applicable data points. **73,455 of them (73.37%) are `no_public_information`.** In Vol. 3, seven days ago, the figure was 72,727 of 93,365 — 77.90%.

Nothing improved. We changed the denominator.

On 2026-08-19 migration `0027` added four fields to the catalogue, taking it from 59 to 63. Those four fields have been assessed on roughly 15% of published entities, so they contribute 5,783 slots that carry no row at all — neither a value nor an absence. A slot we have not looked at is not a disclosure, and it is not an absence either. Counting it in the denominator without counting it in the numerator makes the industry look more forthcoming than it is.

Measured like for like, on the same 59 fields Vol. 3 used:

| Basis | Applicable slots | `no_public_information` | Rate | |---|---|---|---| | Vol. 3 (2026-08-17), 59 fields | 93,365 | 72,727 | **77.90%** | | Vol. 4 (2026-08-24), same 59 fields | 93,300 | 72,510 | **77.72%** | | Vol. 4, all 63 fields | 100,116 | 73,455 | 73.37% |

The real week-over-week movement is **−0.18 percentage points**. That is the honest headline, and it is the one we lead with. Anyone who reads the 73.37% next to Vol. 3's 77.90% and concludes the market moved four points toward transparency in a week would be reading our own bookkeeping change as an industry trend. We would rather say so ourselves than have someone else notice.

---

## 1. What we have not assessed

MIT's AI Agent Index publishes that 227 of its 1,350 data points lack public information. We report ours the same way, and we add a category MIT does not need: they annotated every cell of a 30 × 45 grid by hand, so every slot has a verdict. We crawl continuously, and we do not.

Of the 100,116 applicable slots on published entities:

| Status | Slots | Share | |---|---|---| | `present` | 20,832 | 20.81% | | `no_public_information` | 73,455 | 73.37% | | `not_applicable` | 0 | 0.00% | | **No row — never assessed** | **5,829** | **5.82%** |

The 5,829 are not a rounding artifact and they are not evenly spread. 5,783 of them sit on the four fields added on 2026-08-19:

| Field (added by `0027`) | Entities assessed | Share of 1,704 | `present` | |---|---|---|---| | `asset_custody` | 262 | 15.38% | 38 | | `self_reported_performance` | 257 | 15.08% | 35 | | `own_liability_cover` | 256 | 15.02% | **0** | | `market_recognition` | 258 | 15.14% | 15 |

The remaining 46 no-row slots are scattered singletons.

`own_liability_cover` deserves its own line. It was created to ask a question the catalogue could not previously ask: does this vendor carry its own errors-and-omissions or professional-liability cover? It has been asked of 256 published entities. **Zero have disclosed an answer.** That is a small denominator and we are not reporting it as a rate over 1,704. It is nonetheless a clean result on the population we did assess.

`applies_to` is enforced in the denominator: agents are scored against 59 applicable fields, vendors against 49, rather than a flat 63. Separately, 14 rows sit on fields that do not apply to their entity's type. They are excluded from every figure above and are queued as a data-quality item, not silently dropped.

---

## 2. The finding that has survived four volumes

Split the assurance layer into two blocks of six fields each — what a vendor says about **controlling** an agent, and what it says about **paying when the agent fails**.

| Block | Fields | Slots assessed | `present` | Rate | |---|---|---|---|---| | Controls | `audit_trail`, `audit_trail_immutable`, `runtime_governance`, `permission_scopes`, `explainability`, `compliance_certs` | 10,218 | 2,408 | **23.57%** | | Risk transfer | `insurance_available`, `insurance_carriers`, `coverage_limits`, `indemnification`, `liability_cap`, `own_liability_cover` | 8,773 | 21 | **0.24%** |

Both blocks are six fields over the same 1,704 entities. The denominators differ only because the risk-transfer block contains `own_liability_cover`, which is 85% unassessed; slots with no row are excluded from both sides rather than counted as absences.

Roughly a **98-fold** difference. Vendors describe the brakes. They are close to silent on the insurance.

Field by field, the risk-transfer block:

| Field | `present` of 1,704 | Rate | |---|---|---| | `coverage_limits` | 0 | **0.00%** | | `own_liability_cover` | 0 (of 256 assessed) | 0.00% | | `insurance_carriers` | 2 | 0.12% | | `indemnification` | 5 | 0.29% | | `insurance_available` | 6 | 0.35% | | `liability_cap` | 8 | 0.47% |

**`coverage_limits` is 0 of 1,704 for the fourth consecutive volume.** It is the only field in the 63-field catalogue at 100.00% absence, and it has never held a single value since the index opened.

**1,698 of 1,704 published entities (99.65%) have no public evidence of insurance availability.** The six exceptions are the complete population, not a selection: `armilla-ai`, `coalition`, `embroker` and `munich-re-aisure` — all four of which are insurers or insurance intermediaries, i.e. they sell the cover rather than carry it over an agent — plus two agents, `agent-shield` and `rentahuman-workman-rent`.

**Of 1,662 published agents, 2 (0.12%) disclose that insurance is available.**

And 469 of those 1,662 agents (28.22%) have no `present` value on *any* of the 24 assurance fields. Zero of 42 published vendors are in that state.

---

## 3. We read all eight `liability_cap` rows, and seven of them are wrong

`liability_cap` had 8 `present` values. That is a small enough population to read completely rather than sample, so we did — every row, in full, against its stored capture.

**One of the eight is a liability cap.**

| Entity | Stored quote (abridged) | Verdict | |---|---|---| | `agent-shield` | "Our liability is limited to the engagement fee paid." | **Genuine cap** | | `913-ai` | "913.ai UG (haftungsbeschränkt)" | Corporate legal form, from the site's copyright footer | | `agentman` | "Liability cap 1× fees — below firm floor (2×); escalate to partner" | Third-party demo output | | `ai-synth-id-remover` | "We are not liable for any damages arising from the use of this service." | Blanket exclusion, not a cap | | `cortx` | "…shall not be liable for any direct, indirect, incidental, consequential, or punitive damages…" | Blanket exclusion | | `deckdrop-io` | "DECKDROP SHALL NOT BE LIABLE TO EVALUATOR FOR ANY CLAIMS…" | Blanket exclusion | | `free-ai-humanizer` | "…not liable for indirect or consequential damages…" | Exclusion of indirect damages only | | `stripe` | "Stripe and its Affiliates will not be liable for any claim made by a Data Subject…" | Scoped DPA disclaimer |

**87.5% of the field is misfiled.** Three distinct failure modes, and each one is instructive.

**`913-ai` is the funniest and the most alarming.** `UG (haftungsbeschränkt)` is a German corporate form — an entrepreneurial company with limited liability. The stored quote comes from the page footer: `© 2026 913.ai UG (haftungsbeschränkt) · Alle Rechte vorbehalten`. The extractor saw the word for "limited liability" inside a company's registered name and filed it as that company's liability cap. The entity is, as it happens, an insurance-claims automation vendor.

**`agentman` is the class Vol. 3 predicted.** Its homepage renders a contract-review demo: `Indemnification Mutual clause confirmed — no unilateral exposure / Auto-renewal 60-day window vs. your 90-day standard — redline / Liability cap 1× fees — below firm floor (2×); escalate to partner`. That is Agentman reading *somebody else's* contract. Vol. 3 flagged contract-review demo output as the dominant false-positive class in the risk-transfer block and asked Platform Engineering for a negative marker on rendered clause-review blocks. The marker has not shipped, and here is the same defect surfacing in a different field.

**The five blanket exclusions are a definitional failure, not an extraction failure.** A liability cap is a ceiling: liability exists, and it stops at a number. "We are not liable for any damages" is not a ceiling — it is a floor at zero, and it is the opposite claim. Filing both under one field makes the field unreadable. The extractor was following the catalogue description faithfully; the description was wrong.

Correcting all seven takes the risk-transfer block from 21 `present` to **14 of 8,773 assessed slots — 0.16%** — and `liability_cap` from 8 to 1 of 1,704 (0.06%).

**This correction runs in our favour, which is exactly why we are publishing the audit rather than the corrected number.** Vol. 3 found our instrument systematically *understating* disclosure on `audit_trail` and `compliance_certs` — errors that ran against our thesis. This one runs for it. An index whose errors were only ever in one direction would not be an index. Both audits are now on the record, and readers can weigh them together.

We have not moved any row. Reclassifying a stored value is an editorial adjudication and belongs to the Fact-Checker; the eight rows are enumerated in appendix A9 with their evidence IDs so the correction is reproducible rather than asserted.

---

## 4. The first 3

Vol. 3 reported that no entity had ever scored 3 on any of the five rubric dimensions. **That is no longer true.**

On 2026-08-24, `proofchain` was scored **3 on `audit_trail`** — the first 3 on a published entity in the index's history. The capture states every agent gets "a cryptographically verifiable identity and a tamper-evident audit trail," described as "a forensic chain that regulators and auditors can verify without seeing your secrets." That is the rubric's own definition of a 3, met on the vendor's own published page.

One other 3 exists: `holistic-ai`, `runtime_governance`, scored 2026-08-01, on an entity that is still a `candidate` and therefore excluded from every published-entity statistic in this report.

This matters more than a single row. A rubric on which the top band is never reachable is not a rubric, it is a rhetorical device — and for three volumes ours looked like one. It is now demonstrated to be clearable by a vendor that publishes the right thing.

Judged (`v1`) scorecards, 73 published entities, complete distribution:

| Dimension | 0 | 1 | 2 | 3 | n | Trust gap (0–1) | |---|---|---|---|---|---|---| | `outcome_settlement` | 70 | 2 | 1 | 0 | 73 | **98.63%** | | `insurance_indemnity` | 64 | 7 | 2 | 0 | 73 | **97.26%** | | `compliance` | 51 | 13 | 9 | 0 | 73 | 87.67% | | `audit_trail` | 50 | 11 | 10 | 1 | 72 | 84.72% | | `runtime_governance` | 34 | 16 | 23 | 0 | 73 | **68.49%** |

`outcome_settlement` has never exceeded 2 and sits at 0 for 70 of 73 entities — the strongest and most stable result across four volumes. `runtime_governance` is the weakest gap and has been in every volume: nearly a third of judged entities clear a 2.

**The `v1-auto` scorer, partially fixed.** Vol. 2 and Vol. 3 both reported that the automatic scorer could not structurally emit a 0 or a 3 — across 1,387 rows its entire observed range was `{1, 2}` — and both excluded it from every statistic. On 2026-08-14 it began emitting 0s. Across 1,384 `v1-auto` rows on published entities there are now nine: `insurance_indemnity` 5, `compliance` 2, `audit_trail` 1, `runtime_governance` 1.

That is a real fix and we are recording it as one. It is also not finished. **No `v1-auto` row has ever scored 3**, and the dimension coverage is badly lopsided: `runtime_governance` has 438 auto rows and `audit_trail` 406, while **`insurance_indemnity` has 8**. The auto-scorer barely scores the dimension the index exists to measure.

We are again excluding `v1-auto` from every headline statistic, for a fourth volume. Only 3 published entities carry both a judged and an automatic score on any dimension, which is far too few to report a divergence rate — so we are not reporting one, in either direction.

---

## 5. Our own correction queue is not keeping up

Vol. 3's highest-priority handoff named three flagship insurers published as disclosing no insurance information. Seven days later:

| Entity | `insurance_available` today | Status | |---|---|---| | `embroker` | `present` (corrected 2026-08-19) | **Fixed** | | `lloyds-of-london` | `no_public_information` | Still wrong | | `chaucer-group` | `no_public_information` | Still wrong | | `mosaic-insurance` | `no_public_information` | Still wrong |

All three remaining are published live. Lloyd's of London, Chaucer and Mosaic each carry `no_public_information` on all five of the original risk-transfer fields. On `insurance_indemnity` a false absence is indistinguishable from a real 0, so the scorecard prints the opposite of the truth about three of the best-known names in the market we claim to cover.

The broader review backlog, on published entities:

| Flag confidence | Total | Reviewed | Unreviewed | |---|---|---|---| | High | 1,044 | 85 (8.14%) | 959 | | Medium | 812 | 2 (0.25%) | 810 |

Of the 85 high-confidence flags a human has adjudicated, **59 (69.41%) were corrections** — the absence was wrong — and 26 were confirmed. That is the reviewed population only. **We are not extrapolating that rate to the 959 unreviewed flags,** for the same reason Vol. 3 declined to: their field mix is different and their precision is unmeasured. What we can say is that our own detector has flagged 1,044 high-confidence possible errors on published pages and we have looked at 8% of them.

---

## 6. Still not computable: autonomy versus accountability

For a third consecutive volume we are not publishing the autonomy-versus-accountability analysis — do more autonomous agents have weaker audit trails? — and this time we can show why rather than assert it.

`autonomy_level` has 63 `present` values across 1,662 published agents (3.79%). Those 63 values contain **53 distinct strings**. They include a bare numeric scale (`3`, `4`, `5`), prose of every length (`Fully autonomous`, `AUTONOMOUS`, `autonomously`), percentages (`Autonomously resolve up to 89% of conversations`), two German entries (`75–85 % autonome Erledigungsquote`), one Spanish, and one that reads in full: `You own it. You cannot control it.`

Any mapping from that to an ordinal autonomy scale would be a set of judgment calls we made, and the correlation we published would be driven by our mapping rather than by the market. The field needs a controlled vocabulary before it can carry an analysis. Until it has one, the honest output is this paragraph.

Same decision, same reason, for **model concentration risk**: `model_provider` is `present` on 423 of 1,662 agents (25.45%) and `base_models` on 549 (33.03%), both free text.

The **assurance landscape map** remains deferred at 42 published vendors — enough to list, not enough to map without padding.

---

## 7. Where this undercuts us

Four things in this volume run against exact.works's position or against our own instrument, and they belong in the body rather than a footnote.

1. **The absence rate did not improve, and we nearly published that it had.** The 73.37% headline is real arithmetic over a real denominator, and it would have been the most flattering number in four volumes. It is not comparable to Vol. 3's and we said so first. 2. **`liability_cap` was 87.5% wrong in our favour.** Seven of eight values were misfiled, and correcting them makes the risk-transfer gap look *worse*. An instrument that errs toward its owner's thesis is the failure mode we criticise theaiagentindex.com for. 3. **The rubric's top band is reachable, and we said for three volumes that nothing had reached it.** That was true when written and is now false. `proofchain` cleared it on the strictest dimension we score. 4. **The controls half of the thesis keeps weakening.** 23.57% of controls slots carry a real disclosure, `runtime_governance` clears a 2 on 31.51% of judged entities, and Vol. 3's audit found our detector was *understating* `audit_trail` and `compliance_certs` disclosure with 92.59% precision. "Agents are ungoverned" is not what our data says. What survives, and has survived every volume, is narrower: **vendors describe the controls in detail and stay almost entirely silent on who pays when the controls fail.**

---

## 8. Scope limits

Stated here, not buried. The judged rubric covers **73 of 1,704 published entities (4.28%)**, purposively chosen rather than sampled — every dimensional rate above is a rate over those 73 and generalises to the index only as far as that selection allows. The `liability_cap` audit is a complete census of that field's 8 `present` rows and says nothing about other fields. 5,829 applicable slots have never been assessed and are reported as such rather than folded into either the present or the absent column. Every field value rests on the single capture cited by its row, so our central claim is **"not on the page we captured,"** never "not published anywhere." `v1-auto` is excluded from all headline statistics for the fourth volume. The four `0027` fields have ~15% coverage and no figure here treats them as a rate over 1,704.

All quotes reproduced in this report were re-checked against the whitespace-normalised test `assert_quote_is_verbatim()` itself applies — `position(regexp_replace(trim(quote),'\s+',' ','g') in regexp_replace(content,'\s+',' ','g')) > 0` — not against a naive `LIKE`, which produced a false alarm in Vol. 3. All 23 pass.

---

## Appendix — reproduction

Every number above comes from one of these queries, run against Supabase project `invsbcblyrjsvmygulcz` on 2026-08-24. They are given in full so any reader can reproduce or refute them.

**A1 — published population** ```sql select entity_type, count(*) from entities where status='published' group by entity_type; ```

**A2 — catalogue shape** ```sql select applies_to, category, count(*) from field_catalog group by applies_to, category; ```

**A3 — the headline (63 fields)** ```sql with slots as ( select e.id as entity_id, f.field_key from entities e join field_catalog f on f.applies_to='both' or f.applies_to=e.entity_type where e.status='published' ) select count(*) as applicable_slots, count(ef.id) filter (where ef.value_status='no_public_information') as npi, count(ef.id) filter (where ef.value_status='present') as present, count(ef.id) filter (where ef.value_status='not_applicable') as not_applicable, count(*) - count(ef.id) as never_assessed, round(100.0*count(ef.id) filter (where ef.value_status='no_public_information')/count(*),2) as pct_npi from slots s left join entity_fields ef on ef.entity_id=s.entity_id and ef.field_key=s.field_key; ```

**A4 — rows on inapplicable fields** ```sql select count(*) from entity_fields ef join entities e on e.id=ef.entity_id and e.status='published' join field_catalog f on f.field_key=ef.field_key where f.applies_to<>'both' and f.applies_to<>e.entity_type; ```

**A6 — like-for-like, excluding the four `0027` fields** ```sql with slots as ( select e.id as entity_id, f.field_key from entities e join field_catalog f on (f.applies_to='both' or f.applies_to=e.entity_type) where e.status='published' and f.field_key not in ('own_liability_cover','self_reported_performance', 'asset_custody','market_recognition') ) select count(*) as slots, count(ef.id) filter (where ef.value_status='no_public_information') as npi, round(100.0*count(ef.id) filter (where ef.value_status='no_public_information')/count(*),2) as pct from slots s left join entity_fields ef on ef.entity_id=s.entity_id and ef.field_key=s.field_key; ```

**A7 — every published entity with any risk-transfer disclosure** ```sql select e.slug, e.entity_type, string_agg(ef.field_key, ', ' order by ef.field_key) from entities e join entity_fields ef on ef.entity_id=e.id where e.status='published' and ef.value_status='present' and ef.field_key in ('insurance_available','insurance_carriers','coverage_limits', 'indemnification','liability_cap','own_liability_cover') group by e.id, e.slug, e.entity_type order by e.entity_type, e.slug; ```

**A8 — Vol. 3 correction-queue follow-up** ```sql select e.slug, e.status, ef.field_key, ef.value_status, ef.updated_at from entities e left join entity_fields ef on ef.entity_id=e.id and ef.field_key in ('insurance_available','insurance_carriers','coverage_limits', 'indemnification','liability_cap') where e.slug in ('lloyds-of-london','embroker','chaucer-group','mosaic-insurance', 'munich-re-aisure','coalition','armilla-ai') order by e.slug, ef.field_key; ```

**A9 — the eight `liability_cap` rows, read in full** ```sql select e.slug, ef.id as entity_field_id, ef.evidence_id, ef.value_text, ef.quote, ef.extracted_by from entity_fields ef join entities e on e.id=ef.entity_id where e.status='published' and ef.field_key='liability_cap' and ef.value_status='present' order by e.slug; ```

**A10 — scorecard distribution** ```sql select s.rubric_version, s.dimension, s.score, count(*) from scorecards s join entities e on e.id=s.entity_id and e.status='published' group by 1,2,3 order by 1,2,3; ```

**A11 — false-absence review backlog** ```sql select f.confidence, f.verdict, count(*) from false_absence_flags f join entities e on e.id=f.entity_id and e.status='published' group by 1,2 order by 1,2 nulls last; ```

**A14 — every 3 ever awarded; when `v1-auto` first emitted a 0** ```sql select e.slug, e.status, s.rubric_version, s.dimension, s.score, s.scored_at from scorecards s join entities e on e.id=s.entity_id where s.score=3;

select dimension, min(scored_at) from scorecards where rubric_version='v1-auto' and score=0 group by dimension; ```

**A15 — `autonomy_level` value census** ```sql select ef.value_text, count(*) from entity_fields ef join entities e on e.id=ef.entity_id and e.status='published' where ef.field_key='autonomy_level' and ef.value_status='present' group by 1 order by 2 desc; ```

**A17 — coverage of the four `0027` fields** ```sql select ef.field_key, count(*) as rows_written, count(*) filter (where ef.value_status='present') as present, round(100.0*count(*)/1704,2) as pct_of_published_assessed, min(ef.created_at)::date as first_written from entity_fields ef join entities e on e.id=ef.entity_id and e.status='published' where ef.field_key in ('own_liability_cover','self_reported_performance', 'asset_custody','market_recognition') group by ef.field_key; ```

**A18 — verbatim re-check, using the trigger's own normalisation** ```sql select ef.id, e.slug, ef.field_key, ef.evidence_id, position(regexp_replace(trim(ef.quote),'\s+',' ','g') in regexp_replace(rd.content,'\s+',' ','g')) > 0 as verbatim_ok from entity_fields ef join entities e on e.id=ef.entity_id join evidence ev on ev.id=ef.evidence_id join raw_documents rd on rd.id=ev.raw_document_id where e.status='published' and ef.value_status='present' and (ef.field_key in ('liability_cap','insurance_available','insurance_carriers','indemnification') or (e.slug='proofchain' and ef.field_key in ('audit_trail','audit_trail_immutable'))); ```

**A20 — published entities with zero assurance disclosure** ```sql with assur as (select field_key, applies_to from field_catalog where category='assurance'), per as ( select e.id, e.entity_type, count(ef.id) filter (where ef.value_status='present') as present_assurance from entities e join assur a on a.applies_to='both' or a.applies_to=e.entity_type left join entity_fields ef on ef.entity_id=e.id and ef.field_key=a.field_key where e.status='published' group by e.id, e.entity_type) select entity_type, count(*), count(*) filter (where present_assurance=0) from per group by entity_type; ```

**A21 — controls block versus risk-transfer block** ```sql with blocks as ( select unnest(array['audit_trail','audit_trail_immutable','runtime_governance', 'permission_scopes','explainability','compliance_certs']) as field_key, 'controls' as block union all select unnest(array['insurance_available','insurance_carriers','coverage_limits', 'indemnification','liability_cap','own_liability_cover']), 'risk_transfer' ), slots as (select e.id as entity_id, b.field_key, b.block from entities e cross join blocks b where e.status='published') select s.block, count(*) as slots, count(ef.id) filter (where ef.value_status='present') as present, count(ef.id) filter (where ef.value_status='no_public_information') as npi, count(*)-count(ef.id) as never_assessed, round(100.0*count(ef.id) filter (where ef.value_status='present')/count(*),3) as pct_of_all_slots from slots s left join entity_fields ef on ef.entity_id=s.entity_id and ef.field_key=s.field_key group by s.block; ```

Returns `risk_transfer` 10,224 slots / 21 present / 8,752 npi / 1,451 never assessed, and `controls` 10,224 / 2,408 / 7,810 / 6. The rates quoted in §2 are computed over **assessed** slots — `slots − never_assessed`, i.e. 8,773 and 10,218 — which is the conservative basis; over all slots the two rates are 0.205% and 23.552%.

---

**Methodology** is published at `/methodology`, including the five-dimension rubric and the full field catalogue. Corrections: every figure in this report is reproducible from the appendix. If one of them is wrong, we would like to be told, and we will publish the correction the way we published this one.

Entries in this piece 12

Published index entries backed by the same source documents this piece cites.

Sources 23

  1. Armilla provides named, affirmative AI insurance that responds to those failure modes directly
    www.armilla.ai · checked Jul 30, 2026
  2. AI insurance, pioneered by Munich Re in 2018, is triggered by unexpected errors in the ongoing performance of AI models in daily business use.
    www.munichre.com · checked Jul 31, 2026
  3. aiSure TM -backed performance warranties enable you to indemnify your clients for their financial losses or legal liabilities directly related to AI errors.
    www.munichre.com · checked Jul 31, 2026
  4. Mosaic Insurance has partnered with Munich Re to harness the power of aiSure™
    www.munichre.com · checked Jul 31, 2026
  5. Active Cyber Insurance for Enterprises Comprehensive cyber coverage backed by proprietary intelligence and Allianz’s A+ rated capacity.
    www.coalitioninc.com · checked Jul 31, 2026
  6. Cyber Insurance | Active Insurance & Cybersecurity | Coalition Now Available: Active Cyber Insurance for Enterprises
    www.coalitioninc.com · checked Jul 31, 2026
  7. with protection against data breaches, on-site accidents, professional errors and omissions, and more
    www.embroker.com · checked Jul 31, 2026
  8. To the fullest extent permitted by law, XNODE Inc. and its affiliates shall not be liable for any direct, indirect, incidental, consequential, or punitive damages arising from your use of the platform.
    xnode.ai · checked Aug 1, 2026
  9. Google’s IP indemnification policy helps protect Gemini Code Assist licensed users from potential legal ramifications concerning copyright infringements.
    cloud.google.com · checked Aug 1, 2026
  10. Plus requester reputation and incident insurance funded from the fee.
    workman.rent · checked Aug 2, 2026
  11. We are not liable for any damages arising from the use of this service.
    www.aisynthidremover.com · checked Aug 2, 2026
  12. EXCEPT WHERE OTHERWISE PROHIBITED BY APPLICABLE LAW, DECKDROP SHALL NOT BE LIABLE TO EVALUATOR FOR ANY CLAIMS IN CONNECTION WITH THE TRIAL SERVICES OR ANY OTHER SERVICES PROVIDED BY DECKDROP TO EVALUATOR.
    deckdrop.io · checked Aug 2, 2026
  13. Our liability is limited to the engagement fee paid.
    agentshield.win · checked Aug 1, 2026
  14. We carry professional liability insurance.
    agentshield.win · checked Aug 1, 2026
  15. Limitation of liability. To the maximum extent permitted by law, Free AI Humanizer and its operator are not liable for indirect or consequential damages arising from your use of the Service.
    freeaihumanizer.online · checked Aug 3, 2026
  16. 913.ai UG (haftungsbeschränkt)
    913.ai · checked Aug 5, 2026
  17. The legal responsibility sits with us, not you.
    agentcard.sh · checked Aug 7, 2026
  18. Liability cap 1× fees — below firm floor (2×); escalate to partner
    agentman.ai · checked Aug 8, 2026
  19. By using the extension, you agree to indemnify its creator from any liability.
    chromewebstore.google.com · checked Aug 9, 2026
  20. shall indemnify Linear from all claims and losses in connection therewith.
    linear.app · checked Aug 13, 2026
  21. Stripe and its Affiliates will not be liable for any claim made by a Data Subject arising from or related to Stripe’s or any of its Affiliates’ acts or omissions
    stripe.com · checked Aug 14, 2026
  22. ProofChain gives every agent a cryptographically verifiable identity and a tamper-evident audit trail.
    proofchain.us · checked Aug 14, 2026
  23. Tamper-evident. Privacy-preserving. A forensic chain that regulators and auditors can verify without seeing your secrets.
    proofchain.us · checked Aug 14, 2026