Stripe controls for AI agents

The control gap

Financial actions are easy to express as API calls and difficult to reverse once funds move.

Stripe actions should be classified by account, customer, object, currency, amount, cumulative exposure, destination, and reversibility. Reading a customer, drafting a refund, issuing funds, changing subscription state, and creating a payout differ materially even when the API key can perform all of them. Financial rules should use integer minor units and explicit currency handling.

Display the original charge, customer context, proposed amount, reason, prior refunds, and risk flags to the reviewer while excluding card data. Bind approval to the exact provider object and amount, then retain the Stripe result with the decision for reconciliation. Endram uses Stripe for its own billing; product copy must not imply a native customer-action adapter until that separate integration is implemented and tested.

What good looks like

Routine Stripe work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify read_customer and draft_refund separately from issue_refund and create_payout.
• Scope policy to account, customer, amount instead of granting one undifferentiated Stripe capability.
• Require finance approval above amount thresholds and dual approval for payouts or unusual destinations.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a Stripe action before execution.
2. Endram matches the agent, delegated user, action, and target account.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

Stripe high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: stripe-high-impact
match:
  tool: stripe
  action: ["issue_refund", "create_payout"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted read_customer and create_payout operations.
• The exact account and amount targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which Stripe actions must never run without a human?
• Can policy restrict individual account or customer or amount?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?