Trust Security · 03

Security

Last updated: May 2026

How we protect your data, what access we request, and how AI providers handle your information.

AES-256-GCM TLS 1.3 Row-Level Security No AI training

1. Infrastructure

1.1 Hosting

Siftable runs on Google Cloud Platform:

Application — Cloud Run (managed, auto-scaling containers)
Database — Cloud SQL for PostgreSQL (managed, automatic backups)
File storage — Google Cloud Storage (signed URLs with short-lived expiry)
Marketing site — Cloud Run (same platform as the application)

1.2 Encryption

In transit — all connections use TLS 1.3. HSTS is enabled with a one-year max-age, includeSubDomains, and preload.
At rest — Cloud SQL and Cloud Storage encrypt data at rest using Google-managed keys by default.
OAuth tokens — encrypted with AES-256-GCM before storage. Tokens are never stored in plaintext.

1.3 Security Headers

All responses include hardened HTTP headers:

Strict-Transport-Security — forces HTTPS for all connections
X-Content-Type-Options: nosniff — prevents MIME-type sniffing
X-Frame-Options: DENY — blocks clickjacking via iframes
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy — disables geolocation, microphone, and camera access for embedded content

2. Authentication & Access Control

2.1 Authentication Methods

Web app — Google OAuth 2.0 with JWT session tokens
Mobile app — Google ID tokens verified server-side
MCP / API — Personal Access Tokens (PATs) scoped per user
Microsoft Calendar — OAuth 2.0 with PKCE flow

2.2 Data Isolation

Every database query is scoped to the authenticated user. PostgreSQL Row-Level Security (RLS) policies enforce that users can only access their own data, even if application code has a bug.

RLS is enforced at the database level on every user-owned table. The application sets the current user context before each query, and PostgreSQL rejects any access that doesn't match the policy. This is a defense-in-depth measure — data isolation does not depend on application logic alone.

3. OAuth Scopes

We request only the scopes needed for each integration and explain exactly why below.

3.1 Google

Scope	Purpose
`openid`	Verify your identity for login
`email`	Identify your account and send service notifications
`profile`	Display your name and photo in the app
`calendar`	Read your events to show your schedule; write events to create focus blocks and scheduled tasks. Calendar data is cached locally and re-synced from Google. You can disconnect at any time from Settings or from your Google Account permissions.

We request access_type: offline so the app can sync your calendar in the background without requiring you to be logged in. The refresh token is encrypted with AES-256-GCM before storage.

3.2 Microsoft (Outlook / Exchange)

Scope	Purpose
`openid`	Verify identity for calendar connection
`offline_access`	Background calendar sync without re-authentication
`User.Read`	Read your name and email for account linking
`Calendars.Read`	Read your Outlook calendar events
`Calendars.ReadWrite`	Create focus blocks and scheduled tasks on your calendar
`Calendars.Read.Shared`	See shared calendars you have access to
`Calendars.ReadWrite.Shared`	Schedule events on shared calendars you have write access to

Microsoft OAuth uses the PKCE authorization flow for enhanced security.

3.3 Code Repositories

The MCP code integration indexes repositories from your local filesystem only. Siftable does not request GitHub or GitLab OAuth access. Repository paths, commit history, and code embeddings are processed locally and stored in your account's isolated database partition.

4. AI & Data Processing

4.1 No Training on Your Data

Your data is never used to train AI models. All AI providers process your data solely to generate real-time responses. No provider retains your data for model improvement.

4.2 AI Providers

When you use the AI assistant, your messages and relevant context (task titles, calendar summaries, notes) are sent to a major model provider to generate a response. We route to providers including Google, Anthropic, and OpenAI, selected for their commitments to not training on customer data. Each provider's data processing is governed by their respective data processing agreements.

4.3 What Gets Sent to AI

Your message and recent conversation history
Relevant context retrieved from your data (task titles, calendar events, note excerpts) via semantic search
File attachments you include in your message (images, PDFs, text files)

We do not send your entire database to AI providers. Only the context relevant to your current query is included, retrieved through a RAG (Retrieval-Augmented Generation) pipeline.

4.4 Code Execution Sandboxing

When Daemon operators execute code, it runs in isolated cloud sandboxes (E2B) with no access to your account data, local filesystem, or network credentials. Each execution gets a fresh, ephemeral environment that is destroyed after the run completes.

5. Data Retention & Deletion

Account data — retained until you delete your account
Calendar events — cached and re-synced; deleted immediately when you disconnect
Tasks, notes, projects, contacts — retained until you delete them or your account
Chat sessions — retained for 90 days, then automatically purged
Voice sessions — transcripts retained for 90 days; raw audio is never stored
AI-learned preferences — viewable and deletable from the Memory section

To request full account deletion, email hello@execufunction.com. All data is permanently removed within 30 days.

6. Vulnerability Reporting

If you discover a security vulnerability, please report it responsibly:

Email: security@execufunction.com

We ask that you:

Give us reasonable time to investigate and fix the issue before public disclosure
Avoid accessing or modifying other users' data
Provide enough detail to reproduce the issue

We take all reports seriously and will respond within 48 hours.

7. Questions

For security-related questions, contact security@execufunction.com. For general inquiries, reach us at hello@execufunction.com.