Platform How it works Banks Merchants Networks Docs Pricing About Get a demo
BladeRun.js · Shipping

The page tag at your
customer-facing surface.

When a shopping or payment agent lands on your site, BladeRun.js sees it. It detects the agent at the browser layer, accepts attestation tokens from registered agents (Operator, Claude, partner-issued bots), and scores synthetic abuse — all before the agent ever calls your API. One script tag in your page head; the same data plane as Gateway and Time Machine.

Get a demo Read the install docs
1 line
install · script tag in page head
browser
side · before any API call
<5ms
page-load overhead
100%
agent traffic visible at the page boundary
What BladeRun.js does

Three responsibilities. One script tag.

01 / Detect

Detect AI agents arriving at your page before they call your API.

Most shopping and payment agents land on your customer-facing pages first — to browse the catalog, validate inventory, check pricing — before ever calling a checkout API. BladeRun.js runs in the browser at that moment. It collects browser-environment signals that distinguish a real human visitor, a registered shopping agent (Operator, Claude, partner bot), and a scripted bot impersonating one.

  • Headless-browser detection. Puppeteer, Playwright, headless Chrome, undetected-chromedriver — all flagged.
  • Automation-pattern signals. Mouse movement entropy, dwell time, scroll behavior, focus events. No personal data — just shape.
  • Agent runtime fingerprint. When an agent runtime announces itself (Operator User-Agent header, Claude attestation extension), the JS captures it.
install · one tag in page head <script src="https://br.bank.com/br.js"
       data-app="checkout"
       async></script>

// that's it. nothing else to wire.
// signals flow to your BladeRun
// Gateway and Time Machine
// — same data plane as the SDK.
02 / Attest

Accept signed attestation tokens from registered agents.

The major shopping agent platforms — and the agentic-commerce protocols (AP2, MPP, and emerging standards) — issue browser-side attestation tokens that prove an agent is who it claims to be. BladeRun.js validates those tokens against the appropriate trust roots at page load, before any session data accumulates. Registered agents get a fast path; anyone else gets scored on behavior.

  • AP2 mandate verification. Browser-side verification of the agent's mandate signature, scope, and expiry against the AP2 trust root.
  • MPP credential checks. Cloudflare's Merchant Payment Protocol attestation accepted at the page layer.
  • Partner agent registry. Headers and credentials from the major shopping platforms (Operator, Claude, Gemini, partner bots) verified against published keys.
attestation flow · in-browser // 1. agent visits your page
// 2. BR.js reads attestation header
// 3. signature verified against
// AP2 / MPP / partner trust root
// 4. session tagged: registered ✓

// the same session id flows to
// your Gateway when the agent
// makes its API call. one trace.
03 / Score

Score synthetic abuse at the browser layer.

When no attestation is present, the agent is unregistered — and might be a legitimate shopping bot built on a less-mature platform, OR scripted abuse impersonating a registered agent to ride your conversion paths. BladeRun.js scores the browser environment against a behavioral baseline. The score travels with the session into the Gateway and your fraud engine.

  • Per-session score. Computed in the browser; no server roundtrip required.
  • Federation-fed signatures. Patterns flagged at one merchant become signatures distributed to every member through the merchant Federation Network.
  • No blocking by default. JS scores; your fraud engine and Gateway decide what to do with the score. You stay in policy control.
signal payload sent to your gateway {
  "session_id": "sess_8a91",
  "agent_class": "registered",
  "attestation": "AP2:0xb7f...c3a",
  "behavioral_score": 0.04,
  "headless": false,
  "page": "checkout"
}

// fraud engine consumes this
// as additional features.
Where to install

High-leverage page locations.

BladeRun.js is one tag, but it has more impact on some pages than others. Most teams start at checkout (highest conversion stakes) and add product, cart, and search as the deployment matures.

START HERE

Checkout

Highest stakes. Verified agents get clean conversion paths; synthetic abuse blocked.

START HERE

Cart

Agents add and remove items in patterns very different from humans. Fast distinguishing signal.

HIGH VALUE

