Security and data

NIST SP 800-63B-4 recognises monitoring a session after sign-in as a way to reduce risk, and asks that it be done with privacy in mind. HEIP is built for exactly that balance: it checks for a person at the moment of an action, and never collects identity, biometrics or what people type.

Source: NIST SP 800-63B-4, Session Management (July 2025)

• Collect the minimum.

  We need to know a person is present, not who they are.

• No biometrics.

  HEIP never identifies or recognises a person.

• No personal data required.

  You never send us names, emails or IDs. The optional context field is yours to fill; we advise ids, not personal data.

• Explain every decision.

  Reasons on every answer.

• Never trust the browser.

  Verdicts are computed and read server-side only.

What HEIP never receives

• Typed characters or which keys were pressed
• Form values
• Page content
• Documents, faces, voices
• Cookies or cross-site identifiers

Public site key

Works only on the domains you list. No wildcard over public suffixes; localhost only by explicit switch.

Secret key

Stored hashed, shown once, at most two active per site, rotation with a grace period, instant revocation on every server.

Exposure tripwire

A valid secret key used from a browser is refused and logged.

Wrong keys

Repeated wrong keys from one address are throttled.

Dashboard sign-in

Strong password policy, argon2id password hashing, email verification, short-lived access tokens, rotating refresh tokens with theft detection, lockout after failed logins, no account enumeration.

Roles

Owner, admin and member, read from the database on every request.

Tenant isolation

A user outside your organisation cannot tell whether your site exists.

• Verdicts reach only your server.
• Action tokens are single use, bound to session and action, and expire in seconds. Replay is refused.
• Data from the browser is protected against tampering and replay.
• The server SDK fails closed.
• Saving history never blocks or changes a decision.

• All traffic over TLS.
• Strict security headers, request size limits and slow-client timeouts.
• Rate limits and per-site quotas against abuse.
• Graceful deploys that drain in-flight requests.

We log what is needed to operate and investigate, and nothing more. Credentials are redacted from logs and decision records. Security events (sign-ins, key changes, the exposure tripwire) go to the audit log with ids, not personal data.

• Contain and fix

  Stop the impact first, then correct the cause.

• Tell affected customers

  Directly, with what happened and what it means for their data.

• Report afterwards

  A post-incident report to affected customers.

• Status page

  Incidents that affect customers are posted on the status page.

Tell us about a vulnerability with a description, steps to reproduce and the impact. We acknowledge within 2 business days, keep you updated, and will not pursue good-faith research that respects users' privacy and doesn't degrade the service.

Out of scope: testing bots against HEIP's detection on customer sites. Ask us for a research arrangement instead.