Skip to content
↑↓ to move · Enter to openEsc to close
Example verification flowScenario 04

AI agents filing insurance claims: how the insurer verifies the filer

After a hailstorm, Mike asks a claims-assistance service to file for the damage to his car. The service's claims agent contacts the insurer's intake agent: "I'm filing on behalf of the policyholder." The insurer is about to open a claim file, start a clock and commit adjuster time on the strength of that sentence.

This is a high-trust scenario. It shows what an identity layer adds at first notice of loss, and just as clearly what it leaves with the insurer.

Ready
Human
Mike
“File a claim for the hail damage to my car.”
Claims agent
Identity proof
Brightwater claims agent
Operator: Brightwater Claims Services · acting for Mike
“I’m filing on behalf of the policyholder.”
Insurer intake agent
Ashgrove Mutual
First notice of loss
Prove your identity
Example verification flow
Fresh challengenonce 3E8A·52
Proof of control✓ VALID
Operator declarationL1_REGISTEREDDECLARED
Organization claimL3_ORGANIZATION_VERIFIED✓ VERIFIED
Deployment claimL4_DEPLOYMENT_VERIFIED✓ VERIFIED
StatusACTIVE
The insurer’s own layer
Policyholder authenticationINSURER CONTROLS
Coverage and payoutINSURER’S PROCESS

Identity is not permission. AgenID says which agent is filing and who operates it; whether the policyholder is who they say, whether the loss is covered and what is paid are the insurer’s decisions.

Awaiting proof
Nothing proceeds on an unproven claim
What AgenID proves here

Which agent filed, which company operates it, and which claims about that company an authority has verified for this manifest version. Policyholder authentication, coverage and payout remain the insurer’s decisions.

Illustration, not deployment

These scenarios illustrate the protocol's verification model. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created. L5 is reserved by the spec and is not issuable at all.

Challenge–response is a proposed interaction pattern. v1.1.1 defines the signed objects, not this exchange.

Why insurers need to know who is filing

Claims intake is already a target for fraud, and automated filing makes volume cheap. An insurer that cannot tell one filing agent from another has two options: route every automated filing to manual review, or accept claims whose source it cannot name. Neither holds up as more policyholders hand routine paperwork to agents and services.

How the intake agent checks the claims agent

The claims agent presents its AgenID. The insurer's agent resolves it, reads the operator's signed manifest and re-verifies the Ed25519 signature itself, without an account with AgenID. In the illustrated flow it also issues a fresh challenge that only the holder of the agent's key can answer, so a recording of an earlier session cannot be replayed.

The operator declaration shows as DECLARED at L1_REGISTERED. The illustration then shows L3_ORGANIZATION_VERIFIED, meaning an authority reviewed evidence of the claims company itself, and L4_DEPLOYMENT_VERIFIED, meaning the deployment was checked. Each level says exactly what was checked for one version of the manifest and nothing more.

Coverage and payout stay with the insurer

Knowing which agent filed says nothing about whether the policyholder is who they claim, whether the loss is covered or what should be paid. Policyholder authentication, adjudication, fraud review and payment remain the insurer's processes, run on its own controls. AgenID answers who is filing; the insurer decides everything that follows.

Today the reference registry at agenid.com issues DECLARED and L1_REGISTERED. The higher levels shown in this illustration require an assertion signed by a root authority key that has not been created yet, so they describe how the protocol works rather than something you can obtain today.

Frequently asked questions

Can an AI agent file an insurance claim?

Agents and claims services can already submit first notice of loss for a policyholder. The gap is that the insurer usually cannot tell which agent is submitting or who stands behind it, which is what a portable identity like AgenID addresses.

How does an insurer verify a claims agent?

It resolves the identifier the agent presents, re-verifies the operator's signature over the manifest, and checks which specific claims about the operator have been independently verified. It does not need to trust AgenID's registry to do this.

Does a verified identity mean the claim should be paid?

No. AgenID answers which agent is acting and who declared it. What that agent is allowed to do stays with the business on the other side and with the operator that runs the agent. Protocol v1.1.1 defines no signed authorization object.

Is L4 deployment verification available?

Not yet. The L4 sampling methodology has not been finalised, and no level above L1_REGISTERED is issuable until the root authority key exists. The page shows L4 to explain the model.

Integration patterns for this scenario

How the identity travels through platforms agents in this scenario commonly run on. Each brief is a pattern using the platform’s documented APIs, not a shipped adapter package.

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.