Security
Found something? Tell us.
We would rather hear about a weakness from you than discover it later. This page explains where to send a report, what to put in it, what we can act on today, and what happens after you send it.
How to reach us
Two routes. They are handled differently, so pick deliberately.
Both reach us. Only one of them reaches a human first, which matters when you are sending working exploit detail.
The contact form, topic “Security”
Read by a person. Your message is stored in our website database and emailed to us; it does not pass through our AI triage agent. This is the better route for exploit detail.
[email protected], subject prefix [SECURITY]
Better for long reports and attachments — but incoming email is triaged with the help of an AI agent under human oversight, so the message content is processed by our AI provider before a person sees it (see Privacy Policy §5 and §8). Put [NO-AI] in the subject as well and the body never reaches the model.
/.well-known/security.txt
The same contact details in the standard format (RFC 9116) that disclosure tools and scanners look for.
Please do not send us credentials, tokens, or anyone else’s personal data by either route. If proving the issue needs something sensitive, tell us that first and we will arrange a channel — including an encrypted one, since we do not publish a PGP key today.
What to put in the report
Five things get us to a fix fastest.
- The web address or form affected
- What you did, in enough detail for us to repeat it
- What it lets an attacker do
- Anything you attached, and what it contains
- The name you want credited — or that you want none
What is in scope
Right now, this website is all there is.
Lagstyr the product is in private development with no customer installation anywhere, so the list of things worth testing is short.
lagstyr.com and its two forms
The website, the interest-registration form, and the contact form — including their validation, rate limiting (the caps that stop one sender flooding us), the data they store, and how they send mail. The same site is also served on lagstyr-web.pages.dev and per-deployment addresses under it; those count as in scope too.
Our public configuration and our claims
DNS and email configuration for lagstyr.com, our security headers and content-security policy (the browser rules limiting what this site may load), and any place where this site’s statements about security are wrong. A false claim is a defect we want reported.
Anything that does not exist yet
There is no customer installation, hosted trial, practice environment, or product API to test. If you find one, that itself is the finding — tell us immediately.
Our providers’ own systems
Report issues inside Cloudflare, SendGrid, GitHub, or our AI provider to those vendors directly. Tell us as well if the issue affects how we use them.
Testing we ask you not to do
Please stay clear of these.
Not because they are clever, but because they harm other people or tell us nothing we can act on.
- Flooding or load-testing the site to make it slow or unavailable
- Spamming our forms or mailbox
- Social engineering our people or our providers
- Physical attempts against our offices
- Accessing, altering, or keeping anyone else’s data
- Automated scanning heavy enough to degrade the site for others
Testing the rate limits is in scope: a few dozen submissions is fine, and putting rate-limit test in the message body tells us it is you and not abuse. Sustained flooding is not. If proving something would otherwise breach this list, describe it and stop — we will find a safe way to confirm it with you.
What happens next
What you can expect from us.
We are a small team, so these are commitments we can actually keep rather than an enterprise service level.
Within two business days
Brisbane time. If you have not heard back in that window, send a follow-up — a missed report is our failure, not your imposition.
An initial assessment within ten business days
Whether we could reproduce it, how serious we think it is, and what we intend to do. If we disagree with your assessment we will say why, rather than go quiet.
Then we come back to you
We prioritise serious issues we can fix ourselves and tell you when it is done, so you can check our work. Where the issue sits with a provider we will raise it with them and tell you what they say. If we decide not to fix something, we will tell you that too, and why.
Named, if you want to be
We do not run a bug bounty and have no money to offer. If you would like credit, tell us and we will agree where and how it appears. We will not pretend we found it ourselves.
Good-faith research
Research inside this page is authorised.
This page is our prior written consent to the testing it describes, for the purposes of clause 5 of our Terms of Use. If you research in good faith and stay inside this page, we will treat your work as authorised and will not pursue legal action over it; if someone later challenges that research with us, we will confirm it was authorised. Good faith means you keep to the scope above, avoid the testing we have asked you not to do, take only the minimum data needed to prove the issue — stopping as soon as you have proof and deleting it once you have reported it — and hold publication for 90 days from our acknowledgement, or less if we have fixed it sooner and agreed a date with you.
This is our commitment, not legal advice, and it cannot bind anyone else — if your testing would touch one of our providers, their terms still apply to you. If you find anything in our published documents that appears to contradict this page, tell us: we will fix the documents rather than rely on the conflict.
Where our security position is written down.
The trust page records what assurance exists today and what does not — including that no independent penetration test or certification has been done.