Legal
Security
We take the confidentiality and integrity of advisor and client relationship data seriously. This page summarizes the controls Prexo uses to protect the Service.
Last updated: July 18, 2026
1. Our security commitment
Prexo is designed as a multi-tenant SaaS platform where each workspace's data is isolated at the application layer. Security is part of how we build features — especially around authentication, integrations, voice notes, and AI processing — not an afterthought.
No system can guarantee absolute security. This page describes our current practices and should be read together with our Privacy Policy and Terms of Use.
2. Infrastructure and hosting
- Application servers run on hardened Linux hosts with process management, automatic restart, and reverse-proxy TLS termination.
- Production traffic is served over HTTPS with certificates managed via Let’s Encrypt / Certbot.
- The primary application database is PostgreSQL, accessible only from trusted server environments (not exposed publicly to the internet).
- Voice-note audio is stored in private cloud object storage (DigitalOcean Spaces) with access restricted to service credentials.
- Deployments are automated through CI/CD with secrets stored outside the application repository.
3. Encryption
- Data in transit is protected with TLS (HTTPS) for web and API traffic.
- Sensitive third-party OAuth tokens (for example Google Calendar) are encrypted at rest using AES-256-GCM before storage.
- Passwords are handled by our authentication stack using industry-standard hashing — Prexo never stores plaintext passwords.
- Object storage and database connections use credentialed, private access paths rather than public anonymous endpoints.
4. Access control and tenancy
- Session-based authentication protects application routes; unauthenticated users cannot access workspace data.
- Business records are scoped by workspaceId. Queries and server actions enforce workspace membership before returning or mutating data.
- Role concepts (owner / admin / member) exist in the data model to support future team access controls.
- Administrative access to production systems is limited to authorized operators and protected by SSH key authentication on non-default ports.
- Production environment variables and secrets are stored separately from source code and injected at deploy/runtime.
5. Application security practices
- Server-side validation of inputs using typed schemas where forms and actions accept user data.
- Soft-delete and archive patterns for important CRM entities to reduce accidental permanent loss.
- Activity logging for significant mutations to support auditability within a workspace.
- AI natural-language search translates queries into allowlisted structured filters — not arbitrary SQL — to reduce injection risk.
- Webhook endpoints (for example Telegram) validate shared secrets before processing inbound events.
- Dependency and framework updates are applied as part of ongoing maintenance.
6. AI and voice-note data handling
Voice notes and related text may be processed by subprocessors (including OpenAI) solely to provide transcription, extraction, briefs, and search. Key safeguards include:
- AI suggestions are stored for user review; approved changes flow through existing CRM actions rather than silent automatic overwrites.
- Usage events are recorded for AI operations to support accountability and plan limits.
- Telegram linking uses short-lived tokens and workspace-bound connections.
- We do not sell Customer Content, and we do not use your CRM content to train third-party foundation models for unrelated public use.
Because AI providers process content to fulfill your requests, you should avoid submitting data you are not authorized to process, and you should review outputs before acting on them.
7. Integrations
- Google Calendar OAuth tokens are encrypted and can be disconnected from Settings.
- Telegram connections can be unlinked; webhook requests require a configured secret token.
- Email delivery (when configured) uses a dedicated provider API key; if email is not configured, outbound email actions are skipped rather than failing insecurely.
8. Backups, retention, and availability
- Database backups and recovery procedures are maintained as part of production operations.
- Process managers restart the application on failure; reverse proxies handle TLS and request routing.
- We aim for high availability but do not promise uninterrupted uptime. Scheduled maintenance or incidents may occur.
- Data retention follows the practices described in our Privacy Policy.
9. Monitoring and incident response
We monitor application health, failed jobs, and operational logs. If we become aware of a security incident affecting your personal information, we will investigate, take appropriate containment steps, and notify affected users and regulators as required by applicable law.
If you believe you have found a vulnerability in Prexo, please report it responsibly to [email protected]. Include enough detail for us to reproduce the issue. Please do not access other users' data or disrupt the Service while testing.
10. Shared responsibility
Security is a shared responsibility. You should:
- Use a strong, unique password and keep your credentials confidential.
- Sign out of shared devices and protect access to your Telegram account if connected.
- Only invite trusted people if team features are enabled in the future.
- Review AI suggestions before approving changes to client records.
- Ensure you have a lawful basis before storing third-party personal information in Prexo.
- Disconnect integrations you no longer use.
11. Compliance posture
Prexo is built with privacy and security controls intended to support compliance with applicable Canadian privacy laws (including PIPEDA) for a SaaS processor. Specific certifications (for example SOC 2) may be pursued as the business grows; their absence does not mean controls are absent, but we will not claim certifications we have not obtained.