Rate‑Limiting AI Agent Egress to Already‑Allowed APIs

Description and use

Problem: an allowlist does not limit request frequency, causing AI agents to overwhelm APIs. Solution: apply a local request rate limit on the gateway route, capping traffic to 5 requests per second after a 20‑request burst.

Problem

An egress allowlist does not control how often an AI agent can hit an allowed API, leading to excessive traffic that can overwhelm the target.

Outcome

The guarded route limited traffic to the configured burst and steady‑state rate, while the unguarded route allowed all traffic, demonstrating that a route‑level rate limit effectively protects an allowed API from agent overuse.

Workflow

• 1. Configure agentgateway with a localRateLimit policy (maxTokens:20, tokensPerFill:5, fillInterval:1s, type:requests).
• 2. Deploy two gateway instances: one guarded, one unguarded.
• 3. Send 60 requests via curl to each route.
• 4. Verify guarded route returns 429 for excess requests and upstream receives only 20 requests.
• 5. Verify unguarded route forwards all 60 requests to upstream.

Evidence

An egress allowlist decides whether an agent can reach a destination. It has no opinion about how often.

Source

The guarded route: localRateLimit { maxTokens: 20, tokensPerFill: 5, fillInterval: 1s, type: requests } Same 40 requests, same speed: 20 x 200, 20 x 429

Source

scripts/verify.sh asserts the claim directly rather than eyeballing the demo output: it fires 60 requests through each route and checks that the unguarded upstream received all 60, the guarded upstream received fewer, and only the guarded route ever returned a 429.

Source