Security at CommSync

Our approach to security

CommSync sits between you and every conversation your business has, so we treat the security of your messages, contacts, and credentials as foundational rather than a feature. We design for least privilege, encrypt what most needs encrypting, isolate each workspace, and lean on infrastructure providers with strong, independently audited security programs.

This page describes the safeguards we have in place today — including where a protection comes from our own code and where it comes from the platform underneath us. We would rather tell you which layer does what than wave a vague banner. Security is never “finished,” and no system can be guaranteed perfectly secure, but the measures below reflect how we actually build and operate the Service.

Encryption: what is encrypted, and by which layer

All traffic between your browser or client and CommSync is encrypted in transit with TLS, as are our connections to the database, queue, and storage backends. At rest, the picture has two layers, and we want to be precise about which one does what:

Platform encryption at rest

Application data lives in a managed database (Google Cloud SQL), which encrypts storage at rest. File attachments live in Google Cloud Storage with server-side encryption at rest.

Application-level encryption

The credentials you entrust to us — mailbox passwords, SMS provider secrets, integration tokens — get an additional layer of AES-256-GCM encryption in our own code before they touch the database. Details in the next section.

To be equally clear about what we do not do: CommSync is not end-to-end encrypted, and message bodies and attachment contents are not additionally encrypted by our application before storage. The Service has to read your messages to thread them, search them, and file them — that is the product. Their at-rest protection comes from the database and storage platform encryption above, plus the access controls described on this page. We would rather say that plainly than imply a guarantee we do not provide.

Credentials, passwords, and keys

The most sensitive data you give us is the set of credentials that unlock your other accounts. Those get dedicated, application-level protection on top of platform encryption:

• Connected-channel credentials. Mailbox passwords and the API secrets for your SMS providers — Twilio, JustCall, and Skyetel — are encrypted with authenticated AES-256-GCM before they are stored, using an encryption key held outside the database. Credentials for external tool integrations (MCP connections) are protected the same way and are never echoed back through the API.
• Passwords. Account passwords are hashed with bcrypt — we never store them in plaintext and cannot recover them.
• API keys. Programmatic API keys are shown once at creation and stored only as a one-way cryptographic hash, so the raw key cannot be read back from our systems. Keys can also be scoped to specific channels, so a key you hand to an integration can only read and send on the lines you chose.
• Outbound webhooks. Every webhook payload we send is cryptographically signed using a per-endpoint secret, so your receiving systems can verify each delivery genuinely came from CommSync.

Access control and workspace isolation

Every request is authenticated (session tokens via NextAuth, or a hashed API key) and authorized against the data it is allowed to touch. Workspaces are isolated from one another, and within a workspace access is governed by roles and explicit channel grants:

• Role-based access. Owners and admins have implicit access to the workspace’s channels; members see only the channels they have been explicitly granted. The Service checks these permissions on every protected action — including on the API-key path, where a key’s channel scope is intersected with what its owner can access, never widened.
• Workspace isolation. Threads, messages, and attachments belong to exactly one workspace. A connected phone number or mailbox address is globally unique across all of CommSync — a channel already claimed by one workspace cannot be connected to another, which closes off a whole class of cross-tenant mixups.
• Authorized realtime. Live updates are delivered over rooms named and validated per user and per thread — the server verifies your access before you can join a room, and nothing is broadcast on a shared channel.
• Least privilege internally. Access to production systems is limited to personnel who need it to operate the Service.

Support access you control

Our support staff cannot browse your workspace uninvited. When you want hands-on help, you mint a short-lived support-access code yourself in Settings — the same model as handing someone a one-time remote-desktop code:

• Only a one-way cryptographic hash of the code is stored — the code itself exists once, on your screen;
• You choose the access window, from 15 minutes up to 72 hours, and access ends when it expires;
• The code locks to the first person who redeems it, so it cannot be reused by anyone else;
• You can revoke it at any time — revocation immediately force-disconnects any live session using it, and every request made under a grant re-checks that the grant is still valid.

This is deliberately the inverse of the usual “admins can see everything” backdoor: support access is something you grant, watch, and take back.

AI features and your data

CommSync includes optional AI features — label classification, machine-mail filtering, the daily brief, thread titles, and the Ask assistant. When one runs, the relevant message content is sent to the Google Gemini API (or Vertex AI) for inference. How that is constrained:

