Trumis / Security
Security
Last updated: 26 July 2026
Trumis retains complete intake records under a controlled model: content is encrypted before database storage, tenant access is isolated by PostgreSQL row-level security, and every platform-administrator read is attributed and audited.
Architecture
- Encrypted complete records. Every server-processed individual, pilot and licensed intake request and response is encrypted with AES-256-GCM before database storage and retained for up to 24 months.
- Separated access roles. Intake writing, tenant reading, cross-tenant platform reading and administrator authentication use separate restricted database credentials. Platform reads are named and audited.
- Evidence is read on-device. Screenshots are OCR'd in the person's browser; images never reach our servers. Only recognised text is retained with the encrypted intake after the person approves it.
- The model cannot invent a case. Merit decisions are made by a deterministic rules engine over a maintained legal knowledge base. The AI layer phrases conversation; it cannot open the gate, and its output is sanitised before use.
- Minimal supply chain. The API functions run with no third-party runtime dependencies. The web app is dependency-free vanilla JavaScript, with one exception: the OCR library, loaded only when a person attaches a screenshot, pinned to a major version and executed inside the browser sandbox under a restrictive Content-Security-Policy.
Data flows
| Flow | Where | Retention |
|---|---|---|
| Browser ⇄ Trumis API (conversation turns) | Vercel, Sydney (functions pinned to syd1) |
Encrypted intake record, up to 24 months |
| Conversational layer ⇄ AI provider (Anthropic or OpenAI) | Provider servers, typically United States | Not used for training (business API terms); provider abuse-monitoring windows apply |
| Formal-letter payment | Stripe hosted checkout | Held by Stripe; card data never touches Trumis |
| Finished complaint | Generated by Trumis; sending remains controlled by the person | Encrypted intake record, up to 24 months |
| Platform access logs (IP, request time) | Vercel | Short-lived, security and reliability only |
| Pilot measurement counters (aggregate only) | Counter store, configured per pilot | Integers only — UTC day, partner, event, language; never content, identifiers or IP |
| Complaint signal profiles (category codes only) | Postgres (Neon), Sydney | Codes and the UTC day — never wording, names, identifiers or exact amounts; raw rows retained ≤24 months, then only monthly aggregates |
Transport and platform
- All traffic is HTTPS with HSTS (two-year max-age, subdomains included); plain HTTP redirects permanently.
- Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Permissions-Policy headers are set site-wide; the embeddable widget runs under its own restrictive policy.
- Hosting is Vercel's Sydney region, behind Vercel's edge network and platform isolation. Serverless functions are pinned to Australia; the AI provider processing described above is the one overseas flow, and it is disclosed in the Privacy Policy.
- Fair-use rate limits protect availability; licensed partners receive
dedicated keys (an
X-Trumis-Keyheader) with raised limits. Partner keys are stored as environment secrets, never in code.
What a partner integration exposes
Embedding Trumis adds no scripts to your page context: the embed is a sandboxed iframe served from trumis.com.au, and the one-line loader only creates it. Your page cannot read the conversation inside the widget, and the widget cannot read your page. Complaints reach you only when the person sends them. Verified partner branding is resolved server-side from your licence configuration — a third party cannot impersonate your organisation's widget configuration by copying HTML attributes.
Pilot measurement
Organisations running a measured pilot get before/after numbers without
Trumis storing anything about a person or a complaint. Trumis records exactly
three counters — conversations started, accounts produced, partner documents
produced — keyed by UTC day, partner, event and language. Counts are integers:
no content, no identifiers, no IP addresses, and no timestamp finer than the
day. Every other pilot metric is measured inside the partner's own systems,
using the [via Trumis] subject token to segment the cohort. The
full pre-registered method is in the pilot protocol, available on request.
Complaint trend measurement
So organisations can see which kinds of complaint are rising — and act on the service failures behind them — Trumis records an anonymous category profile only after a person confirms a partner-mode complaint was sent: the dispute type, the legal grounds that passed, the urgency level, the industry and (only when it is an organisation from our verified receivers directory) the organisation, and how provable the established facts are, keyed by UTC day.
The store is anonymous by construction, not by policy: its schema has no
column that can hold free text, so the person's wording, names, and story
structurally cannot be stored. No fact values are kept — only which
KB-defined facts were established. No identifiers, no IP addresses, no
timestamp finer than the day, no geography finer than jurisdiction, and no
exact amounts. The credential the complaint API writes with can only append
rows; it cannot read them back. Raw rows are retained for no longer than 24
months and then reduced to monthly aggregates. Published statistics never
show groups smaller than five complaints. The full schema and design are
public in the repository (docs/complaint-signals/).
Certifications and due diligence
Trumis does not yet hold formal certifications such as SOC 2, ISO 27001 or IRAP. We are open about this. The encrypted intake archive, separated database roles, tenant isolation and named administrator audit trail are controls that require independent assurance as the service matures. For licensed partners we answer security questionnaires, walk your team through the codebase's data paths, and support your own penetration testing of a pilot deployment — arrange it via info@trumis.com.au.
Reporting a vulnerability
If you believe you've found a security issue, email info@trumis.com.au with enough detail to reproduce it. We acknowledge reports within two business days, keep you informed while we fix confirmed issues, and credit reporters who want credit. Good-faith research is welcome: don't access other people's data, don't degrade the service for others, and give us reasonable time to fix before disclosing publicly. Machine-readable details are at /.well-known/security.txt. There is no paid bounty programme at this time.