{
  "question": "How do I cap an AI agent's spend per vendor per day across multiple tasks?",
  "slug": "how-to-cap-an-ai-agents-spend-per-vendor-per-day-across-multiple-tasks",
  "url": "https://www.rightshold.com/answers/how-to-cap-an-ai-agents-spend-per-vendor-per-day-across-multiple-tasks",
  "short_answer": "A per-task cap resets with every task. An agent that runs 40 tasks a day, each under a 5.00 cap, can still spend 200.00 with one vendor. A per-vendor daily cap needs a counter that lives outside any one task, is keyed to the vendor, and resets on a fixed clock. On Rightshold the daily total belongs to the credential, not the task: authorize_spend adds every allowed amount to that credential's total for the current UTC day, whichever task asked. So give each vendor its own lane. Issue one agent credential per vendor (issue_agent_credential), then set_spend_policy on it with allowed_domains set to that vendor only, a daily_max_minor for the vendor's daily cap and a per_tx_max_minor. Every task that buys from that vendor calls authorize_spend with that vendor's credential_id. Once the day's total would pass the cap, the next request gets a signed deny with over_daily_cap, and a lane can't be pointed at another vendor because that returns merchant_not_allowed. Add an outer cap on the card or wallet for the total across vendors. ledger_verify keeps every policy version and decision checkable.",
  "checklist": [
    "List the vendors the agent pays and give each one a daily number in its smallest currency unit (1500 for 15.00 USD). Base it on what a normal busy day costs, not on the largest single purchase.",
    "Issue one credential per vendor with issue_agent_credential (an agent label such as buyer-agent:api.vendor-a.com, plus the agent's Ed25519 key and its signature). One agent can hold several credentials, one for each vendor lane.",
    "Call set_spend_policy once per lane: currency, per_tx_max_minor, daily_max_minor, and allowed_domains holding only that vendor (vendor-a.com, or *.vendor-a.com to include subdomains). If you use categories, add allowed_categories too.",
    "Have every task, worker and retry call authorize_spend with the lane's credential_id, the real merchant_domain and amount before it pays. The daily total is shared because the credential is shared, so parallel tasks draw down the same counter.",
    "Know the clock. The Rightshold daily total resets at 00:00 UTC, and Stripe Issuing date-based intervals also start at midnight UTC. A run that crosses midnight can spend up to two days' caps, so keep per_tx_max_minor well below the daily cap.",
    "Count allows, not settlements: an allow counts toward the day's total when it is recorded, even if the agent never completes that payment. Treat the cap as an upper bound on what the agent may commit to, and size it with that in mind.",
    "Don't re-issue a lane's credential in the middle of the day. Each new credential_id starts its own daily total at zero. Issue with ttl_hours long enough to cover your rotation window (up to 168), or set the new lane's cap to the remaining_today_minor shown by GET /v1/spend/policies/{credential_id}.",
    "Add an outer cap for the total across vendors: a daily spending_limits entry on the Stripe Issuing card or cardholder, or one virtual card per vendor with its own daily limit. The lanes cap each vendor; the outer cap stops the sum of lanes from becoming the real budget."
  ],
  "sections": [
    {
      "heading": "Why per-task caps don't add up to a per-vendor cap",
      "points": [
        "Per-request and per-task caps bound one unit of work. Agents rarely do one unit: schedulers, retries, sub-agents and parallel workers all start new tasks, each with a fresh cap. The vendor sees one customer and one bill, so the vendor total is what you need to cap.",
        "GAO's purchase card audits define split purchases as several purchases by the same cardholder from the same vendor on the same day, and use that as a data-mining signal. Vendor plus day is the unit auditors look at when limits are dodged, so it is the right unit for an agent's cap too.",
        "NIST SP 800-53 Rev. 5 AC-6 (least privilege) applies here: give each lane only the vendor and the amount it needs, so a confused or prompt-injected task can't spend another vendor's budget."
      ]
    },
    {
      "heading": "One credential per vendor: a shared daily counter",
      "points": [
        "set_spend_policy stores currency, per_tx_max_minor, daily_max_minor, allowed_domains, allowed_categories and an optional expires_at on one credential. authorize_spend sums that credential's allowed amounts for the current UTC day in the policy currency and denies with over_daily_cap when the new amount would pass daily_max_minor.",
        "Because the total is per credential, a vendor lane is a credential whose allowlist holds one vendor. Any task that uses the lane adds to the same total. A task that sends another merchant_domain to the lane gets merchant_not_allowed, so a lane can't be used as spare budget for a different vendor.",
        "Each decision is plain code, signed and written to the spend_authorizations ledger stream with spent_today_before_minor and daily_max_minor in the record. That shows, per vendor and per day, how close the agent came to the cap and which request crossed it."
      ]
    },
    {
      "heading": "The outer cap across vendors, and what Rightshold doesn't do",
      "points": [
        "Lanes cap vendors one at a time. Add an overall cap where the money moves. Stripe Issuing spending_limits take an amount and an interval (per_authorization, daily, weekly, monthly, yearly or all_time), and a cardholder's limits apply across all of their cards. Stripe aggregates spend on a best-effort basis, with up to about 30 seconds of delay.",
        "Stripe also offers per-merchant-ID spending controls, but in private preview. One virtual card per vendor is the general way to get a hard per-vendor daily limit at the card layer that matches the Rightshold lane.",
        "Rightshold records policies and signs allow/deny decisions. It does not move money, so make the payment step refuse to pay without a fresh allow (valid for 15 minutes), and have merchants or your checkout verify it free with verify_spend_authorization."
      ]
    }
  ],
  "checks": [],
  "ask_rightshold": {
    "start": "https://www.rightshold.com/start?ref=seo",
    "mcp_endpoint": "https://www.rightshold.com/mcp",
    "ask": "Set up a per-vendor daily cap for my purchasing agent: on the credential I use only for api.vendor-a.com, allow 15.00 USD per day and 5.00 USD per purchase, only for that domain. Then tell me what authorize_spend returns when a second task pushes the day's total over 15.00.",
    "mcp_call": {
      "tool": "set_spend_policy",
      "arguments": {
        "credential_id": "crd_YOUR_VENDOR_A_LANE_CREDENTIAL",
        "currency": "USD",
        "per_tx_max_minor": 500,
        "daily_max_minor": 1500,
        "allowed_domains": [
          "api.vendor-a.com"
        ]
      }
    },
    "also": [
      "Needs your owner account key. It's in the trust toolset (connect to /mcp?toolset=trust). Issue one credential per vendor with issue_agent_credential first, then set a policy on each.",
      "authorize_spend returns a signed allow or deny with every failing reason: over_daily_cap, over_per_transaction_cap, merchant_not_allowed, category_not_allowed, policy_expired or credential_revoked. The daily total resets at 00:00 UTC.",
      "verify_spend_authorization is free. Merchants or your checkout use it to check an allow before valid_until.",
      "request_human_approval binds raising a vendor's cap to a named human decision. ledger_verify is free and keyless for every policy version and decision."
    ],
    "scope": "Rightshold records spending policies and signs allow/deny decisions on a hash-chained ledger. It never holds, moves or settles money, and it has no per-merchant counter inside one credential: per-vendor caps come from one credential per vendor. Making every task call authorize_spend, and setting card or wallet limits, are steps you run around those records. Not financial or legal advice."
  },
  "sources": [
    {
      "title": "Stripe Issuing: spending controls (spending_limits, intervals start at midnight UTC)",
      "url": "https://docs.stripe.com/issuing/controls/spending-controls"
    },
    {
      "title": "Stripe: Issuing for agents",
      "url": "https://docs.stripe.com/issuing/agents"
    },
    {
      "title": "GAO-08-333: Governmentwide Purchase Cards (split purchases: same cardholder, same vendor, same day)",
      "url": "https://www.gao.gov/assets/gao-08-333.pdf"
    },
    {
      "title": "NIST SP 800-53 Rev. 5: AC-6 (least privilege)",
      "url": "https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final"
    },
    {
      "title": "Agent spending policies on Rightshold",
      "url": "https://www.rightshold.com/agent-spending-policies"
    }
  ],
  "related": [
    {
      "title": "How to set a separate budget for each AI agent calling paid APIs",
      "url": "https://www.rightshold.com/answers/how-to-set-a-separate-budget-for-each-ai-agent-calling-paid-apis"
    },
    {
      "title": "How to restrict an AI agent to an allowlist of merchant domains and categories",
      "url": "https://www.rightshold.com/answers/how-to-restrict-an-ai-agent-to-an-allowlist-of-merchant-domains-and-categories"
    },
    {
      "title": "How to set per-request and per-run spend caps for x402 agent payments",
      "url": "https://www.rightshold.com/answers/how-to-set-per-request-and-per-run-spend-caps-for-x402-agent-payments"
    },
    {
      "title": "How to alert when an AI agent approaches its spend cap before the hard deny",
      "url": "https://www.rightshold.com/answers/how-to-alert-when-an-ai-agent-approaches-its-spend-cap-before-the-hard-deny"
    }
  ],
  "computed_from": "Curated guidance; license verdicts computed from Rightshold's license profiles at render time. Not legal advice.",
  "updated": "2026-11-07"
}