Cross-Organizational Agent Trust in 30 Seconds

Kaiser Permanente’s AI assistant schedules a specialist referral. The specialist is at Stanford Health—an external provider.

The problem: How does Stanford’s scheduling system trust that Kaiser’s agent is authorized to book on behalf of patient John Smith, with coverage verified, for this specific condition?

Today: fax machines, phone calls, manual verification. Three to five business days.

Why OAuth Fails Here

OAuth was designed for “user authorizes app to access their data.” It proves identity. It doesn’t carry workflow context.

When Stanford receives an OAuth token from Kaiser, it knows the request comes from Kaiser. But it doesn’t know:

• Which patient is this for?
• Was coverage verified?
• Who approved the referral?
• What constraints apply?

To answer these questions, Stanford would need to call Kaiser’s API—adding latency, requiring uptime dependency, and trusting Kaiser’s current state rather than cryptographic proof.

OAuth tokens do not prove authorization history.

The Capability Chain Approach

With Proof of Continuity, the capability chain carries the authorization context across organizational boundaries:

BLOCK 0 — Kaiser Gateway
(signed by Kaiser root key)
├── patient_id: "john_smith_mrn_12345"
├── referral_type: "cardiology_consult"
├── coverage_verified: true
├── approved_by: "dr_chen_npi_987654"
└── designated_executor: kaiser_referral_agent
         │
         ▼
BLOCK 1 — Kaiser Referral Agent
├── constraint: provider IN ["stanford", "ucsf"]
├── constraint: appointment_within_days ≤ 14
└── designated_executor: stanford_scheduling_agent

Stanford’s verification checklist:

• Chain signed by known Kaiser root key? ✓
• Referral agent is designated executor? ✓
• Stanford scheduling agent is next designated executor? ✓
• All constraints satisfied? ✓

No API call to Kaiser needed. Self-contained proof.

The chain IS the proof. Stanford verifies cryptographically—no network call to Kaiser required:

1. Signatures trace to Kaiser’s published root key
2. Each delegation is properly signed by its predecessor
3. Constraints only attenuated (never expanded)
4. Stanford’s scheduling agent is the designated executor

Why This Is Different

Traditional cross-org authorization requires a trust relationship and runtime verification. You’re trusting that Kaiser’s system is up, that it hasn’t been compromised, and that its current state matches what it told you.

Proof of Continuity requires only the chain. The authorization is self-contained. Stanford can verify it offline, in an air-gapped environment, years from now.

The 30-Second Promise

With capability chains:

1. Patient requests referral (2 sec)
2. Kaiser agent creates capability chain (1 sec)
3. Chain transmitted to Stanford (1 sec)
4. Stanford verifies chain cryptographically (50ms)
5. Appointment booked (25 sec)

Total: 30 seconds. No faxes. No phone calls. No waiting.

And if Stanford’s system is compromised? The chain only authorizes THIS referral for THIS patient for THIS appointment window. Blast radius: one appointment.

The Interoperability Unlock

Healthcare interoperability has been “five years away” for twenty years. The technical blocker isn’t standards—HL7 FHIR exists. The blocker is trust across organizational boundaries.

Every integration today requires:

• Legal agreements
• API key management
• Credential rotation
• Incident response coordination

With Proof of Continuity, the trust is in the chain. Organizations publish their root keys. Agents carry self-contained authorization. The integration surface shrinks to “can you verify Ed25519 signatures?”

Beyond Healthcare

The cross-org pattern applies anywhere agents need to act across trust boundaries:

Supply Chain: A procurement agent at Company A authorizes a purchase. The supplier’s fulfillment agent at Company B needs to verify the authorization and constraints (quantity limits, approved SKUs, budget caps).

Legal: A paralegal agent at Law Firm A requests documents from Opposing Counsel B. The receiving system needs to verify the request is part of legitimate discovery with appropriate scope limitations.

Financial Services: A client’s portfolio agent delegates trade execution to a broker’s agent. The broker needs cryptographic proof of authorization with position limits.

In each case:

• No shared identity provider
• No runtime API calls between organizations
• Self-verifying authorization that travels with the request
• Constraints that only narrow, never expand

Trust Federation

Capability chains are self-verifying—you can validate signatures without calling back to the issuer. But organizations still need to establish which issuers they trust.

Stanford still needs to decide: which organizations’ root keys do we accept? This requires:

• Key discovery: How does Stanford learn Kaiser’s root public key?
• Trust policy: Which organizations are trusted partners?
• Revocation: How do we stop trusting a compromised key?

These are federation and governance problems, not cryptographic ones. Today this means contractual relationships, allowlists, or industry directories. Tomorrow it might mean verifiable credentials or decentralized PKI.

Once trust is established, capability chains make authorization verifiable and constrained across organizational boundaries.

The Same Security Model

Whether it’s agents delegating within one organization or a healthcare agent crossing organizational boundaries, the security model is identical:

1. Authority is delegated through cryptographic chains
2. Each delegation can only narrow permissions
3. The designated executor must prove identity via signature
4. Constraints are enforced at the execution gateway

The difference is scope, not architecture. Single-org deployments verify against one root key. Cross-org deployments verify against published root keys from known partners.

This is part of a series on AI agent security. See Proof of Continuity for the technical foundations.