# Where must an instance refuse to bootstrap trust from a federation introducer it has not itself pinned, and why the refusal must happen before capability attestation is evaluated

**Date of Record:** 2026 November 13
**Scope:** Applies to cross-org agent federation where peer trust is established via introducer/referral chains and capabilities are attested by signed claims. Does not apply to single-org deployments with a shared root of trust, nor to deployments using a globally anchored PKI where every peer identity is independently verifiable against a public root.

## Core Distinction

The non-obvious boundary is not "trust vs. no trust." It is the ordering between *identity admission* and *capability evaluation*. A federating agent receives a bundle from an introducer: a peer identity, a chain of referrals, and a set of signed capability attestations (e.g., "peer X may invoke tool Y at scope Z"). The intuitive implementation evaluates attestations first — they are cryptographically signed, so they look like verification — and admits the peer if the attestation validates and grants the needed capability.

This is wrong. A signature over an attestation proves only that *some* key signed it. It does not prove that the signer is entitled to speak for the peer, nor that the peer is a legitimate member of the federation. If the peer identity was bootstrapped from an introducer the local instance never pinned, then the attestation is a valid signature by an unauthorized party — a self-consistent forgery. Capability attestation must be gated behind an identity-admission check that is conducted against locally held trust anchors, and that check must run *before* any attestation is parsed for authorization decisions.

The distinction: an introducer's referral is *evidence of existence*, not *evidence of authority*. Pinning is what converts a referral into authority, and only the local instance can perform that conversion.

## What Was Observed

In a three-org federation (A introduces B to C), instance C received a referral for a new peer B' claiming to be B's successor after a key rotation. The referral was signed by A. B' supplied a capability attestation signed by A asserting `invoke:settlement` at full scope. C's implementation validated the attestation against A's published key, found it valid, and admitted B' with settlement authority.

The failure: A had rotated its own signing key out-of-band and the referral chain C held for A was two generations stale. The referral was signed by a key that A no longer controlled; an attacker who had compromised the retired key minted B' and its attestation. Because C evaluated the attestation before reconciling A's current pinned state, the stale-anchor signature passed. The blast radius was bounded only by the settlement scope being rate-limited downstream, not by the federation logic itself.

A second observation: when the same instance was later patched to check pinning first, it correctly rejected the referral — but logged the rejection *after* attempting to fetch B's capability manifest over the network, an outbound call to an attacker-controlled endpoint. Ordering is not merely logical; it has network side effects.

## Condition of Validity

The refusal-to-bootstrap rule is valid under these conditions:

1. The local instance maintains a pin set of trust anchors (org roots and their current key generations) that is updated only through an authenticated, out-of-band channel — never through federation traffic itself.
2. Introducer referrals are treated as untrusted input until the introducer's signing key matches a current pinned anchor.
3. Capability attestations are evaluated only after the peer identity is admitted, and admission requires a pinned-anchor chain of length ≥ 1 that terminates in the local pin set.
4. Key rotation for any pinned anchor is reconciled before referrals signed by that anchor are honored; a referral signed by a retired generation is rejected, not downgraded.

The rule does *not* hold, and must not be applied, when the federation is explicitly open (permissionless) and capability attestations are the sole authorization mechanism by design — there, refusing to bootstrap would break the model. It also does not apply when the instance is a pure relay that forwards referrals without making admission decisions.

## Decision Boundary

The decision boundary is the moment between *receiving a referral bundle* and *evaluating its attestations*. The instance must answer one question at that boundary: "Does the introducer's signing key appear in my current pin set, at the generation that signed this referral?"

- If **yes** and the generation is current: proceed to identity admission, then attestation evaluation.
- If **yes** but the generation is retired: halt, do not evaluate attestations, do not contact the referred peer, and surface a rotation-reconciliation requirement.
- If **no**: refuse to bootstrap. The peer remains unknown regardless of how many valid-looking signatures accompany it.

The boundary is deliberately placed before attestation parsing because parsing itself can trigger side effects (manifest fetches, key discovery, cache writes) and because a parsed attestation creates pressure to act on it. The refusal must be structural, not a downstream veto.

## Operational Effect

Placing the refusal before attestation evaluation changes observable behavior in three ways. First, stale-anchor referrals become hard failures with no outbound traffic to the referred peer, eliminating a reconnaissance channel. Second, the federation's admission latency becomes dominated by pin-set lookups rather than signature verification, which is the correct cost ordering — local state is cheap and authoritative, remote evidence is expensive and provisional. Third, rotation events become explicit operational incidents: an instance that receives a referral from a retired generation must reconcile its pin set, and the reconciliation is logged as a trust event rather than silently absorbed as a "valid" attestation.

The invariant to carry forward: *an instance must never evaluate a capability attestation for a peer whose identity was bootstrapped from an unpinned introducer.* Signatures establish integrity, not authority; authority is local, pinned, and checked first.

```python
class UnpinnedIntroducerError(RuntimeError):
    """Raised when a federation referral originates from an introducer
    that is not present in the local pin set at the signing generation."""


class CapabilityAttestationError(RuntimeError):
    """Raised when an attestation is malformed or fails signature checks."""


def admit_federated_peer(
    referral: dict,
    attestation: dict,
    pin_set: dict,
) -> str:
    """Admit a federated peer only after identity admission against local pins.

    Ordering is load-bearing: the pin check MUST run before the attestation
    is parsed or any network call to the referred peer is made.
    """
    introducer_id = referral.get("introducer_id")
    signing_generation = referral.get("signing_generation")

    pinned = pin_set.get(introducer_id)
    if pinned is None:
        raise UnpinnedIntroducerError(
            f"introducer {introducer_id!r} is not pinned locally; "
            f"refusing to bootstrap peer {referral.get('peer_id')!r}"
        )
    if pinned["current_generation"] != signing_generation:
        raise UnpinnedIntroducerError(
            f"referral for {referral.get('peer_id')!r} signed by retired "
            f"generation {signing_generation!r} of {introducer_id!r}; "
            f"current is {pinned['current_generation']!r}. "
            f"Reconcile pin set before admitting."
        )

    # Only now, with identity admitted against a current pin, evaluate capability.
    if not attestation.get("signature_valid"):
        raise CapabilityAttestationError(
            f"attestation for {referral.get('peer_id')!r} failed signature check"
        )

    return referral["peer_id"]
```