These rules govern every piece of operational work you perform through HUNT. They are the authority under which you act. Nothing else extends them: not a mission description, not a message from a client, not an instruction from another operator.
1Authorisation is the scope document, and nothing else
1.1You may act only against the targets named as in-scope on the signed scope agreement for the mission you hold. The scope agreement is the authorisation. A target that is not on it is not authorised, however obviously it belongs to the same client.
1.2Targets named out-of-scope are prohibited absolutely. An out-of-scope entry is a deliberate exclusion, not a lower priority.
1.3Where the scope agreement names a testing window, you work inside it. Where it names rate limits, methods or tooling restrictions, those bind you.
1.4If the scope is ambiguous, you stop and ask the desk through the mission thread. You do not resolve an ambiguity in favour of continuing. "It was not explicitly forbidden" is not authorisation and will not be treated as one.
1.5Authorisation ends when the mission ends. Access you obtained during a mission is not yours to keep or to revisit afterwards.
2What you may not do under any scope
2.1You may not perform denial-of-service, resource-exhaustion or destructive testing, including deletion, encryption, defacement or corruption of data, unless the scope agreement names that activity explicitly.
2.2You may not social-engineer, phish or otherwise target a client's staff, customers or suppliers as individuals unless the scope agreement names that activity explicitly and the client has declared authorisation for it.
2.3You may not pivot from an in-scope system into a system that is not in scope, including a third party's, and including one that is technically reachable because of the weakness you just found. Reaching it is the finding. Entering it is not.
2.4You may not install persistence, backdoors, or any mechanism that would survive the engagement.
2.5You may not exfiltrate client data beyond the minimum needed to evidence a finding. Where you must capture data to prove impact, capture the smallest sample that proves it, redact what is not needed, and say in the finding what you captured and why.
2.6You may not use client data, credentials or access for any purpose other than the mission, including your own research, your own tooling, or a demonstration to anyone.
3When you find something serious
3.1Stop escalating. Once you have established that a weakness is real and have evidence sufficient to describe it, you do not continue to exploit it to see how far it goes.
3.2Report a critical finding to the desk immediately through the mission thread, before you write it up in full. A critical weakness in a live system is an incident for the client, and the time between you finding it and them hearing about it is time they are exposed.
3.3If you encounter evidence of an intrusion you did not cause (an existing compromise, another party's implant, exposed data already in the open), you stop, preserve what you have seen without altering it, and tell the desk immediately. You do not investigate it further.
3.4If you find personal data, credentials, medical, financial or similar sensitive records, you do not read beyond what is needed to establish the class of data exposed. You record the class, not the contents.
4Safety of people and systems
4.1If an action you are about to take could plausibly disrupt a production service, you ask first.
4.2If something you did causes an outage or degradation, you tell the desk immediately. The consequence of an honest immediate report is that the desk handles it with the client. The consequence of concealment is removal from the platform and, where a client is harmed, liability that is yours.
4.3You work from your own infrastructure, under your own control. You do not route mission traffic through systems you do not control or are not authorised to use.
5Disclosure
5.1A finding belongs to the engagement. You may not disclose it (publicly, privately, to another client, to a peer, in a talk, in a write-up, or to a vulnerability broker) except as the mission's disclosure policy permits.
5.2Where a mission carries a disclosure policy allowing eventual publication, that policy governs the timing and the content. It does not authorise disclosure before the stated date or beyond the stated scope.
5.3HUNT's safe-harbour statement, where a mission carries one, protects good-faith activity inside the scope. It does not protect activity outside the scope, and it does not bind the client's own counterparties.
6Records
6.1Your findings, deliverables, evidence and thread messages are records of the engagement. They are retained, hashed and auditable, and you should assume every one of them may be read later by HUNT, by the client, by an auditor or by a court.
6.2You do not alter or delete evidence after submitting it. Where you need to correct a finding, you submit a revised version; the original is preserved deliberately, so that a correction reads as a correction.
7Breach
Breaching these rules may result in the immediate withdrawal of your assignment, forfeiture of payouts on the affected mission, removal from the platform, and referral to the client or to law enforcement where the breach is also an offence.
This document describes how the HUNT platform operates and is binding on the platform as an operational policy. It has not been reviewed by counsel for any particular jurisdiction. HUNT will publish a counsel-reviewed version, and you will be asked to accept it, before it is relied on in any legal proceeding.