Security Practices

1. Overview

StrideVoice processes sensitive business and communications data on behalf of our Customers, including call recordings, transcripts, and caller personal information. We take the security of this data seriously and have implemented a multi-layered security program to protect it.

This page describes our security practices at the time of its last update. Security is an ongoing effort; we continuously improve our posture as threats evolve. If you have questions about our security practices or wish to report a vulnerability, please see Section 13.

Customers who require more detailed security information for procurement or compliance purposes may request our security questionnaire response by contacting [email protected].

Where we are honest about maturity: StrideVoice is an early-stage, founder-operated company preparing for a controlled beta. StrideVoice does not itself hold a SOC 2 or ISO 27001 certification; our cloud providers do (see Section 11). Our internal security program relies on repeated internal and AI-assisted adversarial audits; a third-party penetration test is planned before our first paying customer, and SOC 2 is on the post-beta roadmap.

2. Infrastructure and Hosting

2.1 Hosting and Cloud Providers

StrideVoice’s services run on cloud infrastructure with independent security certifications:

• Railway: Customer dashboard and backend API are deployed to Railway, which provides containerized deployment on AWS infrastructure with SOC 2 compliance.
• Supabase: Database layer (PostgreSQL) hosted on Supabase, which maintains SOC 2 Type II certification and ISO 27001 compliance.
• Cloudflare: DNS, CDN, WAF, and DDoS mitigation. Cloudflare holds multiple security certifications including SOC 2 Type II and ISO 27001.
• Telnyx: Telephony infrastructure, AI processing, and S3-compatible cloud storage for knowledge base documents and call recordings. Telnyx operates under FCC carrier regulations with SOC 2 compliance.

2.2 Network Security

• All public endpoints are protected by Cloudflare’s Web Application Firewall (WAF), which filters malicious traffic and mitigates OWASP Top 10 attack patterns;
• DDoS protection provided by Cloudflare’s anycast network, which absorbs and mitigates volumetric attacks;
• Production services run in isolated, containerized environments managed by our hosting providers;
• All database access requires authenticated connections, and row-level security policies enforce tenant isolation on every tenant-scoped table.

2.3 Availability

Core infrastructure is designed with redundancy and automatic failover, including a standby API deployment that can answer inbound call webhooks if the primary hosting provider experiences an outage. Automated uptime monitoring runs around the clock with a public status page at status.stridevoice.com. Our Service Level Agreement (stridevoice.com/sla) describes our uptime commitments for paid production plans; beta accounts are covered by the Beta Program Agreement instead.

3. Encryption

3.1 Encryption in Transit

All data transmitted between users’ browsers or applications and StrideVoice services is encrypted using TLS 1.3. TLS 1.0 and 1.1 are not supported. We enforce HTTPS-only access with HTTP Strict Transport Security (HSTS) headers. All internal service-to-service communications are also encrypted in transit.

3.2 Encryption at Rest

• Call recordings: Stored and encrypted at rest by Telnyx using server-side AES-256 encryption.
• Knowledge base documents: Stored in Telnyx Cloud Storage (S3-compatible) with server-side encryption at rest.
• Database: Supabase PostgreSQL databases use at-rest encryption at the volume level.
• Third-party integration credentials: Encrypted with AES-256-GCM before storage in the database. The encryption master key is stored separately in Infisical (our secrets manager) and never in the database. A unique initialization vector (IV) is generated for each encrypted value. Authentication tags are verified on decryption.

3.3 Secrets Management

All application secrets (API keys, database credentials, encryption keys) are managed through Infisical. No secrets are stored in source code, version control, environment files on servers, or container images. Secrets are injected into the runtime environment at deployment time.

4. Access Controls

4.1 Customer Data Isolation

StrideVoice enforces strict tenant data isolation using PostgreSQL’s Row-Level Security (RLS) policies. Every table containing customer data has RLS enabled. All database queries are scoped to the authenticated tenant, and API routes additionally filter every query by tenant identifier. These two independent layers are designed to prevent one customer from accessing another customer’s data.

4.2 Authentication

