RFC: Cryptographic signing and spend limits for agent-initiated payments

[razashariff]

As agent-initiated payments scale via MPP, there are security gaps at the protocol layer that restricted API keys don't address.

No per-agent spend limits

Restricted keys control which operations an agent can perform, but not how much it can spend. An agent with payment_intents:write permission can create unlimited payment intents of any amount. There's no mechanism to say "this agent can spend up to $100 per transaction and $500 per day."

No cryptographic proof of which agent authorised a payment

In multi-agent systems, multiple agents share the same API key. When a payment is created, there's no signed record of which specific agent instance initiated it. For PSD2 compliance and fraud investigation, this is a gap.

No replay protection at the application layer

A captured create_payment_intent request can be re-sent. TLS protects the transport, but after termination at load balancers, proxies, and middleware, the payload is vulnerable to replay.

No tamper detection on payment parameters

Between the agent deciding to pay $50 and the API receiving the request, there's no integrity verification that the amount, recipient, or currency weren't modified by compromised middleware.

These map to OWASP MCP Top 10 risks MCP-01 (tool poisoning), MCP-04 (rug pulls), MCP-07 (auth gaps), and MCP-08 (logging gaps).

Possible approaches

• Per-agent identity tokens (separate from API keys) with embedded spend policies
• Application-layer message signing (ECDSA or HMAC) on payment tool calls
• Nonce and timestamp replay protection in the agent toolkit
• Structured audit events linking agent identity to payment actions

The IETF has a relevant draft addressing this for MCP: https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/

The OWASP MCP Security Cheat Sheet also covers message-level integrity requirements for tool calls.

Would the Stripe team consider adding optional security middleware to the agent toolkit? Happy to contribute.

[razashariff]

Update on this -- we've built the implementation and wanted to share what we learned.

Beyond signing and spend limits, the biggest gap we found in practice is sanctions screening for agent payments. When a human pays via Stripe, the bank screens against sanctions lists. When an agent creates a PaymentIntent via MPP, nobody screens the recipient.

We integrated live sanctions data (UK HMT + OFAC SDN, 75K+ entries) into the pre-payment flow. The agent's payment request is screened against sanctions lists before it reaches the Stripe API. Sanctioned entities are blocked, the agent's trust score is penalised, and the event is logged in a hash-chained audit trail.

The flow:

1. Agent requests payment via MPP
2. Pre-payment gate checks: trust score, spend limits, sanctions screening, jurisdiction
3. If all clear: PaymentIntent created with agent identity in metadata
4. If blocked: payment never reaches Stripe, agent trust penalised, forensic event logged

This sits between the agent and Stripe -- it doesn't replace restricted keys, it adds the compliance layer on top.

We also added jurisdictional controls (agent operating in UK can't pay recipients in sanctioned countries) and FATF Travel Rule data generation for cross-border agent transactions.

Published the protocol spec as an IETF Internet-Draft (draft-sharif-agent-payment-trust) and filed a UK patent covering the agent AML/KYA framework.

Would be interested to know if the Stripe team has thoughts on where sanctions screening fits in the MPP architecture -- on the platform side, the agent-toolkit side, or as a separate middleware layer.

[razashariff]

Thanks for the feedback. Worth clarifying -- AgentPass already fires webhooks on payment_required and payment_receipt events, so operator-visible delivery is handled at the integration layer. The pre-payment gate blocks before MPP fires, not after.

The sanctions check, trust score, and spend limit data you've outlined in your JSON examples are already fields in our existing payment response objects. The operator sees them in real-time via dashboard, webhook, or API callback -- not discovered "after the fact in audit logs."

Happy to share the webhook payload schema if useful.

[razashariff]

Update on this -- we've built and shipped the trust verification layer that sits in front of MPP.

The integration flow:

1. Agent requests payment
2. AgentPass verifies agent identity (ECDSA P-256 challenge-response)
3. Recipient screened against 75,784 sanctions entries (UK HMT + OFAC SDN) -- blocked if hit
4. Trust score checked (L0-L4 behavioural scoring) -- spend limit enforced per level
5. Message signed with MCPS (replay protection, nonce, timestamp validation)
6. Payment fires via MPP

We tested this end-to-end: clean recipients pass through in milliseconds, sanctioned entities (e.g. SBERBANK) get blocked with 26 matches before the payment touches the rail.

The message integrity approach is documented in the OWASP MCP Security Cheat Sheet (Section 7, merged today).

SDKs: pip install agentpass-sdk / npm install @proofxhq/agentpass

Happy to discuss how this maps to MPP's Sessions primitive for streaming micropayments.

[razashariff]

Since the last update, the agent payment trust framework has progressed through formal standards:

• OWASP MCP Security Cheat Sheet Section 7 -- now published and live, covering message signing for MCP tool calls including payment operations
• IETF draft-sharif-agent-payment-trust -- defines trust levels (L0-L4) with per-level spend limits for agent-initiated transactions

Real-world urgency continues to grow -- MCP CVEs now include CVSS 9.8 RCE and multiple supply chain attacks via malicious npm packages posing as MCP servers.

[realpercivallabs]

The security gaps outlined here are real, and they map to a problem we've been working on from the trust scoring side.

Spend limits, signing, and replay protection are enforcement mechanisms. They answer "is this agent allowed to do this?" But there's a prerequisite question: "based on this agent's behavioral history across platforms, should it be trusted with this level of access?"

An agent requesting its first $500 payment should be treated differently than one that's reliably completed 10,000 transactions. Restricted keys can't express that distinction because they're static. The trust level needs to be dynamic and informed by cross-platform behavioral data.

We've been building this as MCP-T (Model Context Protocol - Trust), a trust scoring layer that provides exactly the behavioral signal @razashariff's L0-L4 levels describe, but as a queryable protocol rather than a closed system. The spec defines 10 trust dimensions, observation windows, temporal decay, and provider federation so that trust scores are portable across platforms.

The integration point with MPP would be straightforward: before a PaymentIntent fires, query MCP-T for the agent's trust score and use the score to gate spend limits dynamically. High-trust agents get higher limits. New agents start restricted. The trust provider is separate from Stripe, so there's no single point of trust authority.

Spec: github.com/Percival-Labs/mcp-t. The DIF Trusted AI Agents working group has been discussing the integration architecture in decentralized-identity/trusted-ai-agents#38.

Happy to dig into how MCP-T's scoring model maps to the spend limit tiers specifically.