Policy

Why I do not publish
the algorithm.

Fair question, and it deserves a real answer rather than a paragraph I improvise differently every time someone asks. So here is the whole policy, including the parts that are inconvenient for me.

The short version. I score behavior on the server and give you back a number. I do not publish which signals matter or how they are weighted, for the same reason a fraud team does not publish its rules: the day it is public, it stops working for you.

The people I am detecting read this site too. A published weight is not a technical disclosure, it is a configuration change for whoever is trying to get past it. That is not a hypothetical with AI agents, where a new release of a browser automation framework ships most weeks.

Nothing to hide means nothing hidden that costs you money if it turns out to be wrong. The algorithm does not cost you money if it stays secret. A silent outage policy does.

So the line is drawn there, and it is drawn in one direction only. Everything that affects you is public. The recipe is not. If a fact could change whether buying this is a good decision, it belongs on the site, and if it only helps someone evade detection, it does not.

I would rather publish the list than get asked one item at a time, so both halves are below.

Public

If any of this turns out to be wrong or missing, tell me and I will fix it.

The full response contract

What verify returns, field by field, including the threshold your verdict was compared against and whether anything was stored.

What happens when it fails

Timeouts, outages, missing signals, invalid keys, rate limits. Each case and the resulting response.

What leaves the browser and what is stored

Down to the fact that raw input traces never leave the device, that the snippet sets no cookies and does no device fingerprinting, and that you can confirm both in devtools.

Data handling

What is kept, for how long, which subprocessors, and how to delete it.

Pricing and the monthly limits

Including what happens when you hit one, and the fact that you are never billed an overage.

Where this is the wrong tool

On its own page, linked from the pricing page rather than buried.

How early this is

That this is one developer, that you would be among the first teams running it in production, and any limit you would otherwise only discover after paying.

Private, and why

This list exists so the answer is a stated policy rather than a no I improvised when asked.

Which signals matter and how they are weighted

Publishing the weights publishes the bypass. It hands every bot author a test suite.

The scoring internals and per-signal thresholds

You need the decision threshold your verdict was compared against, and the API returns it on every call. You do not need the function that produced the score, and neither does the person trying to get past it.

What Agent Shield looks for

Agent frameworks ship a new release every week. Publishing my tells is writing their patch notes for them, and you would have paid for a feature that died on a Tuesday.

The timing and detail of model changes

I announce changes that affect your integration before they ship. I do not announce the day the door moved.

Customer names, volumes, and which endpoints they protect

Telling the internet who runs bot detection tells attackers exactly where to test.

Security findings that are not fixed yet

I publish the fix and the class of bug. Not the open window.

Anything not on this list

Ask me and I will answer it. team@humaverify.com goes to me.

The policy is in the code, not just on this page

The API computes a per-signal contribution map for every verification. It is kept for support and tuning and it is deliberately never returned in the response. The comment sitting next to that decision in the source says why:

// Per-signal contribution map — INTERNAL only (persisted for support/tuning, // never returned in the API response, so we don't hand attackers the recipe).

I would rather show you the policy in the code than ask you to trust the marketing page describing it.

How to evaluate this without trusting me

You do not evaluate the algorithm. You evaluate the output on your own traffic. Run it in shadow mode for two weeks: call verify, log the confidence, act on nothing. Then go look at the signups you already know were fake and see where they landed. That tells you more than any whitepaper I could write about myself. The free trial is 14 days, so email me and I will extend it rather than have you rush the evaluation.

Two things make that cheap to try. Every response returns the threshold your verdict was compared against, so you are never guessing which number decided it. And the integration is meant to fail open: you wrap the call in a timeout and let the request through if it fails, which keeps an outage on my side from becoming an outage on yours. If I disappear tomorrow your signups keep working and you are back to your old baseline, not down.

Ask me anything else

If something you need to make a decision is not on the public list, that is a gap in the list and not a policy. Write to me and I will either answer it or add it here.