How Vortyx protects security, privacy, and trust

Because Vortyx may process operationally important, private, or commercially sensitive information, security and trust are not secondary features. They shape how Vortyx connects to external providers, stores data, limits access, handles AI-assisted workflows, and gives users control over what becomes tracked or acted on.

• Minimize what is stored.
• Separate credentials from user-visible work data.
• Encrypt sensitive data in transit and at rest.
• Require authenticated, workspace-scoped access to user data.
• Use least-privilege backend permissions.
• Keep AI suggestions review-first, not autonomous.
• Avoid using private content for advertising, resale, data brokerage, or generalized AI training.
• Provide disconnect and deletion paths for connected integrations.
• Maintain repeatable infrastructure deployment and recovery procedures.

Vortyx is designed to identify actionable work signals, not to replicate a user's entire mailbox, calendar, or message history.

For email-based workflows, Vortyx processes provider data only after the user connects the relevant account and enables the related feature. The system is designed to avoid durable storage of raw email mailbox archives. Instead, it stores minimized derived artifacts needed to power user-facing workflows.

• Review items.
• Thread and message references.
• Bounded excerpts or snippets.
• Participants and source context.
• Extracted follow-ups, waiting items, commitments, and draft action records.
• User-visible task, loop, or action state created from review workflows.

Vortyx may need enough context to show why a follow-up or waiting item was suggested, but it does not need to keep a full raw mailbox copy to do that. The product posture is to preserve enough source evidence for user review while limiting unnecessary durable storage.

Vortyx connects to external providers only through explicit user action and provider authorization flows. Examples include Google sign-in and OAuth connection flows, Gmail and Google Calendar features enabled by the user, Microsoft Outlook and calendar connection flows where configured, Slack install or command-driven flows, and Apple or Google app-store subscription flows.

For Google Workspace data, Vortyx uses Google data only for user-facing Vortyx functionality requested or enabled by the user. Gmail read access supports actionable-work detection, follow-ups, waiting states, commitments, unresolved work, and review items. Gmail send access is used only for user-approved sending actions.

Vortyx does not use Gmail content for advertising, retargeting, personalized ads, contact scraping, bulk email generation, resale, data brokerage, or generalized model training.

When an integration is disconnected, Vortyx is designed to stop future synchronization, delete locally stored access credentials where technically supported, and prevent future background processing for that connection. Previously generated user-visible artifacts may remain until the user or workspace deletes them because those objects are part of the user's Vortyx workspace history.

OAuth credentials are among the highest-risk data categories in Vortyx because they grant access to connected provider APIs.

Vortyx treats provider credentials separately from normal product records. The security model separates connected account metadata, OAuth credentials, and user-visible work artifacts such as review items, tasks, loops, reminders, and action drafts.

Backend access to credentials is restricted to the services that need it for provider refresh, sync, disconnect, or user-approved actions. Secrets such as OAuth client secrets are stored in managed secret storage, encrypted at rest, and accessed through backend infrastructure permissions rather than being embedded in the mobile or web client.

The app clients do not receive provider client secrets.

Vortyx uses encrypted network transport for app-to-backend and backend-to-provider communication. Mobile and web clients communicate with backend APIs over HTTPS, backend services communicate with cloud services and connected providers over TLS-protected APIs, and OAuth redirects and token exchanges are handled through provider-supported secure flows.

Sensitive Vortyx data is stored in managed cloud services that provide encryption at rest. User, workspace, connection metadata, review, task, loop, action, and calendar-reference records are stored in encrypted managed database storage. Provider credentials and backend service secrets are stored using managed secret storage with envelope encryption. Object storage used for product artifacts is configured with server-side encryption where applicable.

The important public posture is that Vortyx stores sensitive application data in encrypted managed infrastructure.

Vortyx is workspace-aware. Authentication alone is not enough. A signed-in user must also be authorized for the workspace and resource they are trying to access.

The backend security model resolves the authenticated user, determines the selected workspace, checks workspace membership and role where required, and applies resource-level checks before returning or mutating workspace-scoped data.

• Sign-in identifies the user.
• Workspace authorization determines what that user can access.
• Resource-level checks protect individual records within that workspace context.

This matters because Vortyx supports personal and shared workspace concepts. Personal connected-service content, such as private email-derived review items, should not automatically become visible to a shared workspace.

Vortyx backend services are designed around scoped permissions. Rather than giving every backend service broad access to every data store, infrastructure permissions are scoped to the resources each function needs.

