Security, scan safety and vulnerability disclosure

01Scan safety

It won’t break your site.

A pentest you’re afraid to run doesn’t get run. ZerodayIQ is built to be pointed at production.

Non-destructive by default. Proof means showing access, not using it: a read with a marker, a timing difference, a status code next to its control. Never a deleted record.
Rate-limited. Requests are paced per target, and we never run denial-of-service or volumetric tests.
A guard on destructive actions. Forms and endpoints that could change or delete data are held back from active testing.
Blocked means inconclusive. If a WAF or rate limit stops a test, the coverage ledger says so. We report it as inconclusive instead of hammering the target or calling it clean.
Egress-filtered workers. Scan workers run on a network that blocks private ranges and cloud metadata endpoints.

02Authorisation and scope

Only domains you verify.

ZerodayIQ can’t be used to scan someone else’s site. Scope is enforced by the platform, not by a checkbox.

Ownership is verified. Your email domain and its subdomains are in scope by default. Any other domain needs proof that you control it: a DNS TXT record or a well-known file.
Private targets are refused. Private, loopback, link-local and cloud-metadata addresses are rejected before a scan starts.
Internal scans are approved, not self-serve. The internal agent registers with a scoped token, and each internal engagement is reviewed and approved.
Every scan is attributable. Scans and reports belong to the account that started them, with a full activity log.
The rule is contractual too. Our Terms allow scanning only assets you own or have explicit written permission to test.

03Data handling

Your findings are your data.

We collect what we need to run the scans you ask for. Nothing for advertising, and we don’t use your scan inputs, outputs or chat history to train external AI models.

Encrypted. TLS 1.2+ in transit and AES-256 at rest.
Secrets never logged. Credentials, API keys and tokens you give us for authenticated scans are held in a secret manager and never written to logs.
Least privilege. Production access is limited to a small named operations team, with MFA enforced and audited.
Segmented. The dashboard, scanner workers and database are separated; the database and job queue are never exposed to the internet.
Accounts. Passwords are hashed with bcrypt and sessions are signed JWTs.
Yours to remove. Export, correct or delete your data at any time, including credentials you provided for authenticated scans.
Tested. We run ZerodayIQ against itself, and we commission independent third-party penetration tests of our own platform.

Sub-processors

Serious findings are reviewed by AI models from our LLM sub-processors. Payloads sent to them are redacted, and each sub-processor works only on our documented instructions. The full list and regions are in our Privacy notice.

Sub-processors, their purpose and region
Sub-processor	Purpose	Region
Hosting and database	Application hosting, scan storage, log retention	Asia (primary)
OpenAI	AI inference for scan analysis, review and chat answers	United States
Anthropic	AI inference for analysis and independent review	United States
Shodan	Internet asset enrichment during recon	United States
VirusTotal	File and URL reputation lookups	United States
NVD (NIST)	CVE matching	United States
Email provider	Transactional and enquiry email	Asia / United States
Payment processor	Card processing for paid plans	United States

04Vulnerability disclosure

Found something? Tell us.

No system is immune to every adversary. When something is wrong, we want to hear about it, and we won’t pursue researchers acting in good faith.

Show our security email address

Report a vulnerability

Email our security address with enough detail to reproduce the issue: the affected URL or endpoint, the steps or request, what you observed, and why it matters. A proof-of-concept, screenshot or short video helps us triage faster.

Please report in English where you can, and give us a reasonable window to investigate and fix before any public discussion.

Scope

In scope:

The marketing site at zerodayiq.com.
The dashboard and API at dashboard.zerodayiq.com and /app.
Authentication, authorisation, tenant isolation and data-handling flaws in the above.

Out of scope (unless you can show real, demonstrable impact):

Findings from automated scanners without a working proof-of-concept.
Denial-of-service, volumetric or rate-limit testing.
Social engineering, phishing or physical attacks against our staff or offices.
Missing security headers or best-practice suggestions with no exploitable impact.
Reports about software versions with no demonstrated vulnerability.
Third-party services we do not operate.
Findings produced by running our own scanner against a target you are not authorised to test.

Safe harbor

We will not pursue or support legal action against you for security research that is conducted in good faith and in line with this policy. If you make a genuine effort to follow it, we will treat your research as authorised, work with you to understand and resolve the issue quickly, and we will not ask a third party to take action against you.

This safe harbor does not apply to research that violates the law, accesses or exfiltrates data beyond what is needed to demonstrate a flaw, degrades our service, or harms our users.

What we ask of researchers

Only test accounts and data you own or that we provide for testing.
Stop as soon as you have confirmed a vulnerability; do not pivot further into our systems.
Do not access, modify or destroy data that is not yours, and do not exfiltrate personal data. Use a marker or canary record to prove access instead.
Do not run denial-of-service, spam or automated brute-force attacks.
Keep the details of any vulnerability confidential until we confirm it is resolved.

What you can expect from us

Acknowledgement of your report within 3 business days.
A triage decision (validity and severity) within 10 business days, with a reason if we consider it out of scope.
Progress updates as we work toward a fix, and notice when it ships.
Credit in our security acknowledgements if you would like it, once the issue is resolved. We do not run a paid bug-bounty program at this time.

Changes to this policy

We will update this policy as our program matures. The “Effective” date above reflects the latest revision, and the machine-readable security.txt is kept in step with it.