Spend and send guardrails

What it does

A wrapper that refuses any paid generation call unless a numeric budget and a written approval are set, and stops at the budget. A persistent ledger survives re-runs. A mail connector lets agents search, label and draft but has no send, trash or delete, enforced before a request leaves the machine.

How it works

• The spend guard requires an integer credit budget and an approval string before any paid generation call.
• Spend is tracked per approval in a persistent ledger, so re-running a script cannot reset it.
• The mail connector exposes search, read, label and draft. Send, trash and delete are refused before the request leaves the machine.
• The allowlist is enforced in code, not by the API scope, so the no-send rule holds even if the API would permit it.

Guardrails and design choices

• No paid generation without a numeric budget and a written approval.
• The spend ledger survives re-runs; a new budget needs a new approval string.
• The mail connector has no send, trash or delete, enforced before a request leaves the machine.

Status

Live. The spend guard is wired into scripts that call paid generation APIs. The mail connector is in daily use. The no-send rule covers the connector's tools; it is not a sandbox against an agent with shell access.