Permission to Penetrate
Effective 2026-09-11 (subject to change on legal review) · Version ptp-draft-2026-09-11
Read this before you test anything
breachr performs real security attacks against the systems you tell it to test. Used against a system you are allowed to test, that is lawful, valuable security work. Used against a system you are not allowed to test, it may be a criminal offence under computer-misuse laws across the EU and beyond.
This Permission to Penetrate sets the framework that governs every test you run through breachr. It forms part of our Terms of Use. You accept it, for a specific system, at the moment you add that system as a Target in the portal and confirm the authorisation. That confirmation is your Authorisation. Do not add a Target until you have read this and can honestly make the confirmations in section 3.
1. What this document is, and is not
1.1 This is the standing framework for authorising tests through breachr. It applies to all Targets and all users.
1.2 Your actual, binding permission for a given system is the Authorisation you give when you add that specific Target. That Authorisation names the system, is tied to your account and identity, records the time, and captures which version of this document you accepted. The framework explains the rules; the per-Target Authorisation is the permission itself.
1.3 For a formal engagement, a signed Authorisation to Test schedule (available from us) may be completed in addition. Where a signed schedule exists for a Target, it governs that engagement together with this document.
2. What breachr will do
When you authorise a Target, breachr may, against that Target only:
- scan and enumerate it to map its surface;
- probe it for vulnerabilities;
- perform simulated attacks, including attempts to exploit vulnerabilities it finds;
- where you provide credentials, perform authenticated (grey-box or white-box) testing; and
- record findings, evidence and reports.
- breachr acts only against the Targets you authorise, within the scope you set, and does not knowingly test systems you have not added.
3. What you confirm when you authorise a Target
By adding a Target and confirming, you warrant, for that Target, that:
3.1 Ownership or permission. You own the Target, or you are authorised by its owner to have it security tested.
3.2 Authority. You have the authority to give this permission and to bind the owner of the Target. If you are testing on behalf of a client or employer, you have their authority to authorise this test.
3.3 No third-party harm. Testing the Target will not, to the best of your knowledge, breach any law, any contract, or any right of a third party. If the Target is hosted by a third party (for example a cloud or SaaS provider), you have any permission that provider requires for penetration testing.
3.4 Understanding of risk. You understand that breachr performs real attacks, that testing can cause load, disruption, downtime or data effects on the Target, and that you have taken your own precautions, including backups.
3.5 Accuracy. The scope you set (the Target address, type and any credentials) is accurate and limited to systems you are entitled to test.
You give these confirmations afresh for each Target. They are the foundation of the legal permission that protects both of us.
4. Scope and boundaries
4.1 breachr tests within the scope you define. You are responsible for defining it accurately and for not adding systems outside your authority.
4.2 You must not use breachr to test:
- systems you do not own and are not authorised to test;
- shared infrastructure where testing would affect other tenants you are not authorised to affect;
- systems where testing is prohibited by the host, by law, or by contract; or
- anything for the purpose of causing harm rather than assessing security.
4.3 If you lose authority to test a Target, remove it immediately.
5. Responsibility
5.1 You are responsible for your Authorisations. If you authorise a test of a system you were not entitled to test, the responsibility and the consequences are yours, and the indemnity in our Terms of Use applies.
5.2 We are responsible for operating the Platform with reasonable skill and care, and for acting within the scope you authorise. Our liability is limited as set out in our Terms of Use.
5.3 Security testing informs your security decisions; it does not guarantee security. A clean result does not mean a system is safe. Findings are point-in-time and AI-assisted analysis can be imperfect.
6. Emergencies and stopping a test
If a test is causing unexpected harm to a Target, you can stop it from the portal. If you cannot, contact us immediately at [SECURITY/OPS CONTACT, e.g. security@breachr.ai] and we will help stop it. We may also pause or stop a test if we detect it is causing serious harm or if we believe it is unauthorised.
7. Records
We keep an append-only record of each Authorisation: the account and user who gave it, the Target it covers, the version of this document accepted, and the time. This protects you and us by evidencing exactly what was authorised, by whom, and when.
8. Relationship to our other terms
This document forms part of our Terms of Use and should be read with them and with our Privacy Policy. If a signed Authorisation to Test schedule or master services agreement covers a Target, that document and this one apply together; if they conflict, the signed document prevails for that engagement.
9. Governing law
This document is governed by the laws of Estonia, and the courts of Tallinn have jurisdiction, as set out more fully in our Terms of Use.
10. Contact
Questions before you authorise a test: legal@breachr.ai
Urgent test issues: [SECURITY/OPS CONTACT]
Breachr OÜ, 1b St Hammond Street, Estoniaprov., Estonia.