Hey! Kevan here. Yes, it's its own thing. We classify each provider's API operations into families, and "payment" (anything that moves money or changes billing) is one of them, so a rule can target payments without you listing endpoints.
On your three controls:
- Per-action caps: rules can match request params numerically, so "deny if amount > 5000" works today.
- Approval above a threshold: same matching drives human approval, e.g. "require approval on payments where amount > 1000". The approver sees the exact frozen request that will execute.
- Rolling daily budget: not built yet. Today we have per-agent quotas that count calls per minute/hour/day, but nothing that sums amounts across calls. We have the pieces (amount parsing per call, per-window counters, approvals), so it's a natural next rule type.
On your three controls:
- Per-action caps: rules can match request params numerically, so "deny if amount > 5000" works today.
- Approval above a threshold: same matching drives human approval, e.g. "require approval on payments where amount > 1000". The approver sees the exact frozen request that will execute.
- Rolling daily budget: not built yet. Today we have per-agent quotas that count calls per minute/hour/day, but nothing that sums amounts across calls. We have the pieces (amount parsing per call, per-window counters, approvals), so it's a natural next rule type.