QEEK
Trust

Security at QEEK

QEEK is built for teams who connect real codebases. This page describes how we protect your data, infrastructure, and intellectual property.

Last updated: October 2026

Our Commitment

QEEK, Inc. treats security as a product requirement, not an afterthought. We design for least privilege, encrypt sensitive data, and continuously improve our controls as the platform evolves. For how we handle personal and codebase data specifically, see our Privacy Policy.

Infrastructure & Hosting

QEEK runs on industry-standard cloud infrastructure with clear separation between services:

  • Backend services on Google Cloud Platform (Firebase, Cloud Functions, Cloud Run, Firestore, Cloud Storage, Realtime Database, Cloud KMS, Secret Manager)
  • Web application (my.qeek.ai) hosted on Vercel
  • Marketing site (qeek.ai) hosted on Vercel
  • Primary data region: us-central1 (Google Cloud)
  • DNS managed via Cloudflare
  • Optional WireQ prototype builder runs on Cloudflare Workers and R2 object storage, with build compute on Fly.io (United States)

Encryption

In transit

  • All client and API traffic is served over HTTPS/TLS
  • Firebase Web API keys restricted to approved application origins
  • Webhook endpoints verify signatures using timing-safe comparison

At rest

  • All stored data is encrypted at rest by default with Google-managed AES-256 keys
  • Secrets and integration tokens encrypted with Google Cloud KMS
  • API tokens stored as hashes. Plaintext tokens are never persisted after issuance
  • Repository sync files in Cloud Storage are additionally protected with AES-256-GCM envelope encryption under a QEEK-controlled Cloud KMS key, enabled for new customer accounts
  • Data encryption keys for repo sync transported via short-lived Secret Manager secrets

Authentication & Access Control

  • User authentication via Firebase Auth (email/password and supported OAuth providers)
  • New user registration is invite-only. Sign-up requires a valid beta or team invitation
  • Multi-factor authentication (TOTP) available to all users, and required for access to the administrative panel, with step-up challenge on privileged actions
  • Repository access via a GitHub App with fine-grained, read-only permissions; installation tokens are short-lived and minted per operation
  • Role-based access control enforced in Cloud Functions, Firestore, and Cloud Storage security rules
  • Workspace-scoped data isolation. Users can only access accounts they belong to
  • Admin operations require verified admin role and MFA verification; privileged actions are audit-logged
  • Long-lived API tokens scoped to accounts with hashed storage and revocation support

Code & Data Handling

Your source code is valuable intellectual property. Our default architecture minimizes retention:

  • We do not permanently store full source code files. During a sync the raw files are written to storage encrypted with AES-256-GCM envelope encryption rather than in plaintext, processed, and then deleted, including on aborted or failed syncs
  • What we retain is derived analysis rather than the source itself: natural-language summaries of files, functions and classes, and structural metadata such as file paths, signatures, imports and detected API endpoints
  • Semantic search embeddings are computed from those generated summaries, not from raw source code. We store a truncated preview of the summary text used for each embedding
  • Environment files (.env) are excluded from indexing so that credentials are not captured
  • AI features that need live code access it from GitHub in real time rather than from a long-term code mirror
  • When repository sync is enabled, synced files are stored in isolated Cloud Storage paths with envelope encryption at rest
  • You can delete your account and associated data at any time

See our Privacy Policy for a full breakdown of what we collect and how we use it.

Application Security

We use a combination of preventive controls and automated testing:

  • Firebase App Check enforced on client access to Authentication, Firestore, Realtime Database, and Cloud Functions
  • Input validation and prompt sanitization for AI/agent workflows
  • Firestore and Cloud Storage security rules reviewed and tightened on an ongoing basis
  • Rate limiting, CORS restrictions, and security headers on backend and web application services
  • Static analysis (CodeQL, Semgrep with baseline gates) and security-focused dependency scanning (Dependabot) in CI across application repositories
  • Dynamic scanning (OWASP ZAP): passive baseline against production and staging web surfaces, plus active authenticated scanning against staging
  • Regular internal security assessments with findings tracked in a remediation backlog
  • STRIDE threat modeling for core surfaces (auth, IDE/MCP integration, agent runtime)

Subprocessors

QEEK relies on the following categories of third-party services to operate:

  • Google Cloud Platform / Firebase: compute, database, storage, secrets, and authentication
  • Vercel: frontend and marketing site hosting
  • Cloudflare: DNS, plus Workers and R2 object storage for the optional WireQ prototype builder
  • Fly.io: isolated build compute for WireQ prototype compilation
  • GitHub: repository access and webhook delivery
  • Stripe: payment processing (Stripe handles card data; QEEK does not store payment card numbers)
  • Resend: transactional email
  • Sentry: error monitoring
  • LLM providers (e.g., Google Gemini, OpenAI, xAI): AI analysis and generation, subject to your configured features

A dedicated subprocessor list page is in progress. Contact us if you need a current list for vendor review.

Compliance

QEEK is working towards SOC 2 Type 2 certification. We do not currently hold ISO 27001, HIPAA, PCI, or FedRAMP certifications.

  • Privacy Policy published at qeek.ai/privacy
  • CCPA and GDPR-aligned data practices described in our Privacy Policy
  • Payment card data handled by Stripe (PCI-compliant processor)
  • Formal compliance reports available upon request as our certification program matures

Report a Vulnerability

If you believe you have found a security vulnerability in QEEK, please report it responsibly. Do not disclose the issue publicly until we have had a reasonable opportunity to investigate and remediate.

Email contact@qeek.ai with the subject line "Security Vulnerability Report" and include:

  • A description of the vulnerability and its potential impact
  • Steps to reproduce, including affected URLs or endpoints
  • Your contact information for follow-up

We aim to acknowledge reports within five business days.

Security Questions

For security questionnaires, vendor reviews, or general security inquiries, contact QEEK, Inc. at contact@qeek.ai.