Legal

Security Overview

Version 1.0Effective April 28, 2026civiq, Inc.

Plain-language summary

We treat your business idea, your financials, and your connected accounts the way a private bank treats a wire instruction. Encrypted at rest. Encrypted in transit. Compartmentalized so a breach of one component does not cascade to the others. Independently auditable.

1. Overview

civiq operates a defense-in-depth security posture across infrastructure, application, authentication, and data layers. The principles below apply globally; specific implementation details are summarized in each section.

  • Least privilege: every service account, API token, and human role grants only the access strictly required for its purpose.
  • Cryptographic isolation: credentials and secrets are encrypted with keys derived per-purpose so that compromise of one ciphertext cannot be repurposed against another system.
  • Fail closed: when a security check is unavailable (rate limiter unreachable, encryption key missing, signature unverifiable), the request is denied rather than degraded.
  • Auditability: all sensitive state transitions are logged in immutable observer events for forensic review.

2. Infrastructure

  • Hosting: Google Cloud, US-Central region, with traffic served by Cloud Run behind a Google-managed TLS termination layer.
  • Network isolation: production runs inside a private VPC. Database access is mediated by the Cloud SQL Auth Proxy with private IP only - the database is never exposed to the public internet.
  • Database: managed PostgreSQL with HA replication, automated daily backups, point-in-time recovery, and deletion protection enabled. Backups are encrypted at rest by the managed service.
  • Build pipeline: CI/CD runs in a VPC-peered private build pool. Container images are scanned for vulnerabilities before deployment. Builds that fail security scans block release.
  • Secret management: all secrets (API keys, encryption keys, OAuth credentials, webhook secrets) live in Google Secret Manager with IAM-scoped access. Service accounts read-only access; no human direct read.

3. Authentication and identity

  • Password hashing: Argon2id with parameters meeting OWASP 2024 recommendations.
  • Multi-factor: TOTP and WebAuthn passkeys both supported. TOTP secrets are encrypted at rest with AES-256-GCM using an HKDF-derived key separate from the application JWT signing key. Passkey credentials are stored as public keys per the WebAuthn standard.
  • Session model: WebSession-backed access tokens with rotating refresh tokens. Each session is a stateful row, allowing immediate revocation server-side. “Sign out everywhere” truly invalidates all active sessions in one action.
  • Anomalous-login detection: sign-ins from new devices or networks trigger an email alert to the account holder.
  • Password reset: consumes the reset token in a single atomic transaction, then revokes every active session for the user.
  • Rate limiting: applied to login, register, magic-link verify, password reset, TOTP verify, and passkey verify endpoints.
  • Email enumeration resistance: login and password-reset-request return generic responses regardless of whether the email is registered.

4. Customer-controlled credentials

When you connect a third-party platform (LinkedIn, Meta Ads, Google Ads) via OAuth, the access and refresh tokens are encrypted at rest with the following posture:

  • Algorithm: AES-256-GCM with a 96-bit random IV per encryption and a 128-bit auth tag.
  • Key derivation: HKDF-SHA256 from a server-only master secret with a domain-separation context unique to the credential subsystem (“civiq-credential-v1”). Compromise of a credential ciphertext is useless against any other encrypted system on the Platform.
  • Plaintext lifecycle: plaintext exists only in server memory long enough to make a single API call, then is dropped. Plaintext is never logged.
  • Decrypt failure handling: any decrypt error (tampered ciphertext, rotated key) auto-flags the credential as INVALID and prompts re-authorization rather than retrying.
  • Revocation: disconnect via the integrations UI immediately marks the credential REVOKED. Encrypted blobs are retained for audit (no future-use risk because status filters block them) but become functionally unreadable.
  • Scope minimization: we request the smallest scope set required to perform the actions you authorize - no wildcard scopes, no read-everything scopes.

5. OAuth flow integrity

  • OAuth flows are server-side only. Authorization codes and tokens never touch the browser.
  • The OAuth state parameter is a signed JWT carrying the customer ID, target platform, and return URL. The state token is verified before any database write at the callback endpoint, providing CSRF protection plus identity binding.
  • Open-redirect attacks are blocked: the post-callback return URL is validated against an allowlist (same-origin paths only, no protocol-relative URLs, no path traversal).
  • For platforms requiring offline access (Google Ads), we use access_type=offline and prompt=consent to ensure a refresh token is always issued.

6. Payments

Payment processing is delegated to Stripe. We never receive, store, or process card numbers. The webhook integration is signed-request-verified, idempotent at the Stripe event level (atomic claim on event.id), and fails closed on signature errors.

7. AI agent isolation

civiq orchestrates multiple AI agents per customer engagement. Isolation principles:

  • Per-session context: agents operate on the customer’s session state only. There is no cross-customer prompt sharing or context bleed.
  • Stream watchdog: long-running agent streams are monitored for idle timeouts and hard timeouts. Hung streams are terminated with a recoverable error rather than a stranded resource.
  • Tool execution: agent tool calls execute server-side under the same auth context as the originating request. No agent tool can elevate privilege or write outside its declared schema.
  • Provider opt-outs: commercial API endpoints are configured to exclude customer content from provider model training (where the provider supports such opt-outs).

8. Logging and audit

  • All authentication events, payment events, gate transitions, agent failures, and security-relevant state changes are recorded as immutable observer events.
  • Logs do not include plaintext credentials, plaintext tokens, plaintext customer content, or sensitive PII beyond what is needed for the audit purpose.
  • Application logs are retained for 12 months. Authentication and audit logs are retained for 12 months; financial records for 7 years.

9. Responsible disclosure

We welcome reports of suspected security issues. To report a vulnerability:

  • Email security@civiq.io with a clear description and reproduction steps.
  • Do not exploit the issue beyond what is necessary to demonstrate it.
  • Do not disclose publicly until we have had reasonable time to investigate and remediate.

We commit to acknowledging reports within 2 business days and providing a remediation timeline within 5 business days. We will credit the reporter publicly upon resolution unless asked otherwise.

10. Contact

Security questions, audit requests, or compliance documentation: security@civiq.io.