Security. Reported safely.

Why this page exists

If you find a genuine security bug in something we built or operate, we want to hear about it before anyone else does. This page is how to tell us safely, what happens after you do, and the protection we offer a good-faith researcher who follows it. Every report that reaches security@gattyworks.com gets a real look from a senior engineer, not a form letter.

What is in scope

This policy covers security issues in products, tools, and infrastructure that GattyWorks owns and operates, including:

• gattyworks.com and every route on it
• Studio-built tools we operate ourselves, such as Handoff and Semantic Search
• Open-source projects published under github.com/gattyworks
• Any other software, system, or account publicly and verifiably associated with GattyWorks Private Limited

Client projects we built are not automatically in scope. Those systems belong to the client, and only the client can authorise testing against their own production environment. If you find something in a site we clearly built, tell us anyway. We will route it to the right owner.

How to report

Email security@gattyworks.com with as much of the following as you can:

• The affected URL, repository, or product
• What the bug is and why it matters
• Exact steps to reproduce it
• A proof of concept, kept to the minimum needed to demonstrate the issue
• How you would like to be identified, if credited

If the finding involves real user data, credentials, or anything else you would rather not send in plain text, encrypt it to our PGP public key first. Fingerprint below.

We reply to every genuine report. If it needs more detail, we will ask. If it does not, we start work.

What keeps this safe for you

Security research done in good faith, inside this policy, will not lead to a legal complaint, a police report, or account suspension from us. That protection holds as long as you:

• Test only the systems listed as in scope above, and only with a genuine security purpose
• Stop and report immediately the moment you access data that is not yours, rather than exploring further
• Never run anything destructive: no data deletion, no service disruption, no denial-of-service testing
• Never use automated scanners that generate heavy traffic without emailing us first
• Never attempt social engineering against our team or clients
• Give us a reasonable window to fix the issue before you discuss it publicly, in a talk, a blog, or anywhere else

Testing outside this scope, or outside these rules, is not covered by this policy and may be unlawful. This safe harbor is ours to interpret, and we reserve the right to make that call in good faith based on what you actually did.

What we promise

We investigate every in-scope report ourselves, senior engineer on it, no outsourced triage. We keep you updated as it moves. Confirmed issues get fixed and re-audited before we consider the report closed. We do not take legal action against a researcher who reported in good faith and stayed inside this policy, and we will say so in writing if you ever need it.

Credit and, in rare cases, reward

Once a confirmed fix is deployed and re-audited, and once we have approved it internally, we say thank you properly:

• Public credit, with your consent, in a blog post or a credits note on the affected product
• In rare cases, for reports we judge to be unusually severe, novel, or well documented, a discretionary monetary reward. This is not a running bug bounty programme with a fixed payout table, it is a case-by-case thank you

Credit and reward are ours to decide, and only apply once a report is approved on our side. Until then, please do not claim credit publicly, list the finding on a resume or portfolio, or disclose it anywhere. That protects you from claiming a finding that turns out to be out of scope, already known, or not reproducible, and it protects our users while the fix is in progress.

What is out of scope

The following do not need a report, or are not eligible for credit or reward:

• Client-owned production systems, unless the client publishes its own policy
• Third-party services we merely use, such as Cloudflare, GitHub, or our email provider
• Reports generated purely by an automated scanner, with no manual verification
• Missing security headers or best-practice advice with no demonstrated impact
• Issues already known to us or already reported by someone else
• Social engineering, physical access attempts, or spam

Contact

security@gattyworks.com for a vulnerability report. This address is monitored directly, not by a support queue. For anything else, hello@gattyworks.com still reaches us.

PGP fingerprint, for encrypting a sensitive report to our PGP public key:

4D48 CE41 B26A B148 D2A6 9421 3A76 4238 2364 D32D