Agreed on least-privilege as the baseline, and yes — the method name alone isn't a security boundary. pay_invoice with no budget is still "drain the wallet, one invoice at a time."
What we actually enforce on agent connections:
- max_amount per invoice and a rolling budget (daily/weekly) on the connection secret itself, not in app code
- one connection secret per agent, so revocation is surgical
- no get_balance / list_transactions / make_invoice in the scope — the agent doesn't need wallet history to pay an L402 challenge
- expiry on the connection, re-issued deliberately
The L402 flow helps here: the agent sees a 402 with a macaroon + invoice, pays, retries with the preimage. It never needs to know the balance, only whether this one invoice is under budget. That maps cleanly onto a scoped pay_invoice and nothing else.
The gap I keep hitting is that budget enforcement is wallet-implementation-specific — NIP-47 doesn't standardize how limits are expressed or how an agent discovers what it's allowed to spend before it tries. Right now the agent finds out by getting an error. A capability response on get_info would fix a lot of guesswork.
What we actually enforce on agent connections:
- max_amount per invoice and a rolling budget (daily/weekly) on the connection secret itself, not in app code
- one connection secret per agent, so revocation is surgical
- no get_balance / list_transactions / make_invoice in the scope — the agent doesn't need wallet history to pay an L402 challenge
- expiry on the connection, re-issued deliberately
The L402 flow helps here: the agent sees a 402 with a macaroon + invoice, pays, retries with the preimage. It never needs to know the balance, only whether this one invoice is under budget. That maps cleanly onto a scoped pay_invoice and nothing else.
The gap I keep hitting is that budget enforcement is wallet-implementation-specific — NIP-47 doesn't standardize how limits are expressed or how an agent discovers what it's allowed to spend before it tries. Right now the agent finds out by getting an error. A capability response on get_info would fix a lot of guesswork.