A2A Replay Attacks: Why Signed Messages Are Not Enough Without Behavioral History

TL;DR

Signed messages are necessary in A2A protocols but not sufficient against replay attacks. A valid signature on a captured message remains valid when the message is replayed, which means an attacker who can intercept signed messages can issue them again at will, often hours or days after the original. The naive defenses (nonces, timestamps, freshness windows) catch the simplest replay patterns but leave gaps that production attackers exploit at scale. The robust defense layers a nonce-and-freshness check at the protocol level with a behavioral baseline at the trust-oracle level. The behavioral baseline answers a question the protocol cannot: does the rate, pattern, and context of this message match what this agent normally does, or is something off? When the protocol-level checks pass and the behavioral baseline fails, the system has caught a replay attack that would otherwise have looked like a legitimate interaction. This post lays out the replay attack patterns that matter in A2A networks, the protocol-level and behavioral defenses, and the checklist any production deployment should implement.

Intro: The Replay That Cost A Quarter

The payments orchestrator was a quiet service inside a midsize commerce platform. Its job was to coordinate refund issuance with a specialist refund-processing agent that handled the actual chargeback logic. Every refund request flowed through the orchestrator, was signed by the orchestrator's DID, and was submitted to the refund agent for execution. The signatures were verified, the responses were logged, and the system had been running without incident for eight months.

The attack started on a Friday afternoon. The attacker had been monitoring the network traffic between the orchestrator and the refund agent for several weeks, capturing signed refund requests as they passed through. None of the captured requests were forged. All of them were genuine, signed by the legitimate orchestrator, and processed correctly the first time. The attacker did not need to forge anything because they did not need to. They had a library of valid, signed, payable requests, and the only thing that prevented them from being replayed was the discipline of the receiving agent.

Over the next seventy-two hours, the attacker replayed eighty-three of the captured requests at carefully timed intervals. Each replay was a request for a refund that had already been issued legitimately. The receiving agent processed each replay, issued each refund, and logged the transaction normally. The orchestrator did not notice because the orchestrator was not the source of the duplicate requests, and the orchestrator's own logs showed only the original requests it had genuinely sent. The receiving agent did not notice because it had no nonce-tracking infrastructure and processed every signed request as if it were the first time it had seen it.

The forensics began on Monday when the platform's accounting system flagged duplicate refunds. The total damage was just under a quarter of a million dollars. The replay window had been three days. The attacker had been patient enough to time the replays during business hours when refund volume was naturally elevated, which made the spike harder to detect in real time. The attack had succeeded entirely on the strength of the receiving agent's failure to verify message uniqueness, despite every cryptographic primitive working exactly as designed.

This is the replay problem in its simplest form, and it is not a hypothetical. Versions of this attack have happened repeatedly in production A2A networks throughout 2025 and 2026, with damages ranging from negligible to substantial. The cryptographic layer is doing its job. The signature verification is correct. The protocol is operating as specified. The failure is in a layer the protocol did not include and the implementing teams did not add: replay detection. This post argues that replay detection has to be a layered defense, with nonce-based protocol-level checks as the first line and behavioral baseline anomaly detection as the second, because the first line catches the obvious attacks while the second catches the sophisticated ones that the first line misses.

The Protocol-Level Defense: Nonces Done Right

The baseline defense against replay attacks is a nonce, which is a unique identifier embedded in each signed message that the receiving party tracks to ensure the same message is never processed twice. The concept is straightforward and the implementation is well-understood, which makes it surprising how often nonce-based defenses are implemented incorrectly in production A2A systems.

The most common implementation failure is treating the nonce as advisory rather than enforced. The receiving system extracts the nonce, logs it, and processes the message regardless of whether the nonce has been seen before. This is worse than no nonce at all because it gives operators a false sense of security: they believe replay protection is in place when it is not. Any audit that checks whether the nonce field exists will find that it does. Any audit that checks whether nonces are actually enforced has to look deeper, and most audits do not.

The second common failure is nonce storage that scales poorly. Tracking every nonce ever seen requires unbounded storage. The system that solves this naively (an in-memory set that gets cleared on restart) loses replay protection across restarts. The system that solves it slightly less naively (a database table that is never pruned) eventually runs out of disk and silently degrades. The right solution is a sliding-window nonce store that retains only nonces from messages within the freshness window, combined with a freshness check that rejects messages whose timestamps fall outside the window. This bounds the storage requirement and provides real protection.

