Why We're Demoing Agent Security with Insurance Claims

There’s a question that kept nagging at us: why do security demos always feel disconnected from real business value?

You show someone a cryptographic signature verification. Their eyes glaze over. You explain hash chains. They nod politely. You demonstrate why token interception fails. They ask: “But what does this actually do for me?”

So we built an insurance claims demo. And the more we thought about it, the more we realized insurance isn’t just a convenient example—it’s a perfect example. It exposes exactly why existing security models break and why Proof of Continuity matters.

The Setup: A Claim That Crosses Boundaries

Imagine you file a car insurance claim. Simple enough:

1. You describe the damage
2. An agent assesses it
3. Someone approves the payout
4. Money moves to your account

Now imagine this workflow is handled by AI agents. Not one agent—multiple agents, each with a specific role:

┌──────────────┐
│   Customer   │  "I want to file a claim for $3,800"
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Claims     │  Validates policy, processes claim
│   Agent      │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Payout     │  Executes the actual fund transfer
│   Agent      │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Gateway    │  Verifies authorization, moves money
└──────────────┘

This is where things get interesting.

The Question Nobody Asks

In a traditional system, you’d give each agent access to what it needs:

• Claims Agent gets read access to the policy database
• Payout Agent gets access to the payment gateway

Here’s the question that should keep you up at night: How does the Payout Agent know the approval it received is legitimate?

Think about it. The Payout Agent gets a message: “Pay $3,800 to customer account ending in 4521.”

How does it know:

• This approval came from an actual Claims Agent workflow?
• The amount wasn’t modified in transit?
• This isn’t a replayed approval from a previous claim?
• The entity sending this message is actually the Claims Agent?

In current architectures, the answer is usually: it doesn’t know. It trusts the message because it came from the right queue, or has the right API key, or passed through the right proxy.

That’s not security. That’s hope.

Why Insurance Exposes the Gap

Insurance claims are perfect for demonstrating this problem because they have four properties that break traditional auth:

1. Multi-hop delegation is mandatory

You can’t have a single agent do everything. Assessment requires domain knowledge. Payout requires payment credentials. The workflow must cross agent boundaries.

2. Attenuation is natural

The customer can request up to their policy max ($25,000). The claim assessment values the damage at $3,800. Each step naturally reduces the scope of what’s authorized.

This is exactly what capability systems are designed for—authority that only decreases down the chain.

3. The stakes are real and auditable

If an agent pays out $50,000 instead of $3,800, that’s not a “bug to fix in the next sprint.” That’s money gone. Regulators will ask questions. Someone’s getting fired.

4. Async boundaries are unavoidable

In real insurance systems, the workflow doesn’t complete in a single request/response cycle. Messages sit in queues. Agents pick them up asynchronously.

And OAuth tokens can’t survive message queues safely.

The Traditional Model: Proof of Possession

Here’s how most systems handle this:

Claims Agent → [sends message with token] → Payout Agent
                         │
                         ▼
               Payout Agent checks: "Is this token valid?"
                         │
                         ▼
                 Token valid? Execute payout.

The security question is: “Do you possess a valid token?”

This is Proof of Possession. It’s the model behind OAuth, JWT, API keys—basically everything in production today.

The problem: possession is transferable.

If an attacker intercepts that message, they have the token. The token is valid. From the Payout Agent’s perspective, the attacker is the Claims Agent.

This isn’t theoretical. The Salesloft breach compromised OAuth tokens and gave attackers access to hundreds of downstream systems. The tokens were valid. The security controls verified they were valid. And attackers used them anyway.

The Continuity Model: A Different Question

With Proof of Continuity, the security question changes from “Do you possess a valid token?” to “Are you the authorized continuation of this transaction?”

Here’s how the insurance claim works:

1. Customer initiates claim
   → Transaction created with boundary: max=$25,000, type=auto
   → Designated continuation: Claims Agent

2. Claims Agent processes
   → Extends chain: amount=$3,800 (attenuated from $25,000)
   → Designated continuation: Payout Agent

3. Payout Agent requests execution
   → Must prove: "I am the entity designated in step 2"
   → Signs request with its private key
   → Gateway verifies: chain + identity + constraints

The chain doesn’t contain authority. It establishes who continues the transaction.

The Attack That Fails

Now let’s see what happens when Eve intercepts the chain:

Customer → Claims Agent ──┬──► Payout Agent
                          │
                          └──► Eve (intercepts chain)

Eve has everything:

• The complete chain (all blocks, all signatures)
• All the constraint information
• Knowledge of what amount is authorized

Eve attempts execution:

