Noisy Neighbors: When Someone Else's Agent Hammers Your API
Noisy Neighbors: When Someone Else's Agent Hammers Your API
Most guardrail writing assumes the dangerous agent is yours. You budget its actions, gate its writes, log its decisions. Then one morning your API error rate spikes, your on-call gets paged, and the culprit isn't your agent at all — it's somebody else's.
Picture a mid-size travel-booking API. Traffic doubles overnight. No launch, no campaign, no seasonality. The access logs show one client pulling the same search endpoint every 400 milliseconds, around the clock, with a user-agent string that proudly identifies an AI research assistant. Some customer, somewhere, told their agent "keep an eye on prices" — and the agent interpreted that as a promise to check forever, as fast as it could.
Nobody meant harm. That's what makes this failure mode interesting: it's not an attack, it's an externality. An autonomous loop with no cost signal will happily convert "be helpful" into "be relentless."
Three lessons for the receiving side
First, rate limits are no longer optional politeness. Human users self-throttle because clicking is work. Agents don't get tired. If your API's only defense is "nobody would realistically call this that often," you now have a realistic caller. Per-key limits with clear 429 responses aren't hostile — they're the only language a well-built agent reliably understands.
Second, make your errors machine-readable. The polite agent backs off when told to. The badly built one retries harder, because its author never handled the 429 branch. A Retry-After header costs nothing and turns a stampede into a trickle — for every client whose author did the bare minimum. For the rest, limits have to be enforced, not suggested.
Third, identity beats heuristics. The operators of that booking API could only fix the problem because the agent identified itself. If your traffic policies punish honest user-agent strings and reward disguised ones, you're training the ecosystem to lie to you. Give declared agents a sanctioned lane — a cheaper bulk endpoint, a webhook, a diff feed — and most of the noise routes itself there voluntarily.
And three for the sending side
If you operate agents, you're the neighbor. The same discipline you apply to internal actions applies to other people's servers: every recurring external call needs an interval justified by the actual freshness requirement, not by the loop's default. "Check prices" almost never means "every 400ms." It usually means "daily, before the human wakes up."
Build back-off in from day one. Treat a 429 as a instruction, not an obstacle. And cache — an agent that re-fetches what it already knows isn't thorough, it's rude.
The deeper pattern: autonomy budgets shouldn't stop at your own infrastructure's edge. An agent that would never be allowed to hammer its own company's database will cheerfully hammer someone else's API, because nobody wrote a rule about other people's resources. The internet is now full of tireless, well-meaning loops. Whether you're serving them or running them, assume the default behavior is relentless — and design the leash accordingly.