Security
Last updated: October 2026 · Starter text for a pre-launch product, final legal review pending.
This page explains how Trymira handles the credentials that authenticated checks need, and how to report a vulnerability.
Why some checks need credentials
Some applications can only be validated the way a user experiences them: after signing in. A browser flow that signs in and completes a real task needs a username and a password to run, so Trymira has to hold a credential for that application. What follows is exactly what happens to it.
Stored once, write-only from then on
You store the credential in Trymira once, as a secret. From that moment it is write-only: it is never shown in the interface again, it never appears in logs, runs or evidence, and it cannot be retrieved through the API or the CLI. In the dashboard it appears only as a masked value, so your team can see that a secret exists, and nothing more.
Encrypted, and decrypted only when a check runs
Secrets are encrypted at rest and in transit. A secret is decrypted only at the moment a check runs, in memory, inside your own network, by your agent. The plaintext never appears in the dashboard, and it is never part of what the agent sends back.
Or keep the secret in your own vault
At scale, the agent can load secrets from your own external secrets manager instead, so the credential does not have to be stored in Trymira at all. The rules do not change: the secret is used at run time, inside your network, and is never displayed, logged or returned.
What leaves your network does not change
Authenticated checks change nothing about what leaves your network: only the verdict and the evidence, as with every other run. The evidence is scrubbed before it is stored, so a secret never appears in a screenshot, an excerpt or a report.
Vulnerability disclosure
We want to hear from researchers
If you believe you have found a security vulnerability in this website, the Trymira dashboard, or the self-hosted agent, please tell us before disclosing it publicly so we can investigate and fix it.
How to report
Report security problems through the Contact page; do not post them publicly. Mark your message "Security", and include a description of the issue, the steps to reproduce it, and the impact you believe it has. Please do not include other people's data in your report.
What we ask
Act in good faith, avoid privacy violations and service disruption, and only test systems you are authorised to test or that are in scope of this policy. Do not run automated scanners against production targets that are not yours.
What we promise
We will acknowledge reports, keep you informed while we investigate, and credit researchers who report valid issues and follow this policy, once the product launches publicly. We do not pursue legal action against good-faith research that follows this policy.