Why MCP plugins need configurable pre-auth rate limiting

The threat model

An MCP bridge is an RPC server into your editor. A leaked or brute-forced token gives the attacker the ability to spawn actors, edit blueprints, render sequences, or cook packages. The token is the one thing between a local network foothold and arbitrary editor control.

Anti-credential-stuffing, anti-DoS

If you only rate-limit after token validation, a stuffing attack burns your handler budget before the auth gate even runs. A pre-auth rate limit by origin IP flattens the attempt rate before the comparison ever happens.

Sliding window vs fixed window boundary burst

A fixed per-minute window lets an attacker send N requests at second 59 of one window and another N at second 0 of the next — 2x the stated limit in a one-second span. A sliding window counts the last 60 seconds at every instant, so the limit is honored at every instant, not on average.

The budget

The default is 200 requests per minute per observed origin. Loopback-only remains the default, so remote origins never reach this layer unless the operator deliberately exposes the listener. The budget sits in front of token validation and is now configurable through RateLimitPreAuthMaxRequestsPerMinute, editor settings, and runtime posture metadata.

SHA-256 hashed principals

Metrics never log raw tokens. Principals are SHA-256 hashed so operators can correlate abuse without exposing credentials in logs, dashboards, or incident reports.

Implementation notes

The window uses a bounded ring buffer per origin. Eviction is amortized O(1). The memory footprint is predictable regardless of attacker behavior.