HumanPass Privacy Addendum

This HumanPass Privacy Addendum (the “Addendum”) explains how Valgix, LLC. (“Valgix,” “we,” “us,” or “our”) processes information when a Valgix customer uses HumanPass to protect a website, application, form, account flow, checkout, API, or other operation from automated abuse. The organisation or person that configured HumanPass is the “Customer”; a person whose browser or request is evaluated is a “Visitor.”

This Addendum supplements the Valgix Privacy Policy and Terms of Use. It applies to HumanPass processing, while the Customer's own privacy policy applies to the Customer's website, application, accounts, form contents, and its other processing. It is not a substitute for a separate data-processing agreement where applicable law requires one.

The Customer generally decides whether and why HumanPass is used, which operations it protects, the authorised domains, and how a successful or failed verification is used. For that processing, the Customer generally acts as controller or the equivalent responsible business, and Valgix processes HumanPass data to provide the service on the Customer's instructions.

Valgix may act as an independent controller or equivalent responsible business for limited processing needed to secure and operate HumanPass, prevent fraud and abuse, maintain account and audit records, enforce our Terms, and comply with law. If applicable law assigns the parties different roles for a particular activity, those roles are determined by that law and the parties' actual processing.

When a Visitor reaches an operation protected by HumanPass, the HumanPass widget or Customer integration requests a short-lived challenge. HumanPass validates the Customer's public site key, the requesting website origin, configured domain, selected action, and active settings. Depending on the selected mode and policy, the Visitor may select a checkbox or HumanPass may run without a click or persistent visible widget.

The browser completes a bounded computational challenge and may provide limited runtime-consistency and automation-detection results. HumanPass returns a short-lived, signed response token. The Customer must send that token from its server to HumanPass for verification and must check the returned hostname and action before allowing the protected operation.

HumanPass is an abuse-prevention control, not proof of a person's identity. The Customer remains responsible for authentication, authorisation, fraud controls, rate limits, and the decision to accept or reject an operation.

Configuration and request context

• the Customer's public site key, HumanPass environment, and settings version;
• the requesting origin and canonical hostname;
• the Customer-defined action, such as login, signup, or checkout;
• challenge, response, verification, expiry, replay, and rate-limit state; and
• request and correlation identifiers, route, outcome code, and request duration for rejected or failed requests.

Browser and verification signals

• support for browser capabilities used to run HumanPass, including WebAssembly and related runtime features;
• the computational proof and the time-limited values needed to validate it;
• limited derived results about browser/runtime consistency and indicators commonly associated with automation or manipulation; and
• whether optional instrumentation was completed, blocked, or timed out.

Network information

Like any Internet service, HumanPass receives a network address while handling a request. The HumanPass application uses a trusted client address transiently for security and rate limiting. It is designed not to log raw IP addresses or store them in HumanPass PostgreSQL or Redis. HumanPass derives protected, keyed references for short rate-limit windows instead of placing raw IP addresses in storage keys. Connection metadata processed by our hosting or network layer is governed by the Valgix Privacy Policy.

Information HumanPass is not designed to collect

HumanPass does not need and is not designed to collect a Visitor's name, email, password, payment details, message, or other contents of the Customer's protected form. It does not use HumanPass data for advertising or create a cross-site advertising profile. A Customer may separately process the response token together with information it collects; that separate processing is controlled by the Customer and described in its own privacy policy.

HumanPass information is processed to:

• issue, complete, verify, expire, and prevent reuse of challenges and response tokens;
• confirm that a request comes from a domain and action authorised by the Customer;
• distinguish likely legitimate activity from automated, manipulated, or abusive activity;
• apply security limits, prevent replay, investigate failures, and maintain service reliability;
• provide the Customer with aggregate usage, success, failure, duplicate, and rate-limit statistics; and
• comply with law, enforce our Terms, and protect Valgix, Customers, Visitors, and the public.

The Customer is responsible for identifying and documenting the lawful basis for its use of HumanPass. Depending on the context and applicable law, that basis may include legitimate interests in protecting a service and its users, performance of a contract, compliance with a legal obligation, or consent. Valgix does not select the Customer's lawful basis.

A Customer using HumanPass must:

• use HumanPass only for lawful, proportionate abuse-prevention and security purposes;
• provide all privacy notices and choices required by applicable law;
• accurately identify the Customer and explain its own purposes for using HumanPass;
• configure only domains and actions the Customer is authorised to protect;
• avoid placing personal or sensitive information in action names or other configuration fields;
• protect secret keys and perform final verification only on a trusted server;
• provide an accessible alternative or support route where required; and
• respond to Visitor requests concerning the Customer's use of HumanPass.

