Security

Encryption

At rest: disk-level encryption is configured on production hosts. Backups are encrypted in transit; at-rest encryption for backups is provided by the storage provider (Tigris or Backblaze B2).

In transit: all dashboard and API traffic is served over TLS with certificates issued by Let's Encrypt. Postgres endpoints at *.db.flickercloud.com accept TLS; sslmode=require is the documented default.

Tenant isolation

Tenant isolation is enforced through Postgres roles, per-database schemas, and per-database filesystem datasets. Isolation has not been independently audited; we encourage customers to report any cross-tenant exposure to security@flickercloud.com.

App containers, their migration step and their branch hook jobs run with the runtime's default seccomp filter, privilege escalation disabled, raw sockets removed from their capability set, and no Kubernetes API token. They share the node's kernel with other tenants' containers and may run as root. Only the platform operator can turn this hardening off for an app.

Memory search and graph traversal are scoped to your organization at every hop, not only at the record you started from. Each neighbour is re-loaded under your organization and dropped if it does not belong to it, so an edge alone cannot surface a record you may not read. A record that belongs to another organization and a record that never existed return the same answer, so existence is not probeable.

AI features and your content

Content retrieved from your project — ticket bodies, documents, notes — is treated as data, never as instruction. A document containing text addressed to the assistant does not change what it does.

The tools the assistant can call are read-only and take no organization argument: the organization comes from your session, and any organization-like value appearing in a tool call is discarded before the call runs. This is enforced by the shape of the tool interface rather than by instructions in a prompt, because a prompt is exactly what retrieved content could try to override.

Model keys, search data and agent runs

Your model keys. Flicker stores the provider API keys your organization adds. Each key is encrypted at rest (AES-256-GCM, with a key held in the production environment, not in the database), is excluded from logs and crash dumps, and is shown in the dashboard only as its last four characters. Flicker decrypts it to call your provider for Ask, for embeddings and for agent runs. A hosted factory run receives your key inside its sandbox for the length of the run, so the agent can call the model; a sandbox is also given a short-lived GitHub token limited to the run's repository. We do not yet offer customer-managed encryption keys.

No subscription tokens. Flicker does not hold ChatGPT or Claude subscription tokens and does not run agents on your subscription. Hosted agents use your organization's API key. Flicker skills and the workflow run on your own machine under your own login.

Where search data lives. The text of what you index (repository files, tickets, documents), its search vectors and its metadata are stored in a separate Postgres database (not the control-plane database) that Flicker operates on its Kubernetes cell and all organizations share. Isolation is enforced in application code: every row carries its organization and every search filters on it. There is no database-level row security on that database, and the isolation has not been independently audited.

What your provider sees. Text sent to answer a question or compute embeddings goes to the provider you chose, under that provider's terms, not ours. Flicker does not train models on your content; model calls use your own API keys under your provider's terms. Flicker's own embeddings endpoint is not configured in production, and Flicker's key is never used for organization traffic: embeddings are computed through the model provider connection your organization chose.

Merging and deploying. A factory run opens a pull request and merges it only after a person approves the exact commit CI checked. The run has no deploy step: production deploys stay an explicit action by you. The one caveat is that the GitHub token a sandbox holds can write to its repository, and GitHub does not restrict tokens by branch, so a misbehaving agent is constrained by your branch protection rules, not only by Flicker. Turn them on.

Backups and point-in-time recovery

Per-database backups run through CloudNativePG — continuous WAL archiving to object storage plus periodic volume snapshots. A weekly automated restore drill takes a fresh backup of one real database, point-in-time-restores it into a throwaway cluster, and compares the restored copy against the source — table sets exactly, row counts within a recorded tolerance — so a drill that compares nothing is recorded as a failure rather than a pass. Each run drills one database and the source rotates, so a given database is exercised periodically rather than every week. Point-in-time recovery (PITR) availability and retention windows are best-effort and may vary by database; no RTO/RPO commitment during beta.

Separately, a daily logical dump (pg_dump) of each database is taken inside the cluster and written to object storage. It is a distinct guarantee, not a duplicate: a physical backup copies data files and so copies corruption faithfully, while a logical dump reads every row back through the SQL layer and restores into any comparable PostgreSQL.

Logical dumps have their own automated restore drill. It restores a database's most recent dump into a scratch cluster it creates and drops, then compares the restored copy against the source the same way the physical drill does — table sets exactly, row counts within a recorded tolerance. A drill that cannot run — no dump in object storage, no scratch server able to hold that database's PostgreSQL image, not enough free space to restore into — is recorded as skipped with the reason, never as a pass, so coverage is a per-database fact rather than a platform-wide claim. Some databases are not currently covered for those reasons.

Deletion of customer data is available on request through support until self-serve erasure ships. We do not promise a deletion timeframe; backup catalogs may retain data per backup retention policy.

Authentication and access

The dashboard uses email and password authentication with bcrypt password hashing. Signup is invitation-only and invitations are scoped to a single organization. API keys are issued per organization and stored hashed. Personal CLI tokens are issued per organization to one member, stored hashed, revocable from Account Settings, and limited by the server to identity and agent-config routes — they cannot deploy, read secrets, or reach a database. We do not yet offer SSO or hardware-key MFA; both are on the roadmap.

Subprocessors

The vendors below process customer data or operational metadata on our behalf. We will give reasonable advance notice before adding a new subprocessor that touches customer data.

Data residency

Customer databases and backups are hosted in the United States, specifically the OVH Vint Hill, Virginia data center. We do not currently offer EU or other regional residency; that's planned for after Phase 1.

Penetration testing and audits

We have not yet engaged a third party for a formal penetration test. An external pen test is planned for after Phase 1. We do not hold SOC 2 or ISO 27001 attestations at this time.

Vulnerability disclosure

If you believe you have found a security vulnerability in Flicker, please email security@flickercloud.com with details and, where possible, steps to reproduce. We commit to:

• Acknowledging your report within 3 business days.
• Keeping you informed as we investigate and remediate.
• Coordinating public disclosure within 90 days of the report, sooner if the issue is already public or actively exploited.
• We will not pursue legal action against good-faith researchers who follow the disclosure terms below, to the extent permitted by applicable law. Good faith means: no data exfiltration beyond proof-of-concept, no service degradation, no access to other customers' data, and reasonable disclosure timelines.

Incident response

Security incidents are triaged by our on-call operator. We will notify affected customers without undue delay after becoming aware of a confirmed personal data breach, and in any event consistent with applicable law. See our Data Processing Addendum for more. For general security inquiries, contact security@flickercloud.com.