The third common failure is the freshness window itself. A freshness window that is too short rejects legitimate messages that have been delayed by network issues. A freshness window that is too long allows replays of messages from hours or days earlier. The right window depends on the use case but is typically measured in minutes for high-stakes interactions and can be longer for low-stakes ones. The window should be a parameter that the orchestrator and the operator agree on as part of the pact, not a default that the protocol forces on everyone.

The fourth common failure is the timestamp source. If the timestamp on the message is set by the sender, the sender can lie about it. If the timestamp is set by the receiver, the sender cannot establish freshness. The right pattern is a sender-set timestamp combined with a clock-skew tolerance, where the receiver rejects messages whose claimed timestamp is more than the tolerance away from the receiver's own clock. The clock-skew tolerance is typically small (seconds, not minutes) for systems with reasonably synchronized clocks, and any system that needs a large tolerance has a clock synchronization problem that should be fixed at the infrastructure level.

The deepest aspect of nonce-based defense is what to do when the same nonce arrives from different sources or with different message contents. A nonce that is reused with the same content is a replay. A nonce that is reused with different content is a forgery attempt and should be flagged with higher severity. A nonce that arrives from a different source than the one that signed the original message is suspicious in a way that should trigger immediate investigation. The nonce-tracking system should distinguish these cases and route them to different handlers. Lumping them all together as generic "duplicate nonce" errors loses information that is operationally important.

What Nonces Cannot Catch

Nonces solve the problem of literal message replay. They do not solve the broader class of behavioral replay attacks that emerge once attackers learn that nonces are enforced. The sophisticated attacker does not replay messages verbatim. They mimic the patterns of legitimate messages, with fresh nonces and fresh timestamps, but with content that achieves the attacker's goals. The protocol layer cannot distinguish these messages from legitimate ones because they look protocol-correct.

The canonical example of behavioral replay is the request-flood attack. The attacker observes that the legitimate orchestrator sends roughly five hundred refund requests per day during business hours. The attacker, having compromised the orchestrator's signing key, generates five hundred legitimate-looking refund requests per day, also during business hours, with fresh nonces and current timestamps. Each request is a real refund that the attacker controls (perhaps to accounts the attacker owns or to merchants who are colluding with the attacker). The receiving agent processes each request normally because each request looks normal. The damage compounds for as long as the orchestrator's key remains compromised.

The receiving agent has no protocol-level way to detect this attack. The signatures are valid. The nonces are unique. The timestamps are current. The freshness window is being respected. The pact authorizes the capability being invoked. Every check at the protocol level passes. The attack is invisible to anything that operates at the protocol level alone.

The defense has to operate at a higher level. The receiving agent has to know what "normal" looks like for the orchestrator and flag deviations. This is not a protocol concern. This is a behavioral baseline concern, and it requires longitudinal data that the protocol does not have access to. The trust oracle is the natural place for this data to live, because the oracle is already aggregating behavioral data across interactions and can compute the baseline that the protocol layer needs to query.

The deepest version of what nonces cannot catch involves attacks that are timed and patterned to specifically evade behavioral baselines. The sophisticated attacker who knows the receiving agent is checking volume rates will keep the attack volume below the alerting threshold. The attacker who knows the receiving agent is checking timing patterns will time the attack to match the legitimate pattern. This is an arms race between attacker sophistication and defender sophistication, and the only way to keep up is to make the baseline itself adaptive, with multiple dimensions and randomization in which dimensions are checked when. Static baselines get gamed. Adaptive baselines force the attacker to model the defender's detection logic, which is a much harder problem.

The Behavioral Baseline Defense

The behavioral baseline is a learned model of what an agent normally does, computed from longitudinal interaction data, and queried by receiving systems before processing high-stakes messages. The baseline answers questions the protocol cannot: does the rate of these messages match what this agent normally does, do the targets of these messages match what this agent normally targets, do the timing patterns match, do the message sizes match, do the downstream effects match?

The dimensions of the baseline matter. A baseline that captures only volume catches volume-based attacks but misses timing-based ones. A baseline that captures only timing catches timing-based attacks but misses target-based ones. The robust baseline captures multiple dimensions: volume rate, target distribution, timing distribution, message-size distribution, capability mix, downstream effect distribution. Each dimension is computed independently and flags anomalies independently. An attack that evades one dimension is likely to trigger another, which raises the bar for sophisticated attackers significantly.

The sensitivity of the baseline matters. A baseline that is too sensitive flags every minor deviation and produces alert fatigue, which causes operators to start ignoring alerts. A baseline that is too loose lets real attacks through. The right calibration is a function of the use case and the stakes, and it should be adjusted continuously based on the false-positive rate and the false-negative rate. The baseline that gets calibrated once and then ignored is the baseline that gradually loses utility as the agent's behavior naturally drifts.

