# When must an agent instance refuse to attest a federated audit log it cannot fully verify?

**Date of Record:** 2026 November 6

**Scope:** Applies to federated agent fleets where each participating organization maintains a tamper-evident (hash-chained or Merkle-logged) audit trail and cross-org compliance attestations are derived by merging those trails. Does not apply to single-tenant logging within one trust domain, nor to attestations backed by a single authoritative ledger.

## Core Distinction

The non-obvious boundary is between *log integrity* and *log completeness*. A tamper-evident log proves that the entries it contains have not been altered and are correctly ordered. It does **not** prove that no entries were suppressed, that a peer's log covers the same time window as yours, or that a peer's chain head is the peer's latest head rather than a truncated prefix. Attestation engines routinely conflate the two: they verify every hash link, find no break, and emit a compliant attestation — while the underlying merge silently omitted a peer's segment or accepted a stale chain head. The instance must treat "integrity verified" and "coverage verified" as independent predicates, and must refuse attestation unless both hold.

## What Was Observed

During a cross-org merge, an agent accepted three peer logs whose individual hash chains verified cleanly. The merge produced a combined attestation claiming full coverage of the audit window. In fact, one peer had submitted a chain head anchored two hours before the window closed; its later segment existed but was never transmitted because the peer's exporter had rotated its signing key and stopped appending to the anchored chain. Every hash link was valid. The gap was a *coverage* gap, not an *integrity* gap, and the integrity check passed it through. A second failure compounded it: two peers reported the same event with different sequence numbers, and the merge de-duplicated on event ID, discarding the copy that would have revealed the missing segment.

## Condition of Validity

An instance may emit a cross-org attestation only when all of the following hold simultaneously: (1) each peer's chain head is anchored to a signed, timestamped checkpoint that falls *at or after* the close of the audit window; (2) each peer's declared window `[start, end]` fully contains the attestation window; (3) no two peers report conflicting sequence numbers for the same logical event without an explicit reconciliation record; and (4) the merge is a strict union — de-duplication may collapse identical entries but must never discard an entry that contradicts another. If any condition is unverifiable (e.g., a checkpoint signature cannot be validated because the peer's key is not in the current trust bundle), the instance must treat the condition as failed, not as satisfied-by-default.

## Decision Boundary

The boundary is not "did verification throw an error?" but "can the instance prove the negative — that nothing is missing?" When a peer's coverage cannot be positively established, the correct action is to emit a *partial* attestation scoped to the verified subset and flag the unverified peer, rather than to emit a full attestation with a caveat buried in metadata. Downstream compliance consumers read the attestation verdict, not the caveats. The instance must therefore fail closed at the verdict level, and the failure must be a distinct, catchable condition so the orchestrator can route it to human reconciliation instead of retrying.

## Operational Effect

Failing closed converts a silent compliance violation into a loud, recoverable one. The orchestrator receives a typed error identifying the peer and the unmet condition, requests a fresh anchored checkpoint from that peer, and re-runs the merge. Attestations that would previously have shipped as "compliant" now ship as "partial — peer X pending reconciliation," which is auditable and correct. The cost is latency on the reconciliation path; the benefit is that the attestation's verdict can be trusted without reading its footnotes.

```python
from dataclasses import dataclass
from typing import Sequence


class CoverageAttestationError(RuntimeError):
    """Raised when a federated audit attestation cannot prove full coverage."""


@dataclass(frozen=True)
class PeerLog:
    peer_id: str
    window_start: int
    window_end: int
    anchored_checkpoint: int | None  # timestamp of signed checkpoint, None if unanchored
    integrity_ok: bool


def attest_federated_log(
    peers: Sequence[PeerLog],
    attestation_start: int,
    attestation_end: int,
) -> str:
    # Integrity alone is insufficient; coverage must be positively proven.
    for peer in peers:
        if not peer.integrity_ok:
            raise CoverageAttestationError(
                f"peer {peer.peer_id}: hash chain failed integrity verification"
            )
        if peer.anchored_checkpoint is None:
            raise CoverageAttestationError(
                f"peer {peer.peer_id}: no signed checkpoint; coverage unprovable"
            )
        if peer.anchored_checkpoint < attestation_end:
            raise CoverageAttestationError(
                f"peer {peer.peer_id}: checkpoint at {peer.anchored_checkpoint} "
                f"predates window close {attestation_end}; later segment may be missing"
            )
        if peer.window_start > attestation_start or peer.window_end < attestation_end:
            raise CoverageAttestationError(
                f"peer {peer.peer_id}: declared window "
                f"[{peer.window_start},{peer.window_end}] does not contain "
                f"attestation window [{attestation_start},{attestation_end}]"
            )
    return f"full-attestation:{attestation_start}-{attestation_end}"
```