Rate limiting & abuse protection
Per-agent budget caps, auth abuse guards, and what's not yet enforced.
Partial enforcement today. Some limits listed here are defined in the schema but not yet actively checked at request time. The page is explicit about which are live versus planned.
Agent policy limits
Every agent (delegate) can have an optional policy stored in the database. These limits are per-agent, not per-user or per-IP.
| Limit | Field | Enforced today? |
|---|---|---|
| Daily toll spend cap | maxTollSpendPerDay | ✅ Yes — checked before every toll payment |
| Require approval for sends | requireApproval | ✅ Yes — checked before every outbound email |
| Max reads per hour | maxReadsPerHour | ⚠️ Schema only — not checked at request time yet |
| Max sends per hour | maxSendsPerHour | ⚠️ Schema only — not checked at request time yet |
| Max sends per day | maxSendsPerDay | ⚠️ Schema only — not checked at request time yet |
| Allowed recipients | allowedRecipients | ✅ Yes — enforced in email-write tools |
| Blocked recipients | blockedRecipients | ✅ Yes — enforced in email-write tools |
Daily toll spend cap
The spend cap (maxTollSpendPerDay) is the most actively enforced limit. Before any agent toll payment goes through, the spending tracker reads the agent's total spend since 00:00 UTC and compares it against the cap. Payments that would exceed the cap are rejected. Spend is logged per-transaction so the running total stays accurate across requests.
If no cap is set on a policy, toll spending is unrestricted for that agent.
Auth challenge store
Wallet login and agent login both use a challenge-response flow. Challenges are held in an in-memory store with a 5-minute TTL. As an abuse guard, the store has a global ceiling of 10,000 pending challenges — new challenge requests return 429 Too Many Requests if the ceiling is hit.
This is a coarse guard against flooding the challenge endpoint, not a per-user or per-IP limit. Under normal dogfooding traffic it is nowhere near the ceiling.
What's not in place yet
The following limits are not yet implemented:
- Per-IP rate limiting. No middleware caps requests by source IP. This is the most relevant gap for abuse protection.
- Global API rate limiter. No request-rate ceiling applies across the API surface as a whole.
- Per-user request rate limits. Authenticated users have no enforced request budget.
maxReadsPerHour/maxSendsPerHour/maxSendsPerDayenforcement. The columns exist inagentPoliciesand can be set, but no request path reads them to block or throttle.
During dogfooding, traffic volume is low enough that the missing limits haven't caused problems. The spend cap and approval gate are the meaningful operational controls today. Per-IP and per-user limits are the highest-priority gaps to close before a public launch.
Related
How is this guide?
Last updated on