Skip to content

Cloud Provider

Statement

ClaimGuard runs on Google Cloud Platform. The application's compute, storage, networking, identity, secrets, and audit logging are all GCP services. We do not run on AWS, Azure, or on-premise infrastructure.

This page is the honest baseline for understanding the rest of the infrastructure documentation. It is also where we disclose the most operationally significant fact about our current posture: ClaimGuard shares a GCP project with sibling research workloads, and dedicating a GCP project to ClaimGuard is a roadmap item.

Implementation

Provider and region

  • Cloud: Google Cloud Platform.
  • Project: train-cvit2.
  • Region: europe-west1 (St. Ghislain, Belgium).
  • Zone: europe-west1-b for the production VM.
  • Account holder of record: dtectvision (the parent company).

Services in use

Service Used for
Compute Engine Production VM claim-guard-app-1 (n1-standard-8, no GPU attached).
Persistent Disk Boot disk deepfakebench3 (300 GB, daily snapshots).
Static External IP claim-guard-vm-ip (34.76.180.225).
Identity-Aware Proxy (IAP) Sole administrative SSH path.
IAM Workload service account claim-guard-vm and human access.
Secret Manager Runtime secrets (JWT, DB URL, Google API key).
Cloud Storage (GCS) Image upload buckets used by the c2pa tool.
Cloud Logging Application logs (_Default, 30d) and audit logs (_Required, 400d locked).
Cloud Audit Logs Admin Activity, System Event, Access Transparency.

Services explicitly not in use

  • No managed load balancer (yet — A1.3 roadmap).
  • No Cloud SQL — Postgres runs on the VM's boot disk. Migrating to Cloud SQL is plan step A2.3.
  • No GKE / Cloud Run / Cloud Functions — single VM only.
  • No Cloud KMS / CMEK — using Google-managed encryption keys.
  • No VPC Service Controls.
  • No Security Command Center beyond the GCP defaults (SCC Standard enrollment is plan step A2.4).
  • No Cloud Armor / WAF.

Multi-tenancy disclosure (important)

The train-cvit2 GCP project is not dedicated to ClaimGuard. It is shared with sibling research and engineering workloads operated by the parent company, including (non-exhaustive):

  • ClaimGuard's three production VMs (the application VM, the model VM, and a related model host).
  • The verifai-* fleet (multiple VMs).
  • ComfyUI hosts (comfyui-*).
  • Audio research VMs (audio-dev-*).
  • DeepfakeBench evaluation hosts (deepfakebench*).
  • A social-media scraper VM.
  • Various other research and tooling VMs (60+ in total).

Concretely, this means:

  • Project-level IAM bindings affect every workload in the project. Granting a developer a project-level role gives them that role on ClaimGuard and every other workload in train-cvit2. This bounded the scope of ClaimGuard's IAM cleanup (plan step A1.4) — only former-collaborator removals were safe to execute aggressively; right-sizing of active developers' broad project roles is deferred because we cannot verify which non-ClaimGuard workloads they touch.
  • Audit logs are project-wide. Cross-workload activity shows up in the same logs. This is fine for retention guarantees but means filtering by service account / resource is required for ClaimGuard- specific incident review.
  • Quotas and resource limits are shared. A heavy training run on a sibling VM can in principle compete with ClaimGuard for project-level quotas (mostly external IPs, persistent disk SSD).
  • Blast radius of a sibling-workload compromise. A VM in this project that uses the default compute service account holds project- level roles/editor. ClaimGuard's own VM has been moved to a least-privilege service account (claim-guard-vm, see Secrets management), but a compromised sibling VM running with the default compute SA could still reach ClaimGuard resources. Mitigated only by moving ClaimGuard to a dedicated project (see roadmap below).

We are documenting this transparently rather than leaving it implicit. A trust portal that omits the multi-tenancy reality of its cloud project would be exactly the kind of "false claim" this portal exists to avoid.

Account ownership and billing

  • The GCP organization and the train-cvit2 project are owned by the parent company.
  • Owner-level project access is held by the founder set (roee@dtectvision.ai, dor@dtectvision.ai) — verified post plan step A1.4-step1 on 2026-04-29.
  • Billing is on the company GCP billing account.

Data residency

All ClaimGuard production data — the VM disk, snapshots, and Cloud Storage buckets used by the application — resides in Europe (europe-west1 for compute and disks; the c2pa-related GCS buckets are in the US — see roadmap). Cloud Logging audit log buckets are global GCP-managed buckets but logs are retained within Google's regional infrastructure.

The c2pa tool writes to a GCS bucket (g-lens-image-bucket) located in the US. This is documented as a known anomaly because it predates the hardening engagement; data-residency consolidation is a roadmap item.

Status

partial — verified 2026-04-29.

What's in place:

  • GCP as the sole provider; project, region, and ownership confirmed.
  • Audit logs at 400-day immutable retention.
  • Production VM IAM hardened: least-priv runtime SA prepared, former-collaborator IAM bindings removed, IAP-SSH only.
  • Daily snapshot policy on the boot disk.

What's still pending:

  • Multi-tenant project shared with sibling workloads. Dedicated GCP project for ClaimGuard is the proper SOC 2 isolation fix.
  • Cloud SQL migration (A2.3) — Postgres still on the VM.
  • HTTPS LB + managed TLS (A1.3).
  • Secure Boot, OS Login (A1.5, A1.6) on the VM.

Roadmap

  • Dedicated GCP project for ClaimGuard. Separates ClaimGuard's workload, IAM, billing, audit logs, and quotas from the rest of the parent company's research workloads. Tracked as P2 (plan step A1.4- step4 / equivalent). This is the right-sized SOC 2 isolation fix.
  • Cloud SQL (A2.3).
  • CMEK with customer-controlled KMS keys for compute and GCS, later compliance cycle.
  • VPC Service Controls for an explicit data-exfiltration boundary, later compliance cycle.
  • GCS bucket data-residency consolidation — move the g-lens-image-bucket (US) used by the c2pa tool to an EU region alongside the rest of the data plane.