How RailOps is secured.What your IT department will ask.

Summary for IT

Each claim on this page carries a number from C01 to C38. Claims our automated suite checks keep a hedged wording and a “not yet measured” or “failing” badge until the suite reports a pass; claims marked “source” are true by construction and cited, in our claims register, to the exact files and lines they rest on. The table under How to verify lists every claim and its status.

Architecture & hosting

RailOps is a web application. The browser talks to the railroad's own database project over encrypted connections; the database enforces who may read or change each row. Server functions hold every provider key, so the browser never talks to an AI provider directly.

• Every railroad runs in its own Supabase project and its own website; no account reaches more than one railroad's data. (C05)

Row-level security and tenant isolation are covered in their own section below.

Data protection

In transit and at rest

• passedConnections use TLS 1.2 or 1.3 only; TLS 1.0 and 1.1 are refused on every site and on the database API.C01 · Clearline production audit, 22 October 2026 ; tests SEC-T1
• sourceEncryption at rest is provided by the hosting providers: Supabase encrypts the database on AWS in us-east-2 with provider-managed keys (see Supabase's security statement), and the backup storage encrypts each dump with its own keys. The secrets RailOps stores (the AI provider key, the licensing and control-plane signing secrets, and the outreach email key) are also encrypted in Supabase Vault, with a key Supabase holds outside the database, and are decrypted only inside database functions that check who is asking. No other data is encrypted at the column level.C34 · Supabase's published security statement; Vault migration ; Backup storage settings

Backups

• Every night the database, including the accounts behind it, is dumped and copied to private, encrypted, object-lock-capable storage that Clearline controls, using an upload key limited to that one bucket that cannot delete; the dumps are encrypted with the storage provider's keys. A monthly automated restore drill restores the newest dump into a scratch database and checks the records. The drill proves that records restore, not that a complete hosting project can be rebuilt, and the backup job's success status does not by itself confirm that the dump reached off-site storage; an automatic check for that is planned. (C18)

Supabase keeps its own platform backups in addition to ours. We have not yet published a recovery point or recovery time objective; the nightly schedule alone implies a worst case of about one day of data loss, before counting Supabase's own backups.

Retention

• A retention schedule naming the governing authority and the minimum period for each of 13 record families lives in the database. (C16)

The schedule is shown on the Records screen so the railroad's Director can check each period against the regulation in force. The periods are floors: the backups keep everything.

Personal data RailOps holds

• Employees' names, employee numbers, email addresses and roles.
• Training, exam and qualification records.
• Incident reports and safety concerns; confidential safety concerns are stored without a name.
• Crew location check-ins and route traces, only after the person's recorded consent.
• Contact details of the railroad's customers, and of invited demonstration evaluators.
• The browser description recorded with sign-ins and terms acceptances.

Operational records (car movements, jobs, inspections, waybills, hazmat handling) sit alongside these. Hazmat and TIH handling data is Sensitive Security Information under 49 CFR 1520 and is restricted accordingly (see Record integrity).

Data on staff devices

RailOps keeps a copy of recent data on the device so crews can keep working without signal. Until sign-out also clears that copy (see Roadmap), treat shared yard computers and phones as holding railroad data and protect them with screen locks and separate operating-system accounts.

Identity & access

RailOps uses Supabase Auth with email and password. There are no social or enterprise sign-in providers, and no self sign-up: the sign-in screen offers none, and accounts are issued by the railroad.

• Crews sign in with an Employee ID. The system never discloses which email address sits behind an ID, and answers an unknown ID and a wrong password with the same message, in the same time. Five failed attempts on one ID, or thirty from one network address, within 15 minutes lock that ID or address for 15 minutes, with one message that is the same whether or not the ID exists. (C11)
• A database trigger refuses any change to a person's role, suspension, facility-administrator flag or support grant unless it comes from the railroad's Director or from the server itself. (C08)
• Account administration is checked on the server. On a railroad's project a Trainmaster can issue only the railroad's working roles, never a Director, Trainmaster or vendor support account, and only the Director can reset, suspend, reinstate or remove a Director's account or the support account. Each account change, and every change of role, is written to an add-only log that only the Director can read; if that log cannot be written, the change still goes through and the failure is reported in the server's own log. (C37)
• Screen access can only be narrowed by the Director, never widened beyond what the build allows; the route guard refuses a typed web address for a screen the person may not open, and an automated test covers every screen and role. Screen access is an organisational control, not the lock on the data: row-level security is. (C10)

Plain statements

• Two-step sign-in: Directors and Trainmasters, any other role a railroad chooses, and Clearline's operator account sign in with a password and then a six-digit code from an authenticator app. The database itself refuses their requests, reads included, until the code has been given, so a password alone opens nothing. The server functions behind the Anthropic-based AI features, the Demurrage Calculator AI and switch-list email apply the same rule themselves. A Director resets a lost phone. Crews and customers sign in with a password unless their railroad adds their role.
• Every new or changed password must be at least 12 characters and include a capital letter, a small letter, a number and a symbol. The sign-in service enforces this on every railroad project, and the app checks the same rule when an administrator issues or resets an account. When people change their own password, one known from a data breach is refused. A password set before 24 October 2026 keeps working until it is next changed.
• No self-service password reset, by design: a Director or Trainmaster issues and resets railroad accounts (only the Director for a Director's account or the support account), and a customer's facility administrator resets that facility's logins.
• Suspending an account is an authentication-level ban that takes effect at once; the person's records stay. We recommend suspending departing users rather than deleting their accounts (see Logging & audit).
• Sessions stay signed in on the device and refresh automatically. The app signs out everyone who must use two-step sign-in, apart from crews and customers working in the field, after a period with no typing, clicking or touching in any of its open tabs on that device: 60 minutes unless the Director sets another period, up to a day, or turns it off. A warning a minute before offers to stay signed in.

Settings we check by hand

• manually verifiedFour dashboard settings were checked by hand on the date shown: email self-signup is disabled on every railroad project, leaked-password protection is on, passwords must be at least 12 characters with lowercase and uppercase letters, digits and symbols, and the public website has no site-wide password.C33 · Manual checks register ; tests SEC-M1, SEC-M2, SEC-M3, SEC-M4; manually verified on 2026-10-24

Row-level security & tenant isolation

• Row-level security is switched on for every table in the database: 112 of 112 tables on 22 October 2026. Every read and write therefore passes through the table's access rules; whether each rule is exactly right for each role was last tested against the live database on 8 September 2026, and that per-role test is being repeated. (C07)
• The database rules are written so that customer (industry) logins see only their own facility's rows and shipper logins see only their own cars and never write; per-role testing of these rules against the live database was last done on 8 September 2026 and is being repeated. (C09)

• passedWithout an API key the database API answers 401. With only the public browser key, an anonymous caller reads no rows from any of the sensitive tables the suite probes, and every privilege check behind the access rules that the suite probes refuses anonymous callers.C04 · Clearline production audit, 22 October 2026 ; RailOps database migration revoking anonymous access to the privilege checks ; RailOps database migration of 28 October 2026 withdrawing anonymous access from the remaining privilege checks ; tests SEC-A1, SEC-A2, SEC-A3

Two representative rules

• The switching log can be read and written only by the railroad's own operating and office staff, not by customer logins, trainees or the vendor support account, and the anonymous role holds no rights on it at all.
• Every personnel, training, incident, records, terms, hazmat and shipping-paper table carries a restrictive rule that refuses the vendor support account, whatever any other rule allows and whether or not a grant is live.

Restrictive rules are combined with every other rule on the table, so a rule added later cannot quietly undo them. Paid modules use the same mechanism: a module that is switched off returns no rows to anyone.

Vendor support access and Clearline's support tool

Clearline staff help a railroad only through that railroad's own support account and only while its Director has granted access. There is no Clearline master login to any railroad's data.

How a railroad grants access

1. Once, the railroad's Director creates a support account (role “RailOps support (vendor)”) in Setup → Users. Clearline holds its credentials.
2. When help is needed, the Director grants access for a number of days (at most 90) with a reason, in Setup → Users → Support access, choosing “Read-only (recommended)” or “Read and change”.
3. The grant ends on its own at the end time, or the Director ends it at once with one click.
4. Each grant and revocation, with the kind of grant, is written to a log the railroad can read and nobody can edit. Expiry happens automatically at the recorded end time; the log shows that end time rather than writing a separate expiry entry.

• not yet measuredVendor support access is designed to exist only while the railroad's Director has granted it (at most 90 days at a time), to be read-only unless the Director chooses to let support make changes, to end on its own or by one-click revocation, to be logged append-only, and to stay walled off from 21 personnel, training, certification, incident, records, terms, hazmat and shipping-paper tables whether or not a grant is live. The checks that confirm this against the source and on each railroad's project are shown under How to verify.C06 · RailOps vendor-support migration ; RailOps read-only support migration, 27 October 2026 ; Clearline production audit, 22 October 2026 (Section 3; finding P-15) ; tests SEC-R1, SEC-S8

Read-only by default. A grant is read-only unless the Director picks “Read and change” when granting it. Under a read-only grant the support account can read what the grant opens on operational and configuration tables, and the database refuses it the office-level permissions that would let it change them. Under a “Read and change” grant it holds the same office-level permissions as the railroad's office staff, including making changes, until the grant ends. The Users screen shows which kind of grant is live next to its end date. Either way, Clearline's support tool cannot change anything: it is read-only by construction (C21).

Walled off by the database, grant or not

What Clearline's support tool reads

• The support-access log (who granted access, when, until when and why).
• Module switches and the license sync state.
• Screen-access settings (which screens are switched off for which role).
• The railroad's list of industries it serves.
• The daily briefing schedule.
• Switch-list delivery records, only where the database lets a support login see them (normally it does not).
• The job-tracking and screen-guide switches.
• Account rows (role, suspension, grant dates), with email addresses, employee numbers and phone numbers masked and names reduced to initials.
• Railroad settings such as the railroad's name and ERG edition; emergency contact, phone and address are reported only as present or missing, never their values.

What the support tool never reads

• Evaluations, Part 243 certification files and training records.
• Incidents and confidential safety concerns.
• The Records layer (change log, exports and retention schedule) and terms acceptances.
• The hazmat audit log, hazmat inspections, positive transfers, waybills and other hazmat summaries (SSI).
• The sign-in log, failed sign-in counts, the account-change and switch-list email logs, and notifications.
• Crew location consents and positions, customer contacts and demonstration or call-booking leads.
• The AI provider key, control-plane and licensing secrets, and every other secret.

The support tool's own controls

• passedClearline's support tool refuses to start with anything but a railroad's publishable (browser) key, and refuses to serve data if the configured login is not a support account.C20 · Clearline support tool source ; tests SEC-S1, SEC-S6
• passedThe support tool performs only GET reads and allow-listed read-only function calls; it cannot write, delete, call account administration or send switch lists.C21 · Clearline support tool source ; tests SEC-S2, SEC-S7, SEC-S10
• passedSSI, hazmat, waybill, personnel, incident, records, terms, sign-in-log, account-change and secret tables are denied in the tool's code, and a configuration edit cannot remove those denials. The database itself also refuses the support role on the personnel, training, incident, records, terms, hazmat and shipping-paper tables.C22 · Clearline support tool source ; RailOps read-only support migration, 27 October 2026 ; tests SEC-S3, SEC-S10
• passedPersonal identifiers are masked before the AI model sees them: email addresses, employee numbers and phone numbers are partly hidden wherever they appear, including inside free-text notes; names in name fields are reduced to initials unless staff look up one exact account; contact details in railroad settings are reported only as present or missing. A person's name written inside a free-text note is not detected.C23 · Clearline support tool source ; tests SEC-S4
• passedEvery tool call is written to a tamper-evident, hash-chained audit log that records what was asked of which table, never the data returned; a per-railroad vendor access report is available to the Director on request.C24 · Clearline support tool source ; tests SEC-S5
• not yet measuredBecause the database re-evaluates the grant on every request, revoking or expiring it ends the tool's data access, and the tool is built to re-check the grant during a session; the status of the automated checks is shown under How to verify.C25 · RailOps vendor-support migration ; Clearline support tool source ; tests SEC-S6, SEC-S8
• not yet measuredWhat the support login can and cannot read follows from the database rules above; the per-project measurement (reach and support-wall probes) is shown under How to verify once it has run on a project.C26 · RailOps vendor-support migrations ; Support-login expectations file ; tests SEC-S8
• passedInternal documentation is never served to a customer-tier knowledge base.C27 · Clearline support tool source ; tests SEC-S9
• passedOpening a ticket is the tool's only outbound side effect; it needs a person's confirmation, goes only to Clearline's own email domain over encrypted mail transport, and never contains raw rows.C28 · Clearline support tool source ; tests SEC-S11, SEC-S12

Record integrity

• Regulated records are stamped by the server with who and when, and every change to them is written to an append-only change log by a database trigger the app cannot skip; inspections can be added but never changed or removed, and the database rights to empty a records table in bulk or to attach triggers to it are withdrawn. (C12)
• Inspections, bad orders, incidents, hazmat and Part 243 audit rows and sealed transfers cannot be deleted by any login; every other change or deletion on a regulated table is written to the change log with who did it. (C13)
• Completed TIH positive transfers are sealed into a SHA-256 hash chain and cannot be altered or deleted once complete; a monthly job re-verifies the whole chain and publishes its head outside the database. Two caveats: the head is published to our source repository, which has the same owner as the database, so it is not yet an independent anchor; and on the production project the chain holds one sealed transfer whose head has not changed since 9 September 2026, so the monthly job has re-verified it without adding a new entry. (C14)
• Records exports carry a SHA-256 manifest and are themselves recorded: who exported, when, which record family, which date range and the manifest hash. (C15)
• Hazmat and TIH handling is logged to a separate append-only audit table that only the Director and Trainmaster can read, because the data is Sensitive Security Information under 49 CFR 1520. (C17)

Managers can remove rows entered by mistake on some operational tables, such as a train entered twice or a car-department request raised in error; where the table is a regulated one, each removal is kept in the change log with who made it.

AI and third-party model providers

• AI provider keys are held server-side: the browser never calls Anthropic or Google directly, and the stored key cannot be read back except by the railroad's Director through a guarded function, and only a value shaped like a key can be stored. The RailOps AI operating assistant only proposes changes, which a person must confirm, and does not send the training program. Other AI features do send training material or employee data to a model; the table in the AI section lists exactly what each sends. (C35)

Answers from any AI feature can be wrong. Treat them as suggestions to check against the documentation and the railroad's own rules. Each request to the Anthropic-based AI features is logged with who asked, for which feature and how it ended, never the question itself, and a railroad's daily use of them is capped. An account that must use two-step sign-in can use those features and the Demurrage Calculator AI only after giving its code.

How long Anthropic keeps API inputs, and whether it may use them for training, is governed by Anthropic's commercial API terms; our statement of that position is in section 7 of the Terms of Use.

Sub-processors

These providers process data for RailOps, its websites or Clearline's support tool.

See also our Privacy Policy.

Application & web security

Transport and browser headers

• passedHTTP Strict Transport Security is sent by every site.C02 · Clearline production audit, 22 October 2026 ; tests SEC-T2
• passedEvery site sends browser security headers: a Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. The automated suite checks all five on every site on each run, and their live status per site is published in the report.C03 · Clearline production audit, 22 October 2026 (finding P-4) ; Each site's header configuration ; tests SEC-T3, SEC-D1

Demonstration

• passedAccess to the demonstration is by individual invitation, on a separate project whose railroad data is fictitious and resets every hour (the project also holds invited evaluators' account details); the demonstration settings are present only on the demonstration portal.C19 · RailOps deployment guide ; RailOps demonstration mode ; tests SEC-D1, SEC-M1

Server functions and the control plane

In our 22 October 2026 audit, each of the four server functions we probed refused an unauthenticated call. The functions behind the public call-booking form accept unauthenticated requests by design.

• Clearline's control plane acts on a railroad only through HMAC-SHA256 signed messages made with a secret unique to that railroad: commands are accepted once and only within ten minutes, and an older license cannot replace a newer one. The secrets are kept encrypted in Supabase Vault, no signed-in or anonymous caller can read them, and they can be rotated. (C36)
• Switch lists, interchange orders and transfer records are emailed only to inboxes the facility has saved, ticked from that list, never to an address typed at the moment of sending. The server writes the subject and message; each account may send at most 50 in any 24 hours by default; each send is recorded with its outcome in a log only the Director can read; and an account that must use two-step sign-in can send only after giving its code. (C38)

Code and dependencies

• passedThe support tool's code is statically analysed and its dependencies are audited for known vulnerabilities on each report run; the result and date are in the report.C30 · Dependency audit, 22 October 2026 ; tests SEC-C1, SEC-C2
• passedNo secrets were found in the support tool's repository, its knowledge base or the website sources on the last scan; the date is in the report.C31 · Clearline security suite ; Secret-shape scan, 22 October 2026 ; tests SEC-C3, SEC-C4

• The portal's dependencies are pinned by a lockfile, and its third-party notices are generated from the dependency tree.
• A scan of 501 packages (the portal's dependency tree and the public website's two bundled libraries) on 22 October 2026 found published advisories against a few runtime libraries; our review found none reachable as deployed, and the updates are scheduled.
• The public website serves its browser libraries from its own address, not from a public CDN.

Logging & audit

• Not alerted today: there is no export to a security information and event management (SIEM) system and no real-time alert on failed sign-ins or refused requests. The monthly chain-head job fails loudly if the transfer chain stops verifying.
• Deleting an account today also removes its sign-in log and terms-acceptance entries, so suspend departing users instead; keeping those entries after deletion is planned.
• How long Clearline keeps its support tool's audit log and tickets is stated in section 7 of the Terms of Use.

Incident response & disclosure

Reporting a vulnerability

Write to security@clearlineprotocol.com with “Security” in the subject. Please include what you found, where, the steps to reproduce it and how to reach you. We will acknowledge your report and keep you informed of what we do about it.

• passedA security.txt file (RFC 9116) naming the disclosure contact on this page is published.C32 · RFC 9116 file prepared for the website ; tests SEC-T4

• Safe harbour. If you act in good faith — you test only accounts you are authorised to use, you do not access, change or delete other people's data, you do not degrade the service, and you give us reasonable time to fix an issue before you disclose it — we will not pursue or support legal action against you for that research.
• Do not run automated scanners or load tests against a railroad's production project; talk to us first.
• We do not run a bug bounty and do not pay for reports.

If an incident affects your railroad

Under the Master Subscription Agreement (section 6.4) we notify an affected customer without undue delay.

A written incident-response runbook, covering credential rotation for every class of secret and how we notify customers, is being prepared. Supabase, Netlify and our other providers run incident response for their own platforms.

This page works alongside our Terms of Use and our Privacy Policy.

Roadmap

Planned improvements as of 27 October 2026. We list them so your review can take them into account; this page does not promise completion dates.

• Added 2026-10-29: a weekly automated security check-up (dependencies, secrets, code, headers and content policy, certificates, the database catalog, platform settings) with a written report; an in-app AI notice with recorded acceptance and a generation log; single sign-on (SAML 2.0) for railroads that order it; a public Continuity page; /.well-known/security.txt on every site. RailOps is information technology on your people's phones and office computers; it connects to no signalling, control or interlocking system and issues no movement authority.
• Self-hosted PDF library on the customer site.
• Clearing device caches on sign-out.
• Committing the source of every deployed function.
• An expiry entry in the support access log.
• An automatic check that each nightly backup reached off-site storage, and stated recovery objectives.
• An independent copy of the transfer-chain head.
• An independent penetration test.
• A written incident-response runbook and a breach-notification window stated in hours.

How to verify

Clearline runs its security test suite with api-agent-security --live --target demo. The live checks only read: they make no sign-up, no update and no insert, and they run against the demonstration project unless the production target is named explicitly. Each run writes a machine-readable report and a readable summary, which we share with your IT team on request.

• passedThe published security test suite makes no write request to any project: no sign-up, no update and no insert probes.C29 · Clearline security suite ; tests SEC-S13

Claims marked “source” are cited in our claims register to the exact files and lines of the RailOps source and configuration; we can walk your reviewers through those citations under NDA. Measured and tool claims show their latest automated result below; the manual claim shows the date it was checked.

Last automated run: 2026-10-29T00:07:51Z. 16/19 measured checks passing.

Changes to this page

When a claim's status changes, the page is regenerated from the latest security report; when its wording changes, the version above changes too.

Questions about this page: security@clearlineprotocol.com. Related: Terms of Use and Privacy Policy.