Privacy policy
Effective September 28, 2026; updated October 7, 2026. Operator: Jonathan Hill, an individual operating as Trismag. Trismag is not currently an LLC. Contact: hello@trismag.dev.
This policy covers trismag.dev, its Trismag Netlify previews and gateways, api.trismag.dev, and trismag-api.fly.dev. It also explains the separate handling of support email. The public contact address hello@trismag.dev forwards to an inbox controlled by the operator; email replies may come from Gmail. It does not cover unrelated sites operated by the same person.
The short version
We don’t keep what you scan. The Trismag application processes scan content in memory and is designed not to write raw scan payloads or a history of their verdicts to application storage or logs. Your email address, API key and IP address are not kept as you sent them either: the application stores one-way hashes of them, next to your plan, balance and usage counts. We do not use submitted scans to train models, sell them, or use them for advertising. This is not a promise that no data is processed or that no logs exist anywhere. Hosting providers process requests, the API stores account and abuse-control records, and messages you deliberately email us are retained separately.
Do not submit credentials, private keys, passwords, regulated records, or other sensitive content to the public demo. Use synthetic or properly deidentified examples. Submit content only if you have authority to have it processed.
What passes through the service
- Local examples: selecting a reference example runs in your browser; it does not submit that example for a live scan. Visiting the site still sends ordinary page requests to its host.
- Local package: the downloadable Python package inspects content on your machine and sends nothing to Trismag; it has no network or telemetry code. Downloading it is an ordinary request to the website host.
- Anonymous homepage scans: text goes over HTTPS directly to the Trismag API on Fly.io. Visitors sharing a public IP also share the anonymous allowance.
- Keyed website scans: your content and API key pass through a Netlify function to the API on Fly.io. The gateway does not intentionally persist request bodies or keys and sends scan responses with no-store caching instructions.
- Direct integrations: requests to api.trismag.dev or trismag-api.fly.dev reach Fly.io. Legacy API routes on trismag.dev pass through Netlify before Fly.io; that gateway forwards your IP address to the API, signed, so the API applies the same per-IP limits as on a direct request. Findings returned to you can include excerpts of your input; your integration determines how it stores those responses.
- Optional payments: Stripe hosts checkout and processes payment and billing details under its own policy. Trismag does not send scan content or API keys to Stripe. Signed payment notifications deliver checkout-session details, billing email, amounts and payment status to the Trismag API on Fly.io. The application uses the email in memory to find an existing hashed account and add purchased credits; it does not intentionally persist the raw email or notification body. Stripe checkout is being connected; paid access is not yet offered through this website.
- API key issuance: the supplied email is processed to create a salted hash for account lookup. The account database does not retain the raw email or raw issued key. This does not mean the email was never received in memory or that a hash is anonymous.
- Optional MCP URL inspection: when you explicitly supply a server URL to the API, the service contacts that public HTTPS server to initialize MCP and request tool metadata. It does not invoke the listed tools or deliberately forward your Trismag key or separate scan content. The named server sees the connection and the requested URL, including any path/query you supplied. Do not embed secrets in URLs. Pasted metadata inspection does not make that outbound request.
Memory processing is not a guarantee of immediate secure erasure from RAM, protection against a compromised host, or absence of every possible infrastructure copy. HTTPS protects transport; Trismag must access plaintext to inspect it.
Stored application data and retention
| Data | Purpose and form | Current retention behavior |
|---|---|---|
| Account and key records | SHA-256 key hashes; salted email hashes and salts; creation dates, plan/label, balances | Retained while the account exists; operator-assisted deletion is available. There is no automatic inactivity deletion. |
Pending verification codes (when email verification is enabled; see email_verification in /health) |
Salted email hash and salt, hash of the emailed code, purpose, timestamps, attempt count. The address and the code are not stored readably. | Expire 30 minutes after issue and are removed by the next cleanup pass, or immediately when used, or after five wrong attempts. |
| Daily usage records | Pseudonymous client identifiers, date, request category and count | Eligible for removal when older than seven days at the next cleanup. |
| Burst and monthly counters | Key-derived identifiers, or for calls without a key the pseudonymous client identifier, and usage counts | Burst rows older than one hour become eligible for cleanup. Current and previous calendar-month counters are retained; older months become eligible for cleanup. |
| Duplicate-request records | Salted request-byte hash, pseudonymous client identifier, timestamp | A repeat normally stops qualifying for deduplication after 600 seconds. Expired rows remain until cleanup; ten minutes is a reuse window, not a guaranteed deletion deadline. |
| Grant records | Key hash, reference, amount, source, creation date | Retained with the account unless deleted. A payment grant reference can include a Stripe checkout-session ID. Manual grants can also exist. |
| Payment replay markers | Stripe checkout-session ID and processing time, with no email or account-key hash in this table | API v0.4.6 retains these after account deletion to prevent a paid session from granting credits twice. No automatic expiry is configured. A session ID can be linked to Stripe records; it is not anonymous. Retention needs are reviewed on a valid privacy request. |
| Support and privacy requests | Your email address, message and any information you choose to provide | Retained in the operator’s email account while resolving the request and for legitimate follow-up, security or legal needs. No automatic fixed deletion schedule is currently configured. Ask for deletion when appropriate. |
The running API starts a background cleanup worker immediately and repeats cleanup after a normally 60-second wait, independently of requests. Each pass deletes at most 1,000 expired rows per category, in separate transactions; key issuance also triggers a bounded pass. The health endpoint reports worker status and the age of its last successful pass. A successful pass does not prove there is no backlog. Eligible records can remain longer during backlogs, failures or host suspension; this is not a physical deletion deadline. Deleting SQLite rows does not promise immediate forensic erasure from database pages, write-ahead logs or existing backups. Disabling deduplication stops new dedupe inserts but is not a purge of all stored data.
Hashes and pseudonyms are not anonymous data. A party with the database and salts may test guessed text or email addresses and may reconstruct network addresses. Usage totals reveal activity even though they are not a content or verdict archive.
Purchase acceptance and refund records
The personal purchase flow sends your API key through the Trismag website gateway to the API to authenticate your account. The key is not intentionally logged, put in browser storage or sent to Stripe. Before opening checkout, we store an account-key hash, the purchase-terms version, acceptance time and a random reference. Stripe receives the random reference and can return it with a purchase notification. These records do not contain a raw email, card data, scan content or IP address. Acceptance through this flow does not establish acceptance for a purchase made through an independent direct Stripe link.
Unlinked acceptance records become eligible for bounded background cleanup after 30 days; matched purchase-acceptance records remain until account deletion. Account deletion also removes these acceptance records. Refund reconciliation retains an operation reference, original checkout session ID, credit amount, state, timestamps and, when confirmed by the operator, the Stripe refund ID. Refund records contain no account-key hash or raw email and remain after account deletion to prevent duplicate adjustments. These identifiers can still be linked to Stripe transaction records; they are not anonymous. No fixed automatic expiry is configured for refund records. Database exports and provider snapshots can include these records; the same backup limitations below apply.
Backups and infrastructure copies
New operator SQL exports made with API v0.4.5 omit daily usage counters, duplicate-request fingerprints and the installation salt used for client pseudonyms. They still retain account and key hashes, per-account email salts, balances and grant records; v0.4.6 also retains payment replay markers. These exports remain sensitive. Older exports can retain request fingerprints and client pseudonyms. Fly volume snapshots can contain the full database, including metering and deduplication tables. On September 11, 2026, metadata for the six listed Trismag snapshots reported five-day retention; this is a configuration observation, not verified physical erasure. Five local SQL backups were inventoried and left unchanged. A 30-day local retention schedule is proposed but is not yet automated or an established deletion guarantee. There is no uniform deletion deadline across all copies.
An account deletion removes its active account, credit, grant and key-linked usage rows. It does not automatically erase payment replay markers, Stripe records, old exports, provider snapshots, unrelated IP-derived records or correspondence. The operator must address identifiable copies separately when handling a valid request. We will explain applicable limitations, preservation requirements and available deletion steps rather than promising immediate deletion everywhere.
Providers and other disclosures
- Netlify hosts the website and gateway functions and processes traffic to them, including per-IP request limits on those functions. Netlify privacy information.
- Fly.io hosts the API and its volume, and terminates HTTPS on the direct API path. Fly.io privacy information.
- Cloudflare provides authoritative DNS and inbound email forwarding for hello@trismag.dev. Email sent to that address passes through Cloudflare Email Routing to the operator’s Gmail inbox. The current records use DNS-only routing; this does not make Cloudflare an HTTP scan gateway. Cloudflare privacy information.
- Google/Gmail processes support and legal email forwarded from hello@trismag.dev to the operator’s Gmail inbox. Emailing us is a separate path from scanning. Do not email raw API keys or sensitive scan samples. Google privacy information.
- Stripe processes optional payments, checkout information, fraud prevention and transaction records. The operator can access transaction and customer details in the Stripe dashboard even though Trismag’s account database does not store raw email. The same Stripe merchant account is used for other products: selected checkout notifications are account-wide, and Trismag ignores other Payment Links without intentionally storing their notification bodies. Card details entered at Stripe checkout are handled by Stripe; the Trismag application does not store full card numbers. Stripe’s records, retention and browser features are separate from scan processing. Stripe privacy information.
- Resend sends transactional email on our behalf when email verification is enabled: a one-time code when you request or rotate an API key, or a notice that the address already has one. Resend receives the destination address, subject and body of each message to deliver it; we send nothing else about you, and the application keeps only the salted hashes described above. If verification is disabled, no mail is sent and Resend receives nothing. Resend privacy information.
- An MCP server you name receives the optional metadata request described above. Its operator has its own practices.
Providers may process IP addresses, request paths, timestamps, status codes and other operational metadata under their service configurations, contracts and policies. Their general privacy pages do not establish exact retention settings for this deployment. Our tests do not audit provider logging or snapshot contents; the snapshot metadata observation above has a narrower scope. Processing can occur in the United States and other countries where providers operate; the configured API region is US East (iad). We do not promise geographic data residency or claim a certification, data-processing agreement or legal transfer mechanism that has not been established for your use.
We may disclose information we actually hold when legally required, to address abuse or security incidents, or to establish or defend legal claims. We cannot supply a raw scan archive that the application did not retain, but stored metadata, correspondence and provider records are different categories. If operation transfers to a future company, we will update this policy and provide notice where required; an LLC has not already been formed.
Browser storage, tracking and security
The Trismag website code does not add advertising, analytics, session replay or tracking cookies. Its pages ask browsers not to send the page address (referrer) to other sites. It does not save playground API keys in cookies, local storage, session storage or URLs. A key stays in the current page’s password field until cleared or the page closes; use Forget to clear it. Browser extensions, autofill and customer integrations can handle information separately. Third-party provider websites have their own practices.
The application suppresses ordinary access logging and avoids raw-payload exception messages. It can log limited operational events such as an endpoint and exception type. Every build runs retention tests. Each route that receives content, including its refusals, gets a synthetic canary that must not appear in the test database, its sidecar files or the application’s own output. The database’s tables and columns are checked against a list of every stored field, so new storage cannot be added without a deliberate change, and stored values are checked for verdicts. After a release, canaries sent to the live service are searched for in the files on its server and in its recent application logs. These checks are not proof of every path, provider behavior, or universal zero retention. No security measure can guarantee absolute security.
Your choices and requests
Email hello@trismag.dev with the subject “Trismag privacy” to ask about access, correction, deletion, restriction, objection or portability where applicable. Use the email associated with the API account and describe the request; do not send your API key. We may need proportionate verification before disclosing or changing account data. We respond within applicable legal deadlines and explain if information cannot be located, verified or deleted. Account deletion makes its key unusable. A scan-content history cannot be exported because the application does not retain one.
Where applicable, you can complain to your local data-protection authority and exercise rights without unlawful discrimination. Rights and exceptions depend on your location and circumstances; this page does not claim that every privacy law applies to Trismag. The service is intended for adults and is not directed to children. Contact us if you believe a child submitted personal information.
Changes
The effective date appears above. We will update this policy when practices change and provide additional notice where required. This revision (September 28, 2026) describes the local package, the website’s per-IP request limits, signed address forwarding on legacy API routes and referrer handling, and adds the records and email provider used only when email verification is enabled. Existing explanations of cleanup windows, backups and hosting still apply; no scan-content logging has been introduced. The October 6, 2026 update adds the plain statement at the top of the short version and a sentence on how your email address, API key and IP address are kept, and describes the checks that keep both true; it changes no practice. Because account emails are hashed in the API store, a universal email notification mechanism is not available. Current notices will be published on the website and changelog.