← all posts

Hardpoint Guardian: v2 Rate Limits Are Purposefully Limited

Fixed-window rate limiting keyed by agent/user/tool, deliberately without persistence or distributed coordination.

What v2 Provides

Version 2 introduces fixed-window rate limiting through RateLimitedPolicyStore, but the scope is intentionally narrow:

version: 2
rules:
  - action: allow
    target: {tool: search}
    rate_limit: {max_calls: 10, window_seconds: 60}

What v2 provides:

  • Process-local fixed-window quota keyed by agent, user, and tool
  • Consumption on allow decisions — exhaustion returns throttle
  • Identity keys bounded at 10,000 by default

What v2 deliberately does NOT provide:

  • Persistent or distributed state
  • Redirect execution
  • Multi-action rules
  • Policy memory or scripts
  • Host-side throttle execution

Restarting the process clears quota state. The in-memory store accepts at most 10,000 identity keys by default and fails closed when full.

Why the Limited Scope?

This keeps v2 focused on what it is: a bounded in-process rate limiter, without the project having to solve distributed systems problems (consensus, persistence, coordination) that are outside the authorization decision boundary.

GitHub: https://github.com/argakiig/hp-guardian