• Customer authentication is provided by Supabase Auth, supporting email and password and Google OAuth sign-in. Customer-facing multi-factor authentication (TOTP) is on our roadmap ahead of general availability and is not yet available in the console;
• Automated security alert emails fire on new logins from unrecognized devices, password changes, and authentication factor changes;
• Sessions use signed JWT tokens with short expiration windows and refresh token rotation. Server-side session caching enforces token expiry and immediate revocation;
• Per-tenant rate limiting protects sensitive API operations, with brute-force protections on authentication provided by Supabase Auth.

4.3 StrideVoice Internal Access

Access to production systems by StrideVoice personnel is restricted to those with a legitimate business need and follows the principle of least privilege. Administrative actions taken through the platform are recorded in an audit log. StrideVoice does not access Customer call recordings or transcripts except to operate, debug, and improve the Services (including the closer review beta accounts receive under the Beta Program Agreement), in response to a support request, or when required by law.

5. Call Recording Security

Call recordings contain sensitive audio data and are treated with a higher level of protection than other data types:

• Recordings are hosted by Telnyx and accessed via authenticated, time-limited URLs generated by our backend after verifying the Customer’s session — recordings are never directly publicly accessible;
• All recordings are encrypted at rest using server-side AES-256 encryption;
• Recordings are subject to the Customer’s configured retention policy (default 90 days) and are automatically deleted upon expiration;
• Customers can delete individual recordings or all recordings at any time through the dashboard.

6. PCI Data Protection

StrideVoice is designed to keep your business out of PCI scope. Payments go through Stripe. Card data gets scrubbed. Recordings get purged. You focus on running your business.

6.1 Automatic Transcript Redaction

Credit card numbers, CVVs, and security codes are automatically detected and redacted from every call transcript — before it ever hits our database. If sensitive financial data is detected, the call recording is purged. Your customers’ payment info is never stored on our systems.

• Primary Account Numbers (PANs): Detected via pattern matching and validated with the Luhn algorithm to eliminate false positives;
• CVVs and expiration dates: Detected in context alongside card numbers and redacted;
• Social Security Numbers: Detected and redacted from transcripts;
• Bank account and routing numbers: Detected and redacted from transcripts.

6.2 Recording Purge

When PCI-sensitive data is detected in a call transcript, the associated call recording is automatically purged. A flag is set on the call record so contractors can see that financial data was detected and handled.

6.3 Payment Handling

StrideVoice billing agents are configured to redirect callers to secure Stripe payment links rather than accepting card numbers verbally. This design keeps card data off the voice channel entirely whenever possible.

7. Application Security

7.1 Secure Development

• TypeScript strict mode and ESLint enforce type safety and coding standards;
• All user inputs are validated using Zod schema validation before processing;
• Parameterized queries prevent SQL injection;
• Content Security Policy (CSP), X-Frame-Options: DENY, X-Content-Type-Options, and other security headers are enforced on all responses;
• CORS configured to allow only authorized origins (stridevoice.com, console.stridevoice.com).

7.2 Webhook Security

All inbound webhooks (from Telnyx and Stripe) have their signatures cryptographically verified before processing. Webhooks with invalid or missing signatures are rejected immediately (HTTP 401). This prevents spoofed webhook attacks.

7.3 Error Monitoring

Application errors are captured and monitored in real-time using Sentry on both the backend API and the customer console. Sentry is configured for error monitoring only: performance tracing and session replay are deliberately disabled so that caller conversation content stays out of error reports. Error alerts are routed to the operator in real time.

8. Vulnerability Management

• Dependency scanning: All npm dependencies are scanned for known vulnerabilities using npm audit on every CI build. Builds fail on high or critical severity vulnerabilities;
• Dependabot: GitHub Dependabot monitors for new CVEs in our dependency tree and automatically opens pull requests for security patches. Patch and minor security updates merge automatically once CI passes; major updates are reviewed manually;
• Docker image updates: Base Docker images are monitored monthly via automated tooling so security patches are incorporated promptly;
• Platform patching: Operating system and platform patching for our primary hosting (Railway, Supabase, Cloudflare) is managed by those providers; self-hosted supporting services are updated on a regular cadence;
• Supply chain hardening: All Docker builds and CI pipelines run with --ignore-scripts to prevent malicious postinstall hooks from executing. Lockfiles are enforced on every install;
• WAF rules: Cloudflare WAF rules are updated automatically by Cloudflare to protect against newly discovered web application attack patterns.

