A water-quality model API has no per-client quotas, enabling bulk boundary mapping in tests. What control should defenders prioritize?
Select an answer to reveal the explanation.
Short Explanation
Unlimited sips from the API make it easy to map the whole well—put meters and caps on each client.
Full Explanation
When a water-quality model API has no per-client quotas—enabling bulk boundary mapping in tests—defenders should prioritize per-client quotas and rate limits as anti-extraction controls on civic ML APIs. Quotas raise the cost and slow systematic probing, support fair use across clients, and create natural telemetry for detecting extraction-like patterns against municipal scientific and operational models.
Flagging anomalous query volumes with automated alerting helps triage suspicious traffic, but an alert by itself doesn't stop a client from mapping the whole decision boundary before anyone reviews it. Rotating API keys on a short schedule refreshes credentials without limiting how much any one authenticated client can extract once authenticated. Suppressing confidence scores in outputs obscures decision thresholds but does nothing to stop one client making thousands of small, boundary-mapping queries. The control that actually limits bulk extraction is a per-client quota tied to that client's own query volume.
Exam caveat: quotas slow and complicate extraction; determined actors may still succeed slowly or via many identities. Combine rate limits with authentication, anomaly detection, and output minimization for defense in depth.
Operational check: implement authenticated per-client rate limits on the water-quality API, alert on quota saturation and patterned probing, and periodically reassess limits against legitimate batch-science and operations workloads without disabling the control.