Responsible Disclosure

Scope

In scope:

• ahmedonics.com — the public website, the contact and registration forms, tools and downloads.
• The Hub at /hub/, including the client portal and the sign-in and password flows.
• Guest pages: shared links (/s/), deliveries (/d/) and signing pages (/sign/).
• Machine interfaces: /api/v1, /mcp, /oauth and the .well-known documents, /api/updates and /api/licensing.
• Software and firmware we publish on the downloads page, and the products they belong to, including how they verify updates and licences.
• Hosted products we operate under their own brands — report them here too and we will route the report.

Out of scope: our hosting provider's infrastructure and other third-party services we use (Cloudflare, Google, ClickUp), which have their own programmes; anything that needs physical access to our premises or devices; and the findings listed below that we already know about or that carry no real impact.

The rules

• Test only with accounts and data you created. Do not read, change or delete anyone else's data; if you stumble on it, stop at the minimum needed to show the problem and tell us.
• No denial of service, no flooding of forms or the API, no brute force beyond a handful of attempts, and no automated scanning that generates load. Our rate limits are a control, not a challenge.
• No social engineering or phishing of our staff or clients, and no physical attempts.
• Do not run exploits against clients' installations of our products; test on your own copy.
• Give us time to fix the problem before anyone else hears of it: we ask for up to ninety days from your report, and we will agree a date with you if a fix needs longer or can ship sooner.
• Keep whatever you found confidential, and delete any data you obtained once the report is closed.

How to report

E-mail contact@ahmedonics.com with "Security" in the subject. It reaches an engineer, not a queue. Helpful contents:

• The URL, endpoint, or product and version affected.
• Steps to reproduce, with a request and response, screenshot or short script where that makes it clearer.
• What an attacker could do with it, in your assessment.
• Your name or handle and whether you would like to be credited.

A machine-readable version of this page's contact details is published at /.well-known/security.txt (RFC 9116). We do not yet publish a PGP key; if your report is sensitive enough to need encryption, say so in a first message and we will arrange a channel.

What you can expect from us

• An acknowledgement within one working day, and a first assessment of whether we can reproduce it.
• Updates as we work on it, and a note when the fix is deployed so you can verify it.
• Credit on this page, if you want it, once the fix is out.
• Honesty if we disagree about severity or scope, with our reasoning.

We do not run a paid bug bounty programme at present. We do say thank you, publicly if you like, and we take reports seriously whoever they come from.

Safe harbour

Research carried out within these rules is authorised as far as it concerns us: we will not pursue legal action or a complaint against you for it, and we consider it to comply with our Terms of Use. We cannot authorise testing of third parties, and if a third party or an authority acts against research that touches their systems, we will make clear that you were acting within our programme. If you are unsure whether something is covered, ask before you try it.

Findings we will not act on

These are reported to us often and, on their own, are not vulnerabilities in this system:

• Reports from automated scanners without a demonstrated impact, and "best practice" observations with no exploit path.
• The presence or values of rate limits, version strings or software banners, or the fact that a page or endpoint exists.
• Clickjacking on pages with no state-changing action, or missing headers on responses that carry nothing sensitive.
• Self-XSS, or anything that requires the victim to paste code into their own browser.
• Sign-in and password-reset responses that do not reveal whether an address has an account — that is deliberate.
• TLS configuration, DNS or e-mail authentication of our hosting provider that we cannot change, unless it leads to a concrete attack on us.
• Weaknesses in software that has been modified to skip licence or update verification.

Acknowledgements

Nobody yet — this programme is new. Researchers who report a confirmed issue and ask to be named will appear here.