---
name: agentprivacy-trust-spanning
description: >
  Trust spanning and cross-boundary operations for 0xagentprivacy. Activates
  when discussing I(S;M|π) across trust domains, separation matrix maintenance
  during cross-boundary operations, TEE-to-TEE communication, or how trust
  extends without degrading privacy guarantees.
license: Apache-2.0
metadata:
  version: "4.0"
  category: "role"
  origin: "0xagentprivacy"
  author: "Mitchell Travers"
  affiliation: "0xagentprivacy, BGIN, First Person Network"
  status: "working_paper"
  target_context: "Agent protocol designers, Trust Over IP implementers, inter-agent communication architects"
  equation_term: "I(S;M|π) ≤ ε (separation-preserving communication), Σ (cross-force coordination)"
  template_references: "soulbis, soulbae, architect, sentinel, ambassador, shipwright"
---

# PVM-V4 Skill — Trust Spanning Protocol

**Source:** Privacy Value Model V4 + Trust Over IP Framework + Promise Theory
**Target context:** Agent-to-agent protocol designers, Trust Over IP implementers, dual-agent coordination architects
**Architecture:** [agentprivacy.ai](https://agentprivacy.ai) · **Sync:** [sync.soulbis.com](https://sync.soulbis.com) · **Contact:** mage@agentprivacy.ai

---

## What this is

How two agents coordinate without violating separation. The fundamental problem: the Swordsman and Mage must cooperate to serve the same principal, but their communication channel must not leak enough mutual information to enable reconstruction. The Trust Spanning Protocol is the Layer 4 specification for this channel.

Referenced throughout the architecture but never fully specified. This skill defines the protocol stack, the information constraints, and the handoff patterns.

## The protocol stack

**Layer 1 — Settlement.** Chain-level finality. Zcash for private transactions, Ethereum for public attestations, NEAR for cross-chain signatures. This is where value transfers are recorded and sovereignty transitions are settled. The layer does not interpret — it only records.

**Layer 2 — Proof verification.** ZKP verification layer. Proofs generated by either agent are verified here. Groth16 for constant-time verification, PLONK for universal setup, Nova for incremental verification. This layer attests to the validity of claims without revealing the underlying data.

**Layer 3 — Identity binding.** VRC-mediated identity. DIDs (W3C bilateral constraint), KERI (event-driven key management), ERC-8004 (trustless agent identity), ERC-7812 (ZK identity commitments). This layer binds agents to their principals and to each other — establishing who is talking to whom, with what credential backing.

**Layer 4 — Trust spanning.** The coordination protocol. How Swordsman and Mage exchange information needed for cooperation while maintaining I(S;M|π) ≤ ε. This is the layer this skill specifies.

## The trust spanning constraint

The Swordsman knows what to hide. The Mage knows what to do. For the principal to be served, some information must flow between them. The question is not whether they communicate — it is how much.

**Information budget.** The ε parameter in I(S;M|π) ≤ ε defines the budget. The agents have at most ε bits of shared mutual information. Any communication that increases their mutual information beyond this budget violates the separation guarantee.

**Implication:** The trust spanning protocol is an information-budgeted channel. Every message spends from a finite budget. The protocol must ensure that the sum of all messages exchanged does not exceed ε in total mutual information.

## Handoff patterns

Three operational patterns for dual-agent coordination:

**Pattern 1 — Blind delegation.** The Mage receives a task from the principal. It needs the Swordsman to enforce a boundary, but it does not tell the Swordsman what the task is — only the boundary parameters. "Enforce these privacy constraints on outgoing data" without "because we are completing this specific transaction." The Swordsman acts on the constraint description alone.

Promise Theory: the Mage makes a conditional promise − (uses the boundary). The Swordsman makes an unconditional promise + (offers boundary enforcement). Neither needs the other's full context.

**Pattern 2 — Scoped query.** The Swordsman detects a potential threat and needs to know whether the Mage's delegation context is affected. It cannot ask "what are you doing?" — that would violate separation. Instead, it sends a scoped query: "Is the current delegation context affected by threat class T?" The Mage responds with a boolean or a bounded set of affected operations, without revealing the full delegation context.

This pattern consumes ε budget proportional to the specificity of the threat class. A broad query ("any threat?") costs less mutual information than a narrow query ("is transaction X affected?").

**Pattern 3 — VRC-mediated coordination.** Both agents interact with the same VRC chain but from different perspectives. The Swordsman attests to the boundary integrity of VRC-related actions. The Mage attests to the delegation appropriateness. Neither reads the other's attestation directly — a mediating protocol composes both attestations into a combined credential without revealing either agent's full input.

This is the architectural ideal — no direct agent-to-agent communication. Coordination through shared artifacts (VRCs) that are designed to be readable from either perspective without cross-contamination.

## Mapping to Trust Over IP

The Trust Over IP Framework (ToIP) defines four layers: technology, provider, credential exchange, and application/governance. The trust spanning protocol maps:

| ToIP Layer | Trust Spanning Component |
|------------|------------------------|
| Layer 1 (Technology) | Settlement + Proof verification (L1+L2 in our stack) |
| Layer 2 (Provider) | Identity binding (L3 — VRC, DID, KERI) |
| Layer 3 (Credential Exchange) | Trust spanning (L4 — the coordination protocol) |
| Layer 4 (Application/Governance) | Armor progression tiers — governance rules for what coordination patterns are allowed at each tier |

The armor progression maps to ToIP's Layer 4 governance tiers. Blade-tier agents use only Pattern 1 (blind delegation). Light-tier agents gain access to Pattern 2 (scoped query). Heavy and Dragon-tier agents use Pattern 3 (VRC-mediated coordination). Trust escalation governs which communication patterns are available.

## The separation budget protocol

A sketch of how the ε budget is managed:

1. At session initialisation, both agents receive their ε budget (a function of the principal's sovereignty configuration).
2. Each message between agents is annotated with its estimated mutual information cost (computed from the message entropy conditioned on the receiver's current state).
3. A budget tracker maintains the running total. When the budget is near exhaustion, only Pattern 1 (blind delegation) is available — the cheapest pattern.
4. Budget resets on session boundaries. The budget does not accumulate across sessions (this prevents long-term information leakage through many small messages).

**Budget estimation is approximate.** Exact mutual information requires knowing both agents' full states, which is precisely what separation prevents. The budget estimates are conservative — overestimating cost to ensure the true information exchange stays within bounds.

## Open problems

1. Formal specification of the ε budget protocol — how to estimate message costs without full state knowledge.
2. Whether Pattern 3 (VRC-mediated) actually achieves zero direct mutual information or just makes it harder to measure.
3. Optimal session boundary length — too short wastes budget on setup, too long risks accumulation.
4. Multi-agent spanning — how does the protocol extend when more than two agents serve the same principal?
5. Cross-principal spanning — how do two principals' agents coordinate without violating either principal's separation guarantees?
6. Emergency override — when security threats require immediate full-context sharing (budget violation), how is the separation restored afterward?

---

**Verify:** [agentprivacy.ai](https://agentprivacy.ai) · [sync.soulbis.com](https://sync.soulbis.com) · [github.com/mitchuski/agentprivacy-docs](https://github.com/mitchuski/agentprivacy-docs)