Built for trust.

1. Security principles

Human Gateway follows minimal-data, partner-scoped, defense-in-depth, and security-conscious design principles. The platform is built to keep verification simple for users while maintaining operational controls for partners, projects, actions, sessions, callbacks, and audit events.

2. Platform controls

• Partner, project, action, session, and user separation.
• Partner-scoped verification and auth records.
• Signed callback-oriented integration model.
• Callback timestamps and event identifiers for replay protection and idempotency.
• Session lifecycle controls for private verified-human auth.
• Operational controls for pause, resume, suspend, revoke, and retry flows.
• Audit and security event records for sensitive actions.
• Security headers and HTTPS-first deployment practices.
• Rate limiting and cooldown controls for sensitive public and console flows.
• Minimal technical records for verification, sessions, callbacks, auditability, and abuse prevention.

3. Callback security

Human Gateway callbacks are designed to be verified by partner backends before they are trusted. Partners should verify callback signatures, validate timestamp freshness, use the exact raw request body for signature verification, store event identifiers for idempotency, and reject unexpected project or event values.

Frontend SDK results can improve user experience, but signed backend callbacks should be treated as the trusted source for persistent server-side decisions.

4. Partner security responsibilities

Partners are responsible for securing their own applications, callback endpoints, secrets, environment variables, admin access, user-facing flows, databases, logs, access decisions, and production deployments.

Partners should keep callback secrets private, rotate exposed secrets, use HTTPS in production, restrict allowed origins, test invalid signature rejection, monitor callback failures, and avoid exposing debug receivers or internal test endpoints publicly.

5. Account and console protection

Partner Console access should be limited to authorized users. Partners should use strong passwords, protect active sessions, revoke access that is no longer needed, and keep operational roles aligned with the principle of least privilege.

6. Data minimization

Human Gateway is designed to avoid exposing raw World ID nullifiers, raw World ID proofs, biometric data, identity documents, government identity data, or unnecessary personal identity information to partners through standard Verify/Auth responses or callbacks.

7. Responsible disclosure

If you believe you have found a security issue in Human Gateway, please report it to support@humangateway.dev with a clear description, reproduction steps, affected routes, expected impact, and any relevant screenshots or logs.

Please do not access, modify, delete, disrupt, or exfiltrate data that does not belong to you. Do not perform denial-of-service testing, spam, phishing, social engineering, physical attacks, malware activity, credential theft, or attacks against third-party infrastructure providers.

8. Disclosure scope

Reports related to Human Gateway web properties, hosted flows, Partner Console access, dashboard access, API behavior, callback verification, session handling, project isolation, action isolation, allowed origins, auth flows, and audit/security events are especially useful.

Reports involving only third-party services, public dependency advisories without demonstrated impact, missing security headers with no exploitability, social engineering, denial-of-service testing, or speculative issues may be considered out of scope.

9. No public bug bounty program

Human Gateway does not currently operate a public paid bug bounty program. Responsible reports are appreciated, but no reward, compensation, safe harbor, or response timeline is guaranteed unless separately agreed in writing.

10. Early access security note

Human Gateway is currently an early access and beta-stage service. Security controls, operational processes, SDKs, APIs, documentation, monitoring, and partner tooling may evolve as the platform matures.

11. Related policies

Security should be read together with the Privacy Policy, Terms of Service, and Cookies Policy.