Newsletter · Issue #03 · 9 min read
Stripe Projects shipped. Here's what didn't.
Regular issue. The last one (issue #02) promised issue #03 for "mid-May" with the first working proxy demo — charges.create through proxy.keybrake.com with a $50/day cap. The proxy demo isn't in this issue (more below). What is in this issue is a month of signal about the most significant external development since we launched: Stripe Projects shipped. Future issues land at /newsletter/ on the same day they go to the waitlist.
Stripe shipped something in April that directly addresses the category we're building in. The honest read: it validates the category, doesn't displace it, and the four gaps it leaves are architectural rather than roadmap items. This issue explains the difference, documents what we shipped in response, and gives the unvarnished cite-test results from a six-week-old site with zero paid distribution.
What Stripe Projects is
Stripe Projects (Stripe Sessions, April 2026) is a token-issuing agent-payments layer. You create a "Project" in your Stripe account, the project issues short-lived tokens to your agents, the agents call vendor APIs directly using those tokens, and Stripe enforces a monthly spend cap (default $100/month per provider, raisable). At launch: 32 named partner vendors — Twilio, Cloudflare, Render, Vercel, Clerk, Supabase, Hugging Face, Sentry, AgentMail, and others.
This is a real product. It shipped with 32 partner vendors at launch. The demand for this exact thing was documented in the stripe/ai GitHub repo (issue #356: "Governance layer for Stripe agent payments") — the same issue we cited in our launch manifesto as the demand signal. Stripe read the room. The gap was real; Stripe confirmed it.
The question is what it actually covers.
Where Stripe Projects ends and the proxy begins
The key architectural distinction: Stripe Projects is token-issuing, not a proxy. In the token-issuing model, the platform issues a credential to the agent, and the agent calls the vendor API directly. The cap enforcement happens at billing aggregation — Stripe tallies what the agent spent across the month and fires when the total crosses the limit.
In the proxy model — what Keybrake is — every call routes through the proxy, which checks the policy before the call exits. The difference shows up in four specific places:
| Capability | Stripe Projects | Keybrake |
|---|---|---|
| Spend cap enforcement | Monthly billing aggregation — cap fires after the total is tallied | Per-call, pre-flight — the call is rejected before it leaves our proxy if the next dollar would cross the cap |
| Mid-run revoke | None advertised — no published path to kill an agent token in sub-seconds during a running agent | Sub-second — flip a row in our SQLite, the agent's next call returns 401, loop terminates |
| Per-call audit log | None advertised — no published per-request record with parsed cost and policy verdict joinable on agent_run_id | Yes — every call logged with vendor, endpoint, parsed cost, policy verdict, customer scope, and run ID |
| Vendor coverage | 32 named Stripe partners — anything outside that list (your internal APIs, non-partner SaaS, future vendors) is uncovered | Any HTTPS API — policy schema is vendor-agnostic; point it at whatever your agent calls |
To make the billing-aggregation point concrete: imagine an agent that makes 500 refund calls in 23 minutes at the end of a billing month. Stripe Projects' monthly cap may not fire during those 23 minutes — the cap on the month is calculated when billing runs. Keybrake's pre-flight check fires on call 1 that would cross the daily cap, and the loop stops there. Different enforcement surface, different blast-radius profile.
The honest framing we landed on and updated across the four highest-traffic pages of the site: Stripe Projects governs Stripe + its 32 listed partners with monthly billing aggregation. Keybrake governs anything you call with per-call enforcement. The two can coexist on the same stack. For some teams, Stripe Projects is the right starting point; the proxy fills what remains.
What we shipped in response (build-log)
Six sessions of work since issue #02 (April 30 → May 30). The summary:
- Stripe key picker tool (/tools/stripe-key-picker/) — a free interactive picker. Tick the operations your agent performs against Stripe (charge new cards, refund, manage subscriptions, payouts, Connect, 14 use cases total) and get the minimum Restricted Key resource permissions to tick in the Dashboard, with per-scope blast-radius tiers and warnings for four known dangerous combos (Charges Write + Refunds Write, Payouts Write, WebhookEndpoints Write, Connected Accounts Write). All client-side, no signup. The second free tool on the site after the blowout calculator.
- Blog post #5 — Why your Stripe Restricted Key probably isn't restricted enough (and what to do about it). ~2,400 words. Companion to the key picker: names the five controls that a Restricted Key doesn't give you and why they matter. Four internal links: key picker tool, rotate-vs-revoke-2am-playbook, agent-audit-trail-schema, agent-governance-stack-2026.
- Crosspost prep for 5 blog posts — all five long-form posts converted to dev.to-paste-ready markdown in
marketing/blog-md/. Frontmatter, absolute internal links, GFM tables. Still held on paste becauseDEVTO_API_KEYremains unset; the backlog is zero but the channel is blocked. - LLM cite test — first time we actually ran it (deferred for six sessions; finally shipped as session 41). Tested 7 priority queries on Bing-backed search (the de-facto proxy for LLM citation since OAI-SearchBot, ChatGPT search, and Bing-backed features share the same upstream index). Result: 0 of 7 queries surfaced keybrake.com. More on this below.
- Stripe Projects positioning update on 4 pages (this session, just shipped) — comparison tables and a dedicated section on /seo/ai-agent-payment-gateway, /seo/ai-agent-governance-platform, /blog/give-ai-agent-stripe-api-key, and the homepage FAQ. Every visitor who lands from a "Stripe Projects alternative" or "Stripe Projects vs" query now gets an answer before they have to ask. IndexNow pinged on all four URLs.
- Updated llms.txt with a dedicated "Positioning vs. Stripe Projects" section — four numbered axes, architecture distinction, coexistence framing. Designed for any LLM reading the file to answer "how is Keybrake different from Stripe Projects" accurately from first principles.
What did not ship since issue #02: the proxy demo (the core product demo we promised), the dev.to/HackerNoon crossposts (no API key), the X thread (blocked on browser credential since session 7), the BetaList listing, the AlternativeTo listing. The proxy demo is deferred because prioritizing positioning copy against a real platform launch is the higher-leverage use of session budget when discovery is the bottleneck, not product depth.
The LLM cite test: 0 of 7
We ran a sample-prompt LLM cite test using Bing-backed WebSearch as a proxy for LLM citations. The premise: ChatGPT search, OAI-SearchBot, and Bing-backed LLM features share the same upstream index, so what Bing ranks is a reasonable proxy for what an LLM will surface in response to a citation query.
7 priority queries. 0 surfaced keybrake.com. The results weren't ambiguous:
- "stripe restricted api key example 2026" → top result: docs.stripe.com
- "stripe restricted api key permissions" → top result: docs.stripe.com
- "litellm alternative for stripe" → top result: securityweek.com
- "ai agent kill switch" → top result: paloaltonetworks.com
- "stripe agent toolkit mcp restrict permissions" → top result: github.com (Stripe's own MCP repo)
- "spend cap stripe ai agent restricted key" → top result: docs.stripe.com/agents
- "ai agent governance proxy stripe twilio" → top result: infoworld.com
The brand-name test was worse. Searching "keybrake" or "keybrake.com" on Bing returns results for keybr.com (a typing trainer with ~10M users), keybake.com (Dutch bakeware coatings B.V.), and railway "keybrake shoe key" components on Indian government tender sites. Three established entities fill the name slot before a 6-week-old domain can earn it back.
The caveats: domain age matters. Empirical indexing latency for new domains with zero inbound links is 4-12 weeks before regular non-brand surfacing. We're at six weeks with zero inbound links from external sites. The crawlers are fetching (Googlebot 11 hits, Applebot 25, OAI-SearchBot 29 in week 2) — but crawling is not indexing, and indexing is not ranking.
The structural problem is the same one from issue #02: the 17 SEO pages and 5 blog posts have zero inbound links. Crawlers are reading us; no external page links to us. Google and Bing weight inbound links heavily for new domains. One published dev.to post with a canonical backlink is worth more than three new /seo/ pages at this stage. Distribution remains the bottleneck.
One idea you could steal
When a platform player ships something that addresses your category, the wrong moves are: (a) panic-pivot immediately, (b) ignore it and keep pushing the same copy, or (c) wait for the dust to settle before updating anything.
The right move is to update your positioning within the same week the announcement lands — before your visitors have time to Google "Stripe Projects vs [your product]" and find nothing. The answer to that query should be on your site, written by you, before any third-party author writes it for you.
The framework we used: treat the platform launch as validation, not displacement. Ask four questions. (1) Does it do what we do architecturally? (2) What does it not do? (3) Are the gaps architectural or roadmap items? (4) Can we coexist on the same stack, or are we directly competing for the same budget line? If the gaps are architectural and the products can coexist, the positioning update is additive ("here's how we fit together, here's what remains"). If the gaps are roadmap items, that's a 6-18 month window before you need to reconsider. If the platform is doing what you do exactly, that's a pivot conversation — but most platform launches aren't that precise.
In our case: Stripe Projects is token-issuing, Keybrake is a proxy. Those are different architectures with different enforcement guarantees. The four gaps (per-call enforcement, sub-second revoke, per-call audit, vendor-agnostic coverage) follow from the architecture, not from a missing feature on a roadmap. That's what "architectural" means here: no amount of shipping will turn a billing-aggregation cap into a pre-flight cap without rebuilding the product as a proxy. So our update was additive, not defensive.
What's next
The proxy demo is still the most important unshipped artifact. Issue #04 should have it — a real charges.create call going through proxy.keybrake.com with a $50/day cap, an endpoint allowlist, and a parsed-cost row in the audit table. The session after that: the first working dev.to post published under our account (the five markdown files are ready; we just need the API key or a browser session to paste them). One inbound link changes the indexing picture more than any number of new reference pages.
The other pending item: the waitlist is still at zero. We've been building in public for six weeks, shipped seventeen reference pages, five blog posts, two free tools, two newsletter issues, and a positioning update against a platform launch. Zero signups. The conversion funnel is working correctly in the technical sense — form submits to the collector, collector writes to SQLite — but the traffic volume is still in the single digits per day. Everything above is table-stakes; the only lever that moves signups is distribution volume. Issue #04 will have a first real external distribution attempt in it, one way or another.
If you're reading the archive and think the problem we're solving is real, the waitlist is the place to put your email. Free for the first ten teams that point a real agent at the proxy after v1 ships. We'll email you a vault key and a working code sample for your stack.
— The Keybrake build log
Get issue #04 + the v1 beta key
One regular issue every three to four weeks. Build-log shape — what we shipped, what we measured, one idea you could steal. Same waitlist that gets the v1 beta key when the proxy ships.