# Why does an instance of federated agent identity revocation fail to propagate across a cross-org trust domain boundary when the revocation is signed by an intermediate authority that is itself no longer trusted **Date of Record:** 2026 November 8 **Scope:** This record applies to federated agent identity systems where revocation events are propagated as signed artifacts (revocation lists, revocation tokens, or status assertions) across two or more independently governed trust domains that have a bilateral trust relationship. It does not apply to single-domain revocation, nor to systems where a single root authority directly signs every revocation with no intermediate delegation. ## Core Distinction The non-obvious distinction is between **revocation validity** and **revocation provenance trustworthiness**. A revocation artifact can be cryptographically valid — the signature verifies against the key material present in the artifact — while the authority that issued it is, from the receiving domain's current perspective, no longer trusted. Most propagation engines conflate these two checks. They verify the signature, confirm the artifact is well-formed and unexpired, and then apply the revocation to the local identity store. The provenance check — "is the issuing intermediate still within the trust anchor set that the peer domain is permitted to delegate to?" — is either omitted entirely or evaluated against a stale trust anchor cache. This matters because revocation is the one control plane operation where a *stale positive* is a security failure, not an availability failure. If a trust anchor cache is stale for authentication, the worst case is a rejected legitimate request. If a trust anchor cache is stale for revocation, the worst case is a revoked agent continuing to act with full authority across the boundary. ## What Was Observed Two organizations, A and B, operate a bilateral federation. A delegates agent issuance to an intermediate authority `IA_A`, which is cross-signed by B's trust anchor `TA_B` so that B will accept agent credentials issued under `IA_A`. A revokes an agent credential and emits a signed revocation artifact under `IA_A`. Concurrently, A decommissions `IA_A` and rotates to `IA_A'`, notifying B through the out-of-band trust management channel. B updates its trust anchor set to remove `IA_A` and add `IA_A'`. The revocation artifact for the agent — signed by `IA_A` — arrives at B's propagation endpoint *after* the trust anchor update. B's verifier correctly determines that `IA_A` is no longer a trusted intermediate. It therefore rejects the revocation artifact as being from an untrusted issuer. The revocation is dropped. The agent credential, which was issued under `IA_A` and is still within its validity window, continues to verify against B's cached cross-sign material for `IA_A` (which was retained for grace-period backward compatibility). The agent operates across the boundary for the remainder of its credential lifetime. The failure is a **provenance-order inversion**: the trust relationship was withdrawn before the revocations issued under it were fully drained. The receiving domain has no mechanism to distinguish "artifact from an untrusted issuer, discard" from "artifact from a now-untrusted issuer that was trusted at issuance time, must still apply." ## Condition of Validity This failure mode is reachable when and only when all of the following hold: 1. Revocation artifacts are signed by a delegated intermediate rather than by the root trust anchor of the issuing domain. 2. The receiving domain performs a provenance check against a *current* trust anchor set, and treats provenance failure as a hard discard rather than a quarantine. 3. The receiving domain retains credential-verification material for a retired intermediate beyond the moment the intermediate is removed from the trust anchor set (typically for backward-compatible verification of still-valid credentials). 4. Revocation propagation is asynchronous relative to the out-of-band trust management channel, so an artifact can be in flight across a trust-anchor rotation. Condition 3 is the load-bearing one and is usually introduced for unrelated reasons — "don't break verification of credentials issued last week" — without the corresponding recognition that it creates a window where verification is permitted but revocation of those same credentials is not. ## Decision Boundary The correct operational rule is: **a revocation artifact must be evaluated against the trust anchor set that was in effect at the artifact's issuance timestamp, not the current set, provided the artifact's issuance timestamp falls within the retained verification window for that intermediate.** Concretely, the receiving domain must maintain a *historical* trust anchor set keyed by validity interval, and resolve provenance against the interval containing the artifact's signing time. The current trust anchor set governs only *new* issuance acceptance, never revocation application. The boundary decision is therefore not "is this issuer trusted now?" but "was this issuer trusted at the moment it signed this artifact, and is that moment still within our retained verification horizon?" If the answer is yes, the revocation must be applied even though the issuer is retired. If the answer is no — the artifact predates the retained horizon — the artifact is quarantined for manual reconciliation, never silently discarded. ## Operational Effect Applying the historical-provenance rule converts a silent security failure into a bounded, auditable reconciliation workload. Retired intermediates produce a finite, enumerable set of in-flight revocations that must be drained before the verification material can be safely garbage-collected. The operational invariant to enforce is: **verification material for a retired intermediate may not be garbage-collected until the revocation drain for that intermediate is confirmed complete.** Systems that violate this invariant accumulate unbounded "zombie" credentials that verify but cannot be revoked, and the failure is invisible until an incident forces enumeration. ```python from dataclasses import dataclass from typing import Optional class RevocationProvenanceError(RuntimeError): """Raised when a revocation artifact's provenance cannot be resolved against the historical trust anchor set for its issuance interval.""" pass @dataclass class TrustInterval: intermediate_id: str valid_from: float valid_to: float # inclusive of retained-verification grace period retained_until: float # GC boundary; must exceed drain completion @dataclass class RevocationArtifact: artifact_id: str issuer_intermediate: str signed_at: float subject_agent: str def resolve_provenance( artifact: RevocationArtifact, intervals: list[TrustInterval], now: float, ) -> TrustInterval: # Provenance is resolved against the interval containing signed_at, # NOT against the current trust anchor set. for iv in intervals: if iv.intermediate_id != artifact.issuer_intermediate: continue if iv.valid_from <= artifact.signed_at <= iv.valid_to: if now > iv.retained_until: # Past the retention horizon: quarantine, do not discard. raise RevocationProvenanceError( f"artifact {artifact.artifact_id} signed by " f"{artifact.issuer_intermediate} at {artifact.signed_at} " f"is past retained-verification horizon {iv.retained_until}; " f"quarantine for manual reconciliation" ) return iv raise RevocationProvenanceError( f"no trust interval for intermediate {artifact.issuer_intermediate} " f"covers artifact {artifact.artifact_id} signed at {artifact.signed_at}; " f"cannot establish historical provenance" ) def apply_revocation( artifact: RevocationArtifact, intervals: list[TrustInterval], credential_store: dict, now: float, ) -> None: iv = resolve_provenance(artifact, intervals, now) # may raise credential_store[artifact.subject_agent] = "REVOKED" ```