Mastercard Agent Pay's New Trust Signals: What Is Actually Available

The payment question is shifting from “is this a bot?” to “is this the agent the customer intended to use, for the purchase they allowed?” Those are not the same classification problem. Mastercard's 30 September announcement makes the separation visible: its first new service scores the likelihood that an AI agent initiated a transaction, not whether the user approved that particular purchase.

What was announced

Mastercard expanded Agent Pay with what it calls trust and intelligence services for AI-initiated transactions. Its first service is a probability score identifying likely agent initiation. The announcement says that score is rolling out for testing in the United States. It does not say it is generally available to all issuers or merchants.

Mastercard says it will strengthen the score over time with context about behavior, merchant risk, transaction patterns, credential risk and consumer propensity. Those are described as future enrichment, not a published list of live features an operator can already consume. Mastercard separately describes work with Cloudflare on privacy-preserving web and network signals and with Skyfire on agent identity. The announcement does not say those collaborations constitute live, general integrations available to every participant.

The score sits inside Mastercard's broader Agent Pay Trust Framework. Mastercard names five elements: identity, intent, controls, execution and intelligence. Its accompanying framework explanation discusses Verifiable Intent as an open-source concept for evidence of the user's instruction. Do not flatten these into one feature. Identifying a software actor, recording its delegated instruction, bounding a credential and scoring transaction risk each answer a different question.

The operator distinction

This table is PaymentBrief's operational interpretation of the announced framework. It does not describe four Mastercard API fields. An issuer may use agent context to distinguish a legitimate travel booking across several merchants from suspicious automation, but the issuer still makes the authorization decision. A merchant still needs its own order, payment and fulfilment evidence.

The Mastercard release does not disclose a score threshold, model performance, API schema, latency, pricing, participating banks, general-availability date or changed chargeback allocation. These are not reasons to dismiss the service; they are the questions to ask before changing a production risk rule. A new agent signal should be evaluated against false positives, fraud outcomes and customer friction in the actual portfolio, not presumed to be a consent certificate.

What to ask before integration

If your team is invited into the US test, ask which transaction flows are included, who receives the score, whether it arrives before an authorization or only for later analysis, how it should be interpreted alongside existing fraud controls, and what evidence can be retained for disputes. Ask separately how agent identity and customer intent are captured; the probability score cannot answer those questions by itself.

For a wider map of payment authorization, checkout and agent identity, see the agentic protocol comparison. The operator overview sets out the purchase records that must still join together after an agent acts.