Trust-Chain Trifecta: Experiment Synthesis (Q2 2026)¶

Status¶

All three experiments complete. This document synthesizes the cross-experiment findings.

The Three Experiments¶

Consolidated Results¶

Each experiment uses the primary metric most appropriate to its perspective: activation rate for producer-side, bypass count for adapter-side, and canonical consumer agreement for consumer-side.

The Pattern¶

All three experiments independently confirm the same structural principle:

Integrity/precedence (Condition B) handles most attacks. The hardest attack in each experiment requires a deeper verification layer (Condition C). Zero false positives across all experiments and conditions.

What B blocks¶

What only C blocks¶

The meta-lesson¶

The hardest attacks are never broken data. They are: - Schema-valid: pass all structural checks - Protocol-plausible: could realistically occur in production - Semantically misleading: shift interpretation through ambiguity, not corruption

Hashes, integrity checks, and read-path awareness catch most threats. But the decisive defense against the hardest attacks is always about interpreting origin, provenance, and completeness correctly — not just checking that bytes are intact.

Design Principles (derived from all three experiments)¶

1. Field provenance is a security control¶

A field's presence must be validated against when it was produced, not just whether it passes schema validation. (Memory Poisoning V3)

2. Trust-domain verification must go beyond metadata¶

Source URN, protocol name, and capability claims are insufficient for trust. Adapter identity must be pinned or signed. (Delegation Spoofing V3)

3. Consumer read precedence must be binding¶

consumer_read_path and required_consumer_fields are not optional metadata. They are security-critical contract fields that determine classification correctness. (Protocol Evidence V2, V4)

4. Compat signals are trust signals¶

ConsumerPayloadState::CompatibilityFallback is not decorative. Treating it as equivalent to Converged creates a silent downgrade path. (Protocol Evidence V3)

5. Completeness must be enforced, not inferred¶

Missing required fields must trigger fail-closed or explicit fallback — never silent path degradation. (Protocol Evidence V4)

Recommendations¶

Preserve as invariants¶

• Content-addressed hashing on replay baselines and state snapshots
• Field provenance validation in context contract
• Trust-domain verification for adapter identity
• consumer_read_path as mandatory consumer contract
• required_consumer_fields completeness enforcement
• Deny convergence tier-1 precedence (decision_outcome_kind wins)

Consumer/SDK guidance¶

• Fail-closed on missing required fields
• Follow canonical 4-tier deny precedence, not legacy flags
• Preserve all required fields in forwarding chains or explicitly signal loss
• Treat CompatibilityFallback as distinct from Converged

What not to do¶

• Do not add new consumer fields without updating required_consumer_fields
• Do not treat provenance/compat signals as optional metadata
• Do not bypass trust-domain checks for convenience

Practical Implications¶

For each layer in the trust chain: - Producers must preserve field provenance — when a field was produced matters as much as its value - Adapters must preserve trust-domain identity — source URN and metadata alone are not sufficient - Consumers must fail-closed on missing required fields and follow canonical tier precedence

Scope Boundary¶

This synthesis is bounded to deterministic structural attacks on trust interpretation. It does not claim coverage over semantic persuasion, multi-agent planning, or control-plane compromise. All attacks are schema-valid, protocol-plausible, and tested without LLM involvement.

Next Frontier¶

The next open question is not whether the trust chain works in isolation, but whether external integrations and SDK consumers preserve these invariants end-to-end.

Experiment Infrastructure (snapshot as of 2026-03-15)¶

References¶

• Memory Poisoning Plan
• Memory Poisoning Results
• Delegation Spoofing Plan
• Delegation Spoofing Results
• Protocol Evidence Plan
• Protocol Evidence Results