Rate limiting is enforced on AI endpoints

Unrate-limited AI endpoints are vulnerable to three distinct abuse patterns. First, automated prompt injection probing: an attacker can send thousands of variants per minute, systematically testing which injections succeed—a pattern consistent with MITRE ATLAS adversarial reconnaissance. Second, cost amplification: AI completions are billed per token, so an unprotected endpoint allows malicious actors to exhaust your provider quota and generate costs you bear (OWASP A04:2021 Insecure Design). Third, denial-of-service: even non-adversarial traffic spikes can exhaust your provider's rate limits, causing legitimate users to experience failures. CWE-770 (Allocation of Resources Without Limits) applies directly. NIST AI RMF MANAGE 1.3 requires managing operational risk for deployed AI systems, including resource exhaustion.

Apply per-user (preferred) or per-IP rate limiting that fires before the AI provider call. For Next.js on Vercel, Upstash Redis sliding window rate limiting is the lowest-friction approach.

// src/app/api/chat/route.ts
import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(20, '1 m'), // 20 requests/min per user
  analytics: true,
})

export async function POST(req: Request) {
  const identifier = session?.userId ?? getClientIp(req)
  const { success, limit, remaining } = await ratelimit.limit(identifier)

  if (!success) {
    return Response.json(
      { error: 'Rate limit exceeded. Try again in a moment.' },
      { status: 429, headers: { 'Retry-After': '60' } }
    )
  }
  // AI call proceeds only after rate limit passes
}

Set the window based on legitimate usage patterns. 10–20 requests per minute is appropriate for interactive chat; adjust downward for document-analysis endpoints with higher per-call costs.