A security tool should be able to explain its own boundaries.
BreachLabs probes applications for a living, so it is held to the same standard: explicit scope, isolated execution, allowlisted tools, and limitations stated in writing.
Defensive testing, on targets you are allowed to test.
BreachLabs exists to help teams find and fix weaknesses in their own software before someone else does. It is not a tool for probing systems you do not control.
Intended use
Assessing applications you own or have explicit written permission to test — your own repositories, staging environments, and purpose-built demo targets.
Not supported
Scanning third-party systems, circumventing authorisation, or operating against any target outside a confirmed scope. The website demo is a static illustrative replay — it performs no scanning at all.
Execution is contained and enumerated.
Environment isolation
Assessment runs happen in a disposable environment rebuilt from the recorded revision. Nothing persists into the next run.
Allowlisted tools
Only enumerated tool operations are reachable. There is no generic shell and no arbitrary command surface for the agent to misuse.
Credential hygiene
Assessments use synthetic values. Production secrets are not injected into the environment, and detected secrets are redacted in output.
Application content is data, not instruction.
Source files, HTTP responses, error messages, and tool output are all attacker-influenceable in a hostile codebase. BreachLabs reads them as evidence and does not act on text found inside them.
What this cannot promise.
Honest tooling states its failure modes. These are the ones that matter.
Coverage
Automated assessment cannot enumerate every reachable path. Logic flaws, business-rule abuse, and multi-step attack chains can be missed entirely.
Context
Some reported patterns are safe in context, and some exploitable patterns are unreachable in practice. Verification reduces this error window but cannot eliminate it.
Interpretation
Severity and confidence are judgements with stated inputs. They are decision support, not a substitute for an engineer's review.
Completeness
A clean report means the checks that ran found nothing. It is not a statement that the application is secure, and it should never be presented as one.