Controls that keep a single bad actor or scripted adversary from turning a working feature into a cost-bomb, DoS vector, spam amplifier, or account-compromise funnel.
The defensive layer against adversarial volume: "what happens when one attacker does this 10,000 times a second?"
In scope. Rate limits on authentication endpoints (login / signup / password-reset / magic-link / OTP) to blunt credential stuffing and toll fraud. File-upload size and MIME-type caps to prevent CDN-abuse billing spikes and stored-XSS vectors. Per-user spend caps on LLM / SMS / email APIs to stop overnight bill explosions. Webhook idempotency to neutralize retry storms. Pagination / row-limit enforcement on list endpoints to prevent single-query DB saturation. CAPTCHA and proof-of-work challenges where rate limits alone aren't enough.
Not in scope. Access control decisions about who is authorized ("should this user see this data?") — that's access-control. Input-validation / injection-prevention on the content of the request — that's injection-and-input-trust. Static secret hygiene and cryptographic primitives — that's cryptography-and-secrets. Runtime observability, alerting, and incident response — those are operational concerns, not abuse-resistance primitives.
Distinct because. Abuse resistance targets the volume dimension of attack surface, not the permission or correctness dimensions. A request that would be legitimate if issued once but becomes a weapon when issued 50,000 times is an abuse-resistance concern. Whereas access-control says "this caller may not perform this action," abuse-resistance says "this caller may perform this action, but not 10,000 times a second from 200 IPs."
Common failures in AI-built apps. Happy-path scaffolding produces working endpoints without volume controls, because volume abuse doesn't surface in manual testing. Canonical examples: (a) Twilio toll-fraud bills from unrated SMS OTP endpoints (premium-rate international numbers), (b) OpenAI/Anthropic bill spikes from unrated LLM endpoints, (c) Resend/SendGrid sender-reputation destruction from unrated email-verify endpoints, (d) Stripe double-charges from webhook handlers without idempotency keys, (e) Postgres meltdowns from list endpoints without LIMIT clauses.
Conceptual sub-structure. Rate limiting (per-IP, per-user, per-resource), cost capping (per-user budgets on paid APIs), idempotency (request-deduplication at the handler layer), query-cost bounding (pagination, row limits, timeouts). Sub-taxon paths may be introduced when any one sub-area exceeds ~500 patterns.