Good faith research is never met with lawyers.

Security research makes the product safer, and we want the report to reach us before it reaches an attacker. If you follow this policy, we will: acknowledge your report quickly, work with you to understand and validate it, keep you informed while we fix it, credit you if you want to be credited, and not pursue or support legal action against you for the research. That last commitment is the point of this document, and clause 07 states it in terms.

Email security@transglot.ai. Include what you found, where you found it, the steps to reproduce it, what an attacker could do with it, and anything that helps us confirm it: a request and response, a short video, a proof of concept. Tell us if you want to be credited and under what name. Write in English if you can. If you want to encrypt the report, ask in a first message and we will exchange a key. We also publish a security.txt file with the same address, so an automated scanner points at a mailbox a person reads.

We acknowledge a report within three business days. We give an initial assessment, including whether we can reproduce it and how we have rated it, within ten business days. We tell you when a fix ships and we will normally have shipped one for a high or critical issue within ninety days of validating it, faster where the risk is active. If a fix is going to take longer we tell you why rather than going quiet. We will tell you before we publish anything about the issue, and we will not publish your name without asking.

Please give us ninety days from your first report before publishing details, and longer by agreement if the fix is genuinely complex or if a fix requires a customer to act. We will not use that period to bury the issue: we will keep you updated, and if we cannot fix it we will tell you that too, and we will not object to publication once the period has run. If an issue is being actively exploited, tell us immediately and we will move at that speed instead. We are happy to coordinate a joint advisory and to request a CVE where one is appropriate.

The production web application and the marketing site on our own domains, the public REST API, the delivery endpoint, the in-context editor and its embed surfaces, our published client packages, our webhook delivery and signing, our authentication and single sign-on flows, and our public infrastructure as it is reachable from the internet. Reports about a design decision we have documented as a deliberate trade, such as the shared exact-match translation memory pool or the absence of disk-level encryption on live volumes, are welcome as arguments but are not vulnerabilities: they are stated on the security page precisely so a researcher does not spend an afternoon proving something we already publish.

Anything not operated by us, including a customer’s own website, a third party integration and any system reached through a connector. Denial of service, volumetric or resource exhaustion testing, and anything that degrades the service for other users. Social engineering, phishing, or physical attempts against our staff, our offices or our suppliers. Spam, and reports generated by an automated scanner with no analysis attached. Findings that are only a missing best-practice header, a cookie flag with no demonstrated impact, an outdated library with no exploitable path, a rate limit you found by exceeding it, a self-inflicted cross-site scripting, a clickjacking report on a page with no sensitive action, or the absence of a broad content security policy, which we already document as a gap. Vulnerabilities requiring physical access to a victim’s unlocked device, or requiring a root-level compromise of the victim’s own machine.

If you make a good faith effort to comply with this policy during your research, we will consider your research to be authorised, we will work with you to understand and resolve the issue quickly, and we will not recommend or pursue legal action against you, including under computer misuse, anti-hacking, anti-circumvention or contract law, and including any claim under the Acceptable Use Policy or the Terms of Service that your testing would otherwise breach. If a third party brings an action against you for research conducted under this policy, we will make it known that your activities were authorised. This safe harbour is limited to us: it cannot and does not authorise you to act against a third party, another customer, or anyone else’s systems.

Use only accounts you own or have explicit permission to test, and create your own free workspace rather than probing somebody else’s. Do not access, modify, copy, exfiltrate or destroy data that is not yours, and if you encounter customer data by accident, stop, do not save it, and tell us immediately what you saw so we can assess exposure. Do not degrade availability or run load, stress or denial of service tests. Do not use a finding to gain more access than you need to demonstrate it, and do not maintain persistence. Do not extort, and do not condition disclosure on a payment. Do not publish before clause 04 allows. Comply with applicable law and with any export control or sanctions restriction that applies to you.

There is no paid bug bounty today. What we do offer is a fast, human response, credit in a public acknowledgement if you want it, a written reference for serious findings, and the safe harbour above. If we start a paid program we will publish the scope and the ranges here before we take the first submission.

We will not ask you to sign a non-disclosure agreement as a condition of receiving your report, and we will not use a report submission form as a way to bind you to silence. We will not threaten you for a report that turns out to be low severity or a duplicate. We will not report you to your employer, your university or a platform. If we disagree with your severity rating we will explain why rather than closing the thread.

A customer who finds a vulnerability while using the product is covered by this policy and by its safe harbour, and reporting one is never a breach of the Acceptable Use Policy. Report it to the security address rather than through ordinary support, so that it reaches the right people without sitting in a queue. Do not test with production data belonging to your own end users if you can avoid it.

The security page names the things we have not built, on purpose, so that a reviewer or a researcher learns them from us rather than in diligence: the live volumes are not disk-encrypted, the audit log is append-only at the application layer and carries no hash chain or signature, there is no broad content security policy, and we hold no third party security certification today. Publishing our own gaps is the cheapest honesty in the business and it saves everybody a week.

Security reports and questions about this policy go to security@transglot.ai. Anything that is not a security issue, including abuse and copyright, goes to hello@transglot.ai. Privacy and data protection go to privacy@transglot.ai.