Adversarial work starts
with written permission.
0x0 uses an authorization-first model for penetration testing, red-team research, vulnerability validation, and any activity that could affect a system outside an owned lab.
Every engagement defines the boundary.
The following information is recorded before testing begins. The record can be a contract, statement of work, bug-bounty program policy, CTF rules, or another explicit authorization artifact.
Owner & authorization
Identity of the system owner or authorized program, approving contact, and the authority under which testing is permitted.
Assets & identities
In-scope hosts, applications, APIs, cloud resources, test accounts, excluded assets, and protected data classes.
Techniques & limits
Allowed techniques, prohibited actions, request-rate limits, testing windows, escalation paths, and stop conditions.
Evidence & reporting
Evidence handling, data minimization, retention, severity method, remediation expectations, and disclosure rules.
Minimum impact, maximum evidence.
0x0 favors reversible validation and the least invasive proof needed to establish a finding. Testing does not continue merely to increase impact after the issue is demonstrated.
Stay inside scope
Scope is a technical control, not just paperwork. Unknown or adjacent assets are treated as out of scope until authorization is clarified.
Use controlled identities
Where possible, cross-account and authorization testing uses test identities owned by the client, program, or researcher rather than unrelated third-party accounts.
Stop on sufficient proof
Once exploitability and impact are established with reproducible evidence, further expansion is avoided unless explicitly required by the engagement.