Security Overview
A plain-language account of the security architecture behind Throughline, written for both general users and the technical and procurement teams who need to evaluate it.
For users
Your content is private to you and no one else can see it. Throughline uses the same type of secure, encrypted connection as online banking, and the company that stores your data is trusted by tens of thousands of organisations worldwide.
You can delete your account and all your data at any time, instantly and permanently.
For IT and procurement
The application is built on two enterprise-grade infrastructure providers with established compliance postures.
Vercel
Hosting and edge delivery
SOC 2 Type II certified, GDPR compliant, all traffic over TLS 1.2+.
Supabase
Database and authentication
SOC 2 Type II certified, data encrypted at rest (AES-256) and in transit, hosted on AWS.
Neither provider is novel or unvetted. Both are widely adopted in enterprise SaaS environments.
Email and password authentication with bcrypt password hashing.
Email verification required on signup.
Session management handled by Supabase Auth, JWT-based, with server-side validation on every request.
SSO integration is available for enterprise accounts via SAML 2.0 (Okta, Azure AD, OneLogin) or OIDC (Google Workspace, Auth0). This can be configured to enforce SSO and restrict access to your email domain only.
Row Level Security (RLS) is enforced at the database level on every table, not at the application layer. This means even if the application layer had a bug, the database itself enforces that users can only read and write their own records.
The key architectural point
Your data is isolated at the database level, not just the application layer. Row Level Security means no code path, however unexpected, can expose one organisation's content to another.
Company administrators can view data for users within their own organisation only.
User story content is sent to Anthropic's Claude API for processing. Anthropic's enterprise API terms prohibit training on customer data by default. The following is important for your assessment.
No personally identifiable information (name, email, employee ID) is included in AI requests. Only the text the user types into the story fields is sent.
Full prompts and AI responses are not logged server-side. Only character count, timestamp, endpoint, and user ID are stored, for rate limiting purposes.
Rate limiting is enforced per user: 6 AI requests per minute, 60 per day.
Input is capped at 12,000 characters per request.
Basic prompt injection filtering is applied on all AI inputs.
All significant user and admin actions are written to an immutable audit log. Company administrators can export this log at any time.
Story creation
Story modification
Story deletion
AI requests
Admin setting changes
Security incidents
Story data: 365-day default retention, configurable per organisation from 7 to 3,650 days.
Users can export all their data or delete their account with full cascade deletion at any time.
Company administrators can trigger an immediate data purge.
This is a pilot product in active development, not a platform that has undergone independent penetration testing or achieved its own SOC 2 certification. The security posture described above reflects the current implementation and the certifications of the underlying infrastructure providers. Organisations with strict data classification requirements should note that story content, while not labelled as PII, may contain sensitive internal communications. We recommend advising pilot users not to enter content classified above their organisation's standard internal use threshold during the trial period.
For security concerns or compliance questions, response within 24 hours.
phil@sophiescott.com.au