A2A Rate Limits As A Trust Signal: Why Bursts Are Suspicious And Steady Is Reassuring

TL;DR

Rate limits in A2A are usually framed as capacity guards: protect the callee from being overwhelmed. That framing misses the more interesting use of rate: it is a behavioral signal about the caller. A counterparty whose rate suddenly triples is doing something different from yesterday, and different is often a problem (compromised keys, runaway loop, panic dump of work). A counterparty whose rate is steady within its normal envelope is reassuring. This post lays out the framework for treating rate as a trust signal, including the alert spec for catching the dangerous patterns early.

The Failure Mode That Forces The Reframing

A marketing analytics agent operated by a mid-sized firm has been calling a data enrichment counterparty for six months at a steady rate of about 200 calls per hour during business hours and near-zero outside them. On a Tuesday at 2 AM, the calls start coming in at 4,000 per hour and continue at that rate for ninety minutes. The data enrichment counterparty's rate limiter is configured for a hard ceiling of 5,000 per hour, so the calls go through. The bill at the end of the month is roughly twenty times the historical average. The marketing firm disputes the bill, claiming they did not authorize the activity. The data enrichment provider points to the calls, which were within the contract limits.

The investigation reveals that the marketing firm's API key for the analytics agent had been exposed in a Git history three weeks earlier. The key was rotated, but only after the attacker had already collected it. The attacker used the key to drive a high-volume scrape of the enrichment API, presumably to harvest data for resale or for training another model. The enrichment provider's rate limiter saw nothing wrong; the calls were within the contract envelope.

The enrichment provider had a capacity-based rate limit. They did not have a behavior-based rate observer. Capacity-based limits cannot detect anomaly because anomaly is below the limit. The 4,000 calls per hour was twenty times the normal rate, which is the most important fact in the entire incident, and the enrichment provider's systems did not record it as a fact at all.

This is the failure mode that the reframing addresses. Rate limits as capacity guards are the right primitive for the wrong question. The right question is not whether the caller is consuming too much capacity; it is whether the caller is behaving the way the caller usually behaves. A burst is an anomaly even when it is below the capacity ceiling, and treating burst-detection as a separate operational concern from rate-limiting is the gap that lets these incidents through.

The framework below restructures the operator's view. Rate is not a single number with a single threshold. Rate is a distribution over time, with a baseline that is specific to each counterparty, a normal envelope around the baseline, and a set of departure patterns that signal different kinds of trouble. The departure patterns are the trust signals. The capacity ceiling is still there, but it is the last line of defense, not the only one.

The Three Rate Patterns That Signal Trouble

Most rate anomalies fall into one of three patterns, each with a distinct cause and a distinct response. Understanding the patterns is the first step in turning rate into a trust signal.

Pattern 1: Sudden Sustained Burst

The rate goes from baseline to 5x or more, and stays there for minutes or hours. The example above is this pattern. The cause is almost always one of: compromised credentials being exploited, a runaway loop in the caller's code, a misconfigured retry mechanism that turned a single failure into a flood, or a deliberate scrape attempt by a malicious operator.

The signal is unambiguous because the pattern is rare in healthy operation. Agents that legitimately need a 5x burst usually request the burst capacity in advance through a contract amendment or a pre-arranged window. Unannounced sustained bursts are not how legitimate users behave.

The response is to throttle aggressively (drop the rate back to or below baseline) and surface the burst to the caller's operator immediately. The throttling is automatic; the surfacing is human-readable so the caller can investigate. If the caller confirms the burst is intentional, the throttle can be relaxed; if the caller cannot confirm or finds evidence of compromise, the credentials are rotated and the calls within the burst are flagged for refund or dispute.

Pattern 2: Sudden Brief Spike

The rate goes from baseline to 10x or more for a few seconds and returns to baseline. The cause is usually a queued backlog being drained (calls that were stuck behind a slow upstream now firing all at once), a thundering-herd effect from a synchronized event, or a brief loop bug that was caught by the caller's own monitoring.

The signal is ambiguous because the pattern can be benign. The right response is to log the spike with full context, increment a counter on the caller's profile, and alert if the spike pattern recurs more than twice in a short window. A single spike is noise; three spikes in an hour is signal.

Pattern 3: Slow Drift Upward

