Security & Privacy

How FlyDocs handles your data: relay architecture, encryption, authentication, and what we do and don't see.

FlyDocs is a relay, not a vault. Your code and issue content stay in your repository and your PM tool. FlyDocs translates requests between your AI assistant and your project management provider -- it does not store your data.

Relay Architecture

When you run an issue command in cloud tier, the request flows through the FlyDocs relay:

  1. Your AI assistant calls a FlyDocs script locally
  2. The script sends an API request to the relay with your fdk_ key
  3. The relay authenticates the request, decrypts your provider credentials, and forwards the operation to Linear or Jira
  4. The provider response passes back through the relay to your local environment

Issue content passes through the relay but is not persisted. The relay logs the operation metadata (endpoint, method, status code, latency) for usage analytics, not the payload.


Authentication

User Authentication

FlyDocs uses Clerk for authentication. GitHub OAuth is the primary sign-in method, with email as a secondary option.

API Keys

  • API keys use the fdk_ prefix for easy identification
  • Keys are SHA-256 hashed before storage -- the plaintext key is shown once at creation
  • Keys are scoped to a workspace and can be revoked from the dashboard
  • Store your key in FLYDOCS_API_KEY environment variable, never in committed files

Provider Credentials

Your Linear or Jira credentials (OAuth tokens) are encrypted at rest using AES-256-GCM. They are decrypted only per-request as the relay processes your operation, then immediately discarded from memory.


What FlyDocs Sees

Data Stored Purpose
Relay API requests (endpoint, method, status, latency) Yes Usage analytics and debugging
Workspace configuration (projects, labels, team structure) Yes Dashboard and workspace management
User accounts (email, GitHub ID) Yes Authentication via Clerk

What FlyDocs Does Not See

Data Why
Your source code Never leaves your machine. FlyDocs scripts run locally.
Your issue content Passes through the relay but is not stored or logged.
Your local files (flydocs/, .claude/) Read only by your local AI assistant. Never transmitted.
Your AI conversations Handled by your AI provider (Anthropic, OpenAI, etc.), not FlyDocs.

Hook Security

The auto-approve hook (auto-approve.py) controls which commands your AI assistant can run without manual confirmation. Security measures:

  • Uses anchored regex patterns to match allowed commands
  • Rejects shell metacharacters (;, |, &, $, backticks) to prevent injection
  • Only pre-defined FlyDocs skill scripts are auto-approved
  • All other commands require explicit user approval

Data Residency

FlyDocs cloud services are hosted in the United States:

Service Provider Purpose
Database Convex Workspace data, configuration, usage logs
Hosting Vercel Dashboard and relay API
Authentication Clerk User accounts and sessions

Security Milestones

FlyDocs has completed a comprehensive security hardening milestone covering:

  • Environment variable history audit
  • Authentication guards on all API endpoints
  • AES-256-GCM encrypted provider credentials
  • Deletion cascades (workspace deletion removes all associated data)
  • Tier gating (cloud features enforce valid subscription)
  • Error sanitization (no credential leaks in error responses)
  • Hook security (metacharacter rejection, anchored regex)
  • CORS configuration
  • JQL injection prevention (Jira integration)
  • HSTS headers

Third-Party Services

Beyond the core infrastructure, FlyDocs uses these services on the marketing site and dashboard:

Service Scope Data
PostHog Marketing site only Anonymous page views and interactions
HubSpot Marketing site only Email capture for marketing site signups

PostHog and HubSpot are not present in the dashboard or relay. They only run on the public marketing site.


Policies

Questions about security? Contact us at support@flydocs.ai.