Sign inContact us
◈Security

How TrailScope handles your data.

Specific facts about where your trail book lives, how it's encrypted in transit and at rest, and how each organisation's records are isolated from every other.

AWS Sydney
ap-southeast-2
AES-256 at rest
TLS 1.2+ in transit
Row-level isolation
RLS on every table
Cards via Stripe
Never on our servers
⬡Architecture

Six things, stated plainly.

Below are the architectural facts behind that. We don't claim certifications we don't hold, and we don't use phrases like "enterprise-grade" or "bank-level". If something here is unclear or you want documentation for a procurement review, email us — contact below.

Where your data lives

TrailScope runs on Supabase (managed Postgres) hosted on AWS. The project is region-pinned to AWS Sydney — ap-southeast-2 — so trail data, backups and Edge Function execution all stay in Australia.

  • Single AWS region: ap-southeast-2 (Sydney)
  • Daily encrypted backups managed by Supabase
  • No data is sold or shared with third parties

Encryption

All connections to the application and database use TLS 1.2 or higher. Database storage is encrypted at rest with AES-256 via AWS-managed keys.

  • TLS 1.2+ enforced on every HTTPS connection
  • AES-256 at rest on the underlying AWS volumes
  • API keys for AI providers never returned to the browser — only the last four characters

Tenant isolation

Every table that holds organisation-scoped data has Postgres Row Level Security enabled. The shared is_org_member() function gates every read and write — a query made by user A cannot return rows belonging to organisation B.

  • RLS on clients, loans, trail/upfront/clawback, tasks, uploads, AI keys, billing
  • is_org_member(org_id) check on every multi-tenant policy
  • Service-role key used only inside Edge Functions, never shipped to the browser

Authentication & roles

Sign-in is handled by Supabase Auth using email + password or Google / Microsoft OAuth. Within an organisation, members hold one of three roles: ADMIN, BROKER, VIEWER. Settings, member management, billing changes and account deletion are gated to ADMIN both in the UI and in the SQL policies.

  • Email/password and Google + Microsoft OAuth (configurable per project)
  • Three roles: ADMIN, BROKER, VIEWER
  • Destructive actions (delete org, delete member) require typed-name confirmation and an ADMIN role check enforced in a SECURITY DEFINER RPC

Payments

Card numbers, expiry dates and CVCs never touch our servers. Subscriptions, card entry, plan changes and invoice history are all handled inside Stripe Checkout and the Stripe Customer Portal — TrailScope only stores a Stripe customer ID and the current plan / status.

  • Stripe Checkout collects and stores card data (PCI-DSS handled by Stripe)
  • Webhooks verified with HMAC-SHA256 against the shared secret before any DB write
  • Local mirror table holds plan, status, period end — never card numbers

AI provider keys (BYOK)

Organisations on a paid plan can bring their own Anthropic, OpenAI or Gemini API key. Keys are stored with Postgres column-level grants so the authenticated role literally cannot SELECT the api_key column — the RPC that reads it runs as service-role inside an Edge Function, and only the last four characters are ever sent to the browser.

  • Per-organisation key, scoped via the same RLS rules
  • GRANT applies to status / provider / key_last4, never to api_key
  • Conversation prompts sent server-side to the provider — they don't transit the browser

Found a vulnerability or have a question?

Email security@trailscope.com.au. We read every report. Please include reproduction steps and don't run automated scans against the production environment.

Email security team