Security Overview

DarkBird runs on Google Cloud via Firebase App Hosting — a managed, serverless platform operated by Google. We do not manage physical servers, data centers, or OS-level infrastructure. Google maintains SOC 2, ISO 27001, and related certifications for the underlying platform. All traffic is encrypted in transit via TLS enforced at the platform layer.

Security response headers are set by the application on every response it serves:

• Strict-Transport-Security — enforces HTTPS for one year, including subdomains
• X-Frame-Options: DENY — blocks clickjacking via iframes
• X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks
• X-XSS-Protection — legacy XSS filter for older browsers
• Referrer-Policy: strict-origin-when-cross-origin

Content Security Policy (CSP) further constrains what the browser is allowed to load and execute, sharply limiting the impact of any cross-site-scripting (XSS) attempt. On the authenticated application — where session tokens and tenant data live — the policy is strict: scripts are permitted only via a cryptographic per-request nonce with no unsafe-inline, so an injected <script> cannot execute. object-src, base-uri, and frame-ancestors are locked down, external connections are restricted to an explicit allowlist, and violations are reported to a monitoring endpoint so anomalous script activity is visible. Public marketing pages carry a CSP as well; because they hold no session or customer data, their policy is tuned for static delivery.

Authentication is handled by Firebase Auth, backed by Google Identity Platform. We do not store passwords — Firebase manages credential storage, hashing, and breach monitoring.

After sign-in, the server issues custom claims — short-lived, cryptographically signed tokens that encode the user's organization membership, role, and account status. These claims are the authoritative source for all permission decisions and are verified server-side on every request without additional database lookups.

Session tokens expire automatically and cannot be extended client-side. Role changes (e.g., promotion from Member to Admin) take effect after the user's token refreshes, which happens on next sign-in or explicit refresh.

DarkBird is a multi-tenant platform. Each client organization is assigned a unique organizationId that is embedded in every data record and in the user's signed auth token.

Firestore security rules are the enforcement layer. Rules are evaluated server-side by Google's infrastructure and enforce that:

• A user can only read or write records belonging to their own organization
• All permission checks are based on the cryptographically signed auth token — not on untrusted client-supplied values
• There are no Firestore document reads inside the security rules themselves, which eliminates an entire class of privilege-escalation attack (where a user could craft a document to manipulate a rule evaluation)

This means even if a client-side bug existed in our application, the database layer would independently reject any cross-tenant read or write.

Rules govern every request the application makes on a user's behalf. A small number of staff-operated maintenance jobs run server-side with administrative credentials, outside the rules layer, as any platform's backend operations do — these are not reachable by clients or by client-side code. The only such job whose output is visible to clients is the benchmark aggregation described under Cross-Organization Benchmarks below, which publishes an anonymized, threshold-gated aggregate and no per-organization data.

Within an organization, four roles are enforced: Owner, Admin, Member, and Billing.

• Owner — full control including settings, integrations, and billing
• Admin — can manage team members and configuration
• Member — standard operational access
• Billing — read-only access except for billing management

Role checks are enforced in Firestore security rules. Application code does not duplicate permission logic that the database layer already enforces.

All data mutations go through server-side functions (Next.js Server Actions backed by the Firebase Admin SDK). There are no public REST endpoints for application data. The client never writes directly to the database.

This means:

• All inputs are processed in a controlled server environment before touching the database
• The server validates organization membership and role on every write
• Clients never hold database credentials or admin-level access tokens

DarkBird integrates with third-party systems including ConnectWise, HaloPSA, and Quoter. Credentials for these integrations are:

1. Never transmitted to or stored on the client — credentials flow only through server-side code
2. Encrypted at rest using AES-256-GCM with authenticated encryption (prevents tampering)
3. Per-organization key isolation via HKDF — each organization's credentials are encrypted with a unique derived key, so a key compromise for one organization does not expose any other organization's data
4. Master key stored in Google Secret Manager — outside the application code and deployment artifact

