Legal
Privacy Policy
Controller: Launch AI Solutions LLC (“LaunchAI,” “we,” “us,” or “our”)
Service: LaunchAI, accessible at https://launchai.work, including related subdomains such as https://portal.launchai.work/ (collectively, the “Service”).
Privacy Contact: privacy@launchai.work
Operational Support Contact: support@launchai.work
LaunchAI is a task-automation platform. You use it to set up AI Agents and automated workflows that carry out tasks in the software systems, websites, and accounts you choose to automate. To let those Agents sign in and act, you store credentials for those systems in the LaunchAI credentials vault, and LaunchAI makes them available to your Agents when they run.
This Privacy Policy is a binding statement of how LaunchAI collects, uses, stores, discloses, and deletes personal data in connection with the Service. By creating an account, connecting a third-party integration, or otherwise using the Service, you agree to this Policy. If you do not agree, do not use the Service. Our Terms of Service further describe how automation and Agents work.
1. Scope and Applicability
1.1 This Policy applies to personal data processed by LaunchAI when you or your organization use the Service for task automation, including account authentication, company tenancy, the credentials vault and OAuth connections that your Agents use to access systems you choose to automate (including Google Workspace and Microsoft 365 / Outlook / OneDrive / SharePoint products), support tickets, workflows, rules tables, search indexing, desktop device enrollment, and related operational features.
1.2 This Policy includes:
- Google API Services User Data disclosures in Section 4 (controlling as to Google user data); and
- Microsoft identity platform / Microsoft Graph User Data disclosures in Section 5 (controlling as to Microsoft user data).
1.3 This Policy does not govern Google’s or Microsoft’s own processing of your data. Those providers’ processing is governed by their respective terms and privacy policies.
2. Categories of Personal Data We Process
2.1 Account and Authentication Data
| Data | Source | Purpose |
|---|---|---|
| Email address | User signup / invite | Account identity, authentication, company membership |
| Display name | User signup | Profile display within the Service |
| Firebase Authentication identifier | Firebase Auth | Password authentication, session verification, account disable/enable |
| Password | User (stored by Firebase Auth, not by LaunchAI application databases as plaintext) | Authentication |
| Company membership, roles, invites | Service | Multi-tenant access control |
| Active company selection | Service | Authorization scope for API requests |
Authentication is implemented via Firebase Authentication. LaunchAI stores corresponding user records (email, name, Firebase ID, activity status) in its application MongoDB database.
2.2 Credentials Vault Data (Non–Third-Party OAuth Content)
The credentials vault is central to LaunchAI’s automation purpose. You store credentials for the systems you want to automate so that your Agents can sign in to and act in those systems when they run. LaunchAI encrypts stored credentials at rest and supplies them only to Agents belonging to your company, and only to the extent those Agents are configured to use them.
For credentials of type login, note, and application, LaunchAI may store:
- Credential metadata (name, username, URL, type, owner, company ID, status, provider key, product keys)
- Encrypted secret fields (passwords, notes, TOTP seeds, security questions) using AES-GCM with per-company key derivation
- For OAuth application credentials: encrypted access/refresh tokens and plaintext connected-account profile fields (see Sections 4 and 5)
- Credential audit log entries (actor, action, IP address, user agent, timestamps, limited metadata)
2.3 Support, Workflow, Rules, Search, and Desktop Data
Depending on features your organization enables, LaunchAI may process:
- Support ticket metadata, message bodies (plaintext in customer MongoDB), attachment metadata, and attachment bytes in Google Cloud Storage
- Support ticket login credentials (encrypted at rest)
- Workflow definitions, versions, comments, AI copilot conversation messages, and workflow attachment objects in GCS
- Rules table metadata and cell/file data (files in GCS)
- Search index documents and embedding vectors derived from indexed content
- Desktop device registration, enrollment, delivery receipts, and related control-plane records (subject to TTL purge defaults)
- Operational logs and Cloud Run structured logs for reliability and debugging
2.4 Technical and Security Data
- IP address and user agent on credential audit events
- OAuth CSRF/PKCE state records and HttpOnly binding cookie during OAuth connect flows (TTL default: 600 seconds)
- reCAPTCHA Enterprise assessment signals on signup (where enabled)
- Rate-limit and presence keys in Redis
3. How We Use Personal Data (General Uses)
LaunchAI uses the data in Section 2 to:
- Provide, operate, secure, and maintain the Service as a task-automation platform
- Authenticate users and enforce company-scoped permissions
- Store credentials you submit for systems you choose to automate, and resolve (decrypt or refresh) those credentials so your Agents can access those systems and carry out automated tasks
- Operate support ticketing, retention/archive/purge, email delivery (SendGrid), and Attachment AI / summarization features
- Operate workflow and Agent design, workflow AI copilot, rules, and search
- Enroll and communicate with Desktop clients
- Detect abuse, enforce rate limits, and investigate security incidents
- Comply with law and respond to lawful requests
LaunchAI does not operate third-party advertising pixels, PostHog, Google Analytics, Mixpanel, Sentry browser SDKs, or similar product-analytics trackers in the portal application code.
4. Google User Data — Access, Use, Storage, Sharing, and Flow
(Google API Services / OAuth Limited Use Disclosures)
This Section describes exactly how LaunchAI handles data obtained through Google OAuth and Google APIs. Google connections are stored in the credentials vault so your Agents can sign in to and automate the Google products you explicitly connect.
4.1 Google OAuth Products and Scopes Requested
When a user connects one or more Google products in the credentials vault (so Agents can automate those products), LaunchAI requests the union of scopes for the selected product keys. Every Google product connection also includes the base OpenID scopes.
| Product key | Display name | Scopes requested |
|---|---|---|
| (base for all Google products) | — | openid, email, profile |
google_drive | Google Drive | Base + https://www.googleapis.com/auth/drive.file |
google_gmail | Gmail | Base + https://www.googleapis.com/auth/gmail.modify |
google_sheets | Google Sheets | Base + https://www.googleapis.com/auth/spreadsheets |
google_calendar | Google Calendar | Base + https://www.googleapis.com/auth/calendar |
google_contacts | Google Contacts | Base + https://www.googleapis.com/auth/contacts |
google_docs | Google Docs | Base + https://www.googleapis.com/auth/documents |
google_slides | Google Slides | Base + https://www.googleapis.com/auth/presentations |
OAuth parameters used by LaunchAI’s Google adapter:
- Authorization endpoint:
https://accounts.google.com/o/oauth2/v2/auth - Token endpoint:
https://oauth2.googleapis.com/token - Userinfo endpoint:
https://openidconnect.googleapis.com/v1/userinfo - Revocation endpoint:
https://oauth2.googleapis.com/revoke - PKCE:
S256 access_type=offlineprompt=consent
Google may return userinfo.email / userinfo.profile scope URLs; LaunchAI normalizes these to email / profile. Presence of a refresh token is recorded internally as synthetic offline_access for scope-coverage checks; that synthetic value is not requested as a Google scope string.
4.2 Exactly What Google User Data Is Accessed
A. Data LaunchAI currently reads from Google (implemented API calls):
| Google API call | Fields accessed | Stored by LaunchAI? |
|---|---|---|
| OAuth authorization code exchange | access_token, refresh_token, expires_in, scope, token_type, optional id_token | Access token, refresh token, and token metadata (scope, token_type) stored encrypted. id_token is parsed in memory and not persisted. |
| OpenID userinfo | email, name only | Stored as plaintext credential fields connected_account_email, connected_account_name |
| Token refresh | New access token (and refresh token if rotated) | Encrypted update of stored tokens |
| Token revoke | Token identifier submitted for revocation | Tokens purged from LaunchAI after disconnect |
B. Google Workspace content APIs (Gmail messages, Drive file contents, Calendar events, Sheets cells, Contacts records, Docs/Slides documents):
As of the Last Updated date, LaunchAI application code does not call Gmail, Drive, Calendar, Sheets, Contacts, Docs, or Slides content APIs. Product scopes are requested and stored so that an authorized connection can later obtain a fresh access_token through LaunchAI’s internal credential resolve interface when your Agents (or authorized LaunchAI service components) need to automate product-scoped operations. Until such an operation is invoked, LaunchAI does not ingest, index, cache, or store Gmail message bodies, Drive file bytes, Calendar event payloads, or other Workspace content obtained via those APIs.
C. Definition — “Google user data”:
(i) OAuth tokens and granted scopes obtained via Google OAuth; (ii) the connected Google account email and name from userinfo; and (iii) any Workspace content subsequently retrieved using those tokens through Google APIs when product features invoke them.
4.3 Complete Technical Flow (Google OAuth)
-
Select Google product(s)
Authorized user selects Google product(s) in the LaunchAI credentials UI.
-
Create OAuth connection state
Backend creates OAuthConnectionState with PKCE verifier, state, scopes, and binding hash.
- State TTL: default 600 seconds (Mongo TTL + cleanup worker)
-
Set binding cookie
Backend sets an HttpOnly credentials_oauth_bind cookie.
-
Redirect to Google
Browser redirects to the Google authorization URL with the requested scopes.
-
Google callback
Google redirects to the LaunchAI callback.
-
Verify & exchange code
Backend verifies state + binding cookie, then exchanges the code at oauth2.googleapis.com/token.
-
Store profile & encrypt tokens
Backend calls userinfo; stores email/name on Credential; encrypts tokens into CredentialSecretPayload.
-
Keep tokens fresh
Scheduled/on-demand refresh keeps access tokens fresh.
- Google refresh-token keepalive default: 150 days
-
Resolve access token for Agents
When your Agents (or authorized internal components) need access, they may request a decrypted access_token for a connected credential to automate tasks in the connected Google products.
-
Disconnect & revoke
On disconnect: revoke at Google, purge ciphertext, clear email/name/scopes, and set connection_status=disconnected / status=revoked.
4.4 Is Google User Data Stored on LaunchAI Servers?
Yes, as follows:
| Data element | Storage location | Encryption at rest |
|---|---|---|
access_token | MongoDB collection credential_secret_payloads | AES-GCM; HKDF-derived per-company key; AAD bound to company_id:credential_id:field |
refresh_token | Same | AES-GCM (same scheme) |
Token metadata (scope, token_type) | Same | AES-GCM |
connected_account_email | MongoDB credentials | Not field-encrypted (plaintext document field) |
connected_account_name | MongoDB credentials | Not field-encrypted |
granted_scopes, product keys, expiry / refresh timestamps, connection status | MongoDB credentials | Not field-encrypted |
| In-flight OAuth state / PKCE verifier | MongoDB oauth_connection_states | Short-lived; TTL-deleted |
| Credential OAuth connect/disconnect audit events | MongoDB credential_audit_log | Retained per audit policy |
4.5 Data Retention — Google-Related Records
| Record | Default retention | Deletion method |
|---|---|---|
| OAuth connection state / PKCE | 600 seconds TTL | Automatic TTL delete + cleanup worker (stale states purged after 24 hours retention window for cleanup) |
| OAuth binding cookie | Max-age = OAuth state TTL (600 seconds) | Cookie expiry / clear on completion |
| Live OAuth tokens while connected | Retained while connection remains connected (refresh keepalive default 150 days for Google) | Overwritten on refresh; purged on disconnect |
| Tokens + profile fields after disconnect | Immediately purged/cleared on disconnect | Hard clear of ciphertext fields; email/name/scopes null/empty |
| Soft-deleted credential documents | 30 days | Hard delete of credential, secret payload, OAuth states, refresh states |
| Credential audit logs | 730 days | Hard delete of expired audit documents |
4.6 How LaunchAI Uses Google User Data
LaunchAI uses Google user data solely to:
- Authenticate the user’s Google account connection to the credentials vault
- Identify the connected Google account (email/name) in the LaunchAI UI and credential records
- Maintain and refresh OAuth tokens so authorized LaunchAI components and your Agents can call Google APIs for the products the user explicitly connected, in order to automate tasks in those systems
- Enforce scope sufficiency checks before resolving an
access_tokenfor a requested product key when an Agent or authorized internal component needs access - Revoke tokens and disconnect integrations at the user’s or administrator’s direction
- Record security/audit events related to connect, refresh, resolve, and disconnect operations
4.7 Strict Prohibitions — Sale, Ads, and AI Training (Google User Data)
4.7.1 No sale or advertising use.
LaunchAI does not sell, rent, lease, or trade Google user data to any third party, data broker, or advertising platform. LaunchAI does not use Google user data for serving advertisements, ad targeting, or ad personalization.
4.7.2 No AI/ML training on Google user data.
Data obtained through Google Workspace APIs and Google OAuth (including tokens, userinfo email/name, granted scopes, and any Workspace content retrieved using those tokens) is never used to train, retrain, fine-tune, or otherwise improve generalized Artificial Intelligence or Machine Learning models operated by LaunchAI or by any third party on LaunchAI’s behalf.
4.7.3 Limited Use.
LaunchAI’s use of Google user data complies with the Google API Services User Data Policy, including the Limited Use requirements, for the scopes requested.
4.8 Sharing of Google User Data with Sub-Processors
Google user data may be processed by the infrastructure sub-processors listed in Section 6 solely to host, secure, transmit, or operate the Service. LaunchAI does not share Google user data with OpenAI, SendGrid, or advertising platforms for marketing or model training.
Human access to Google user data by LaunchAI personnel is limited to security, abuse investigation, legal compliance, and technical support cases where access is necessary to operate or restore the Service, and is subject to internal access controls.
5. Microsoft User Data — Access, Use, Storage, Sharing, and Flow
(Microsoft identity platform / Microsoft Graph Disclosures)
This Section describes exactly how LaunchAI handles data obtained through Microsoft OAuth (Entra ID / Azure AD) and Microsoft Graph for Outlook, OneDrive, and SharePoint product connections. Microsoft connections are stored in the credentials vault so your Agents can sign in to and automate the Microsoft products you explicitly connect.
5.1 Microsoft OAuth Products and Scopes Requested
When a user connects one or more Microsoft products in the credentials vault (so Agents can automate those products), LaunchAI requests the union of scopes for the selected product keys. Every Microsoft product connection includes the base Microsoft scopes.
| Product key | Display name | Scopes requested |
|---|---|---|
| (base for all Microsoft products) | — | openid, profile, offline_access, User.Read |
microsoft_outlook | Outlook | Base + Mail.ReadWrite, Calendars.ReadWrite |
microsoft_onedrive | OneDrive | Base + Files.ReadWrite.All, Sites.Read.All |
microsoft_sharepoint | SharePoint | Base + Files.ReadWrite.All, Sites.Read.All |
Admin consent (organization-level): For the Microsoft provider catalog, LaunchAI may expose an admin-consent URL built as:
https://login.microsoftonline.com/organizations/v2.0/adminconsent
with client_id, redirect_uri, and the union of all Microsoft v1 product scopes (openid, profile, offline_access, User.Read, Mail.ReadWrite, Calendars.ReadWrite, Files.ReadWrite.All, Sites.Read.All). Admin consent is used so a Microsoft 365 tenant administrator can grant organizational permissions required for those products.
OAuth parameters used by LaunchAI’s Microsoft adapter:
- Authorization endpoint:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
({tenant}defaults tocommonviacredentials_microsoft_tenant_id) - Token endpoint:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token - Profile endpoint:
https://graph.microsoft.com/v1.0/me(Microsoft Graph, not OIDC userinfo) - Revocation endpoint:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/revoke - PKCE:
S256 response_mode=queryprompt=select_account- Callback route:
/api/v1/oauth/microsoft/callback(also accepts the shared credentials OAuth callback)
5.2 Exactly What Microsoft User Data Is Accessed
A. Data LaunchAI currently reads from Microsoft (implemented API calls):
| Microsoft API call | Fields accessed | Stored by LaunchAI? |
|---|---|---|
| OAuth authorization code exchange | access_token, refresh_token, expires_in, scope, token_type, optional id_token | Access token, refresh token, and token metadata (scope, token_type) stored encrypted. id_token is used in memory to extract tenant claim tid and is not persisted. |
Microsoft Graph GET /v1.0/me | mail or userPrincipalName (as email); displayName (as name) | Stored as plaintext connected_account_email, connected_account_name |
id_token claim tid | Microsoft Entra tenant ID | Stored as plaintext connected_tenant_id |
| Token refresh | New access token (and refresh token if rotated) | Encrypted update of stored tokens |
| Token revoke | Token + client_id / client_secret / token_type_hint | Tokens purged from LaunchAI after disconnect |
B. Microsoft Graph content APIs (Outlook mail/calendar, OneDrive files, SharePoint sites/files):
As of the Last Updated date, LaunchAI application code does not call Microsoft Graph Mail, Calendar, Drive, OneDrive, or SharePoint content endpoints beyond GET /v1.0/me. Product scopes are requested and stored so that an authorized connection can later obtain a fresh access_token through LaunchAI’s internal credential resolve interface when your Agents (or authorized LaunchAI service components) need to automate product-scoped operations. Until such an operation is invoked, LaunchAI does not ingest, index, cache, or store Outlook message bodies, calendar event payloads, OneDrive/SharePoint file bytes, or other Graph content obtained via those APIs.
C. Definition — “Microsoft user data”:
(i) OAuth tokens and granted scopes obtained via the Microsoft identity platform; (ii) connected account email, display name, and tenant ID from Graph /me and id_token; and (iii) any Microsoft 365 / Graph content subsequently retrieved using those tokens when product features invoke them.
5.3 Complete Technical Flow (Microsoft OAuth)
-
Select Microsoft product(s)
Authorized user selects Microsoft product(s) (Outlook, OneDrive, and/or SharePoint).
- Optional: Microsoft 365 admin completes admin-consent URL for organizational scopes
-
Create OAuth connection state
Backend creates OAuthConnectionState with PKCE verifier, state, scopes, and binding hash.
- State TTL: default 600 seconds
-
Set binding cookie
Backend sets an HttpOnly credentials_oauth_bind cookie.
-
Redirect to Microsoft
Browser redirects to login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize.
-
Microsoft callback
Microsoft redirects to the LaunchAI Microsoft callback with an authorization code.
-
Verify & exchange code
Backend verifies state + binding cookie, then exchanges the code at the Microsoft token endpoint.
-
Read profile & tenant
Backend calls Graph GET /v1.0/me and extracts tenant tid from id_token.
-
Validate tenant
Microsoft connection requires a tenant_id.
- On reconnect, a different tid than the stored connected_tenant_id is rejected (tenant_mismatch)
-
Store profile & encrypt tokens
Backend stores email/name/tenant_id on Credential and encrypts tokens into CredentialSecretPayload.
-
Keep tokens fresh
Scheduled/on-demand refresh keeps access tokens fresh.
- Microsoft refresh-token keepalive default: 60 days
-
Resolve access token for Agents
When your Agents (or authorized internal components) need access, they may request a decrypted access_token for a connected credential to automate tasks in the connected Microsoft products.
- Optional product_key scope-coverage check
-
Disconnect & revoke
On disconnect: revoke at Microsoft, purge ciphertext, clear email/name/tenant/scopes, and set disconnected/revoked.
5.4 Is Microsoft User Data Stored on LaunchAI Servers?
Yes, as follows:
| Data element | Storage location | Encryption at rest |
|---|---|---|
access_token | MongoDB credential_secret_payloads | AES-GCM (same scheme as Google tokens) |
refresh_token | Same | AES-GCM |
Token metadata (scope, token_type) | Same | AES-GCM |
connected_account_email | MongoDB credentials | Not field-encrypted |
connected_account_name | MongoDB credentials | Not field-encrypted |
connected_tenant_id | MongoDB credentials | Not field-encrypted |
granted_scopes, product keys, expiry / refresh timestamps, connection status | MongoDB credentials | Not field-encrypted |
| In-flight OAuth state / PKCE verifier | MongoDB oauth_connection_states | Short-lived; TTL-deleted |
| Credential OAuth audit events | MongoDB credential_audit_log | Retained per audit policy |
5.5 Data Retention — Microsoft-Related Records
| Record | Default retention | Deletion method |
|---|---|---|
| OAuth connection state / PKCE | 600 seconds TTL | Automatic TTL delete + cleanup worker |
| OAuth binding cookie | Max-age 600 seconds | Cookie expiry / clear on completion |
| Live OAuth tokens while connected | Retained while connected (Microsoft refresh keepalive default 60 days) | Overwritten on refresh; purged on disconnect |
| Tokens + profile fields after disconnect | Immediately purged/cleared | Hard clear of ciphertext; email/name/tenant/scopes cleared |
| Soft-deleted credential documents | 30 days | Hard delete of credential and related secret/OAuth state documents |
| Credential audit logs | 730 days | Hard delete of expired audit documents |
5.6 How LaunchAI Uses Microsoft User Data
LaunchAI uses Microsoft user data solely to:
- Authenticate the user’s Microsoft account connection to the credentials vault
- Identify the connected Microsoft account (email/display name) and Entra tenant (
connected_tenant_id) - Enforce tenant consistency on reconnect and when refreshing sibling credentials in a connection group
- Maintain and refresh OAuth tokens so authorized LaunchAI components and your Agents can call Microsoft Graph for the products the user explicitly connected (Outlook, OneDrive, SharePoint), in order to automate tasks in those systems
- Enforce scope sufficiency checks before resolving an
access_tokenfor a requested product key when an Agent or authorized internal component needs access - Support organization admin consent for Microsoft product scopes
- Revoke tokens and disconnect integrations at the user’s or administrator’s direction
- Record security/audit events related to connect, refresh, resolve, and disconnect operations
5.7 Strict Prohibitions — Sale, Ads, and AI Training (Microsoft User Data)
5.7.1 No sale or advertising use.
LaunchAI does not sell, rent, lease, or trade Microsoft user data to any third party, data broker, or advertising platform. LaunchAI does not use Microsoft user data for serving advertisements, ad targeting, or ad personalization.
5.7.2 No AI/ML training on Microsoft user data.
Data obtained through the Microsoft identity platform and Microsoft Graph (including tokens, /me profile fields, tenant ID, granted scopes, and any Outlook/OneDrive/SharePoint content retrieved using those tokens) is never used to train, retrain, fine-tune, or otherwise improve generalized Artificial Intelligence or Machine Learning models operated by LaunchAI or by any third party on LaunchAI’s behalf.
Clarification regarding OpenAI: LaunchAI uses OpenAI for Support summarization, Attachment AI chat/embeddings, speech transcription, global search embeddings, and Workflow AI copilot. Those pipelines operate on LaunchAI-hosted support/workflow/search content supplied by users of the Service. They are not fed Outlook mail/calendar bodies, OneDrive files, or SharePoint content retrieved via Microsoft Graph APIs. Microsoft user data from Microsoft OAuth/Graph connections is excluded from model-training and from any “improve our models” use.
5.7.3 Permitted use limitation.
Microsoft user data is used only to provide or improve user-facing features of the Service that depend on the Microsoft products the user (or tenant administrator) authorized, and for security, abuse prevention, and legal compliance related to those features.
5.8 Sharing of Microsoft User Data with Sub-Processors
Microsoft user data may be processed by the infrastructure sub-processors listed in Section 6 solely to host, secure, transmit, or operate the Service (e.g., encrypted token storage in MongoDB Atlas; application runtime on Google Cloud Run).
LaunchAI does not share Microsoft user data with OpenAI, SendGrid, or advertising platforms for marketing or model training. SendGrid is used for LaunchAI support/transactional email delivery of LaunchAI-generated messages, not for exporting Outlook mailbox contents.
Human access to Microsoft user data by LaunchAI personnel is limited to security, abuse investigation, legal compliance, and technical support cases where access is necessary to operate or restore the Service, and is subject to internal access controls.
5.9 Microsoft-Specific Differences from Google (Summary)
| Topic | Microsoft | |
|---|---|---|
| Profile API | OpenID userinfo (email, name) | Graph /me (mail/userPrincipalName, displayName) + tid |
| Tenant ID stored | No | Yes (connected_tenant_id); required; reconnect mismatch rejected |
| Offline access | access_type=offline | Scope offline_access |
| Auth prompt | consent | select_account |
| Admin consent URL | None | Yes (organizations/v2.0/adminconsent) |
| Refresh keepalive default | 150 days | 60 days |
| Revoke request | Token only | Token + client credentials + token_type_hint |
6. Sub-Processors and Third Parties (Infrastructure)
LaunchAI uses the following sub-processors / service providers. Regions reflect production defaults in LaunchAI infrastructure configuration (primary GCP region: us-central1).
| Sub-processor | Role | Data involved |
|---|---|---|
| Google Cloud Platform (Cloud Run, Cloud Storage, Secret Manager, Memorystore Redis, Cloud Tasks/Workflows, monitoring) | Application hosting, file object storage, secrets, queues, jobs | Application data, attachments, logs, encrypted secrets material as configured |
| Firebase Authentication / Firebase Hosting | User authentication; portal hosting | Account email/name, auth tokens, hosting assets |
| MongoDB Atlas | Primary application and per-company customer databases | Credentials (including encrypted Google and Microsoft tokens), support data, workflows, users, audit logs |
| OpenAI | LLM, embeddings, Whisper transcription for Support / Search / Workflow AI | LaunchAI support/workflow/search text and speech audio — not Google Workspace or Microsoft Graph mailbox/Drive/SharePoint contents retrieved via those APIs |
| SendGrid | Outbound transactional / support email delivery | Email recipient addresses and message content generated by LaunchAI support email features |
| Google reCAPTCHA Enterprise | Bot protection on signup | Client signals / tokens for assessment |
| Google OAuth / Google API endpoints | Authorization, token issuance/refresh/revoke, userinfo | OAuth codes, tokens, userinfo email/name |
| Microsoft identity platform (login.microsoftonline.com) / Microsoft Graph | Authorization, token issuance/refresh/revoke, profile (/me); admin consent | OAuth codes, tokens, Graph profile fields, tenant ID |
LaunchAI does not use AWS, Cloudflare, or Supabase as hosting sub-processors for the Service as implemented.
7. OpenAI and Other Non-Google / Non-Microsoft AI Processing
7.1 Provider: OpenAI only (no Anthropic, Gemini, or Azure OpenAI client in application code).
7.2 Data categories that may be sent to OpenAI:
- Support ticket subjects, descriptions, and message/chunk text for summaries and embeddings
- Support attachment extracted text and Attachment AI chat turns
- Speech/dictation audio for Whisper transcription
- Workflow AI copilot prompts including workflow graph/context JSON
7.3 Workflow AI response storage: LaunchAI may set OpenAI Responses API store according to configuration (workflow_ai_store_responses, default enabled) for conversation continuity. This is not LaunchAI model training and is not applied to Google Workspace or Microsoft Graph content retrieved via those APIs.
7.4 LaunchAI does not implement fine-tuning or dataset-upload training jobs against customer data in application code.
8. Cookies and Similar Technologies
| Name / type | Purpose | Duration |
|---|---|---|
credentials_oauth_bind | Binds OAuth callback to the initiating browser session (CSRF/session binding) for Google and Microsoft connect flows; HttpOnly; Secure in staging/production; SameSite=Lax | Default max-age 600 seconds |
| Designer step-up session (first-party) | Elevated authentication for sensitive credential-designer operations | Session / product-defined |
| Firebase Auth session artifacts | Maintain authenticated portal session | Per Firebase Auth configuration |
LaunchAI does not set third-party advertising cookies.
9. Data Retention (Non–OAuth Defaults)
| Data class | Default retention |
|---|---|
| Soft-deleted credentials | Hard-purged after 30 days |
| Credential audit logs | 730 days |
| Support tickets | Archive-eligible 30 days after closed; operational purge 365 days after archive (GCS cold archives retained unless separately destroyed; GCS delete-on-operational-purge default off) |
| Support / workflow email webhook events | Approximately 30 days (Mongo TTL) |
| Desktop deliveries / receipts | Default 30 days (Mongo TTL on purge_at) |
| Workflow orphan attachments | Deleted from GCS after configured grace period |
| Legal holds | Block support operational purge while active |
Retention windows are configuration defaults and may be adjusted for a deployment; material changes affecting Google or Microsoft user data retention will be reflected in an updated Policy.
10. Security Measures (Technically Concrete)
LaunchAI implements the following controls relevant to personal data, including Google and Microsoft user data:
- AES-GCM encryption for OAuth access/refresh tokens and other credential secrets, with HKDF per-company keys and per-field AAD
- PKCE S256 on Google and Microsoft OAuth authorization
- OAuth state + HttpOnly binding cookie verification on callback
- Microsoft tenant ID requirement and reconnect tenant mismatch rejection
- Company-scoped authorization checks before connect, disconnect, reveal, and resolve
- Rate limits on OAuth disconnect and credential resolve
- Token revoke at Google or Microsoft on disconnect when no live sibling credential remains in the connection group
- Separation of application DB and per-company customer DBs for tenant data
- TLS for Service endpoints in production
- Cloud provider secret management for runtime secrets
No security program eliminates all risk. Unauthorized access, hardware failure, or misconfiguration may still occur.
11. User Rights, Revocation, and Controls
11.1 Disconnect Google or Microsoft / Revoke Access (in-product)
You (with appropriate company permission credentials.oauth.connect) may:
- Disconnect a Google or Microsoft application credential via the Service (
POST /api/v1/credentials/{id}/oauth/disconnect), which:- Calls the provider’s token revocation endpoint when the credential is the last live member of its OAuth connection group
- Permanently deletes encrypted access/refresh tokens from LaunchAI
- Clears connected account email/name, Microsoft
connected_tenant_id(if applicable), and granted scopes - Marks the credential disconnected/revoked
- Delete the credential record (soft-delete, then hard purge after the credentials retention period)
Provider-side revocation (recommended in addition to in-product disconnect):
- Google: https://myaccount.google.com/permissions
- Microsoft: https://account.microsoft.com/privacy and/or your organization’s Microsoft Entra admin center app permissions / enterprise applications consent for LaunchAI
After provider-side revocation, LaunchAI refresh/resolve operations will fail; you should also disconnect the credential in LaunchAI to purge stored tokens.
11.2 Access, Correction, and Portability
Authorized users may access and update profile fields and company-managed records available in the Service UI/API. For copies of personal data not available in-product, email privacy@launchai.work.
11.3 Deletion / Account Deactivation
- Credential / Google / Microsoft connection deletion: supported as described above.
- Support ticket operational purge / GCS destroy: available to authorized administrators under support retention controls and legal-hold rules.
- User deactivation: company/system administrators may deactivate a user (
DELETE /api/v1/users/{user_id}), which disables the Firebase user and sets the LaunchAI user inactive.
As of the Last Updated date, LaunchAI does not provide a self-service “delete my entire account and all tenant data” consumer endpoint. Organization offboarding and full-tenant erasure requests must be submitted to privacy@launchai.work and will be handled through administrative procedures (including, where applicable, support GCS prefix destroy and database offboarding).
11.4 Legal Holds
Support legal holds, where placed by authorized administrators, suspend operational purge of held support records until released.
11.5 Jurisdictional Rights
Depending on your location (including GDPR/UK GDPR/CCPA-CPRA where applicable), you may have rights to access, rectify, erase, restrict, object, portability, and to appeal certain denials. Submit requests to privacy@launchai.work. We may verify identity and authority (including company-admin authority for tenant data) before acting. You may lodge a complaint with a supervisory authority where legally available.
12. Children
The Service is directed to business users. LaunchAI does not knowingly collect personal data from children under 16 (or higher age required by local law). If you believe a child provided personal data, contact privacy@launchai.work for deletion.
13. International Transfers
Production infrastructure defaults to Google Cloud us-central1 with MongoDB Atlas connectivity used by that deployment. If you access the Service from outside the United States, your data is transferred to and processed in the United States (and any other region where configured sub-processors operate, including Microsoft identity/Graph endpoints). Where required, LaunchAI relies on appropriate transfer mechanisms (e.g., contractual clauses with sub-processors).
14. Changes to This Policy
LaunchAI may update this Policy by posting a revised version at https://launchai.work (or a linked Privacy Policy URL) and updating the “Last Updated” date. Material changes affecting Google or Microsoft user data use, scopes, storage, or sharing will be stated expressly. Continued use of the Service after the effective date of changes constitutes acceptance of the updated Policy to the extent permitted by law.
15. Contact
Launch AI Solutions LLC
Web: https://launchai.work
Privacy requests: privacy@launchai.work
Support: support@launchai.work
For Google or Microsoft OAuth / user-data questions, include the connected account email, provider (Google or Microsoft), and the LaunchAI credential identifier if available.
16. Governing Language
This Policy is the controlling privacy notice for the Service. Product UI copy, marketing pages, and internal engineering documentation do not modify the obligations stated here unless expressly incorporated by a written amendment.