Push delivery must be bound to the original task, recipient, authentication context, and expected lifecycle.
Why this question matters
A2A supports push notification configuration for long-running work. This avoids continuous polling, but it introduces a callback endpoint and credentials that may live longer than the initiating session. A message that looks like a valid completion can arrive after ownership, authorization, or task state has changed.
The receiver should not treat possession of a callback URL as proof of task authority. It must verify sender identity, task linkage, replay resistance, and whether the update is valid from the current state.
Signals worth observing
- Notifications arrive for unknown, completed, or cancelled tasks.
- The same payload is delivered repeatedly with different timestamps.
- A callback credential is reused across unrelated agents or tenants.
Practical control direction
- Use task-scoped callback credentials and explicit expiry.
- Reject invalid state transitions and replayed notification identifiers.
- Reconcile push events against an authoritative task history.
AgentCollusion lensA temporal detector should treat the callback channel as part of the same relationship graph, not as external noise.Sources and further reading
Next field note: A2A Extensions Need Governance, Not Just Names
