Platform How it works Banks Merchants Networks Docs Pricing About Get a demo
For Payment Networks

The trust layer for
agentic commerce.

AI agents are about to initiate payments on your network — acting on a consumer's or a business's mandate. BladeRun verifies the agent, validates its mandate, and attributes every call, end to end across the issuing and acquiring sides. A verifier, not an issuer. Provider-agnostic, network-aligned. From the team behind InAuth — acquired by American Express.

0
payments we process — a verifier, not a processor
AP2
mandates verified, never issued
2
sides of the transaction, one trust layer
2016
the team American Express already acquired (InAuth)
The agent transaction

An agent is about to tap your rails — on someone's behalf.

The next transaction won't be a card or a phone. It will be an AI agent acting on a mandate — initiating a payment, comparing prices, completing a checkout. The network sits in the middle of that transaction and owns the question no model provider can answer: is this agent authorized, on whose mandate, and at what scope?

ISSUING SIDE

A bank's agent calls out to pay.

A payments or treasury agent inside an issuer initiates a transfer on a customer's behalf. Who signed the mandate? Is the agent in profile? Was this authorized — or injected?

ACQUIRING SIDE

An agent arrives at the merchant.

Operator, Claude, or a scripted agent hits a merchant checkout or API. Human, declared agent, or impersonator? Does its mandate match what it is trying to buy?

Where BladeRun sits

One trust layer across the whole agent transaction.

BladeRun is not in the settlement path. It is the verification and governance layer that wraps the agent transaction — checking the mandate on the way out, attributing the agent on the rail, and scoring the call when it lands at the merchant.

IssuerBank's agentinitiates payment on a mandate
BladeRunVerify & attributemandate valid · agent in profile · attributed
NetworkYour railsrouting & settlement — untouched
BladeRunScore the arrivalGateway + BladeRun.js at the merchant
AcquirerMerchant surfacecheckout · API · MCP
Same engine, both ends · one verified agent identity · evidence the network owns
What it does for the network

Verify the agent. Attribute the call. Govern the transaction.

Four capabilities a network needs to make agentic commerce safe — and to monetize it — that no foundation-model provider will build for you.

01 / VERIFY

Mandate verification

Cryptographically verify the agent's authority to act: AP2 payment mandates, RFC 9421 signed requests, network tokens, or enterprise agent IDs (Okta, Ping, Entra). Standards-agnostic by design — a verifier, not an issuer. We check whatever credential the agent presents and reward valid ones with a trusted lane.

02 / ATTRIBUTE

Per-agent attribution & metering

Know which agent, on whose mandate, at what volume. The attribution layer agentic commerce needs — for fraud, for chargeback evidence, and for metering. You cannot price or meter agent traffic without knowing whose call it is. This is also how a bank complies with the Section 1033 access boundary.

03 / GOVERN

End-to-end across the transaction

One governance plane on both sides: inspect, score, and enforce on the issuing side (the bank's outbound agent) and the acquiring side (the agent hitting the merchant). One event shape, one audit surface across the whole transaction — and a sub-60-second kill switch if an agent goes out of profile mid-flow.

04 / INTEGRATE

Feed the risk engines you already run

Verified agent signal — the mandate, the prompt origin, the tool call — flows into Accertify, Actimize, Feedzai, and your own models. The runtime agent context those engines never had. BladeRun produces the signal; it does not replace the engine. Additive, not competitive.

The precedent

What InAuth was for device trust, BladeRun is for agent trust.

InAuth started at the bank, expanded to the merchant, and integrated with the risk engine — and across the card networks it became infrastructure. American Express acquired it in 2016. BladeRun is the same channel model on a new surface, by the same founders. The agent-trust layer is at the 2011 stage of that curve.

Channel 01

Bank

Govern the agents the issuer runs — outbound to any model, inbound from any caller. The same wedge that started InAuth.

Channel 02

Merchant

Verify agents arriving at checkout and on public APIs — declared, undeclared, or impersonating. BladeRun.js on the surfaces you already run.

Channel 03

Risk engine

Feed verified agent signal into Accertify, Actimize, and Feedzai. The integration that turned device trust into infrastructure — repeated for agents.

Why a network

The trust layer agentic commerce needs cannot come from a model provider.

OpenAI will not govern Anthropic's agents. No issuer governs an acquirer's traffic. They are competitors. The agent transaction needs a verification layer that is provider-agnostic and network-aligned — one that sits above every model and attributes every agent, with evidence the network owns. Structurally, that is a network's role to occupy, not a model vendor's.

PROVIDER-AGNOSTIC

Above every model, by architecture.

One policy plane across OpenAI, Anthropic, Azure, Bedrock, Gemini, and self-hosted. Add a provider tomorrow; the trust posture does not change. No model vendor will govern another's traffic — only an independent layer can.

NETWORK-ALIGNED

Evidence you own, attribution you control.

Every verified agent transaction is logged immutably to storage you control — not a model provider's cloud. The attribution and audit trail the network keeps, regardless of which model the agent called.

Common questions

What network and risk teams ask first.

No. BladeRun is a verification and governance layer — not a processor, acquirer, or issuer. We verify the agent's mandate, attribute the call, and govern the agent's behavior. We never sit in the settlement path and we do not hold funds.
We are a standards-agnostic verifier. We check whatever mandate the agent presents — AP2 payment mandates, RFC 9421 signed requests, network tokens, or enterprise agent IDs — and grant valid ones a trusted lane. We do not issue a competing standard; whatever the network blesses, BladeRun is how a transaction complies with it safely.
No — additive. Accertify, Actimize, Feedzai, and your own models never had runtime agent context: the mandate, the prompt origin, the tool call, the sub-agent spawn. BladeRun produces that verified signal and feeds the engine you already run. We make your risk stack agent-aware; we do not replace it.
Pre-GA. The 2026 founding design-partner program defines the agent-trust model every later participant inherits — which is exactly why being a founding network partner matters. We are not asking for a commitment; we are asking for a working session against your rails, your standards, and your risk stack.
In your environment, under your keys. Every verified agent transaction is logged immutably to storage you control — your S3, your KMS, your retention policy. The attribution and audit trail belong to the network, not to whichever model the agent happened to call.
Start with a conversation

Agents are about to transact on your rails.
Be the network that governs them first.

A working session with the founders — the agent transaction mapped against your rails, your standards, and your risk stack. No slides. No procurement. Just the architecture you would actually deploy.