If you have found a security problem in Trenchant Countersign or on this site, we want to hear about it, and we will not make it difficult for you.
Last reviewed 26 September 2026
Please include enough to reproduce it: the affected component or URL, the steps you took, and what you saw. A proof of concept helps and is not required — a clear description of the flaw is worth more than a working exploit we cannot follow.
Report in English if you can. If that is difficult, send it in your own language rather than not sending it.
We are a small team. These are the intervals we aim for rather than a service level we are promising you, and saying so is more useful to you than a number we might miss while somebody is on holiday.
Usually within three working days, from a person. If a week passes with no reply, please chase us — it means something went wrong at our end, not that we are ignoring you.
Normally inside two weeks — whether we can reproduce it, and how seriously we are treating it.
As fast as the severity warrants. We will tell you the plan rather than leave you guessing, including when the honest answer is that it will take a while.
Public credit where you want it, in whatever we publish about the fix and on this page. Tell us the name or handle to use, or ask to stay anonymous. We will check with you before publishing anything.
We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use one to stop you talking about a flaw in our product once it is fixed. What we may say about a particular customer’s deployment can be constrained by our agreement with that customer — that is their information, not ours to publish — but it never extends to silencing you about the product itself.
Listed plainly rather than left for you to discover after the work. These are reports we will close without a fix, so please do not spend your time on them.
Report those to the service. We will help you reach them if that is useful.
Of our people, our customers, or their users.
Offices, hardware, post.
Including volumetric testing. Please do not.
SPF, DKIM and DMARC findings with no demonstrated impact.
Unless you can show what it lets somebody do.
Sent without a human reading it first.
If you make a good-faith effort to follow this policy, Trenchant Labs LLC will not bring or support legal action against you for your research, and will treat your work as authorised for the purposes of any computer-misuse law that turns on authorisation.
Good faith means: stay within scope, stop as soon as you have demonstrated the problem, do not access, modify or keep data belonging to anybody else, do not degrade the service for its users, and give us a reasonable chance to fix it before you publish.
This is a commitment we can only make on our own behalf. It does not bind our customers, their users, or anybody else whose systems or data your testing reaches, and they keep whatever rights they have. That is the real reason “do not touch data belonging to anybody else” is a condition here rather than friendly advice — cross that line and we are no longer the only party involved, and we cannot protect you from the others.
We do not pay for reports, and we would rather say so here than have you find out after the work. This is a small company and the money does not exist yet.
What we can offer is a fast, human response, public credit if you want it, and a fix. If that changes, this page will change with it.
A vulnerability in your own deployment — a misconfiguration, an exposed instance — is support rather than disclosure, and support@trenchantlabs.com will get to it faster. Send it to security@ if you are not sure which it is; we would rather triage it than have you hesitate.
Machine-readable contact: /.well-known/security.txt