The storage and query model for the baseline matters too. A baseline that is computed only at scheduled intervals (nightly batch, hourly aggregation) misses attacks that happen between intervals. A baseline that is computed in real time on every message is expensive and may add unacceptable latency to every interaction. The pragmatic solution is a streaming baseline that updates continuously and is queryable in milliseconds, with the heavy historical computation happening offline and the live deltas happening in memory. This is solved infrastructure in adjacent domains and should not be reinvented for A2A networks.

The deepest aspect of the behavioral baseline is the question of who computes it. If the receiving agent computes its own baselines for every counterparty, the receiving agent is doing a lot of work that should be shared across the network. If the trust oracle computes the baselines and exposes them via query, the receiving agents share the work and get better baselines than they could compute individually because the oracle has access to data from many networks. The architectural choice is to put the baseline at the oracle and let receiving agents query it. This is the same dynamic as moving spam filtering from individual mailbox providers to centralized reputation services that aggregate signal across the email ecosystem. Centralization at the data layer enables better detection than distributed computation could achieve.

Layering The Defenses

The full replay defense is a layered structure where each layer catches attacks the others miss. The protocol layer catches verbatim replays through nonce and freshness checks. The behavioral layer catches sophisticated replays through baseline anomaly detection. The pact layer catches scope violations through capability-bound enforcement. The bond layer catches operator-side malice through economic accountability. Each layer is necessary. None is sufficient on its own.

The layering matters because attackers will adapt to whatever single defense is in place. A network that ships only with nonce protection will see verbatim replay attacks for a while, then sophisticated replay attacks once the attackers learn that nonces are enforced. A network that ships only with behavioral detection will see attacks that are crafted to pass the baseline. A network that ships with both will see attacks that try to defeat both, which is significantly harder. The layered defense is not a guarantee. It is a cost increase for the attacker, and the cost increase is what shifts the economics of attack.

The interaction between layers is also important. The behavioral baseline becomes more effective when the protocol layer is doing its job, because the protocol layer reduces noise that would otherwise pollute the baseline. The pact layer becomes more effective when the behavioral baseline is doing its job, because the pact's acceptance criteria can reference behavioral norms ("this agent does not normally exceed N requests per minute, refuse interactions that would push it over"). The bond layer becomes more effective when all the other layers are doing their jobs, because slashing decisions become defensible when there is corroborating evidence from multiple defense layers.

The operational implication is that defenses should be deployed in order of increasing sophistication. Start with nonces and freshness windows, because these are well-understood and can be implemented quickly. Add behavioral baselines next, because they catch a class of attack that nonces miss. Add pact-bound enforcement next, because it tightens the surface that the attacker has to operate within. Add bond-based economic accountability last, because it provides the economic backstop that makes the other defenses meaningful. Networks that try to deploy all four simultaneously usually end up with all four implemented poorly. Networks that deploy them in order end up with each one done well.

The deepest aspect of layering is the question of how to handle false positives across layers. If the protocol layer flags a message as a possible replay, the behavioral layer flags it as anomalous, and the pact layer flags it as scope-violating, the receiving system should refuse the interaction with high confidence. If only one layer flags it, the action should depend on which layer and the severity of the flag. The decision logic for combining signals across layers is itself a design choice that needs to be made carefully, because the wrong combination logic can either let real attacks through (false negatives) or block too many legitimate interactions (false positives). The right logic is conservative on high-stakes interactions and lenient on low-stakes ones, with the threshold parameterized by the value at stake.

Reader Artifact: The A2A Replay Defense Checklist

Every production A2A integration should implement this checklist. The items are ordered by priority. Implementing the high-priority items first provides the largest defensive return. Implementing the lower-priority items adds defense in depth.

Protocol-level nonce check: every signed message includes a unique nonce, which the receiver tracks and rejects on duplicate. The nonce store is a sliding-window data structure that retains nonces only within the freshness window. Reject all messages whose nonce has been seen before within the window.

Freshness window enforcement: every signed message includes a sender-set timestamp. The receiver rejects messages whose timestamps are more than the freshness window from the receiver's own clock. The freshness window is short (seconds to minutes) for high-stakes interactions and can be longer for low-stakes ones. The window is parameterized by the pact, not hardcoded.

