Make automated abuse expensive, not impossible.

Guard sits in front of your signup, login and checkout. Every attempt costs the caller real work before your server ever sees it, and the token it produces can be spent once, on one action, from one of your own hostnames.

Open the console See how it works

What happens when someone submits your form

Four steps. The visitor sees none of them unless Guard decides to look harder.

The page asks for a challenge. Your site key identifies the action being protected — a login is not a checkout, and they do not have to cost the same.
The browser does the work. A proof of work runs before the form can be submitted. It is milliseconds for one visitor and a bill for someone attempting thousands.
Sometimes it escalates. After repeated failures from the same visitor or the same address, Guard also asks for a picture to be identified. Most people never see it.
Your server verifies the token. One call, and the token is spent. It cannot be replayed, and it cannot be moved to a different form.

What it does today

Everything here is live, not planned.

Work on every attempt

Proof of work is required, not optional. A caller that skips it is refused rather than quietly downgraded to a weaker result.

Single-use tokens

A token authorises one action once. The second use is refused, so a captured token is worth nothing.

Keys scoped to your surfaces

Bind a key to your hostnames and to the actions it may speak for. A key issued for your marketing page cannot mint proof for your checkout.

Escalation that remembers

Repeated failures raise the cost, tracked per visitor and per address, so switching browser tabs does not reset the budget.

Rotation and revocation

Rotate a secret or revoke a key from the console. A revoked key stops working immediately.

Your own activity, visible

See what Guard saw: requests, how many carried a proof, how many escalated, and what it scored — for your workspace only.

Two additions to a page you already have

One script on the page, one call from your server.

<!-- on the page with the form -->
<script src="https://api.bolrach.io/v1/guard/sdk/guard.js"></script>
<script>
  // create it as the page LOADS, not inside your submit handler:
  // the interaction collector starts listening the moment it exists.
  var guard = BolrachGuard.create({ key: 'YOUR_SITE_KEY' });
</script>

// then, before you submit
const result = await guard.protect('login');
if (result.ok) submitWith(result.token);

// on your server, verify it once — this SPENDS the token
POST https://api.bolrach.io/v1/guard/tokens/verify
     Authorization: Bearer YOUR_SECRET
     { "token": result.token, "action": "login" }

What Guard is not

Security products are usually sold on what they stop. It is more useful to know where the edges are, so here they are.

It raises cost; it does not make abuse impossible. A determined attacker with enough machine time can still pay the toll. The point is that mass abuse stops being cheap, and cheap is what most of it depends on.
The picture is a cost multiplier, not proof of a human. Solvers exist. Every attempt still costs a full challenge cycle and a proof of work, which is what makes it worth having — not an unbeatable puzzle.
It reports risk rather than blocking on it. Guard scores what it sees and shows you, and what enforces today is the proof gate. Nothing is refused because a score looked wrong.
It cannot see traffic that never runs it. Anything that does not execute the script — an API client, a crawler, a callback — is outside what a browser check can answer for, and should be authenticated by credential instead.

Built for the estate, open to everyone

Guard protects the sign-in and signup forms across Bolrach's own platforms. It is the same service, the same keys and the same console that you would use — we are not running a different one behind the scenes.

Open the console