• No training on your content. We use only the paid Gemini API tier and Vertex AI, whose data-use terms state that prompts and outputs are not used to train models. Your messages are not used to train models, ours or anyone else’s.
• Pinned models. Each feature runs against a specific, pinned model policy — not whatever endpoint is cheapest that day — so we know exactly where content goes.
• Off means off. AI features can be disabled per feature or entirely in Settings. With AI disabled, no message content is sent to any inference provider, and the rest of the product works exactly the same.
• Audited runs. Every AI run is logged with its token usage and outcome, and validated against a strict output schema before anything is applied to your inbox.
• Telemetry counts, it does not read. The observability we keep on AI records the model, latency, token counts, and cost of each run. Prompt and completion content is excluded before anything leaves the server — our analytics platform never receives it.

Application security

• Input validation. Requests are validated against strict schemas before they are processed.
• Safe rendering. Inbound email HTML is sanitized and rendered in an isolated context, which protects against cross-site scripting from message content.
• Separation of concerns. Our frontend never talks to the database directly; all data access flows through a controlled API tier with authentication and authorization.
• Verified inbound webhooks. Carrier callbacks are verified before they are trusted — Twilio requests, for example, are checked against their cryptographic request signature before a single byte is processed.
• Abuse protection. Sensitive endpoints — including AI features and the public contact form — are rate-limited.
• Dependency hygiene. We track and update third-party dependencies to address known vulnerabilities.
• Telemetry is redacted at the source. Application logs and error reports we ship off-box for reliability monitoring are stripped of message bodies, subjects, addresses, and search text before they leave our infrastructure. The redaction happens in our own code on the way out, not in the tool that receives them — so the content never reaches a system where it would have to be trusted to forget it.
• Analytics cannot see message content. Product analytics carry event names, route paths, and plan metadata — never message content, contact details, or search text. Session recording and heatmaps are restricted to our public marketing and sign-in pages by an explicit allowlist that fails closed: any route not named on that list, which is every authenticated surface in the app, is never recorded.

Infrastructure and subprocessors

We build on established cloud providers and handle data through a small set of vetted subprocessors. These providers maintain their own industry-standard compliance programs (such as SOC 2, ISO 27001, and PCI-DSS) for the layers they operate:

Database & storage

A managed database (Google Cloud SQL) and Google Cloud Storage; the Service itself runs on Google Cloud.

Payments

Stripe (PCI-DSS Level 1) — we do not store full card numbers.

SMS carriers

Twilio, JustCall, and Skyetel, for the numbers you connect.

System email

Twilio SendGrid, for password resets, invites, and notifications.

AI inference

Google (Gemini API / Vertex AI), only when AI features are enabled (see above).

Product analytics & telemetry

PostHog (United States) for usage analytics, error tracking, and redacted reliability logs. It does not receive message content, contact details, or search text.

Monitoring

Better Stack for uptime monitoring, which does not receive message content.

Our job queue (Redis) is self-hosted inside our own infrastructure — it is not a third-party service and queue data never leaves our servers. For the full picture of how data is shared, see our Privacy Policy.

Monitoring, availability, and backups

We monitor the health of the Service continuously. Application components expose health checks, background workers report heartbeats, and an independent, off-site monitor watches availability and alerts us to problems. You can see live status on our status page.

Our managed database platform maintains automated backups and point-in-time recovery, which we rely on for durability and disaster recovery.

Data retention and deletion

You control your data. Items you move to Trash are permanently deleted after 30 days by a scheduled sweep, orphaned attachment files are cleaned up automatically, and deleting your account removes your personal data and per-user content, subject to short operational backup windows and any retention required by law. More detail is in our Privacy Policy.

Reporting a vulnerability

We welcome reports from security researchers and treat them seriously. If you believe you have found a vulnerability, please email support@commsync.ai with details and steps to reproduce. We ask that you:

• Give us a reasonable opportunity to investigate and remediate before public disclosure;
• Avoid privacy violations, data destruction, or service degradation, and only interact with accounts you own or have permission to test;
• Do not run automated scanning that could disrupt the Service or other users.

Acting in good faith under these guidelines, we will not pursue action against you, and we’re glad to credit researchers who help us improve.

Your role in security

Security is shared. Please protect your account with a strong, unique password, keep your devices secure, scope and rotate API keys you create, grant support access only when you need it, and ensure your messaging practices comply with applicable law and carrier requirements (see our Terms of Service). Tell us right away at support@commsync.ai if you suspect any unauthorized access.