How we protect your data.

System architecture

TIO runs on Railway for application services, Supabase for the database, and Cloudflare in front for edge and network protection. Each layer adds its own controls rather than relying on one perimeter: Cloudflare filters traffic before it reaches the app, the app enforces authentication and authorization on every request, and the database runs under a role with only the access it needs.

Privacy practices

We do not sell personal data. We honor deletion, access, and opt-out requests in the same way California law requires, as a matter of practice.

For any data that would fall under GDPR, we follow the same principles as a matter of practice: a stated legal basis for processing, a documented retention period, and a clear path for someone to request their data or its deletion.

Authentication and access

Login sessions are cookie-based, marked HttpOnly and Secure, and scoped to same-site requests only, so they can’t be read by scripts or replayed cross-site. A session expires after 8 hours idle or 24 hours regardless of activity. Signing in from a new device closes any existing session. Repeated failed logins are rate-limited.

Every account holds one of four roles: owner, operator, finance, or admin. Roles gate which actions an account can take. On top of roles, each user’s account can be further restricted to specific pages, so a company can hand out narrower access than the role alone would allow.

Database and encryption

Data in transit runs over TLS, enforced at the edge with HTTP Strict Transport Security so a browser will not silently fall back to plain HTTP. Data at rest is encrypted by Supabase and Railway as part of their own infrastructure, both of which run under their own third-party security certifications.

Each customer’s records are scoped to that customer’s account at the query layer, so one customer’s data is never returned by another customer’s request.

Secrets management

API keys, database credentials, and other secrets are held in a dedicated secrets manager and injected into services at runtime. They are not stored in source control or in plaintext configuration files shipped with the code.

Monitoring and audit trail

Every authenticated request is logged: who made it, what it touched, when, and from where. Requests are classified by sensitivity, and anything flagged as a security event or a failed authentication attempt alerts us immediately, not on a delay.

Beyond request logs, each filing an agent drafts carries its own decision record: which document a field’s value came from, and why the agent chose it over another candidate. That record is available for review alongside the draft itself.

Application security

State-changing requests (anything that creates, edits, or deletes data) require a matching CSRF token, checked on every request. Response headers block content-type sniffing, clickjacking, and cross-site scripting at the browser level. Requests that bypass our edge network and try to hit application servers directly are rejected.

AI model security

Two things matter here: what the model can be tricked into doing, and what happens to your data afterward.

Every document an agent reads (an email, an invoice, a bill of lading) comes from a party outside our control, and could contain text written to manipulate an AI reader. We treat all of it as data, never as instructions, enforced in four layers: the untrusted content is fenced off from the model’s actual instructions, only a fixed, whitelisted set of fields can come back as output, each field is validated against the shape it’s supposed to have, and outputs are checked against patterns that would indicate a manipulation attempt. A value that fails any one of those checks does not reach a draft.

On data use: we never train models on your data. Not a model of our own, not a fine-tune, not a shared one. The agents get better by keeping the corrections your team makes, which is a different mechanism entirely from training on your documents.

The model that reads your documents in production runs under a commercial API agreement that contractually excludes your data from model training. That is a different arrangement from the free consumer chat tools, where training on what users type is common. Your documents, filings, and correspondence are never used to improve anyone’s model. Any provider has to clear that bar before it reads a customer document in production, whichever model is best at the time.

Supported model providers

We choose the model that reads a document on measured performance for this workload, and we expect that choice to change as the frontier moves. Today that is Google’s Gemini API. Whatever it is next, the bar is the same: a commercial agreement that excludes your data from training, and an evaluation against real freight documents before it goes anywhere near a customer’s work.

Failover and reliability

When a document can’t be read with enough confidence, the agent stops and flags it for a person to handle directly, with an immediate alert to us. A result you can catch and correct is safer than a confident wrong one you can’t. This is the deliberate design: every draft that reaches you is either a value the agent is confident in, or an explicit flag asking for your eyes, never a quiet guess.

Human review, every time

No agent submits a filing or writes to a customer’s operational systems without a person at that company reviewing it first. That is not a configurable setting. It is why the product is built the way it is.

Report a vulnerability

If you find a security issue, email security@tiocore.com. We read every report.