Security & Trust Overview

1. Security at a glance

Trailspark is buying-group intelligence for product-led growth. We ingest first-party product and CRM signals, score accounts and contacts, and write results back to your CRM. That means we are trusted with business contact data and product-usage data — and we have engineered the platform accordingly.

---

2. Our security philosophy

We build security in rather than bolting it on. Three principles guide us:

1. Minimize the data we hold and expose. We encrypt the sensitive data we store, and we deliberately keep direct identifiers out of systems that don't need them — most notably our AI evaluation layer (§9).
2. Defense in depth. No single control is load-bearing. Authentication, authorization, tenant scoping, encryption, input validation, and security headers each independently reduce risk.
3. Verify, don't assume. Security-relevant behavior is covered by automated tests, and the codebase has been put through a structured, adversarial security review.

---

3. Compliance & certifications

SOC 2 — roadmap-aligned, in progress. Trailspark is not yet SOC 2 attested. We have, however, built and operated our controls against the SOC 2 Trust Services Criteria (Security, Availability, and Confidentiality), and formal attestation is on our roadmap. Several controls in our codebase were implemented explicitly to meet SOC 2 expectations (for example, password-complexity enforcement and defense-in-depth security headers).

What this means for you today:

• We can speak in detail to each control area below and demonstrate the underlying implementation on request.
• We provide a Data Processing Agreement (DPA) governing how we process personal data, including our sub-processor list and EU/UK/Swiss Standard Contractual Clauses for international transfers.
• Independent third-party penetration testing is planned as part of our attestation roadmap; internally, we have completed a structured multi-lens security audit of the application (§11).

We are happy to share our current roadmap and target timeline under NDA.

---

4. Access control & authentication

• Passwords are never stored in plaintext. They are hashed with scrypt (a memory-hard algorithm) using a unique per-user salt, and verified using constant-time comparison to resist timing attacks.
• Password policy enforces a minimum length of 12 characters and complexity (upper, lower, numeric, and special characters).
• Multi-factor authentication (MFA) is available using TOTP authenticator apps, with one-time backup recovery codes. MFA secrets and backup codes are stored encrypted.
• Brute-force protection: repeated failed logins trigger progressive account lockout, and authentication endpoints are rate-limited.
• Sessions are server-side, carry idle and absolute expiration, are bound to a request fingerprint to detect hijacking, and use HttpOnly / Secure / SameSite cookies in production.
• Authorization is role-based. Privileged actions require the appropriate role, and every request that touches tenant data re-verifies the user's membership and role in that tenant.

---

5. Encryption

In transit. All traffic is served over TLS (1.2 or higher). In production we enforce HTTP Strict Transport Security (HSTS) with a one-year max-age and includeSubDomains, so browsers refuse to connect over plaintext HTTP.

At rest. The underlying managed database encrypts stored data at rest. On top of that, Trailspark applies application-level field encryption to the most sensitive data using AES‑256‑GCM (authenticated encryption with a unique initialization vector per value, which both encrypts the data and detects tampering):

• Contact email addresses
• Third-party integration credentials (OAuth access/refresh tokens, API keys/secrets)
• MFA secrets and backup codes

For data we must be able to look up without decrypting (e.g., matching a contact by email), we store a one-way SHA‑256 hash of the normalized value rather than the plaintext, so lookups never require the plaintext value to be present.

Key management. Encryption keys and all other secrets are managed outside of source control via a dedicated secrets-management system and the hosting platform's secret store. The application validates the presence and strength of critical secrets at startup and refuses to run in production without them.

---

6. Multi-tenancy & data isolation

Trailspark is a multi-tenant SaaS application. Each customer is a logically isolated tenant:

• Tenants are resolved per request (including via dedicated subdomains), and a tenant context is attached to the request before any data is accessed.
• Every data query is scoped to the requesting tenant, and membership in that tenant is verified on each request.
• One tenant cannot enumerate, read, or write another tenant's accounts, contacts, signals, evaluations, or configuration.

Cross-tenant isolation is treated as a first-class correctness property and is exercised by automated tests.

---

7. Application security

• Input validation: request payloads are validated against strict schemas; invalid input is rejected before processing.
• Injection resistance: database access goes through a typed query builder using parameterized queries, which prevents SQL injection by construction.
• CSRF protection: state-changing requests require a per-session CSRF token; cross-site request forgery is blocked for browser-originated state changes.
• Security headers: we apply a hardened set of HTTP headers via Helmet — Content-Security-Policy, HSTS, X-Content-Type-Options: nosniff, frameguard (clickjacking protection), referrer policy, and cross-origin resource/opener policies.
• Rate limiting: authentication-sensitive endpoints (login, registration, password reset) are rate-limited per client.
• Webhook integrity: inbound webhooks (e.g., payment events) are verified using cryptographic signatures against the original request bytes and are processed idempotently to prevent replay.