• A review-listing endpoint should not need the same privileges as a provider-token refresh path.
• A disconnect flow needs credential deletion capability, but unrelated read-only surfaces should not.
• Background sync workers need provider access for enabled connections, while user-facing APIs should remain workspace-scoped.

Least privilege is not a one-time task. It requires recurring access review as new integrations, actions, and background workers are added.

Vortyx uses AI to identify and explain possible work signals, including follow-ups, commitments, waiting items, next steps, recurring responsibilities, draft replies, draft follow-ups, and scheduling or resurfacing suggestions.

The trust boundary is that AI suggestions are not treated as final external actions. Users review what matters before it becomes tracked or sent. Suggested items can be edited, dismissed, snoozed, confirmed, or marked handled. Draft replies and follow-ups are user-editable. Email sending is not automatic; it requires user approval.

Review-first AI is both a product principle and a security principle. It keeps external action authority with the user.

• Private workspace content is not used for advertising.
• Google Workspace data is not used for advertising or generalized model training.
• Connected-service data is not sold to data brokers.
• Gmail data is not used for contact scraping, bulk email generation, unrelated analytics, marketing profiling, or resale.
• Slack data is not used for broad workspace surveillance, advertising, resale, or unrelated analytics.

Vortyx uses connected-service data to provide the features the user enables: review, capture, continuity tracking, scheduling, draft assistance, reminders, and workspace organization.

Operational logging is necessary for reliability and security, but logs can become a data-risk surface if they contain private content. Vortyx's security posture is to keep logs focused on operational metadata rather than private payloads.

Examples of safer log fields include request IDs, provider names, workspace or connection identifiers, event types, counts and status outcomes, error categories, timing, and retry state.

Logs should not contain OAuth access tokens, OAuth refresh tokens, provider client secrets, authorization headers, full email bodies, raw voice transcripts, full AI prompts or responses, or private provider payloads.

Security also includes recoverability. Vortyx backend infrastructure is managed as code and deployed through repeatable infrastructure and packaging workflows.

This supports two security goals: the system can be redeployed from controlled source and infrastructure definitions, and operational data stores can be recovered from infrastructure-supported recovery mechanisms when enabled.

Recovery controls must be balanced with deletion and privacy expectations. Backups and point-in-time recovery can retain deleted data for limited recovery windows.

Vortyx has a regional routing and workspace-home-region architecture foundation. The backend can resolve a user's workspace and route requests to the appropriate regional stack based on workspace context.

• Workspace data can be associated with a home region.
• Requests can be routed through a regional backend path.
• Global routing can remain separate from regional workspace data storage.

This creates the foundation for region-aware data residency controls as the product and customer commitments mature.

Vortyx supports account deletion and connected integration disconnect behavior as part of the trust model.

For integration disconnect, the intended behavior is to stop future synchronization and background analysis, delete locally stored OAuth credentials, revoke provider tokens where technically supported, and keep previously generated user-visible artifacts until separately deleted by the user or workspace where applicable.

For account deletion, the operational model includes identity verification, disconnecting owned integrations, deleting locally stored OAuth credentials, disabling future sync and background processing, and removing or tombstoning account and notification records where supported.

Some records may be preserved where needed for security, fraud prevention, billing, legal compliance, dispute resolution, backup recovery, or system integrity.

• Vortyx asks for connected-service access only for enabled features.
• Connected-service data is used for user-facing Vortyx functionality, not advertising.
• AI-generated suggestions remain reviewable.
• Email sending requires user approval.
• Personal connected-service review content stays private unless the user promotes or shares it into workspace-scoped objects.
• Sensitive data is encrypted in transit and at rest through managed infrastructure.
• Provider credentials are stored separately from normal review and task data.
• Disconnect paths are available for integrations.
• Account deletion and privacy request handling are supported.
• Private content, OAuth tokens, secrets, and full provider payloads should not be logged.

Users should not assume Vortyx is a zero-data-storage product, that every deletion request instantly removes all data from backups or recovery windows, or that AI suggestions are guaranteed to be perfect.

The honest trust posture is stronger than a vague promise. Vortyx stores the data needed to provide continuity workflows, minimizes and scopes that data where practical, protects it with managed security controls, and keeps user judgment in the loop before external actions occur.

Vortyx is built for work that users cannot afford to lose: follow-ups, commitments, waiting items, next steps, recurring responsibilities, and reviewable actions drawn from email, messages, voice, text, and calendars.

That requires a security model built around data minimization, encryption, scoped authorization, credential separation, review-first AI, provider disconnect controls, safe logging, and repeatable infrastructure operations.

The practical trust promise is this: Vortyx helps keep important work visible and moving while preserving user control over connected data, generated suggestions, and external actions.