Script tag in your page head.
Before any API call.
Page-load impact at p95.
Agent traffic seen at the page boundary.
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.
<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.
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.
// 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.
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.
{
"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.
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.
Highest stakes. Verified agents get clean conversion paths; synthetic abuse blocked.
Agents add and remove items in patterns very different from humans. Fast distinguishing signal.
Inventory probes, price scraping, agent comparison shopping all show up here.
Bot vs. agent vs. human search behavior is highly distinguishable. Catches scrape-as-shop patterns.
Detect ATO attempts via agents replaying credentials.
Promo-race exploitation by parallel agents.
Coordinated chargeback abuse signals.
Agents probing your support flows for jailbreaks or knowledge extraction.
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.
Captures attestation, environment fingerprint, behavioral score before any backend call.
Receives the BladeRun.js signal alongside the agent's API call. Same session ID, one trace.
Per-session record combines page-side and API-side data. Shared with Federation as anonymized signal.
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.
For agents you built. Captures every tool call inside your agent's process. Default for banks.
Explore Sentinel SDK →
At the agent boundary. Inspects every HTTP call traversing the perimeter. No code change required.
Explore Gateway →
On your customer-facing pages. Detects agents at the page layer before they call your API. Default for merchants.
You're here
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.
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.