A scraper hammers the city's open-data AI API with rapid repeated requests. Which gateway control best mitigates that abuse?

Abuse and scraping against municipal AI APIs are mitigated with gateway rate controls. Applying per-client rate limits on the city's open-data AI API constrains how fast any single actor can hammer the service, protects availability for legitimate researchers and residents, and reduces cost spikes from automated extraction. Limits also buy time for abuse detection, client identification, and key revocation when scrapers misbehave, which is essential for shared civic open-data platforms with finite budgets and capacity.

Applying per-client monthly quotas on the AI API gateway caps total monthly volume but does not throttle request frequency, so a scraper sending rapid bursts still gets through and keeps hammering the service in the short term. Applying global request throttling on the AI API gateway limits aggregate traffic for everyone but does not isolate the abusive client, so a single scraper can still consume shared capacity and legitimate users get throttled too. Enforcing uniform response delays on the AI API gateway adds latency to every response but does not cap how many requests a client can send, so a scraper using parallel requests keeps hammering the endpoint while legitimate users are slowed as well.

Exam caveat: per-client rate limiting is the expected gateway control for rapid repeated AI API abuse on municipal endpoints. Operational check: set and enforce per-client quotas at the AI API gateway, alert on sustained limit hits, identify scraper fingerprints, and combine limits with authentication and anomaly monitoring rather than replacing those controls.