Context
There is no rate limit on credential operations — an agent can call POST /api/credentials/issue or POST /api/credentials/verify in a tight loop with no back-pressure. This creates a DoS vector and makes it hard to detect brute-force attempts.
What to implement
In-memory sliding window limiter
Per-agent limits (keyed by agentId or caller IP for unauthenticated routes):
- Issue: 10 requests / minute
- Verify: 60 requests / minute
- Revoke: 5 requests / minute
Response when limit exceeded
429 Too Many Requests with:
{ "ok": false, "error": "rate_limit_exceeded", "retryAfterSec": 42 }
And header: Retry-After: 42
Store design
Map<agentId, { windowStart: number, count: number }> — reset window on each new minute boundary.
Acceptance criteria
🎁 Evidencia visual = reward extra
- Si tu PR incluye video demo o capturas de pantalla mostrando la funcionalidad pedida funcionando end-to-end, va a ser considerado para rewards de GrantFox en esta issue. No es obligatorio, pero suma mucho para la evaluación.
Context
There is no rate limit on credential operations — an agent can call
POST /api/credentials/issueorPOST /api/credentials/verifyin a tight loop with no back-pressure. This creates a DoS vector and makes it hard to detect brute-force attempts.What to implement
In-memory sliding window limiter
Per-agent limits (keyed by agentId or caller IP for unauthenticated routes):
Response when limit exceeded
429 Too Many Requestswith:{ "ok": false, "error": "rate_limit_exceeded", "retryAfterSec": 42 }And header:
Retry-After: 42Store design
Map<agentId, { windowStart: number, count: number }>— reset window on each new minute boundary.Acceptance criteria
retryAfterSecandRetry-Afterheader🎁 Evidencia visual = reward extra