How we protect your data.

System architecture

TIO runs on Railway for application services and Supabase for the database, with Cloudflare in front of the application. Each layer adds its own controls: requests reach the app through the edge, and the app requires authentication and authorization on protected routes.

Email reaches TIO through a rule in your own mail system, which copies mail to an agent mailbox that TIO hosts on Amazon Web Services. TIO holds no password or sign-in to your mailboxes, and you can stop the copy at any time by turning the rule off.

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 five roles: owner, admin, operator, finance, or sales. Roles gate which actions an account can take. Operator, finance and sales accounts 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 providers run under their own third-party security certifications.

Our database provider takes an automatic physical backup of each database every day. We last restored a database backup into a separate project and checked it against the source on October 13, 2026.

Each customer’s operational data, such as shipments, documents and agent runs, is kept in its own database. Account and sign-in records are held in a separate identity store.

Secrets management

API keys, database credentials, and other secrets are held in a dedicated secrets manager. They are not stored in source control.

Monitoring and audit trail

Authenticated requests to the application are logged: who made the request, what it touched, when, and from where. This request log excludes the activity beacon used for engagement tracking; some accepted beacons have no separate log entry. Requests are classified by sensitivity, and a security event or a failed authentication attempt sends us an alert. The application records failed security-alert delivery for investigation.

We save a record of each change request in the web application before the change runs. If we can’t save that record, the change doesn’t run. Health checks and machine endpoints are exempt.

The agent write-event journal is append-only for the application. For each agent write to a customer’s TMS, the journal keeps what the agent was about to send and the TMS’s reply. Database permissions and enforcement rules protect stored events from application edits and deletion. Agents can add an outcome as a new event. Run summaries are separate records that can change as work progresses.

We configure monitoring per customer database. In enabled environments, daily checks use a restricted, read-only account to look for security alerts without confirmed delivery and send findings to our security channel. An assigned responder handles unresolved alerts.

A weekly automated scan checks our software dependencies for known vulnerabilities, and dependency updates are proposed every week. Incidents follow a written response runbook.

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 from a signed-in browser require a matching CSRF token. Sign-in, account recovery and machine-to-machine endpoints are protected by their own checks. Response headers restrict content-type sniffing and framing and set a content security policy. Production web services validate the edge secret at startup and refuse to start if it is missing. Application servers reject requests that bypass the edge, apart from designated health and machine endpoints.

Sign-in, password recovery and password changes are rate limited. So are the assistant endpoints that call a model.

AI model security

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

Email, invoices and bills of lading can contain text written to manipulate an AI reader. During document extraction, we separate that content from the model’s instructions, limit output to an allowed set of fields, validate field formats, and check for patterns that suggest manipulation. These checks help keep untrusted content within the document-reading task.

On data use: we do not train models on your data. Not a model of our own, not a fine-tune, not a shared one. When your team corrects an agent, TIO turns the correction into a rule for your operation. A rule is a different mechanism from training a model on your documents.

The models that read your documents in production run on paid commercial API services whose terms exclude customer content from model training. That is a different arrangement from the free consumer chat tools, where training on what users type is common.

Supported model providers

We choose the model for each workload on measured performance, and we expect that choice to change as the frontier moves. Today the providers are Google (the Gemini API) and OpenAI. We evaluate a model on real freight documents when we choose it for a workload.

Failover and reliability

When an agent cannot read a document with enough confidence, it sends the work to a person instead of guessing. A result you can catch and correct is safer than a confident wrong one you can’t.

How agents are allowed to act

There is no single rule. Each action an agent can take has its own setting. It runs on its own, it sends the work for review, or it waits for a person’s reply. Anything outside your rules goes to a person, with the facts already attached.

A customs filing is prepared as a draft. A person on your team reviews and files it.

TMS write permissions are configured by action and customer. TIO can disable a configured write action while leaving other actions enabled. The agent write-event journal protects stored events as described in Monitoring and audit trail.

Review TIO for your operation

Send your security questionnaire and proposed workflows to hello@tiocore.com. Include the inboxes and systems you plan to connect, and the actions you want an agent to take.

We use that scope to review the applicable access controls, action permissions, monitoring configuration and supporting evidence with you.

Our Privacy Policy describes data collection, use, sharing and privacy requests. Our Terms of Service explain action settings and filing responsibility.

Report a vulnerability

If you find a security issue, email security@tiocore.com. We review the reports sent to this address.