Product detail

Inventory probes, price scraping, agent comparison shopping all show up here.

HIGH VALUE

Search

Bot vs. agent vs. human search behavior is highly distinguishable. Catches scrape-as-shop patterns.

EXPAND TO

Account / Login

Detect ATO attempts via agents replaying credentials.

EXPAND TO

Promo / Coupon

Promo-race exploitation by parallel agents.

EXPAND TO

Returns / Refunds

Coordinated chargeback abuse signals.

EXPAND TO

Support / Chat

Agents probing your support flows for jailbreaks or knowledge extraction.

Where it sits

In the browser. Before the API call.
Same data plane as Gateway.

BladeRun.js is the third integration vector alongside the Sentinel SDK and the Gateway. Each captures a different surface; together they cover every place an agent can interact with your stack.

CUSTOMER PAGE

BladeRun.js · in the browser

Captures attestation, environment fingerprint, behavioral score before any backend call.

→
YOUR PERIMETER

BladeRun Gateway

Receives the BladeRun.js signal alongside the agent's API call. Same session ID — one trace.

→
EVIDENCE

Time Machine

Per-session record combines page-side and API-side data. Shared with Federation as anonymized signal.

The three integration vectors

Pick what fits your surface.

BladeRun captures agent activity at three points: in the agent's process (you built the agent), at the API perimeter (the agent calls your APIs), and on the page (the agent visits your customer-facing surface). Most banks deploy SDK + Gateway. Most merchants deploy BladeRun.js + Gateway. Both can use any combination.

VECTOR 01 · IN-PROCESS

Sentinel SDK

For agents you built. Captures every tool call inside your agent's process. Default for banks.

Explore Sentinel SDK →
VECTOR 02 · NETWORK

BladeRun Gateway

At the agent boundary. Inspects every HTTP call traversing the perimeter. No code change required.

Explore Gateway →
VECTOR 03 · BROWSER

BladeRun.js

On your customer-facing pages. Detects agents at the page layer before they call your API. Default for merchants.

You're here
Common questions

What engineering teams ask first.

One async script tag in your page head. The script is served from your domain (CNAME'd to BladeRun's CDN) so it bypasses third-party cookie blockers and ad blockers. No build-step integration; works alongside whatever frontend stack you already use — React, Vue, Angular, Astro, server-rendered HTML, anything.
Under 5ms on the main thread at p95. The script is small (~12KB gzipped), loaded async, and runs after the page is interactive. It does not block first-paint, first-contentful-paint, or time-to-interactive. We publish per-page Core Web Vitals impact in the documentation.
No — by default it scores. Blocking is a Gateway or fraud-engine decision based on the score, not a JS decision. You can configure per-page friction (CAPTCHA, step-up auth) in response to the score, but the default behavior is purely observational. Same shadow-mode pattern as the rest of the platform.
BladeRun.js collects no PII and no third-party cookies. The signals it captures are environmental (browser API features, automation indicators, timing distributions, attestation headers). It is GDPR / ePrivacy compatible without consent banners in most jurisdictions, but we provide a documented integration with your existing consent management platform if needed.
Your fraud engine (Sift, Forter, Riskified, Signifyd, in-house) consumes the BladeRun.js signal as additional features alongside its existing rules. Your bot-management vendor (Cloudflare Bot Management, Akamai, DataDome, hCaptcha) operates at a different layer — they protect against generic bots; BladeRun.js separates legitimate registered agents from synthetic abuse. Complementary, not competitive.
Yes. Banks typically default to Sentinel SDK + Gateway because their primary AI surface is agents they build internally. But banks with customer-facing AI experiences — agent-accessible help portals, public banking-agent surfaces, AI-powered self-service flows — benefit from BladeRun.js the same way merchants do. Many banks deploy all three vectors over time.
Pilot the page tag

One script tag.
Visible on every customer-facing page in 24 hours.

Add the tag to one page — checkout is the recommended start. The first week runs in observe-only mode while your team sees the agent breakdown on real traffic.

Get a demo Request the install docs