Responsible disclosure.
Harvey's job is to find serious flaws in software. Finding them creates a duty to handle them carefully — for our clients and for anyone whose data those flaws could expose. This is how we do that.
Findings in a client's own code
When you engage Harvey, everything we find is yours. We deliver findings privately to you and only you. We do not publish, sell, share, or disclose them to any third party. What you do with a finding — fix it, accept the risk, ignore it — is your decision. Our data-retention and access commitments for engagement material are covered on the Data Handling page.
Findings in code we were not engaged to audit
Some of Harvey's work looks outward — for example, research that scans publicly available AI-generated apps to understand how common a class of flaw is. When that work surfaces a real, exploitable vulnerability in an app we can identify, we follow coordinated disclosure:
- Notify privately first. We contact the owner through a reasonable channel (a published security contact,
security.txt, or the most direct contact we can find) before telling anyone else. - Give reasonable time to remediate. Our default window is 90 days from first contact before any public mention, shorter only if the flaw is being actively exploited, and extendable by agreement if a fix is genuinely in progress.
- Withhold exploit detail. We never publish a working exploit, a proof-of-concept, or reproduction steps tied to an identifiable app — not before a fix, and not after.
- Prefer no attribution. Public write-ups describe the class of flaw, not the victim. We do not name an affected app without its owner's explicit permission.
Research reports
When Harvey publishes aggregate research ("we looked at N apps and found X% had a given problem"), the report contains only aggregate, anonymized figures. No individual app is named, no dataset of vulnerable targets is released, and no finding is described in a way that would let a reader locate or exploit a specific app. If a specific app in the sample has a serious live flaw, we follow the private disclosure steps above before the research is published — not after.
What we ask in return
If you receive a disclosure from Harvey, please acknowledge it and let us know your remediation timeline. We are not looking for a bounty and we are not trying to embarrass anyone — we would rather the flaw quietly get fixed. If you believe a report is mistaken, tell us; we would rather correct the record than be wrong in public.
Reporting a vulnerability to us
If you find a security issue in Harvey's own site or tooling, we want to hear about it. Report it privately and give us reasonable time to fix it before disclosing publicly, and we will do the same courtesy in reverse. A dedicated security contact address is being finalized; until it is published here, use the contact route on the site and mark it "security."
Scope. In scope: the harvey-qa.com marketing/scan-request site and Harvey's publicly available scanning tooling. Out of scope: any client's codebase, infrastructure, or data that Harvey has accessed as part of an engagement — that belongs to the client, and a report about it should go to the client directly, not to us. Also out of scope: automated volume scanning that degrades the site for other visitors, and any form of social engineering against our operator.
Safe harbor. We will not pursue legal action against a good-faith researcher who stays within this scope, avoids privacy violations, data destruction, and service disruption, and reports what they find privately before any public disclosure. We ask for the same coordinated-disclosure courtesy described above in return.
Response time. Our target is to acknowledge a report within 5 business days. We are a small operation, so this is a target, not a guaranteed SLA, and it is one of the items awaiting operator confirmation below.
Coverage honesty is the brand.
The same discipline that makes us careful with disclosures is why every report shows what we didn't check.