A city open-data GenAI API lacks rate limits, allowing scrapers to burn budget and probe jailbreaks. What API-design control should architecture add?
Select an answer to reveal the explanation.
Short Explanation
An open fire hose with no valve is a gift to scrapers and jailbreak tourists. Put authenticated rate limits and quotas on the city’s GenAI API so budget and abuse stay bounded. Unlimited tokens are not a public-service badge of honor here.
Full Explanation
Public municipal GenAI APIs without rate limits invite scrapers that burn provider budget, degrade availability for residents, and automate jailbreak or probing campaigns. Architecture should add abuse-resistant controls: authenticate callers where appropriate, enforce rate limits and quotas, and set anomaly thresholds that trigger throttling or investigation on the open-data GenAI endpoint. These API-design controls protect both fiscal exposure and service quality for civic users.
Publishing unlimited free tokens to encourage civic engagement maximizes cost and abuse surface under the guise of openness. Removing authentication so rate limiting becomes unnecessary inverts the control model—authentication and quotas usually work together, and anonymous unlimited access worsens scrapers. Logging only successful answers and ignoring high-volume error storms blinds operators to probing patterns that often appear as failures or policy denials.
Exam caveat: open data does not require open-ended GenAI spend; publish datasets under open licenses while still metering generative endpoints. Operational check: enable authenticated rate limits and quotas on the city GenAI API, alert on anomalous request rates and error storms, cap daily spend per key, and verify scrapers receive 429/deny responses without exhausting the provider budget.