Add MCP server actions limits

[JavierCane]

Scenario

I want to let AI agents interact with the MCP Server having autonomy to make refunds, cancel subscriptions, and so on.

What can I do right now: Enable the Stripe MCP server in my account, create a restricted key allowing these kind of actions, configure my agent with that MCP server and API key.

Problem

I am not limiting the option that the agent refunds the last 1.000 payments, cancels all the active subscriptions, or any other harmful action.

How this could be possible:

• For some reason such as the agent misunderstanding some instruction. Example:
  1. The user sends a message like "refund all his charges" after a previous message fetching the information of a customer
  2. The AI agent starts calling the refund MCP server tool for each one of the Stripe account payments
• Someone bypassing the agent guardrails.

Ideas

One solution could be something like being able to limit the amount of refunds to perform per day via MCP + having thresholds for warnings in these kind of operations.

It would be similar to managing spending limits in server providers such as Vercel. Some kind of "Stripe MCP server limits" configuration page with options for the different write permissions such as:

• Do not allow to make more than 10 refunds per day.
• Send an email when reaching the 75% of that limit.
• Checkbox like "Send email notifications for MCP server usage anomalies" that produces alerts such as "5 subscriptions cancelled in less than 1 minute via MCP".

Thanks!

[Josepassinato]

This problem is exactly what gets surfaced the moment agents start calling write-side payment APIs autonomously, and it doesn't really resolve at the MCP-server layer alone — the agent ends up sitting between an LLM (which can be jailbroken or misread instructions) and a payments API (which is non-reversible). Restricted keys help, but they're a coarse instrument: they say "this key can do refunds", not "this key can do at most 5 refunds totaling under $X today, only for customers in this allowlist".

I've been working on this from the agent-side governance angle (project: PayJarvis, https://github.com/Josepassinato/payjarvis-core, Apache 2.0). The pattern that turned out to matter in practice maps cleanly to what you're describing:

1. Pre-action policy gate. Before the agent calls a sensitive MCP tool (refund_payment, cancel_subscription, etc.), it requests approval against a policy. The policy evaluates per-action limits, daily/weekly/monthly caps, category allow/blocklists, merchant/customer allowlists, and time windows. Decision: auto-approve, owner-approve (push notification with context), or block.

2. Cryptographic authorization for the call that actually goes out. Approved actions get a short-lived RS256 JWT (5-min expiry, single-use jti) bound to that specific tool call. The receiver verifies via JWKS, no callback to the policy issuer needed.

3. Anomaly thresholds. "Refund all charges" is exactly the pattern that should trigger a hard pause and an owner approval, not just a per-call limit — the system should detect the velocity, not only the per-call value.

The reason I think this lives partially outside Stripe (or any single payment provider) is that owners typically run agents that touch multiple destinations — Stripe for refunds, Shopify for orders, AWS for infra, etc. — and they want one consistent policy/audit trail across all of them. But there's also a clear case for Stripe-native MCP-level limits (rate limit, daily cap, simulation mode) for the specific Stripe surface, and I'd +1 that strongly.

Happy to share the BDIT spec or compare notes if useful: https://github.com/Josepassinato/payjarvis-core/blob/main/docs/bdit-spec/BDIT-SPEC.md

— José Passinato (PayJarvis)

[musaabhasan]

For payment-side tools, I would not rely on the restricted key alone. The key defines which API families are technically reachable, but the missing control is an action envelope around each agent task.

A useful design is to make the MCP server or gateway enforce a policy object before every write-side call: subject, intent, exact resource scope, max amount, max count, aggregate window, retry limit, idempotency key, approval threshold, and evidence fields.

That prevents the “refund all charges” failure mode because even if the agent loops, the gateway sees the second, third, or thousandth refund attempt as outside the approved envelope. I would also add a dry-run mode for high-impact actions: the agent can propose affected payments or subscriptions, but execution requires a separate approval bound to those exact IDs and amounts.

[egoriklok]

This is the right failure mode to model: restricted keys define reachable API families, but they do not fully define the authorized action envelope for an autonomous agent.

For write-side payment actions, I would separate three layers:

1. Permission reachability — what the restricted key/MCP server can technically call.
2. Action envelope — what this specific agent task is allowed to do now: action type, resource IDs, max count, max amount, aggregate window, retry/idempotency rule, and approval threshold.
3. Evidence + revocation — what record proves the action was authorized/executed, and how the permission is reduced or revoked after the task.

A minimal policy object for the “refund all charges” case could be:

agent_action_envelope:
  action: refund_payment
  scope:
    customer_ids: [explicit IDs only]
    payment_ids: [explicit IDs only]
  limits:
    max_refund_count: 1
    max_total_amount: "100.00"
    currency: USD
    window: per_task
  controls:
    dry_run_required: true
    owner_approval_required_above: "0.00"
    idempotency_key_required: true
    loop_detection: block_after_first_unapproved_attempt
  evidence:
    approval_source: human | policy_engine
    audit_record_required: true
    revocation_path: reduce_key_or_disable_policy

The important boundary is that the agent should first produce the candidate affected objects in dry-run mode. Execution should require a separate approval bound to those exact IDs and amounts. If the model loops or broadens the scope, the second call falls outside the envelope and blocks.

For docs, a short “before enabling write-side MCP tools” checklist could help operators:

• Which actions are reachable?
• What per-task and aggregate limits apply?
• Who/what approves exceptions?
• What evidence proves approval and execution?
• How are duplicate/looped calls blocked?
• How is access revoked or reduced?

This stays secret-free: no API keys, customer data, or payment credentials need to be shared to define the envelope.

[rpelevin]

I like the direction of the policy and envelope ideas above. The one split I would keep very clear is that the limit object should not become the proof of authority. Limits and policies can say what the agent is allowed to try, but for something like a mass refund I would want the first tool call to stop at a dry run and show the exact customers, payments, amounts, and reason. Execution should need a separate receipt for that exact set before anything moves. If the agent changes scope, retries with different parameters, or broadens the list, the receipt no longer matches and the payment call does not go through. That keeps Stripe keys and MCP permissions focused on what the agent can reach, policies focused on what it should stay within, and the receipt focused on the human question that matters later. Who approved exactly what before money moved.