When Stripe Projects isn't enough — and what to reach for

What Stripe Projects does well

First, the things Stripe Projects genuinely solves:

• Billing aggregation across 32 partner vendors. Twilio, Cloudflare, Vercel, Supabase, Hugging Face, Sentry, AgentMail and 25 others flow through Stripe's billing graph natively. If your agent stack is built on this partner list, you get spend tracking across all of them without deploying any infrastructure.
• Token issuance at the Stripe layer. Stripe Projects can issue tokens to agents that limit what actions they can take and tie billing to the project. The integration is native to Stripe's platform, which means lower friction if you're already a Stripe Billing customer.
• Monthly spend ceiling. When a Project's cap is hit, Stripe stops billing further charges to that Project. The cap is configurable ($100/month default, raisable). For high-level budget governance — "don't let this agent spend more than $500 in Twilio credits this month" — this works.
• No infrastructure to operate. Stripe Projects is a Dashboard configuration, not a service you run. For teams with minimal ops surface, this is real value.

The four gaps

Gap 1: No pre-call enforcement

Stripe Projects' cap fires at monthly billing aggregation. That means every charge in the month already executed before the cap became relevant. In a tight stuck loop — an agent retrying a failed payment 400 times per second — a monthly cap can be exhausted in milliseconds of real time. Every one of those charges already landed before the billing system registered the total.

A pre-call enforcement proxy checks the agent's policy before forwarding the request to Stripe. If the per-call cap would be exceeded, the request returns a 429 to the agent. The charge is never created. The downstream side effect never happens.

If your risk model is "don't let this agent create more than X charges per day" rather than "don't bill more than $Y to this Project in a month", you need pre-call enforcement — not monthly aggregation.

Gap 2: No per-call audit log

Stripe Projects provides billing-aggregation summaries: total spend per vendor per month, per Project. There is no per-call log — no record of which endpoint was hit, which customer ID was passed, what the response code was, or what happened in what order.

When a stuck loop runs and you need to understand which customers are affected and in what sequence, a billing summary doesn't give you enough. You need the row: timestamp, vault_key or agent_run_id, vendor, endpoint, request params, vendor-parsed cost, HTTP status, latency. That row is what the 2am incident reconstruction query runs against.

See the audit trail schema post for the full 16-column design — the rows you want, the indexes that make them fast to query, and the sample queries (top-10 spend spikes, all cap-exceeded calls, per-agent-run reconstruction).

Gap 3: No sub-second mid-run revoke

Stripe Projects doesn't advertise a revocation path that propagates in under a second. If an agent is running right now — creating charges in a tight loop — and you need it stopped immediately, waiting for monthly billing to close is not an option.

A vault-key revoke in Keybrake propagates in median under 5 seconds: flip the status to revoked in one API call, and the next request from any agent using that key returns a 401 before the charge reaches Stripe. See the 2am revoke playbook for the latency numbers and decision tree.

Gap 4: No coverage outside Stripe's 32 partners

Stripe Projects governs spend across its named partner list. If your agent also calls APIs that are not in that list — a custom internal billing API, a niche payment processor, a SaaS vendor that hasn't partnered with Stripe — those calls are outside Stripe Projects' visibility entirely.

Most production agent stacks call at least a few APIs that will never be Stripe partners. A governance layer built on Stripe Projects has a fixed ceiling on coverage. A proxy-based governance layer covers any HTTP API you configure.

Who needs an alternative (and who doesn't)

Keybrake as a Stripe Projects alternative — and complement

Keybrake is not a Stripe Projects replacement for teams that want billing-platform integration. It's the enforcement layer that sits upstream of both Stripe Projects and the actual charge.

Adding Keybrake to an agent that uses Stripe is two changes:

1. Issue a vault key via the Keybrake API (sets per-vendor daily cap, endpoint allowlist, expiry).
2. In your agent, set STRIPE_API_KEY=vault_key_xxx and STRIPE_BASE_URL=https://proxy.keybrake.com/stripe.

Every Stripe request now flows through Keybrake first. If it passes policy, Keybrake forwards it to Stripe with the real Stripe secret key (which the agent never sees). The charge lands in Stripe's billing graph and flows into Stripe Projects' aggregation as normal. You get both enforcement layers: Keybrake fires at request time, Stripe Projects fires at billing aggregation time.

FAQ

Does Keybrake work with Stripe Projects?

Yes. They operate at different points in the request lifecycle and don't conflict. Keybrake enforces pre-call; Stripe Projects enforces at billing aggregation. If you run both, you get two enforcement layers: Keybrake blocks bad calls before they execute; Stripe Projects provides the billing cap as a second line of defence.

Is Keybrake only for Stripe?

No. Keybrake governs any HTTP API — Stripe, Twilio, Resend, Shopify Admin, or any custom internal API. The vault key policy includes a vendor field, and each vendor has a separate cap and allowlist configuration. Stripe Projects is Stripe-native only.

What happens when a Keybrake cap is exceeded?

Keybrake returns a 429 to the agent with a Retry-After header. The request is not forwarded to the vendor. The charge is never created. If the agent retries immediately, it continues to get 429s until the cap window resets or a human changes the policy.

Does Keybrake replace Stripe Restricted Keys?

Not necessarily. Stripe Restricted Keys cover resource-level and permission-level scope natively within Stripe. Keybrake adds what Restricted Keys can't do: per-day spend cap, mid-run revoke, per-call audit with parsed cost, and customer-scope allowlist for non-Connect accounts. The most robust setup uses both: a Restricted Key stored in the Keybrake proxy (the agent never holds it), Keybrake adding the four capabilities Restricted Keys lack.