Security
Security at Triage
We're a small team. Security is not optional — it's how we earn the right to hold your data.
Infrastructure
Infrastructure
Triage is built on infrastructure providers with established security certifications. We inherit the controls and certifications of our underlying stack.
Hosting: Vercel Pro — SOC 2 Type II compliant. All application code and serverless functions run on Vercel's managed infrastructure.
Database: Supabase on AWS eu-west-1 (Ireland) — SOC 2 Type II compliant. Primary data residency in the EU.
HTTPS / TLS 1.3 — All traffic is served over HTTPS. TLS 1.3 is the minimum version enforced across all endpoints.
HSTS enforced — HTTP Strict Transport Security headers are set on all responses, preventing downgrade attacks and cookie hijacking.
Application
Application Security
Row Level Security (RLS): Every Supabase database query is scoped to the authenticated user via Postgres RLS policies. No query can return data belonging to a different user, regardless of application-layer logic.
JWT authentication: Auth is handled by Supabase Auth using short-lived JWT tokens. Tokens are refreshed automatically and cannot be reused after expiry.
API rate limiting: All API endpoints enforce per-user rate limits to prevent abuse, credential stuffing, and runaway credit consumption.
Input sanitisation / prompt injection prevention: All CSV and CRM data is sanitised before being included in Claude API calls. User-supplied data is never directly interpolated into AI system prompts.
No eval() or unsafe innerHTML: User-supplied data is never passed to
eval() or set as raw innerHTML. DOM manipulation uses safe APIs only.
Content Security Policy: CSP headers are set to restrict resource loading to trusted origins and prevent XSS attacks.
Dependency auditing:
npm audit runs on every deploy. Critical and high vulnerabilities block deployment.
Data
Data Security
Encryption at rest: AES-256 encryption is applied to all data at rest via Supabase's default storage configuration.
Encryption in transit: TLS 1.3 is enforced on all connections between clients, application servers, and the database.
CSV files not permanently stored: Uploaded CSVs are processed server-side to generate briefs and are not written to persistent storage. Raw CSV data is discarded after processing.
API keys stored encrypted, never logged: Third-party API keys (ZeroBounce, People Data Labs, CRM tokens) are stored as encrypted environment variables. They are never written to logs or exposed in client-side bundles.
Anthropic (Claude) — inference only: Our DPA with Anthropic confirms that data submitted via the Claude API is used solely for inference and is not retained for model training.
Internal access
Access Control
No shared accounts internally. Every team member uses individual credentials. Shared login is not permitted for any service.
Principle of least privilege. Service accounts and team members are granted the minimum access needed to perform their function. Access is reviewed when roles change.
Production database access is restricted. Direct production database access is limited to a maximum of two engineers and is audit logged.
No customer data accessed without permission. We do not access customer data for debugging or investigation without explicit permission from the customer, except where required by law.
Responsible disclosure
Vulnerability Disclosure
If you've found a security issue in Triage, we want to hear about it. We take all reports seriously.
How to report
Email security@triage.club with a description of the vulnerability, steps to reproduce, and any relevant proof of concept. Please include what data or functionality could be affected.
We aim to acknowledge reports within 48 hours.
We will keep you updated on our progress.
We do not pursue legal action against good-faith researchers. We ask that you do not publicly disclose findings before we've had a chance to address them.
Certifications
Compliance & Certifications
We are transparent about what we are and aren't certified for. We don't overstate our compliance posture.
GDPR
Designed compliant from day one. EU data residency. See Trust Centre.
Vercel SOC 2 Type II
Inherited from hosting provider (Vercel Pro).
Supabase SOC 2 Type II
Inherited from database provider (Supabase on AWS eu-west-1).
Stripe PCI DSS Level 1
Payment card data is handled entirely by Stripe. Triage never touches raw card data.
Independent SOC 2
Not yet certified. On the roadmap for the Enterprise tier launch.
FAQ
Security Questions
Is Triage secure for enterprise use?
Triage is built on SOC 2 Type II compliant infrastructure (Vercel and Supabase), enforces Row Level Security on all data, and encrypts all data in transit (TLS 1.3) and at rest (AES-256). We are not yet independently SOC 2 certified — that is on our roadmap for the Enterprise tier. If your procurement process requires documentation, contact security@triage.club.
Where is Triage's data hosted?
The primary database runs on Supabase hosted on AWS eu-west-1 (Ireland). The application is served via Vercel's edge network. EU data residency is maintained for all primary database storage.
How does Triage prevent unauthorised data access?
Supabase Row Level Security (RLS) is enforced on every database query. Each query is automatically scoped to the authenticated user — no application-layer logic can bypass this. JWT-based authentication with short-lived tokens ensures sessions cannot be reused after expiry.
Does Triage protect against prompt injection?
Yes. All CSV and CRM data is sanitised before being passed to Claude API calls. User-supplied data is never directly interpolated into AI system prompts without sanitisation, which prevents malicious content in a CSV from manipulating the AI's behaviour.
How do I report a security vulnerability?
Email security@triage.club with details of the vulnerability, steps to reproduce, and the potential impact. We aim to respond within 48 hours. We do not take legal action against good-faith researchers.