How HEIP works
The shape of the system, why it is hard to fool, where data goes, and how mistakes are handled. In plain words, without the parts that would teach a script to pass.
The idea
Automation can fake a moment. It struggles to fake a whole visit.
Most checks happen once: a puzzle at login, a face scan at sign-up. Pass it once and you are trusted for the rest of the session. That is exactly the gap automation uses.
HEIP checks continuously, and answers at the moment an important action happens. The question is not “did this one click look human?” but “has a person been in control of this visit, the whole way through, up to now?”
The flow
- Visitor's browser: Page loads HEIP. Then HEIP: Session opens, using the site key.
- Visitor's browser: Visitor uses the page. Then HEIP: Evidence builds.
- Visitor's browser: Visitor presses Pay. Then HEIP: One-time action token.
- Visitor's browser: Form sends the token. Then Your server: Receives the token.
- Your server: Asks HEIP to verify. Then HEIP: Decides with your policy, using the secret key.
- HEIP: Decision and reasons. Then Your server: Allow, step up or deny.
- Your page loads the HEIP script with your public site key. The key only works on the domains you allowed.
- HEIP builds evidence quietly while the visitor uses the page. Nothing is shown to them.
- The visitor acts. When they press a protected button, the page asks HEIP for an action token: valid once, for that action, for a few seconds.
- Your server verifies. It sends the token to HEIP with your secret key.
- HEIP decides using your policy for that action, and returns allow, step up or deny, with reasons.
- A record is kept so your team can review the decision.
What HEIP sees, and what it never collects
HEIP's browser script looks at how the page is being used: the kind of interaction people produce naturally as they read, move and act. It does not look at what is being done or who is doing it.
Never collected
- What is typed, or which keys are pressed
- Form values or page content
- Names, emails, phone numbers, IDs
- Faces, voices, photos
- Cookies or any cross-site identifier
The script is small, runs in the background, and does not slow the page. Its data is protected against tampering and replay on the way to HEIP.
Evidence over time
HEIP keeps a running assessment of every session.
The whole visit
It is built from the whole visit, not a snapshot.
Suspicion raises the bar
for what HEIP will allow.
Trust can be earned back
Consistent, natural use earns trust back. One odd moment does not condemn a session for ever.
Never trusted blindly
A session that looked fine keeps being assessed.
Answers are tied to the action
- One token per action
- When the visitor presses Pay, the page gets a token for checkout, for this visit only.
- Short-lived
- It expires in seconds: 25 by default, up to 2 minutes.
- Single use
- HEIP accepts it once. A copied or replayed token is refused.
- Bound to the action
- A token for comment cannot approve withdraw. A mismatched attempt still uses the token up.
- Bound to the session
- A token from one visit cannot be used with another.
Why it matters: A bot cannot collect an “allow” from a quiet page and spend it on a sensitive action later.
Only your server sees the answer
The visitor's browser never learns HEIP's verdict or reasons. If it did, a bot could test itself against HEIP until it passed.
Only your server, holding your secret key, can ask for and read a decision. If a valid secret key is ever sent from a browser, HEIP refuses it and records an alert, so a leaked key is noticed rather than silently abused.
Policies decide, per action
The same evidence can mean “allow” for posting a comment and “step up” for a withdrawal. You choose how strict each action is, starting from one of four presets and adjusting from there.
HEIP only says deny when it has strong, recent evidence of automation. Anything uncertain is step up, so you stay in control of what happens to real people.
- Critical
- Fast
- Standard
- Observe
Explaining every decision
Every decision comes with reasons and a record id. Your team logs the reasons, sees decisions in the dashboard's history for 30 days, and can look up the detailed record of a single decision while investigating.
Reasons tell your team why a policy was or was not met. They are designed for review, not for tuning a bot.
Too little evidence isn't suspicion
Is there enough evidence yet?
Early in a visit, there may simply be too little to say.
Does the evidence point to automation?
That is a different situation, and HEIP treats it differently.
“Not enough evidence” leads to step up, never deny.
When HEIP gets it wrong
No detection system is perfect. HEIP is built so mistakes are cheap.
Observe mode first
See what HEIP would decide on your real traffic before it affects anyone.
Step up, not block
Uncertainty produces a step-up you control, not a denial.
Per-action policies
Relax one action without weakening the rest.
Reasons and records
Every surprising decision can be reviewed, with us if needed.
Your fail-safe choice
You decide whether an unreachable HEIP means no (the default) or yes.
Trust has to move with the action.
When digital actions can be automated, trust must move with them.