Stripe

General Analysis reported a demonstration in July 2025. An assistant had both a messaging integration and the Stripe MCP server, which used the account’s secret key with default permissions. A plain text-message request for a $50,000 coupon was refused: the assistant asked the owner to confirm. A second message faked an earlier conversation in which the owner appeared to approve the coupon, and the assistant created it. The tool call appeared in the interface, but nobody was watching. It was a demonstration, not a reported loss.

Stripe’s own guidance makes the general case: a secret key has unrestricted permissions on every Stripe API, and Stripe recommends restricted keys for most uses. Restricted keys can also be tagged as belonging to an autonomous agent.

• An agent or MCP server gets a restricted key with only the permissions its task needs. A key that cannot create coupons or refunds cannot be talked into creating them.
• Do not auto-approve tool calls that move money — coupons, refunds, credits, payouts.
• Do not connect payment tools to an assistant that also reads messages from the public. That pairing is what the demonstration exploited.

• Verify Stripe-Signature against the raw request body, before parsing it. Frameworks that parse JSON first break verification, and the tempting fix is to skip it. Never skip it — an unverified webhook is an open endpoint that grants access.
• Send an idempotency key with every request that creates or charges, so a retried request cannot charge twice.
• Handle each event idempotently. Stripe may deliver an event more than once, and not in order. Key on the event id, and derive state from the object rather than from the order events arrived in.
• Never put a live key (sk_live_) in a fixture, a test or an example env file. Use test-mode keys, and restricted keys for anything that only reads.