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 the results back to your CRM. Your customer and product data is the raw material the product runs on, so we treat security as a design constraint on how it is built rather than a layer added once it worked. The table below summarizes where that shows up; the sections after it carry the detail a reviewer needs.

---

2. Our security philosophy

Three principles shape how we build.

1. Minimize what we hold and what we expose. We encrypt the sensitive data we store, and we keep direct identifiers out of systems that have no need for them. The clearest example is our AI evaluation layer (§9).
2. Defense in depth. No single control carries the whole system. Authentication, authorization, tenant scoping, encryption, input validation, and security headers each reduce risk independently of the others.
3. Verify, don't assume. Security-relevant behavior is covered by automated tests, and the codebase has been reviewed against a written inventory of attack classes rather than by inspection alone.

---

3. Compliance & certifications

Trailspark is not yet SOC 2 attested. We have 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 exist specifically to meet SOC 2 expectations, including password-complexity enforcement and defense-in-depth security headers.

What that means for you today:

• We can speak in detail to every 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 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 with a constant-time comparison to resist timing attacks.
• Password policy enforces a minimum length of 12 characters, along with additional strength requirements and checks against reused and commonly-breached passwords.
• 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. They carry both idle and absolute expiration, are bound to a request fingerprint so that a stolen cookie replayed elsewhere fails validation, and use HttpOnly, Secure, and 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, an authenticated cipher with a unique initialization vector per value, which both encrypts the data and detects tampering. The encrypted fields are:

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

For data we must be able to look up without decrypting, such as matching a contact by email, we store a one-way cryptographic hash of the normalized value alongside the ciphertext. Lookups therefore never require the plaintext value to be present.

Key management. Encryption keys and all other secrets are managed outside of source control, in 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 rather than trusted from the session.
• One tenant cannot enumerate, read, or write another tenant's accounts, contacts, signals, evaluations, or configuration.

We treat cross-tenant isolation as a correctness property, not a policy, and it is exercised by automated tests.

---

7. Application security

• Input validation. Request payloads are validated against strict schemas, and 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 rather than by review.
• CSRF protection. State-changing requests require a per-session CSRF token, which blocks cross-site request forgery 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 for clickjacking protection, referrer policy, and cross-origin resource and opener policies. The Content-Security-Policy is enforced in production and constrains where executable content may be loaded from.
• Rate limiting. Authentication-sensitive endpoints, including login, registration, and password reset, are rate-limited per client.
• Webhook and ingestion integrity. Inbound webhooks and signal-ingestion endpoints are authenticated before any payload is processed, rate-limited per client, and handled idempotently so that retried or duplicated deliveries are not processed twice. Credential material for these endpoints is validated at startup. We describe the specific verification mechanisms to customers and security reviewers on request.

---

8. Infrastructure & operations

• Hosting. The application runs on Railway, a managed cloud platform, with TLS termination and isolated production environments.
• Database. Supabase, a managed and access-controlled PostgreSQL service, 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. Held in a dedicated secret store, injected at runtime, and never committed to source control.
• Backups and recovery. The production database is backed up automatically by the managed database provider. Formal recovery-time and recovery-point objectives are not yet defined.

---

9. AI / LLM data handling (important)

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

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

• Internal numeric identifiers for the account and contact
• Firmographic attributes at the company level, such as industry, region, employee-count band, and market segment
• Demographic attributes used for role classification, specifically job title and normalized role, but not the person's name
• Summarized behavioral signals, meaning event types and dates such as "pricing page viewed"

The payload excludes:

• Email addresses, which are never decrypted for this purpose
• Personal names; first and last name are not sent
• Phone numbers and other direct personal identifiers

This is enforced in code. The contact's email and name are never included in what is sent to the model, and the boundary is covered by automated tests.

Two qualifications worth stating plainly:

• Job title and firmographics can be indirectly identifying in combination, so we treat them as personal data under our DPA. No direct identifier is transmitted.
• Signal content you configure is passed through as you supply it. Trailspark's own contact fields are excluded by construction. Signal mapping, however, is under your control: if you map a field containing personal data into the signals you send us, that content forms part of the evaluation context. We are glad to review your signal configuration with you.

AI sub-processor. The LLM provider is configurable per organization, across Anthropic (Claude), OpenAI (GPT), and Google (Gemini), and only the selected provider receives data. The current production default is OpenAI, in a deterministic configuration. The same minimized payload applies regardless of provider, and the data is used for inference only. It 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, meaning name, business email, job title, and employer, along with the product and CRM signals you send us and the evaluations we derive from them. We also store account credentials for your team, as email plus a 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), and we do not display internal processing identifiers or token and usage internals to end users.
• Data retention. Operational data follows defined lifecycle and purge routines. Stale invitations and integration push logs, for example, 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 as the controller in fulfilling data-subject requests covering access, rectification, erasure, restriction, and portability. Requests we receive directly from data subjects are redirected to you.
• What we do not collect. The Service has no field for contact phone numbers, and we do not collect them.
• No special-category data. The Service is not designed to process special categories of personal data under 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

• Automated regression coverage. Security-relevant behavior is covered by an automated test suite of roughly 1,100 test files, about 67 of which are dedicated to authentication, MFA, account lockout, authorization, tenant isolation, CSRF, encryption, the audit-log hash chain, and the AI no-direct-identifier boundary. Each is a named regression test tied to a specific control, and the suite is run during development and code review. We can walk a security reviewer through any of them.
• Structured security review. The application has undergone documented hardening audits covering injection, tenant isolation, authentication and MFA, authorization, and webhook and API-key handling, with findings tracked to remediation in a written ledger. The process is repeatable and evidence-based rather than ad hoc.
• Dependency hygiene. Dependencies are version-pinned via lockfiles for reproducible builds, and reviewed for known vulnerabilities.
• Change control. Changes are reviewed before merge, and production deploys are controlled.

---

12. Vendor & sub-processor management

We use a small set of 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, such as HubSpot or Salesforce, are integrations you control rather than Trailspark sub-processors.

International transfers. Personal data is processed primarily in the United States, with transactional email 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 contact@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: contact@trailspark.ai
• We are happy to walk a security reviewer through any control area live and, under NDA, share deeper detail on our architecture and SOC 2 roadmap.

---