---

8. Infrastructure & operations

• Hosting: the application runs on Railway (managed cloud platform) with TLS termination and isolated production environments.
• Database: Supabase (managed, access-controlled PostgreSQL) with encryption at rest and automated backups, hosted in the United States.
• Environment separation: development, test, and production are separated, with production secrets isolated from non-production environments.
• Secrets: managed centrally (Doppler / platform secret store) and injected at runtime; never committed to source control.
• Backups & recovery: the production database is backed up automatically by the managed database provider. Formal recovery-time / recovery-point (RTO/RPO) targets are not yet defined.

---

9. AI / LLM data handling (important)

Trailspark uses a large language model (LLM) to evaluate account and contact fit. We designed this layer to minimize what reaches the AI sub-processor: no direct contact identifiers — names, emails, or phone numbers — are sent.

For standard evaluation, the payload sent to the LLM contains only:

• Internal numeric identifiers (account ID, contact ID)
• Firmographic (company-level) attributes — e.g., industry, region, employee-count band, market segment
• Demographic attributes used for role classification — job title and normalized role (not the person's name)
• Summarized behavioral signals — event types and dates (e.g., "pricing page viewed")

The payload explicitly excludes:

• ❌ Email addresses (never decrypted into a prompt)
• ❌ Personal names (first/last name are not sent)
• ❌ Phone numbers or other direct personal identifiers

This is enforced in code: the contact's email and name are not selected into, or rendered into, the prompt that is sent to the model. (Job title and firmographics can, in combination, be indirectly identifying and are therefore treated as personal data under our DPA — but no direct identifier is transmitted.)

• AI sub-processor: the LLM provider is configurable per organization — Anthropic (Claude), OpenAI (GPT), or Google (Gemini) — and only the selected provider receives data. The current production default is OpenAI (gpt-5.4-nano, deterministic configuration). Regardless of provider, the same minimized payload applies, and the data is used for inference only and is not used to train the provider's models, per each provider's data-processing terms.

---

10. Data privacy & governance

• What we store: business contact details (name, business email, job title, employer) and product/CRM signals you send us, plus the evaluations we derive. Account credentials for your team (email + hashed password) and any integration tokens you authorize.
• Sensitive-data minimization: contact emails are encrypted at rest; emails and names are kept out of the AI layer (§9); we do not display internal processing identifiers or token/usage internals to end users.
• Data retention: operational data follows defined lifecycle and purge routines (for example, stale invitations and integration push logs are pruned automatically). On termination, Customer Data is available for export for 30 days, after which it is deleted or anonymized within 90 days (except where law requires longer retention).
• Data subject requests (GDPR/CCPA): as a data processor, we assist you (the controller) in fulfilling data-subject requests — access, rectification, erasure, restriction, and portability. Requests we receive directly from data subjects are redirected to you.
• No special-category data: the Service is not designed to process special categories of personal data (GDPR Article 9) or equivalent.
• Data Processing Agreement: available on request; it governs our processing of personal data, including sub-processors and international transfers.

---

11. Secure development lifecycle

• Test-driven development. Security-relevant behavior — authentication, authorization, tenant isolation, encryption, the AI no-direct-identifier boundary — is covered by an automated test suite that runs in CI.
• Structured security review. The application has undergone a documented, multi-lens hardening audit (covering injection, tenant isolation, authentication/MFA, authorization, webhook/API-key handling, and more), with findings tracked to remediation. This demonstrates a repeatable, evidence-based security process rather than ad-hoc fixes.
• Dependency hygiene. Dependencies are version-pinned via lockfiles for reproducible builds and reviewed for known vulnerabilities.
• Change control. Changes are reviewed before merge; production deploys are controlled.

---

12. Vendor & sub-processor management

We use a small set of reputable sub-processors, disclosed and governed via our DPA (Annex D). The current set:

This list mirrors Annex D of our DPA. Your own connected systems (e.g., HubSpot, Salesforce) are integrations you control, not Trailspark sub-processors.

International transfers. Personal data is processed primarily in the United States (transactional email is handled by an EU provider). For transfers from the EEA, UK, or Switzerland, we rely on the EU Standard Contractual Clauses, the UK International Data Transfer Addendum, and the Swiss amendments, as set out in our DPA.

---

13. Incident response & responsible disclosure

• Incident response: we maintain incident-response procedures and operational tooling for production monitoring and log inspection. We will notify affected customers of confirmed security incidents involving their data within 72 hours of confirmation, in line with our DPA.
• Responsible disclosure: security researchers and customers can report suspected vulnerabilities to security@trailspark.ai. We commit to acknowledging reports and working in good faith toward remediation.

---

14. How to engage our security team

• General security questions, questionnaires, and DPA requests: security@trailspark.ai
• We're happy to walk a security reviewer through any control area live and, under NDA, share deeper detail on our architecture and SOC 2 roadmap.

---