The Customer may not represent that HumanPass establishes identity, guarantees that every accepted request is human, or replaces the Customer's security and legal responsibilities.

Invisible mode can evaluate a request without a persistent visible HumanPass widget. A Visitor may therefore not otherwise know that HumanPass is operating. Before or when processing begins, a Customer using invisible mode must provide a clear and reasonably prominent notice and must include a HumanPass disclosure in its own privacy policy.

The Customer's disclosure must:

• name Valgix HumanPass;
• explain that it is used to distinguish legitimate users from automated abuse;
• describe the categories of signals processed to the extent required by applicable law; and
• provide a working link to this HumanPass Privacy Addendum at https://valgix.com/legal/humanpass-privacy-addendum/.

A suitable notice is: “This site uses Valgix HumanPass to protect forms and services from automated abuse. HumanPass processes limited device, browser, network, and verification signals. See the HumanPass Privacy Addendum.” The Customer may adapt this language, but must not hide the use of HumanPass or remove the required link. If law requires prior consent, the Customer must prevent HumanPass from starting until that consent is obtained.

HumanPass is designed around short-lived verification state. Challenge, response, replay-prevention, idempotency, and rate-limit records normally expire within the configured verification lifetime and a limited security allowance. Customer-configured challenge and response lifetimes are currently bounded between 30 and 600 seconds.

Hourly operational counters temporarily held in Redis expire after approximately 48 hours. HumanPass then keeps aggregate hourly counts—such as challenges issued, responses verified, failures, duplicates, and rate limits—for Customer analytics and service operations. Those aggregate records do not contain a raw IP address or form content.

Site configuration, authorised domains, credential metadata, aggregate usage, and account audit records are retained while needed to provide HumanPass, secure the service, resolve disputes, enforce our Terms, and comply with legal obligations. Deleting a site disables its active configuration and revokes its active secret keys. Site-linked configuration, aggregate usage, and audit records may remain until the applicable deletion or retention period ends, and limited audit or legal records may be retained where necessary. Backup deletion may take additional time.

Valgix may disclose HumanPass information to infrastructure, hosting, network, database, security, monitoring, support, and professional-service providers only as reasonably necessary to operate, secure, and support HumanPass or comply with law. These providers are subject to contractual or legal confidentiality and data-protection obligations appropriate to their role.

We may also disclose information to an authority or another party where required by law, to protect rights and safety, investigate abuse, establish or defend legal claims, or complete a corporate transaction subject to appropriate safeguards. We do not sell HumanPass personal data or share it for cross-context behavioural advertising.

HumanPass information may be processed in countries other than the Visitor's or Customer's country. Where applicable law restricts international transfers, Valgix uses a recognised transfer mechanism or other lawful safeguard, taking account of the nature of the data and processing.

Customers are responsible for assessing whether their own use of HumanPass requires additional disclosures, contractual terms, transfer assessments, or localisation measures.

HumanPass uses short-lived signed tokens, server-side origin and action checks, bounded expiries, replay prevention, rate limits, encrypted configuration caching, keyed storage references, secret hashing, tenant isolation, and structured logging controls designed to reduce disclosure of secrets and personal data.

No system is completely secure. Customers must keep secret keys out of browser code, verify responses on a trusted server, rotate a key that may be exposed, restrict access to HumanPass settings, and notify Valgix promptly of suspected compromise.

A Visitor should normally contact the Customer operating the protected website or application first. The Customer determines why HumanPass is used and can identify the relevant operation, account, and request context. Depending on applicable law, Visitors may have rights to information, access, correction, deletion, restriction, objection, portability, withdrawal of consent, or complaint to a supervisory authority.

Valgix will reasonably assist Customers with valid requests relating to HumanPass. A Visitor may also contact privacy@valgix.com. Include the protected website, approximate date and time, and any HumanPass request identifier shown in an error, but do not send passwords, secret keys, complete response tokens, or unrelated sensitive information.

We may update this Addendum as HumanPass, our providers, or legal requirements change. The “Last updated” date identifies the current version. We will provide reasonable notice of a material change where required, and Customers must update their own notices and integrations when necessary.

Privacy questions may be sent to privacy@valgix.com. Legal notices may be sent to the registered-office address and legal contact published on the Valgix Legal page.