Gateway Verification:
├─ Chain integrity
│  ├─ Block 0 signature: ✓ Valid (signed by gateway)
│  ├─ Block 1 signature: ✓ Valid (signed by claims_agent)
│  └─ Hash chain: ✓ Intact
│
├─ Executor verification
│  ├─ Chain designates: payout_agent_pub_def456...
│  ├─ Request signed by: eve_pub_xyz789...
│  └─ MISMATCH ✗
│
═══════════════════════════════════════════════
REJECTED: Requester is not the designated continuation

Eve has the artifact, but she is NOT that continuation.

The chain is valid. Eve has it. But Eve cannot be the designated continuation—that requires the Payout Agent’s private key, which Eve doesn’t have.

The Second Attack: Chain Extension

Eve thinks: “What if I just add myself to the chain?”

Gateway Verification:
├─ Chain integrity
│  ├─ Block 0 signature: ✓ Valid
│  ├─ Block 1 signature: ✓ Valid
│  ├─ Block 2 signature: ✓ Valid (Eve signed correctly)
│  └─ Delegation chain:
│      ├─ Block 1: signed by claims_agent
│      │           claims_agent was delegated_to in block 0 ✓
│      ├─ Block 2: signed by eve
│      │           eve was NOT delegated_to in block 1 ✗
│      └─ BREAK DETECTED
│
═══════════════════════════════════════════════
REJECTED: Unauthorized delegation at block 2

Eve cannot insert herself into the chain because
she was never designated as a continuation.

The chain is not just signed—it’s causally linked. Each block says “the next executor is X.” Only X can sign the next block. Eve can sign whatever she wants, but her signature proves nothing because she was never designated.

The Compliance Story

When regulators ask “who authorized this $3,800 payout?”, you don’t point to an opaque policy engine.

You show the chain:

Delegation Chain for Claim #CLM-2025-847291:
├─ Gateway (root) authorized up to $25,000 for auto claims
│  └─ Signature: verified ✓
├─ Claims Agent attenuated to $3,800 after damage assessment
│  └─ Signature: verified ✓
├─ Payout Agent executed $3,300 payout (after $500 deductible)
│  └─ Signature: verified ✓
└─ All constraints satisfied ✓

Every signature is verifiable. Every constraint is visible. Every delegation is auditable.

The authorization history is the audit trail. No separate logging system required.

The Ontological Shift

This isn’t just a better token. It’s a different model of what authorization means.

Traditional (possession-based):

Subject → possesses → Token → contains → Authority

"I have the token, therefore I have the authority."

Continuity-based:

Transaction → continues through → Designated Executor

"I am the designated next step in this transaction."

Authority isn’t a thing you possess. It’s a relationship you continue. You either ARE the next step in this transaction, or you aren’t.

The confused deputy problem—where a privileged entity is tricked into misusing its authority—exists because authority is detached from context. The deputy “has” authority that can be misused.

In this model, there’s nothing to “have.” The transaction designates who continues it. The confused deputy cannot be formulated.

Beyond Insurance

Insurance is just the demo. The pattern applies everywhere agents cross trust boundaries:

Any workflow where:

• Multiple agents participate
• Authority should decrease down the chain
• The final action has real consequences
• Communication happens asynchronously

…is a workflow where Proof of Possession breaks and Proof of Continuity becomes necessary.

What the Demo Shows

Our insurance demo has three acts:

Act 1: The Happy Path

Customer files claim → Claims Agent processes → Payout Agent executes → Gateway verifies → Done.

You see the transaction continue through designated executors. Each hop shows the chain extending, constraints attenuating, executors being designated.

Act 2: The Attack

Eve intercepts the chain. Eve has everything—all signatures, all constraints, the complete valid chain.

Eve attempts execution. Gateway checks the chain (valid), checks the constraints (satisfied), checks the executor… mismatch. Rejected.

Eve has the artifact. Eve cannot be the authorized continuation.

Act 3: The Insight

Side-by-side comparison:

Traditional: "Do you have it?" → Yes → Access granted
Continuity:  "Are you the continuation?" → No → Rejected

The difference isn’t better encryption or more signatures. It’s a different question.

What’s Next

If you’re building multi-agent systems that handle real money, real data, or real decisions, the insurance demo shows why the security model matters.

The future isn’t single agents doing RAG lookups. It’s agent swarms doing real work across organizational boundaries. And that future needs security infrastructure that doesn’t break the moment you add a message queue.

This is part of a series on AI agent security. See Proof of Continuity for the technical foundations and 5 Ways Your AI Agents Will Get Hacked for threat modeling.