9. Incident Response

StrideVoice maintains a documented incident response plan covering detection, containment, eradication, recovery, and post-incident review.

In the event of a security incident affecting Customer data:

• StrideVoice will investigate and contain the incident as quickly as practicable;
• Affected Customers will be notified within 72 hours of confirmation of a personal data breach, as required by our Data Processing Agreement (stridevoice.com/dpa);
• Notification will include the nature of the incident, data affected, likely impact, and corrective measures taken;
• A post-incident report will be prepared for significant incidents and made available to affected Customers upon request.

Service disruptions are communicated in real-time at status.stridevoice.com.

10. Personnel Security

StrideVoice is a founder-operated company. We state this plainly because it is the honest answer to the “personnel security” section of a security review, and because it has a real upside: the number of people with access to production systems and Customer data is currently one.

• Production access is limited to the founder; there is no shared or standing third-party access to Customer data;
• Any contractor or team member added in the future will be bound by written confidentiality obligations and granted least-privilege access before receiving any production access, with access revoked promptly when their engagement ends;
• Customer-facing team access controls in the product (seat management and role-based permissions) are built and will be enabled as team features roll out.

11. Sub-Processor Security

All sub-processors are evaluated for security posture before engagement and are required to maintain security standards consistent with industry best practices:

• Telnyx: FCC-regulated carrier with SOC 2 compliance, providing secure telephony infrastructure, AI processing, encrypted audio, call recording storage, and S3-compatible cloud storage for knowledge base documents;
• Stripe:PCI DSS Level 1 certified payment processor (the highest level of PCI compliance), handling all cardholder data on StrideVoice’s behalf so that StrideVoice never processes or stores raw payment card data;
• Supabase: SOC 2 Type II and ISO 27001 certified database provider with enterprise-grade security controls;
• Cloudflare: SOC 2 Type II, ISO 27001, and PCI DSS certified CDN and security provider;
• Resend: Transactional email provider with SOC 2 compliance and TLS-enforced email delivery.

12. Backup and Recovery

StrideVoice maintains backup and disaster recovery procedures to protect Customer data against loss:

• Database:Our database is hosted on Supabase’s managed PostgreSQL platform. Enabling Supabase’s automated daily backups with point-in-time recovery, and running a documented recovery drill, are committed items on our pre-launch checklist before we take paying customers — we do not yet claim a tested recovery point objective;
• Call recordings: Stored in Telnyx Cloud Storage with provider-managed redundancy and encryption at rest;
• Application configuration: All application code, infrastructure configuration, and workflow definitions are version-controlled in Git. Secrets are managed through Infisical with audit logging and rollback capability;
• Recovery Time Objective (RTO): In the event of a complete infrastructure failure, we target recovery of core services within 4 hours. This is a target, not yet a tested commitment.

Our API infrastructure includes an always-on failover deployment that can answer inbound call webhooks if the primary hosting provider experiences an outage, prioritizing continuity of phone answering above all other functions.

13. Responsible Disclosure

StrideVoice welcomes responsible disclosure of security vulnerabilities. If you have discovered a potential security issue in our platform, please report it to us before disclosing it publicly so that we have the opportunity to investigate and remediate.

How to Report

Email your vulnerability report to [email protected] with the subject line “Security Vulnerability Report.” Include:

• A description of the vulnerability;
• Steps to reproduce the issue;
• The potential impact;
• Your contact information (optional, for coordinated disclosure).

Our Commitments

• We will acknowledge receipt of your report within 3 business days;
• We will investigate and provide an initial assessment within 10 business days;
• We will keep you informed of our remediation progress;
• We will not pursue legal action against researchers who act in good faith, avoid accessing or modifying Customer data, and report vulnerabilities to us before public disclosure.

StrideVoice does not currently offer a bug bounty program. We ask that you do not exploit vulnerabilities beyond what is necessary to demonstrate the issue, and that you allow us at least 30 days to remediate before public disclosure.

14. Contact

For security inquiries, vulnerability reports, or security-related questions: