Perimeter Where each capability sits at your merchant perimeter
MERCHANT PERIMETER Shopping AgentOPERATOR · CLAUDE · BOT AP2 / MPPPROTOCOL TRUST ROOTS BladeRun.jsPAGE TAG · IN BROWSER CDN · WAFEXISTING EDGE BladeRun GatewayAT AGENT BOUNDARYVERIFY · SCORE · LOG Fraud EngineYOUR EXISTING STACK Merchant APICART · CHECKOUT · INV Issuer / AcquirerPAYMENT · CHARGEBACK Time MachineYOUR S3 · CHARGEBACK PROOF Merchant FederationCROSS-MERCHANT SIGNAL
The five capabilities

One agent boundary, five jobs.

Capability 01 · Identity

Every inbound agent is verified at two boundaries.

BladeRun verifies agent identity at both your boundaries: BladeRun.js on the page when the agent first lands on your customer-facing surface, and BladeRun Gateway at the API when the agent calls your checkout. Registered agents arrive with verifiable mandates carrying scope, spend cap, and the principal who issued them. Unregistered agents are scored against a behavioral baseline at both points.

The agent boundary is your new perimeter. The verifier sits in front of your existing fraud engine, not next to it.

Where: BladeRun.js in your customer-facing pages and the BladeRun Gateway at your API edge, both validating against the published protocol trust roots.
Capability 02 · Signal

Separating legitimate agent traffic from scripted abuse.

Most merchants today either reject all bot traffic, including the high-conversion shopping agents, or let synthetic abuse through. Both are bad. BladeRun.js scores the agent at the page layer the moment it lands; the Gateway picks up the scored session when the same agent calls your API. Your fraud engine sees a labeled request, not a guess.

Your highest-intent purchase channel, registered, mandated agents, gets a clean conversion path. Everything else gets scored or blocked.

Where: BladeRun.js on customer-facing pages + the Gateway carrying the page-side score forward into the rest of your stack.
Capability 03 · Policy

Mandate scope and merchant policy enforced at the boundary.

An AP2 or MPP mandate is more than just a credential. It carries explicit authorization scope: which merchants the agent may transact with, which categories, which spend cap. The Gateway enforces that scope on every request before it reaches your checkout.

Your existing fraud rules consume the BladeRun signals as additional features. Your downstream API code does not change.

Where: the BladeRun Gateway in front of your fraud engine and merchant API.
Capability 04 · Evidence

Per-agent forensic evidence for every chargeback.

When an issuer disputes an agent-initiated transaction, you have the entire context in one signed packet: agent identity, verified mandate, scope match, behavioral score, cryptographic timestamp. Stored in your S3 bucket, under your KMS keys.

Disputes that previously tilted against the merchant by default now have evidence the issuer can validate independently.

Where: Time Machine writing to your storage. Issuer-ready chargeback packets exportable as a single click.
Capability 05 · Collective defense

Cross-merchant signal, one merchant's catch becomes every member's defense.

Opt-in. The Gateway forwards anonymized, one-way signal hashes, synthetic-agent fingerprints, mandate-spoof patterns, abuse signatures, to the merchant Federation Network. Within a minute, every other member merchant has the protection.

Your data does not leave your environment; only the privacy-preserving signal hash does. Membership is double-blind, even from BladeRun staff.

Where: Federation Service operated by BladeRun. Your client publishes one-way hashes; you receive everyone else's.
The deployed components

Each capability is a deployed BladeRun product.

Pilot it on your traffic

One CDN routing rule. Visible results in 48 hours.

Point one endpoint at the BladeRun Gateway, search, cart, or checkout. The first week runs in shadow mode so your team sees the agent breakdown on real traffic before any enforcement is enabled.