Trust & Safety

Access Verification

h4ckbot is a restricted tool. Not everyone who signs up gets full access — new accounts go through a manual verification step before the model is unlocked. This page explains why that step exists, exactly what we check, and how we protect your privacy while doing it.

Why we verify

Offensive security knowledge is dual-use by definition. The same techniques that let a penetration tester identify a critical vulnerability in a client's network can — in the wrong hands — be used to attack systems without authorisation.

Technical guardrails in the model are necessary but not sufficient on their own. Guardrails can be probed, and over time edge cases emerge. The strongest protection is ensuring that the people who have access to the tool are practitioners who operate within a legal and ethical framework to begin with.

Verification is not about distrust — it is about establishing a shared professional context. We want to know that you are using h4ckbot for authorised security work, so that we can give you an unrestricted, useful experience without having to hedge every answer.

What we check

Verification is a professional context check, not an identity check. We are not verifying your legal name or government-issued identity. We are verifying that you work in or study offensive security, and that your intended use is within scope of authorised testing.

The review looks at a combination of the following signals:

Professional email domain

High

An email from a recognised security consultancy, enterprise security team, or academic institution carries significant weight. Addresses from major consumer providers (Gmail, Outlook personal accounts) require more supporting context.

Stated role and organisation

High

We look for consistency between the role you describe and the organisation you list. A "penetration tester" at a company with a publicly visible security practice is straightforward. Vague or unverifiable claims require additional context.

Stated use case

Medium

A plausible, specific use case — client engagements, internal red team, CTF preparation, academic research — is easier to approve than a generic "I work in security". The more context you give, the faster the review.

Public professional presence

Low / supporting

We may search for public evidence of your professional work — conference talks, published CVEs, a professional LinkedIn or personal blog. This is a supporting signal only and is not required.

Referral from existing verified user

Accelerating

If an existing verified h4ckbot user refers you, the review threshold is lower. Referrals shift accountability — the referring user is aware they are vouching for you.

What we do not check

Government-issued ID — we never ask for a passport, driving licence, or national identity document
Address, date of birth, or any demographic data
Financial information of any kind
Proof of employment — we do not contact your employer or verify employment independently
Security clearance status — cleared status is noted if you mention it but never required or independently verified

How the review process works

1
Register and verify your email
Create an account and confirm your email address. Email verification is automated and instant. It does not constitute access approval — it is simply ownership confirmation.
2
Submit a booking request
Use the booking form to describe your role, organisation, and intended use case. This is the primary input for the manual review. The more specific you are, the faster the review.
3
Manual review by the h4ckbot team
A member of the team reads your submission, may run a limited public search (see signals above), and makes an approval decision. We aim to respond within 3 business days. We do not use automated scoring — every review is a human decision.
4
Decision communicated by email
You receive an email with the outcome. Approved accounts are unlocked immediately. If we need more context we will ask by email rather than reject outright. Rejections include a brief reason and you can reapply with additional information.
5
Ongoing access
Once approved, access is persistent. We do not require annual re-verification. If your role changes significantly — especially if you leave a professional security role — you are responsible for not using the platform outside the originally stated context.

Privacy during verification

We are aware that people in offensive security are often careful about their online footprint — and that is a reasonable professional stance. Here is exactly what happens to information gathered during verification:

What is stored?

Your email address, the contents of your booking request, and the reviewer's decision note. If we found public information that supported the decision, that is summarised in the note — we do not store raw scraped data.

Who can see it?

The h4ckbot team members involved in the review. Verification records are not accessible to other users, never displayed in your profile, and not visible to instance admins if you are using a self-hosted deployment (they see your account status, not the review record).

Is it shared with third parties?

No. Verification data is not sold, licensed, or shared with any third party, including analytics providers, payment processors, or data brokers. It does not leave h4ckbot infrastructure.

How long is it retained?

Verification records are retained for as long as your account is active, plus 12 months after account deletion. This window allows us to review patterns if a former user is later identified as having acted in bad faith.

Can I request deletion?

Yes. Email contact@h4ckbot.com with a deletion request. Account deletion will revoke access. The 12-month retention window applies as described above; after that, all records are purged.

What if I want to use a pseudonym?

You can use a professional pseudonym provided you supply enough context for a meaningful review. We care about professional context, not legal identity. A pseudonym used consistently across public security research (CVEs, blog posts, conference talks) is often as verifiable as a real name.

Appeals and edge cases

If your application is declined and you believe the decision was wrong, reply to the decision email with additional context. Common reasons for initial rejection include an insufficiently specific use case or a mismatch between stated role and visible professional presence — both of which can be resolved with a brief explanation.

Students in accredited offensive security programmes (OSCP preparation, university cybersecurity degrees, etc.) are welcome to apply. State your programme name and institution and we will evaluate accordingly.