AIPS-1 is a common framework for the issuance, identification and verification of insurance policies covering AI agent activity.
Five core properties. Three tiers. Machine-verifiable in real time.
CC0 — no rights reservedSibling of AIS-1 · AES-1 · AAS-1 · ARS-1Open for comment until 30 November 2026
The Standard
What is AIPS-1?
Identity tells a counterparty who an agent is. Execution-environment integrity tells the counterparty
where the agent operates. Neither answers the question that determines whether a counterparty can
rationally transact with an autonomous agent:
if something goes wrong, who pays?
AIPS-1 addresses what we call the Illegible Insurance Problem. Cover may exist — the agent
operator may have written a perfectly serviceable policy with a regulated insurer — but the cover is not
legible to machines at the moment of reliance. Today it is a PDF, a paragraph in a master service agreement,
or an opaque number in a vendor portal. None of these is acceptable for a system in which an agent must,
at the moment of accepting a transaction, verify that its counterparty is covered, that coverage extends to the
specific risk in question, that the policy is in force, and that a defined settlement path exists.
ISSUER
Regulated insurer in a Recognised Jurisdiction — authorised under its own insurance regulation, no Kadikoy gating
↓ issues
ARTEFACT
Policy Certificate — structured, signed, on-chain representation of the underlying Policy
↓ satisfies
P1
Issuer
P2
Coverage
P3
Trigger
P4
Settlement
P5
Verifiability
Without AIPS-1
✕
Counterparties cannot verify cover at the moment of reliance — they would have to call the insurer
✕
Coverage scope expressed in free text; ambiguous limits; undefined perils
✕
Claim triggers depend on the Issuer's "reasonable opinion" or undefined external conditions
✕
Settlement path opaque; no defined response timeline or payout instrument
✕
Reinsurance and capital markets cannot price agent-risk pools at standard
With AIPS-1
✓
On-chain Policy Certificate, machine-verifiable in milliseconds against the Issuer's regulatory authority
✓
Coverage scope parseable per the AIPS-1 Coverage Schema — perils, exclusions, limits, deductibles, named insureds
✓
Trigger predicates objectively evaluable against declared Evidence Sources
✓
Settlement path bound to defined endpoint, response timeline, payout instrument, fallback dispute mechanism
✓
Reinsurance and capital-markets transfer can price agent-risk pools against a portable, structured representation
Scope Limitation
AIPS-1 is a representation standard, not a regulatory framework. The underlying Policy
remains governed by the law of the Issuer's jurisdiction. The Certificate is a structured representation
of that Policy designed for machine consumption. Issuance of a Certificate does not create insurance
coverage where none has been written under the underlying Policy.
Core Properties
P1 to P5. One question.
Every AIPS-1 Policy Certificate must satisfy five core properties. They roll up to a single architectural
question: is this policy credibly enforceable? A Certificate that satisfies all five is one whose existence,
scope, trigger conditions, settlement path and current status can be verified by any third party without
trusting the Issuer's word for any of them.
P1
Issuer Authority
Regulated insurer in a Recognised Jurisdiction with verifiable regulator-issued authorisation credential. No self-insurance representations.
P2
Coverage Specificity
Structured Coverage Scope — perils, exclusions, limits, deductibles, named insureds, period of cover. No free-text-only scope.
P3
Trigger Determinism
Trigger conditions expressed as predicates evaluable against declared Evidence Sources. No Issuer-discretionary triggers.
P4
Settlement Path
Defined claims endpoint, response timeline, payout instrument, fallback dispute mechanism. No Issuer-discretionary timelines.
P5
On-Chain Verifiability
Current Status retrievable from public chain data without Issuer disclosure. Status transitions reflected on-chain.
Tiers
Three tiers. By standing-behind, not underwriting quality.
AIPS-1 defines three tiers of Policy Certificate, distinguished by the category of Issuer and the presence
of reinsurance backing. The tier reflects the resilience of the standing-behind, not the quality of the
underwriting — a well-written Tier I policy may provide better cover for a given risk than a poorly-written
Tier III policy. The tier MUST be declared on the Certificate and is verifiable at runtime.
TIER I
Standard Commercial
Licensed commercial insurer in a single Recognised Jurisdiction. Reinsurance discretionary. Routine agent operational risk: professional indemnity, errors & omissions, cyber, general liability.
Commercial
TIER II
Captive and Specialised
Captive insurer, mutual, protected cell, segregated account company or specialised insurance vehicle. Reinsurance typically present. Bespoke risk profiles and novel agent activities. The natural home for Bermuda, Cayman, Vermont, Guernsey and Singapore captive markets.
Captive · specialised
TIER III
Sovereign-Backed
Tier II Issuer with sovereign or quasi-sovereign reinsurance backstop, guarantee fund participation, or equivalent. Reinsurance required. Systemic agent activities — settlement infrastructure, market plumbing, critical-sector deployments.
Sovereign-backed
Recognised Jurisdiction
A Recognised Jurisdiction is one whose Insurance Supervisor is an IAIS member, operates an
ICP-consistent licensing regime, maintains a public register of authorised insurers, and has been admitted
to the AIPS-1 Recognised Jurisdiction List under published governance procedure. Inclusion is procedural,
not substantive endorsement of any particular insurer authorised in that jurisdiction. The List is a
governance artefact maintained openly, amendable by published procedure, and not part of the normative
standard — so it can update without re-issuing the spec.
Verification
One Certificate. Five properties. Milliseconds.
A Relying Party — counterparty agent, exchange, regulated institution, regulator — verifies the Policy
Certificate at the moment of relying on the underlying coverage. The verification flow is designed to be
executable by an autonomous agent without human intervention, composing with AIS-1 identity resolution,
AES-1 enclave checks (where applicable), and AAS-1 record emission.
Reference verification implementations — JavaScript client library, Solidity on-chain verifier, MCP
server-side module — ship in v0.2 along with the did:aips1 DID method specification.
Composition
Part of an open agent infrastructure stack.
AIPS-1 is designed to compose with the rest of the open agent infrastructure stack. An agent's full
runtime attested footprint includes one AIS-1 Bond (identity), optionally one AES-1 Enclave Certificate
(execution environment), one or more AIPS-1 Policy Certificates (insurance), and a stream of AAS-1
records (activity).
AIS-1
Agent identity
Issuer, Policyholder and Insured Agents identified by AIS-1 DIDs
AES-1
Execution environment
Coverage MAY be conditioned on operation within an AES-1 enclave
AAS-1
Records of activity
Class A records admissible as Evidence Sources under P3 Triggers
AIPS-1
Insurance policy
This standard — first open standard for portable agent insurance
Timeline
From working paper to deployed standard.
JUN 2026
AIPS-1 v0.1 published
Specification, P1–P5, three-tier classification, Policy Certificate schema, worked example. Open for public comment.
LIVE
Q3 2026
v0.2 — Tooling and first issuance
did:aips1 DID method, JavaScript / Solidity / MCP reference verifiers, Coverage Schema v1, first Tier I and Tier II Certificate issuances in production.
Q3 2026
Q4 2026
v0.3 — Reinsurance and Tier III
On-chain reinsurance attestation framework, Tier III sovereign-backed framework, syndicated coverage structures, first Tier III Certificate.
Conformance suite, test vectors, reference verifier hardening.
Q2 2027
Q3 2027
v1.0 — Standardisation track
Submission to ISO TC 68 / SC 8 liaison and IAIS observer engagement. Stable schemas.
Q3 2027
Companions
Part of an open agent infrastructure stack.
AIPS-1 is one of an open family of agent infrastructure standards published by Kadikoy Limited under CC0.
Each addresses a distinct subject — identity, execution, audit, remittance, and now insurance.
Feedback is invited from insurance supervisors (IAIS members and national regulators); commercial insurers
and reinsurers; captive insurance markets and managers (Bermuda BMA, Cayman CIMA, Vermont DFR, Guernsey
GFSC, Singapore MAS); insurance brokers and risk advisers; AI agent developers; legal, regulatory and
compliance professionals; standards organisations (ISO TC 68, IAIS, IFRS Foundation); and the wider
AI-agent developer community. The comment period closes 30 November 2026. A revised v0.2
will incorporate substantive feedback.
Open questions for comment:
Should P3 permit Issuer-discretionary triggers at Tier I while retaining the hard determinism requirement at Tier II and Tier III? ·
Should the Recognised Jurisdiction List be governed by AIPS-1's own governance body, or delegated to an existing standards organisation (e.g. IAIS)? ·
Should Trigger predicates be expressed in a defined predicate language (e.g. JSONLogic, Rego) or remain Issuer-defined within a structural envelope? ·
What is the appropriate on-chain home for Policy Certificates — a dedicated registry, the Issuer's own contract space, or a multi-chain identifier scheme? ·
Should reinsurance attestations be on-chain artefacts in their own right (suggesting an AIPS-2 reinsurance standard) or remain fields within the Policy Certificate? ·
How should Certificate Status changes notify subscribed Relying Parties without exposing the Insured Agent's transaction graph?
Open questions for comment:
Should P3 permit Issuer-discretionary triggers at Tier I while retaining the hard determinism requirement at Tier II and Tier III? · Should the Recognised Jurisdiction List be governed by AIPS-1's own governance body, or delegated to an existing standards organisation (e.g. IAIS)? · Should Trigger predicates be expressed in a defined predicate language (e.g. JSONLogic, Rego) or remain Issuer-defined within a structural envelope? · What is the appropriate on-chain home for Policy Certificates — a dedicated registry, the Issuer's own contract space, or a multi-chain identifier scheme? · Should reinsurance attestations be on-chain artefacts in their own right (suggesting an AIPS-2 reinsurance standard) or remain fields within the Policy Certificate? · How should Certificate Status changes notify subscribed Relying Parties without exposing the Insured Agent's transaction graph?