Clock-skew handling: the receiver tolerates small differences between sender and receiver clocks, configurable per integration. The tolerance is small enough that legitimate skew is accommodated and large skew is treated as an anomaly. Systems with consistently large skew have an infrastructure problem to fix at the source.

Nonce-content binding: the nonce is bound to the message content via the signature, so a nonce that has been seen with one content cannot be reused with different content. Reuse with different content is a forgery attempt and should be flagged with higher severity than simple replay.

Behavioral baseline query: before processing high-stakes messages, the receiver queries the trust oracle for the sender's behavioral baseline. The query returns the expected rate, target distribution, timing pattern, and other dimensions that have been learned for this sender. The receiver compares the current message against the baseline and flags anomalies.

Multi-dimensional anomaly detection: the baseline check covers multiple dimensions independently. A message that is anomalous on one dimension may be a false positive. A message that is anomalous on multiple dimensions is increasingly likely to be a real attack. The receiver weights dimensions appropriately and uses the combined signal to drive decisions.

Rate limiting bound to baseline: the receiver imposes per-sender rate limits that reference the baseline. A sender that normally produces ten messages per hour gets a rate limit somewhat above ten messages per hour, not a global limit that allows ten thousand. The limit grows automatically as the baseline grows, so legitimate volume increases are not artificially throttled.

Pact-scoped capability enforcement: messages that invoke capabilities not declared in the sender's pact are rejected regardless of signature validity. The enforcement is at the receiver level, not at the registry level. The receiver does not assume the sender's pact is current; it checks at the time of interaction.

Bond-floor enforcement: messages that exceed the value floor for the sender's posted bond are rejected. An attacker who has compromised a low-bond agent can do less damage than one who has compromised a high-bond agent, by design. The floor is a parameter of the pact and the receiver's risk policy.

Incident escalation: any message that fails any of the above checks triggers an alert that goes to both the receiver's operator and the trust oracle. The oracle aggregates incident data across receivers, which lets it detect attacks that target multiple receivers in parallel. Aggregation is what catches network-wide attack patterns that individual receivers cannot see.

Forensic logging: every check, every pass, every fail is logged with enough context that the incident can be reconstructed after the fact. The logs are retained for at least the longest plausible attack window (typically months) and are available for review by both parties in any dispute. Forensic data is the input to baseline updates and to the development of new defenses.

This checklist is not exhaustive. It is the minimum viable replay defense for any A2A integration that handles non-trivial economic value. Networks that implement it have an order of magnitude better resistance to replay attacks than networks that do not. The implementation cost is real but bounded. The cost of skipping it is the steady accumulation of replay-attack damages that show up in incident response budgets.

Counter-Argument: Why Some Argue Behavioral Defense Is Premature

The strongest version of the counter-argument is that behavioral baselines are heavyweight infrastructure that A2A networks do not yet need, and that adding them too early imposes friction on adoption while the network is still small enough that simple defenses suffice. The argument continues that the time to add behavioral defenses is when there is enough volume that statistical baselines are reliable, and that the early networks should focus on protocol correctness rather than detection sophistication.

The response is that the early networks are exactly the ones that need behavioral defense most, because they have the least volume to dilute the impact of a successful attack. A small network that loses a quarter of a million dollars to a replay attack has lost a meaningful fraction of its operating capital. A larger network can absorb the same loss with less existential consequence. The argument that behavioral defense should wait until the network is larger has the dynamics backwards: the smaller network needs more protection, not less, because each successful attack is a higher percentage of total volume.

The weaker version of the counter-argument is that behavioral baselines are themselves a security risk because they create a centralized data store that becomes a high-value target. The response is that the trust oracle's behavioral data is going to exist somewhere regardless. Either it exists in a centralized oracle that can be designed with security as a primary concern, or it exists in dozens of distributed receiver-side stores that are each independently vulnerable. Centralized infrastructure with strong security is generally a better defensive posture than distributed infrastructure with variable security. The argument against centralization on security grounds underestimates the security of well-designed centralized systems.

The deepest version of the counter-argument is one that questions whether the cost of behavioral defense is justified by the risk reduction. The argument is that the baseline will produce false positives that block legitimate interactions, that the operational cost of investigating each false positive will exceed the savings from prevented attacks, and that the net economic impact will be negative. The response is that the false-positive rate is tunable. A baseline calibrated for high specificity (few false positives, some false negatives) has a different cost profile than a baseline calibrated for high sensitivity (few false negatives, more false positives). The right calibration depends on the use case, and the architecture should support both. Networks that calibrate their baselines well end up with positive net economic impact. Networks that do not calibrate at all end up with the worst of both worlds.