The encryption scheme uses AES-256-GCM with a random IV per encryption operation and authenticated tags that detect any ciphertext tampering before decryption.

DarkBird uses Google Gemini (and optionally customer-supplied AI keys via BYOK on the Enterprise plan). Several safeguards apply:

• All AI calls are server-side — API keys never leave the server
• All AI outputs are validated structured data — the application never executes or directly renders freeform model output
• Token usage is logged per-call — enabling cost monitoring and anomaly detection
• AI context is org-scoped — Expert Center, calibration data, and catalog context loaded for a given org cannot be accessed by another org's AI session

DarkBird publishes an anonymized benchmark showing how a given labor template's estimate-vs-actual variance compares across the platform, so a client can see whether their own calibration is typical or an outlier. This is the only mechanism by which any data derived from one organization informs what another organization sees, so it is worth stating precisely what it does and does not involve.

What is published: for each normalized template name — the template name, a count of how many organizations contributed, and a median variance multiplier. Nothing else.

What is not published: organization identifiers, organization names, customer or client names, pricing, cost, rates, project data, product data, and per-organization figures. The aggregation reads an internal organization id solely to count distinct contributors and to prevent any single organization from weighting the result; that id is discarded before anything is written and never appears in the published record.

Protections:

• k-anonymity threshold — nothing is published for a template until at least 3 distinct organizations have contributed a sample for it. Below that threshold the entry is discarded, not published, so a value can never be attributed back to one organization.
• Per-organization weighting — each organization contributes a single averaged figure before the cross-org median is taken, so an organization with many records cannot dominate or infer others.
• Republished, not accumulated — each run rebuilds the aggregate from current data and clears prior entries, so a template that drops below the threshold stops being published rather than leaving a stale value behind.
• Aggregation is staff-triggered and superuser-gated; the client-facing read joins an organization's own data against the already-anonymized aggregate and performs no cross-organization read.

Client control: Settings → AI Preferences has a dedicated Contribute to Cross-Org Benchmarks toggle (default on, matching the historical behavior above). Turning it off excludes the organization's calibration data from future aggregation runs and removes access to the comparison view — an organization can't see the benchmark without being in the pool that produces it. (Note: this is a separate setting from Contribute to Global Brain, which governs catalog categorization signals only — different mechanism, different data.)

DarkBird exposes an organization-scoped REST API and MCP endpoint for programmatic access. API keys are:

• Shown exactly once at creation — the application stores only a SHA-256 hash of the key, never the key itself
• Org-scoped — a key grants access only to its own organization's data, through the same service layer the application UI uses
• Revocable instantly from Settings, with only a display prefix retained for identification
• Locked at the database layer — the key collection is denied to all client reads and writes by security rules; only server-side code can touch it

Subscription billing is handled by Lemon Squeezy. Webhook events are:

• Verified via HMAC-SHA256 signature over the raw request body
• Protected against replay attacks via timestamp-based idempotency checks
• Cross-validated so an incoming event for a customer ID that doesn't match the stored org binding is rejected

DarkBird never stores full payment card data. All card information is handled exclusively by Lemon Squeezy's PCI-compliant infrastructure.

• TypeScript strict mode is enforced — type errors break the CI pipeline and block deployment
• All external API traffic is server-side — no third-party API keys are bundled into the client JavaScript
• Dependency management via npm with a committed lockfile
• The CI pipeline runs a type check pass and a full production build before any deployment

• New organizations are approved manually by DarkBird staff before gaining access
• Suspended accounts are blocked at the database rules layer — not just the application layer
• Email verification is required before full account activation

• We do not sell client data, disclose it to other clients, or use it to train AI models
• We do not log credential values — only metadata (sync timestamps, error status)
• We do not expose administrative or debug interfaces publicly

The one place data leaves a single organization's boundary is the anonymized benchmark aggregate described under Cross-Organization Benchmarks above. It carries no organization identifiers, no customer names, no pricing, and no project data — and it is not used for model training.