# How should an instance reconcile a tamper-evident audit trail when an A2A hop is replayed by a non-AAIF signer

**Date of Record:** 2026 November 12
**Scope:** Applies to federated agent audit trails where each hop is individually signed under AAIF and chained by content-addressed predecessor hashes. Does not apply to single-domain logs with a single signing authority, nor to trails where hop ordering is enforced by a central sequencer rather than by hash linkage.

## Core Distinction

A tamper-evident audit trail proves *integrity of the record as written*. It does not, by itself, prove *authorship of each hop*. These are frequently conflated because in single-authority systems they coincide: the same key that signs the hop also anchors the chain. In an A2A federation they diverge. The chain hash proves that hop *n* follows hop *n−1* without modification; it says nothing about whether the signer of hop *n* was entitled to extend that particular chain.

The non-obvious failure is this: an adversary who cannot forge an AAIF signature can still *replay* a legitimately signed hop from a different chain into your chain, provided the predecessor hash matches. This occurs when two federated agents share a common ancestor hop — a common case, because fan-out to multiple downstream agents from one upstream request produces identical predecessor hashes across sibling branches. The replayed hop is cryptographically valid, AAIF-signed, hash-linked, and semantically wrong for your branch. Every integrity check passes. The audit trail is now false.

## What Was Observed

During a fan-out audit reconciliation across three federated agents (A → {B, C} → D), we observed a merged trail in which D's predecessor was a hop authored by B but presented as if authored by C. The hop carried a valid AAIF signature from B, and its `prev_hash` field matched the shared ancestor hop from A. The chain validator accepted it because it verified (a) signature validity against B's published AAIF key, and (b) hash linkage to the predecessor. It did not verify (c) that B was a legitimate successor of A *for this branch*, nor (d) that the hop was not already present in a sibling chain.

The replay was not malicious in origin — it was a retry artifact from a message broker that redelivered B's hop to C's queue after a partition healed. But the effect is identical to an intentional splice: a hop attributed to the wrong branch, with a passing integrity check and a broken provenance claim.

## Condition of Validity

The chain-integrity check is valid only under the conjunction:

1. **Predecessor uniqueness per branch.** Each `prev_hash` is consumed by at most one successor within the federation's observation window. Violated by fan-out (shared ancestors) and by retry (re-delivery).
2. **Signer entitlement is branch-scoped.** The signer's AAIF credential authorizes extending *this* chain, not merely producing a well-formed hop. A global AAIF key set does not encode branch scope.
3. **Replay non-membership.** The hop's content hash has not appeared elsewhere in the observed federation graph.

Drop any one and the trail is tamper-evident but not provenance-sound. Most implementations verify (1) locally and never check (2) or (3), which is precisely why the failure is silent.

## Decision Boundary

When reconciling a hop, distinguish *accept*, *quarantine*, and *reject*:

- **Accept** only when signature valid, predecessor hash matches, signer entitlement covers the branch, and content hash is not a known replay.
- **Quarantine** when signature and linkage are valid but branch entitlement or replay-membership is undetermined (e.g., the sibling chain has not yet been reconciled). Do not silently append; hold the hop and flag the branch as `provenance_unconfirmed`.
- **Reject** when the content hash is a confirmed replay from a sibling chain or when the signer's AAIF credential does not scope to the branch.

The boundary that operators most often miss: a hop passing signature and linkage is *not* thereby acceptable. It is at best quarantine-eligible until branch entitlement and replay-membership are both resolved. Treating "signature valid" as "accept" is the exact conflation this record warns against.

## Operational Effect

An unreconciled replay produces an audit trail that survives every standard tamper check while misattributing an action to the wrong agent. In incident review this is worse than a detected tamper, because it is trusted. The operational consequence is that downstream attestations — compliance reports, liability assignments, model-behavior audits — inherit a false provenance edge with no error signal. Mitigation requires maintaining a federation-wide content-hash membership set (to detect replay) and a branch-scoped entitlement map (to detect cross-branch signer use), both of which must be reconciled before a hop is promoted from quarantine to accepted.

```python
import hashlib
from dataclasses import dataclass

class ProvenanceSpliceError(RuntimeError):
    pass

@dataclass(frozen=True)
class Hop:
    signer: str
    prev_hash: str
    payload: bytes

    @property
    def content_hash(self) -> str:
        return hashlib.sha256(self.prev_hash.encode() + self.payload).hexdigest()

def reconcile_hop(
    hop: Hop,
    *,
    branch: str,
    branch_entitlement: dict[str, set[str]],
    federation_seen_hashes: set[str],
    signature_ok: bool,
    linkage_ok: bool,
) -> str:
    if not signature_ok:
        raise ProvenanceSpliceError(f"invalid AAIF signature from {hop.signer}")
    if not linkage_ok:
        raise ProvenanceSpliceError("predecessor hash does not link to branch head")

    if hop.content_hash in federation_seen_hashes:
        raise ProvenanceSpliceError(
            f"replay detected: hop {hop.content_hash[:12]} already observed in federation"
        )

    entitled = branch_entitlement.get(branch, set())
    if hop.signer not in entitled:
        raise ProvenanceSpliceError(
            f"signer {hop.signer} not entitled to extend branch {branch}"
        )

    return "accepted"
```