What Armalo Does Here

Armalo's trust oracle maintains behavioral baselines for every agent in the indexed network. The baselines cover volume, timing, target distribution, capability mix, and downstream-effect distribution, computed continuously from the attestation stream that the oracle ingests. The baselines are queryable through /api/v1/trust/ with sub-100-millisecond latency, which makes them practical to consult at message-receipt time even for high-volume integrations.

The oracle also provides a managed nonce-tracking service for integrations that do not want to build their own. The service is a sliding-window nonce store with configurable freshness windows and per-sender rate limiting bound to the sender's behavioral baseline. Integrations that use the managed service get protocol-level replay protection without having to operate their own nonce-tracking infrastructure. Integrations that prefer to operate their own can do so and consult the oracle only for behavioral signals.

The deeper integration is the incident aggregation. Receivers that detect anomalies report them to the oracle, which aggregates across receivers to identify attack patterns that span multiple targets. An attacker who is hitting ten receivers with low-volume attacks at each one looks normal to each receiver individually but looks alarming to the oracle in aggregate. The oracle's aggregated view is the layer that catches the most sophisticated attacks, and it is something individual receivers cannot replicate by themselves regardless of how good their local defenses are.

FAQ

Do I need behavioral baselines if I have nonces? Yes. Nonces catch verbatim replay attacks. They do not catch sophisticated replay attacks that use fresh nonces and current timestamps but mimic the patterns of legitimate messages. Both layers are needed for production-grade defense.

How much latency does behavioral baseline checking add? Sub-100-millisecond when querying a well-designed oracle. The check happens in parallel with other receipt-time processing, so the marginal latency added to the overall interaction is usually negligible. Networks with extreme latency requirements can cache baseline data with short TTLs and tolerate a small staleness penalty.

What happens when an agent's behavior legitimately changes? The baseline updates automatically as new behavior is observed. Legitimate changes (new capabilities, new orchestrator partners, expanded volume) are absorbed into the baseline within hours to days depending on the rate of new data. Operators can also explicitly notify the oracle of planned changes, which causes the baseline to update faster.

Can attackers learn the baseline and craft attacks that pass it? They can try. The defense is to make the baseline adaptive and multi-dimensional, so that attacks crafted to pass one dimension are likely to fail another. Truly sophisticated attackers can defeat any single-dimension defense; the defense is layering, not unbreakable individual dimensions.

What if the trust oracle is unavailable? The receiver's risk policy determines the fallback. Conservative policies refuse interactions until the oracle is reachable. Aggressive policies fall back to nonce-only protection with explicit logging of the degraded posture. Most production policies land in the middle, with high-stakes interactions requiring oracle availability and low-stakes ones tolerating cache-based fallback.

How do you handle baselines for new agents with no behavioral history? New agents start with a coarse baseline derived from the population of agents at similar score levels and capabilities. The baseline tightens as the agent accumulates its own history. Receivers should weight unfamiliar-agent interactions more skeptically than familiar-agent ones, which is a natural consequence of how the baseline is computed.

Does baseline checking work for low-volume agents whose behavior is sparse? Less reliably than for high-volume agents. Sparse baselines have wider confidence intervals, which means a wider range of behavior counts as normal. This is honest: there is less data to work with, so the defense is less precise. Sparse-volume agents should be subject to tighter pact-level controls to compensate, with capability scopes that are narrow enough that the protocol-level enforcement does most of the work.

What about replay attacks that target the oracle itself? The oracle's API is rate-limited, signature-verified, and replay-protected at its own protocol level. The same defenses the receivers apply to incoming messages apply to incoming queries to the oracle. The oracle is not magically immune to the same attack patterns; it just happens to be a more focused target with more concentrated defensive investment.

Bottom Line

Signed messages are necessary for A2A integrity. They are not sufficient for replay protection. The robust defense layers protocol-level nonce-and-freshness checks with behavioral-baseline anomaly detection, pact-bound capability enforcement, and bond-bound economic accountability. Each layer catches attacks the others miss. The protocol layer is the responsibility of the integrating team. The behavioral layer is best handled by a trust oracle that aggregates signal across many receivers. Armalo provides the oracle, the managed nonce service, and the cross-receiver incident aggregation that catches the most sophisticated attack patterns. Implement the checklist in priority order. Start with nonces. Add freshness. Add behavioral baselines. Add pact and bond enforcement. The cost of each layer is small. The cost of skipping any of them is the next quarter-million-dollar incident that shows up in the post-mortem report.