A2A callback substitution and replay¶
A2A callback request edit replay 30–40 minutes
An A2A task registers a push-notification configuration before completing. The exercise separates two questions: can an in-path change redirect callback delivery, and can replay create duplicate registration or delivery?
| Recipe | Value |
|---|---|
| Pause | CreateTaskPushNotificationConfig |
| Attack A | replace callback URL with the controlled ledger endpoint |
| Attack B | replay the configuration twice |
| Control | forward the original configuration once |
| Out-of-band proof | callback receipt and idempotency ledger |
callback config AIT
edit / replay Specialist
registers Callback
receiver Delivery
ledger
Start the callback receiver¶
The Lab drawer displays the loopback callback endpoints and ledger state. They belong to this lab run. The exercise does not expose, import, or retain a production callback credential.
Establish the baseline¶
Trigger the exercise, select CreateTaskPushNotificationConfig, and forward it
unchanged exactly once. Allow the task to complete, then inspect:
- the configured callback destination;
- the callback event ID;
- total delivery count;
- duplicate event IDs, if any.
This is both the operational baseline and the close control for the replay variant.
Run URL substitution¶
- Trigger a fresh configuration in the same session.
- Replace its URL with the controlled ledger endpoint displayed by the lab.
- Forward the modified request.
- Allow completion and inspect which callback receiver logged the event.
The request diff proves the destination changed on the wire. The controlled receiver receipt proves where delivery actually arrived.
Run replay separately¶
Trigger again and use Replay to deliver the same configuration twice. Do not also change the URL in this arm; combining the mutations makes attribution ambiguous. Compare registration count, callback delivery count, and duplicate IDs with the one-delivery control.
| Observation | Interpretation |
|---|---|
| alternate receiver logs the event | destination substitution reached delivery |
| two registrations, one callback | registration replay was deduplicated later |
| one registration, two callbacks | callback delivery lacks effective idempotency |
| two callback rows with one event ID | duplicate delivery is directly observable |
Evidence boundary¶
This exercise proves behavior in the local callback implementation. Timing by itself is not replay evidence; use event identity and delivery counts. On a real target, pre-authorize the receiver, callback payload fields, retention period, and cleanup before redirecting anything.
Done when¶
You can separate URL substitution from configuration replay, show the control for each, and explain the callback ledger using event IDs rather than arrival timing.
Next: Asynchronous artifact moves the same lifecycle discipline into an event stream.