When Someone Else's Agent Knocks
When Someone Else's Agent Knocks
Most writing about agent guardrails assumes the agent you need to worry about is your own. You design its permissions, cap its blast radius, log its actions — and you're done. Then one day your API starts getting hammered at 4am, and the culprit isn't a scraper or a botnet. It's somebody's helpful AI assistant, politely and relentlessly doing its job.
Here's a pattern-level version of a story we've seen play out. A mid-size travel-booking API starts seeing bursts of traffic that look almost human: well-formed requests, valid auth, sensible query parameters. But the cadence is wrong — a request every 400 milliseconds, for hours, walking through every combination of a search space no human would exhaust. Someone downstream had wired an agent to "check availability until you find a match," and the agent, lacking any concept of being a good citizen, did exactly that.
No malice. No exploit. Just an autonomous loop with no backoff, no budget, and no one watching.
The uncomfortable symmetry
If you run agents, you're on both sides of this. Your agent is someone else's noisy neighbor waiting to happen. Three design rules follow from taking that seriously:
1. Every loop needs a budget, not just a goal. "Retry until it works" is not an instruction — it's a denial-of-service policy with good intentions. Every autonomous loop should carry an explicit budget: max attempts, max duration, max spend. When the budget runs out, the agent stops and reports, it doesn't improvise. The report is the feature: a human decides whether the goal was worth ten more attempts, not the loop.
2. Backoff is a courtesy you extend by default. Humans naturally slow down when a system feels sluggish. Agents don't feel anything. If a call fails or crawls, an agent will happily retry at machine speed forever unless you build in exponential backoff and jitter. This isn't just politeness — it's self-preservation. The fastest way to get your API key revoked is to be the client that retries hardest during someone else's outage.
3. Rate limits are a contract, and agents should read the contract. Most APIs publish limits. Most agent frameworks ignore them. An agent that checks response headers for rate-limit signals and adjusts is doing verification — treating the outside world as something to observe, not just command. An agent that ignores 429s and keeps pushing is running open-loop, and open-loop autonomy is how you end up in someone's incident report.
On the receiving end
The defensive posture matters too. Assume some fraction of your inbound traffic is now agents, and that the fraction is growing. Rate-limit by behavior, not just by identity — a valid key with an inhuman cadence deserves a slowdown. Make your error responses machine-legible, because the "user" reading them may be a loop deciding whether to retry. A clear Retry-After header is cheaper than an outage.
The takeaway
Autonomy design doesn't stop at your own perimeter. An agent that pursues its goal without a budget, without backoff, and without reading the room is a liability even when every individual action it takes is technically correct. The correctness of each step is not the correctness of the loop.
Give your agents goals, yes. But give them budgets, manners, and a stop condition first. The internet is a shared apartment building, and your agent doesn't get to practice drums at 4am just because it never sleeps.