# Under what conditions must an instance refuse to complete a trust-anchor handshake when the peer's certificate chain validates but its delegation depth exceeds the local federation policy

**Date of Record:** 2026 November 8

**Scope:** Applies to cross-organization agent federation where trust is established via delegated signing keys (X.509-style path or equivalent capability chains) and where each federation node enforces a local maximum delegation depth. Does not apply to flat trust models (single shared root, no re-delegation) or to purely symmetric-key peer authentication where no delegation chain exists.

## Core Distinction

Certificate-chain *validity* and delegation-chain *admissibility* are independent predicates. A chain can be cryptographically valid end-to-end — every signature verifies, every issuer constraint is satisfied, every validity window contains the current time — while still being inadmissible under the receiving organization's federation policy because the number of intermediate delegations exceeds a locally configured bound. The boundary failure occurs when an implementation collapses these two predicates into one, treating "signature verifies to a trusted anchor" as sufficient to admit the peer.

The non-obvious part: the failure is silent in the happy path. A peer whose chain is short works indefinitely. The defect only surfaces the first time a legitimate partner re-delegates through an intermediate broker — a topology that becomes common precisely as federations grow. At that moment a node either (a) admits a chain deeper than policy permits, quietly widening its trust surface, or (b) rejects a valid partner and reports a generic "untrusted peer" error that misdirects the incident response toward key material rather than policy.

## What Was Observed

During a federation rollout between three organizations, Org A's agent gateway accepted a delegation chain from Org C that traversed two intermediate brokers (A→B→C plus a per-session ephemeral key issued by C). The chain validated cleanly: five signatures, all anchors resolved to the shared federation root. Org A's policy document specified a maximum delegation depth of 2 (root → org anchor → leaf). The observed chain had depth 4.

The gateway's validation routine called a standard path-validation library, which returns success on a valid chain and does not expose the number of intermediate CA certificates as a first-class result. The depth check had been written against a *different* code path — the one used for locally-issued credentials — and was never invoked for inbound federated handshakes. The two code paths had diverged during a refactor three months earlier.

The consequence was not immediate compromise but an unbounded trust surface: any holder of a valid Org C leaf, including ephemeral session keys minted by a compromised broker, could present to Org A. The depth bound existed precisely to cap the blast radius of a compromised intermediate; with the check bypassed, a single compromised broker at depth 3 conferred admission rights that policy intended to withhold.

Detection came from an unrelated audit comparing the *declared* policy depth against the *observed* chain depths in the handshake logs. The logs recorded chain length but not the policy decision, so the mismatch was only visible by cross-referencing two data sources.

## Condition of Validity

The refusal-to-admit decision is correct if and only if all of the following hold:

1. The peer presents a chain that terminates at a configured trust anchor (validity predicate satisfied).
2. The number of intermediate delegation certificates — excluding the anchor and the leaf — exceeds the local `max_delegation_depth`.
3. The local policy is marked `enforce_depth = true` for the peer's federation realm. (Some realms are explicitly configured as depth-exempt for legacy interoperability; for those, the check must be skipped deliberately and logged as an exemption, not silently omitted.)
4. The chain has not been pre-authorized by an out-of-band federation agreement that names the specific intermediate brokers and their permitted depths.

If condition 3 or 4 fails, admission is permitted and the depth count is recorded for audit but does not gate the handshake. The distinction between "policy forbids" and "policy exempts" must be explicit in the decision record; conflating them is the same class of error as conflating validity with admissibility.

## Decision Boundary

The boundary is between *rejecting the peer* and *rejecting the chain*. These are not the same operation and must not share an error path.

- **Reject the peer** when the anchor does not resolve or a signature fails. The peer is untrusted; no further negotiation is meaningful.
- **Reject the chain** when the anchor resolves and signatures verify but depth exceeds policy. The peer is *identified* and *trusted at the anchor level*; only this particular delegation path is inadmissible. The correct response is to negotiate an alternate path (direct anchor presentation, or a shallower re-delegation) before failing the handshake.

Collapsing these into a single "handshake failed" outcome destroys the information the peer needs to recover and the information the operator needs to diagnose. A depth rejection should carry the observed depth, the policy limit, and the offending intermediate's subject — never the raw chain, which may leak topology.

A second boundary: depth is counted on *intermediate CA certificates only*. Leaf credentials and the anchor are not counted. Off-by-one errors here are the most common source of false rejections after the check is finally wired in, and they manifest as legitimate partners failing at exactly the policy limit.

## Operational Effect

When the check is correctly enforced, the operational signature is a class of handshake rejections that are *recoverable*: the peer retries with a shallower path or escalates to its federation operator, and the incident closes without key rotation. When the check is absent, the signature is the opposite — no rejections at all, and a trust surface that grows with federation topology. The absence of depth-rejection events in the logs is itself a signal worth alerting on for any realm where deep delegation is expected.

The remediation pattern that held: expose delegation depth as a first-class field in the validation result, record the policy decision (admit / reject-chain / exempt) alongside every handshake, and assert in CI that the depth-check code path is reachable from the inbound federated handshake entry point. The last item is the one that would have caught the original divergence.

```python
class DelegationDepthExceeded(RuntimeError):
    """Raised when a cryptographically valid chain exceeds local federation policy depth.

    Distinct from UntrustedPeerError: the peer's anchor resolved and all
    signatures verified. Only this delegation path is inadmissible.
    """

    def __init__(self, observed_depth: int, policy_limit: int, offending_subject: str):
        self.observed_depth = observed_depth
        self.policy_limit = policy_limit
        self.offending_subject = offending_subject
        super().__init__(
            f"delegation depth {observed_depth} exceeds policy limit {policy_limit} "
            f"at intermediate '{offending_subject}'"
        )


def admit_federated_peer(chain, policy) -> bool:
    """Return True if the peer may be admitted under local federation policy.

    Precondition: chain has already passed cryptographic path validation
    against a configured trust anchor. This function decides *admissibility*,
    not *validity*.
    """
    if not chain.anchor_resolved:
        # Not a depth question; the peer is simply untrusted.
        raise UntrustedPeerError("anchor did not resolve to a configured trust anchor")

    intermediates = [c for c in chain.certificates if c.is_ca and not c.is_anchor]
    observed_depth = len(intermediates)

    if not policy.enforce_depth:
        # Explicit exemption for legacy realms; record, do not gate.
        chain.record_decision("exempt", observed_depth)
        return True

    if observed_depth > policy.max_delegation_depth:
        offending = intermediates[policy.max_delegation_depth].subject
        chain.record_decision("reject_chain", observed_depth)
        raise DelegationDepthExceeded(
            observed_depth=observed_depth,
            policy_limit=policy.max_delegation_depth,
            offending_subject=offending,
        )

    chain.record_decision("admit", observed_depth)
    return True
```