Security

1. Where to send it

Send it to megasent.go@gmail.com. That address is read by a person rather than a form, and it is the same address published in our security.txt file.

Put SECURITY at the start of the subject line. The same mailbox receives sales and support mail, and that one word is what moves your report to the front of it.

We do not publish a PGP key yet, so mail to us is not encrypted end to end. If what you have found is serious enough that you would rather not send it in clear text, write to us without the details and say so, and we will agree on a channel first.

2. What to include

• Which product, and which version: this website, the licence API, the Windows installer, the Revit add-in, the desktop app, or the MCP server.
• What an attacker actually gets out of it. That tells us more than a severity score does, and it is what decides how fast we move.
• Enough steps for us to reproduce it, plus any proof-of-concept code you are willing to share.
• How you would like to be credited when we publish the fix — or that you would rather not be named at all.

3. While you are testing, please do not

• Read, change or delete data that is not yours. If a proof of concept starts returning somebody else's record, you have proved the point — stop there and tell us.
• Degrade the service for anyone else: no load testing, no denial of service, and no automated scanning at volume against the live site or the licence API.
• Publish before we have had the window described below. If you disagree with our timing, say so — a disagreement we know about is one we can resolve.
• Attack the people. No phishing, no pretexting, no social engineering of us, of our customers, or of our suppliers, and no physical intrusion.

4. Our timeline

• An acknowledgement written by a person within five business days. Not an autoresponder.
• An initial assessment within ten business days: whether we could reproduce it, and whether we consider it a vulnerability.
• An update at least every fifteen days for as long as the report is open, even when the update is that nothing has moved.
• A fix, or a written explanation of why there will not be one. You get our reasoning either way, and you are free to disagree with it in public.
• Ninety days from your first report as the default disclosure window — shorter when we ship the fix sooner, longer only if you agree to it.

5. Safe harbour for good-faith research

We will not start legal action against you, and will not ask anyone else to, over security research that follows this policy. That protection covers the access genuinely needed to demonstrate a problem, including reading data that is unmistakably ours.

If someone else brings a claim against you over work that followed this policy, we will state publicly and in writing that the research was authorised.

What we cannot do is waive rights that are not ours. This policy authorises testing against our own systems and our own software. It does not authorise testing against Autodesk, Cloudflare, our payment provider, or a customer's installation, and nothing here binds them.

If you are unsure whether something is covered, ask before you test. A question costs us five minutes; an assumption can cost you a great deal more.

6. Credit, and what we do not offer

If you want it, we will name you in the advisory and in the release notes for the version that carries the fix. If you would rather stay anonymous, that is the default and we will not mention you at all.

There is no bug bounty. We do not pay for reports. We would rather say that plainly on this page than let you spend a weekend on the assumption that we do.

7. How we publish, and who else we tell

Fixes for security issues are published as advisories on this site, and any customer we can identify as affected is told directly rather than left to read about it.

From 11 September 2026 we are also required, under Article 14 of the EU Cyber Resilience Act, to report actively exploited vulnerabilities and severe incidents to the relevant national CSIRT and to ENISA: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. Those clocks are separate from the ones above and are not ours to extend.

If your report is the thing that starts one of those clocks, we will tell you so, because it changes what we can say and when.

8. In scope

• This website, and every page on it.
• The licence API: activation, renewal, seat release, the free trial check, download authorisation and the store webhook.
• The Windows installer and its downloader, the desktop app, the Revit add-in, and the MCP server.
• The signed licence token and the signed update manifest — and above all, anything that would let someone forge either one, or make a client accept a forgery.
• Anything that makes the AI assistant write to a Revit model, run code, or reach the network without the person at the keyboard asking it to. Text inside a project — element names, comments, sheet notes — is attacker-controlled input as far as we are concerned, and a path from there to a model edit is a vulnerability, not a quirk.

9. Out of scope

• Autodesk Revit itself. If the bug is in Revit, it is Autodesk's to fix: report it to their PSIRT at psirt@autodesk.com or through their published disclosure programme. Tell us too, and we will coordinate with them — that is what the word coordinated is doing in the title of this page.
• Cloudflare, our payment provider, GitHub, and any other supplier's own infrastructure. Each runs its own disclosure programme and each is far better placed to fix its own product than we are.
• The language model being wrong. A model that gives a bad answer, or that can be talked into saying something foolish, is a bug report and not a security report — send it to the same address with a different subject and it is genuinely welcome. What crosses back into scope is when that output changes a model, runs something, or leaves the machine on its own.
• Volumetric denial of service, and raw scanner output with no demonstrated impact. A missing header, a weak cipher suite or a version banner is a finding we will read, but on its own it is not a vulnerability report.
• Mail configuration on domains we do not send mail from, and reports whose entire content is the output of a public configuration checker.

10. Already known — no need to report these

Spacealyx builds are not yet signed with a certificate from a public certificate authority, so Windows and Revit will both warn you about the publisher on installation. We know, it is deliberate only in the sense that the certificate is still being bought, and it is being fixed before general sale.

If you find something else that we appear to have written down as known, report it anyway. Being told twice costs us a minute; not being told costs considerably more.