The rate climbs gradually over days or weeks, from a baseline of 200 per hour to 800 per hour to 2,000 per hour. The cause is usually feature growth (the caller has added new use cases that consume more capacity), customer growth (the caller's own user base has expanded), or accumulated retries from chronic upstream issues.

The signal is positive in some cases (legitimate growth) and concerning in others (degrading reliability driving retry storms). The response is not to throttle but to surface the trend to both the caller and the callee. If the trend is growth, the contract may need to be renegotiated. If the trend is retries, the underlying reliability issue needs to be fixed.

Slow drift is the easiest to miss because no individual hour is anomalous. The detection requires a longer-horizon view: what was the rate this week versus last month? Without that view, slow drift accumulates until it triggers a capacity-based limit, at which point the caller experiences a sudden hard failure that they could have addressed proactively if anyone had been watching.

The three patterns require different detection mechanisms. Sudden bursts and spikes are caught by short-window comparison (this minute versus the last 60 minutes). Slow drift is caught by long-window comparison (this week versus the prior 8 weeks). A rate-as-trust system needs both.

The Baseline: How To Compute It Without Losing Signal

The baseline is the heart of the framework. Without a per-counterparty baseline, the rate signals are useless because all you can compare against is the global average, which is dominated by the loud counterparties and tells you nothing about the quiet ones.

The baseline has to capture two facts about a counterparty's normal behavior: the typical rate at this hour of this day of the week, and the typical variance around that rate. A counterparty that calls 200 per hour during business hours and 5 per hour overnight has a different baseline at 2 PM Tuesday than at 2 AM Saturday, and the variance is also different (overnight calls are lumpier).

The usual approach is a per-counterparty time-of-week histogram with exponential smoothing. The week is divided into buckets (15 minutes is a reasonable granularity, giving 672 buckets per week); each bucket holds a smoothed mean and standard deviation of the call rate observed in that bucket over the past several weeks. New observations update the bucket with a smoothing factor (alpha around 0.1 is typical), so the baseline drifts to follow real changes but is not whipsawed by a single anomalous hour.

The baseline is updated continuously, but anomaly detection compares the current rate against the baseline at the time of the comparison, not against the baseline that includes the current rate. This is important: if you let the current observation update the baseline before you compare, large anomalies disappear into the baseline and you never alert on them. The order is observe, compare, then update.

The variance is as important as the mean. A counterparty whose mean is 200 per hour with a standard deviation of 20 has a tight baseline; a deviation to 400 is 10 sigma and clearly anomalous. A counterparty whose mean is 200 per hour with a standard deviation of 100 has a loose baseline; a deviation to 400 is 2 sigma and might be normal noise. Using fixed thresholds (always alert on 2x baseline) overalerts on the second counterparty and underalerts on the first. Using sigma-based thresholds adapts to each counterparty's natural variance.

The baseline needs to handle new counterparties gracefully. A counterparty that has been calling for two days has not generated enough data for a robust baseline. The convention is to use a global default for the first week (with looser thresholds), then transition to the per-counterparty baseline as enough data accumulates. The transition can be smooth (a weighted blend of global and per-counterparty) or hard (switch over at a specific data threshold); both work.

The baseline also needs to handle counterparty changes. A counterparty that legitimately starts a new use case will have a step change in their baseline, which the smoothing absorbs slowly. To accelerate the absorption, the counterparty can request a baseline reset, which the system processes after confirming the request is signed and authorized. Without the reset, the new use case looks anomalous for several weeks, which is annoying but not catastrophic.

The Rate Anomaly Alert Spec

Here is the named artifact. The alert spec defines what to detect, when to alert, and what to put in the alert. It is opinionated and operationally practical.

Detection Inputs

• Per-counterparty time-of-week baseline: mean and standard deviation per 15-minute bucket, smoothed over the past 8 weeks.
• Short-window observation: actual rate in the most recent 5 minutes.
• Medium-window observation: actual rate in the most recent 60 minutes.
• Long-window observation: actual rate in the most recent 7 days.

Alert Triggers

• Burst Alert: short-window rate exceeds baseline by more than 5 sigma (or 5x for sparse counterparties without enough variance data) and stays elevated for at least 3 minutes. Severity: high.
• Spike Alert: short-window rate exceeds baseline by more than 10 sigma but returns to baseline within 3 minutes. Severity: low on first occurrence, escalating to medium on second, high on third within an hour.
• Drift Alert: long-window mean exceeds baseline by more than 2x for at least 3 days running. Severity: low (informational) but persistent until acknowledged.
• Quiet Alert: short-window rate falls below baseline by more than 5 sigma during a window where the baseline is non-trivial. Severity: medium. Quiet is also a signal: a counterparty that suddenly stops calling may have failed silently or been compromised in a way that disabled the integration.
• Pattern Alert: short-window rate exhibits a recognizable adversarial pattern (uniform interval, exact powers of two, prime-numbered intervals). Severity: high. Healthy traffic is irregular; perfectly regular traffic is usually automated abuse.

Alert Payload

• counterpartyDid: the agent generating the anomalous rate.
• pattern: which trigger fired (burst, spike, drift, quiet, pattern).
• currentRate: observed rate in the relevant window, in calls per minute.
• baselineRate: expected rate from the baseline, in calls per minute.
• baselineSigma: variance of the baseline, in calls per minute.
• deviationSigma: how far from baseline the observation is, in standard deviations.
• windowStart: the start of the observation window.
• windowEnd: the end.
• recentSamples: a small sample of call records (callId, timestamp, capability) for context.
• relatedAlerts: any other alerts on this counterparty in the past 24 hours, for pattern recognition.
• recommendedAction: based on the pattern, the system's suggested response (throttle, log, escalate, contact operator).

Alert Channels

• High severity: page the on-call operator immediately, throttle the counterparty automatically.
• Medium severity: notify the on-call operator within the hour, log to the audit trail, do not throttle automatically.
• Low severity: append to the daily digest, log to the audit trail.

Throttle Behavior

• Burst alert with auto-throttle: rate cap at the baseline for the next 15 minutes, then reassess.
• Manual escalation: operator can extend the throttle indefinitely, lift it, or convert to a hard block.
• Throttling decisions are themselves audit events with operator identity recorded.

The alert spec is the kind of thing that needs to be tuned after deployment. The default thresholds are conservative; operators in noisier environments will need to relax them, and operators in quieter environments may want to tighten them. The spec is the starting point, not the finished product, but it is a defensible starting point.

Why Quiet Is Also A Signal

The instinct is to alert on too many calls and ignore too few. Too few is also a signal, and missing it is a category of incident that has its own footprint.

The most common reason for a sudden quiet is that the counterparty has crashed or been disabled. An agent that called 200 times an hour for six months and now calls 0 times an hour is either retired (in which case there should be a notification), broken (in which case the operator needs to know), or replaced (in which case the integration is moving to a new counterparty and again the operator should know). Silent retirement is rare and usually a misconfiguration, which is itself worth fixing.

The second reason is partial compromise. An attacker who has stolen credentials may not exploit them immediately; they may sit on the credentials, observing the legitimate traffic and waiting for an opportunity. In some sophisticated cases, the attacker disables the legitimate caller (taking the agent offline or redirecting its traffic) so that the attacker's own use of the credentials does not blend with concurrent legitimate use. The signal of this attack is that the legitimate traffic stops while the credentials remain active.

The third reason is upstream failure. The counterparty depends on a downstream service that has degraded, and the counterparty is shedding load by reducing calls. From the callee's perspective, this looks like quiet; from the system perspective, it is an upstream problem manifesting as a downstream symptom. Catching it through quiet detection lets the callee reach out and offer help or absorb the issue gracefully.

Quiet detection has its own sensitivity tradeoffs. Counterparties with low or sporadic baseline rates produce false-positive quiet alerts easily; the threshold needs to be set so that legitimate idle periods do not trigger. The convention is to require both the deviation from baseline and the absolute window to be non-trivial: alert only if the baseline rate during the window is at least a few calls per hour, and the observed rate is at least 5 sigma below it.

Quiet detection also benefits from corroboration. If the counterparty reports its own health to a status endpoint, the quiet alert can be cross-referenced: a counterparty reporting healthy that has gone quiet is more concerning than one reporting unhealthy. Both should be alerted, but the priority is different.

The Pattern Alert: Why Regular Is Suspicious

The pattern alert deserves its own treatment because the underlying observation is counterintuitive. Healthy A2A traffic is irregular. Even an automated process that runs on a 5-minute schedule produces calls with some jitter (network delay, scheduling slop, downstream variability). Calls that arrive at exactly 5-minute intervals to the millisecond are not produced by a normal process; they are produced by something that has gone out of its way to be regular.

Adversarial traffic is often regular. Scrapers tend to back off in fixed intervals; brute force attempts use fixed cadences; data harvesters cycle through pages at uniform rates. The regularity is not always intentional; it is often a side effect of the simple loops that adversarial code tends to use. The detection takes advantage of this: a calling pattern that lacks the natural jitter of legitimate traffic is suspicious, even if the rate itself is not anomalous.

Detecting regularity is a different computation from detecting rate. It requires looking at the inter-arrival times of calls, computing their distribution, and comparing against the distribution of legitimate traffic. The simplest test is the coefficient of variation of inter-arrival times: legitimate traffic has CV around 1 (Poisson-like); regular traffic has CV near 0. A CV below some threshold (0.2 is a reasonable starting point) is the signal.

False positives are real. Some legitimate processes do call on tight schedules: heartbeat checks, cron jobs, polling integrations. The convention is to whitelist these patterns explicitly: a counterparty can register a expected-pattern declaration with the rate observer, listing the call types that will exhibit regular timing. Calls in those types do not trigger the pattern alert; calls in other types do. The whitelist is itself an audit signal because changes to it should be reviewed.

The pattern alert catches a class of attack that the rate-only alerts miss. An attacker who is careful to stay within the rate envelope can fly under the burst and spike alerts but cannot easily reproduce the natural irregularity of human-driven workflows. Catching them on the pattern is sometimes the only signal available.

Closing The Loop: Rate Signals As Trust Score Inputs

The alerts above are operational; they trigger immediate human or automated action. There is a second use of rate signals that is strategic: feeding them back into the counterparty's trust posture for long-horizon decisions.

A counterparty that triggers many burst alerts over months is not behaving consistently. The instability is itself a trust signal, and it should affect the counterparty's composite score. The mechanism is to weight the rate-anomaly history into one of the score's dimensions (reliability is the natural fit, since rate stability is a form of operational reliability).

The weighting needs to be careful. A single burst is not evidence of bad behavior; it is evidence of an incident, which can happen to any operator. A pattern of bursts (say, more than two unexplained bursts per quarter for three quarters running) is evidence of operational immaturity. The score should reflect the pattern, not the single event.

The inverse is also true. A counterparty whose rate is steady for months without anomaly is operationally mature. The score should reward this. The mature behavior is not just an absence of anomaly; it is a demonstration that the counterparty's internal systems are well-managed. That demonstration has value, and the trust signal should price it.

Feeding rate signals into the score also creates an incentive: counterparties become motivated to investigate and explain their bursts proactively, because unexplained bursts cost them score and explained bursts do not. The explanation becomes part of the audit record, which improves the network's overall transparency. Over time, the rate-anomaly review becomes a routine operational practice on the counterparty's side, not just on the callee's side.

The score-feedback path is what turns rate from an operational concern into a strategic one. Operators who care about their trust posture care about their rate stability, which means they invest in the internal practices that produce stability. The network gets healthier as a side effect of every counterparty's local optimization for their own score.

Counter-Argument: Rate Signals Are Too Noisy To Be Useful

The most common counter-argument is that rate is noisy by nature, and any signal extracted from it will be drowned in false positives. Operators who have implemented rate alerts often report being overwhelmed by alerts, learning to ignore them, and effectively having no rate detection at all. The pragmatic response, the argument goes, is to set rate limits at the capacity ceiling and forget about behavioral signals.

The argument is wrong but the experience that motivates it is real. Naive rate alerting does produce overwhelming noise, mostly because the thresholds are global rather than per-counterparty and because the windows are wrong for the patterns being detected. The framework above addresses both: per-counterparty baselines mean each counterparty's alerts are calibrated to their own normal, and the multi-window approach catches different patterns with different time scales.

The alert volume from a well-tuned rate-as-trust system is moderate, not overwhelming. A network of 1,000 counterparties produces a few alerts per day in steady state, almost all of them informational. The high-severity alerts are rare (a few per month) and almost always indicate real incidents. The pattern is similar to fraud detection in payments: the work is in building the model, but the operational load once the model is in place is manageable.

The other half of the response is that the alternative (no behavioral detection) is worse than noisy alerts. The incident at the start of this post happens routinely in networks that rely only on capacity-based rate limits. The cost of a single such incident often exceeds the cost of a year of alert-tuning work. The economics favor investing in the detection.

A related counter-argument is that operators do not have the data to compute baselines. If you are starting from zero, you cannot alert on departures from a baseline you do not have. This is fair, and it is why the framework has a graceful onboarding path: start with global defaults, transition to per-counterparty baselines as data accumulates. The first few weeks of operation will produce more false positives than the steady state, but that is true of any anomaly detection system and is not a reason to skip building it.

What Armalo Does

Armalo's behavioral telemetry endpoint exposes per-counterparty rate metrics in the form orchestrators need: short-window observation, medium-window observation, baseline mean, baseline sigma, recent anomaly count. The baselines are computed across the network, not per-operator, which gives small operators access to the same baseline quality that a large network would compute internally.

The trust oracle (/api/v1/trust/) consumes rate-anomaly history as one of the inputs to the reliability dimension of the 12-dimension composite score. Counterparties with steady rates earn reliability score; counterparties with chronic anomalies lose it. The weighting is intentional: a single anomaly does not move the score meaningfully, but a pattern of anomalies does.

The alert spec described above is part of Armalo's recommended A2A operating practice. The reference implementation is open and integrates with the trust oracle for baseline data and with the audit log for context inclusion in alerts. Operators who do not want to operate their own anomaly detection can subscribe to Armalo-managed alerting for their counterparties at a per-counterparty fee.

The multi-LLM jury that contributes to score updates is itself a target of rate observation: jury sessions that fire more often than baseline trigger their own alert path, since unusual jury activity often indicates either an attempt to game the score or a quality issue that is producing many disputes. The jury rate is exposed alongside the agent rate metrics.

FAQ

Q: How long does it take to build a useful baseline? Two to four weeks of typical traffic for a per-counterparty baseline that is robust enough to alert on. Earlier alerts use the global default, which is looser but still catches the most extreme anomalies.

Q: Can baselines be shared across operators? Yes, and there is value in doing so. A counterparty's baseline as observed by one operator is usually similar to its baseline as observed by another, so a network-wide baseline gives small operators access to quality detection without their own data. Armalo's behavioral telemetry endpoint exposes the network-wide baseline.

Q: What about counterparties that legitimately burst? They can register expected-burst windows in advance (a contract amendment or a one-off pre-arranged window). Calls within the registered window do not trigger alerts. Unregistered bursts always alert.

Q: How do I tune the sigma thresholds without producing too many false positives? Start conservative (5 sigma for high-severity, 3 sigma for medium) and review the alert log weekly for the first month. Counterparties whose alerts you consistently ignore should have looser thresholds; counterparties whose alerts you act on should keep tight thresholds.

Q: Should I throttle automatically on burst alerts? For counterparties whose burst pattern correlates with confirmed incidents, yes. For counterparties whose bursts have a history of being benign, log and notify but do not throttle. The decision is operational and changes over time.

Q: What if my own caller is the one bursting? The rate-as-trust framework cuts both ways. If your agent is bursting at a counterparty, you should detect that yourself before the counterparty alerts you. Outbound rate observation is the same machinery applied to your own outbound traffic.

Q: How does this interact with rate limit billing? It does not directly. Rate limits for billing are about capacity and contract terms; rate observation for trust is about behavior. The two systems share metrics but make different decisions.

Q: Can rate signals be gamed by an attacker who knows the baseline? A sophisticated attacker who knows the baseline can stay within it, which is one of the reasons the pattern alert (regularity detection) exists. Layering multiple signals makes evasion harder; no single signal is uncrackable.

Bottom Line

Rate is not just a capacity metric. It is a behavioral fingerprint, and departures from a counterparty's normal behavior are some of the earliest and clearest signals of trouble. The framework above turns rate observation into a trust signal: per-counterparty baselines, multi-window anomaly detection, calibrated alerts, and feedback into the trust score. The cost is moderate; the benefit is catching incidents before they become disputes. Capacity-based limits are still necessary as the last line of defense, but a network that relies only on capacity limits is missing most of the signal that rate observation can provide. The alert spec in this post is the artifact you can implement next week. The trust oracle is the substrate that makes it pay off.