Skip to main content

Review current security boundaries

Security documentation must distinguish a control observed in the product from a policy promise, contract term, audit result, or planned feature.

Verified implementation controls​

  • Supabase JWT authentication protects private API routes.
  • Workspace and resource access checks enforce role permissions in backend routes.
  • Integration tokens use Supabase Vault and a service-role-only decrypted view.
  • Stripe webhook events are verified with the Stripe signing secret.
  • Workspace invitation, shared-test, chat-session, and Vox approval tokens use hashing or signatures appropriate to their flow.
  • Public knowledge URLs reject credentials and private-network destinations and recheck redirects.
  • Vox attachments use a private storage bucket and expiry sweeper.
  • Custom voice creation records consent confirmation and uses a private provider voice.
  • Agent publication snapshots functions and integration tools for versioned runtime behavior.

Current limitations​

caution

The current Telnyx webhook route parses event payloads but does not verify a Telnyx signature before processing them. Do not represent Telnyx webhook-signature verification as an implemented control. Remediate and test it before relying on the webhook for a formal security assessment.

Other current boundaries include:

  • no configurable call or transcript retention period;
  • no individual voice-call deletion or transcript export control in the interface;
  • no Vox thread deletion control;
  • no guarantee that every call has a stored audio recording;
  • no automatic PII redaction before knowledge embedding or model processing;
  • no product evidence here of a current SOC 2, ISO 27001, PCI DSS, HIPAA, or similar certification;
  • no self-service BAA workflow;
  • no source-code basis for promising zero retention or no-training terms for every selected third-party provider; and
  • no single account-wide export or deletion workflow.

Policy and implementation drift​

Repository policy drafts and security notes can become stale or describe intended behavior. Before publishing a claim:

  1. verify the production code path;
  2. verify deployed database migrations and storage policies;
  3. verify provider settings and the signed agreement;
  4. verify the current public Privacy Policy and Terms; and
  5. assign an owner and review date.

Do not copy a roadmap item into customer-facing security documentation as if it already exists.

Regulated or high-risk data​

Before processing health, payment-card, biometric, children's, government-ID, legal, or similarly sensitive data, obtain written approval from the organization's security and legal owners and confirm all required provider agreements and technical controls. If those controls are not established, keep the data out of Wirevox.