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:
- Your AI assistant calls a FlyDocs script locally
- The script sends an API request to the relay with your
fdk_key - The relay authenticates the request, decrypts your provider credentials, and forwards the operation to Linear or Jira
- 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_KEYenvironment 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.