Accounts I control
I start from an account, trial tenant, or registration I created and control. I do not treat that as contractual authorisation from a vendor.
How I work
Security research can create risk if it is performed carelessly. My approach is designed to establish whether a genuine issue exists while minimising access, impact, and unnecessary handling of third-party information.
Minimum necessary proof
I stop after the smallest amount of evidence needed to demonstrate the security boundary failure.
Read-only wherever possible
I avoid state-changing actions against records or accounts that do not belong to me.
No bulk enumeration
I do not scrape or systematically collect another customer's information to increase the apparent size of a finding.
Data minimisation
I omit or redact incidental names, email addresses, record values, contract titles, and customer identifiers from ordinary email.
Direct disclosure
I send reports directly to the vendor or its designated security contact with enough information to assess and reproduce the issue.
Accurate severity
I describe technical severity and operational priority separately. Not every cross-tenant issue is automatically Critical.
Remediation support
I can clarify evidence, discuss likely control failures, and validate the fix using an account I control.
No payment condition
I never withhold a report pending payment. If a vendor validates the work and chooses to make a discretionary contribution, that does not affect cooperation.
What vendors can expect
I write reports for technical triage and remediation, not for show.
- A clear impact summary
- Affected components or route families
- Reproduction information
- Testing boundaries
- Redacted evidence
- Severity rationale
- Suggested remediation direction
- An offer to validate the fix
- Identifiers for cleanup of accounts controlled by me, where relevant
My research is independent. A report does not imply that the affected vendor commissioned a penetration test, audit, or compliance assessment.