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: the GCP project.
  • 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 the production VM (GCP Compute Engine VM).
Persistent Disk Boot disk the boot disk (daily snapshots).
Static External IP the static external IP (the VM's static external IP).
Identity-Aware Proxy (IAP) Sole administrative SSH path.
IAM Workload service account the workload service account and human access.
Secret Manager Runtime secrets (JWT, DB URL, API key).
Cloud Storage (GCS) Image upload buckets used by the content-provenance service.
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 — the LB rollout step roadmap).
  • No Cloud SQL — Postgres runs on the VM's boot disk. Migrating to Cloud SQL is the Cloud SQL migration step.
  • 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 the SCC enrolment step).
  • No Cloud Armor / WAF.

Multi-tenancy disclosure (important)

The the GCP project GCP project is not dedicated to ClaimGuard. It is shared with sibling research and engineering workloads operated by the parent company. The full project hosts ClaimGuard's production VMs alongside ~60 other research and tooling VMs spanning multiple internal initiatives (model training, evaluation, audio research, data scraping, internal gateways).

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 the GCP project. This bounded the scope of ClaimGuard's IAM cleanup ( the IAM cleanup pass) — 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 (the workload service account, 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 GCP 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 the IAM cleanup pass 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 content-provenance service-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 content-provenance service writes to a GCS bucket (the upload 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

implemented — verified 2026-05-06.

What's in place:

  • GCP as the sole provider; project, region, and ownership confirmed.
  • Audit logs at 400-day immutable retention; long-retention archive bucket the long-retention audit log bucket populating Cloud Audit Logs via the audit log sink (sink-filter fix 2026-05-04).
  • Production VM IAM hardened: least-priv runtime SA in use (the workload service account), former-collaborator IAM bindings removed, IAP-SSH only, Shielded VM Secure Boot on (the Secure Boot step, 2026-05-02).
  • HTTPS LB live (the LB rollout step, 2026-05-03) with Google-managed cert, HTTP→HTTPS redirect, and Cloud Armor (rate limit + Adaptive L7-DDoS protection, 2026-05-04).
  • Daily snapshot policy on the boot disk.

Roadmap items (do not block this control):

  • Dedicated GCP project for ClaimGuard (today shares the GCP project with sibling research workloads). The proper SOC 2 isolation fix; tracked.
  • Cloud SQL migration (the Cloud SQL migration step) — Postgres still on the VM.
  • OS Login (the OS Login step) 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 ( the IAM cleanup pass- step4 / equivalent). This is the right-sized SOC 2 isolation fix.
  • Cloud SQL (the Cloud SQL migration step).
  • 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 the upload bucket (US) used by the content-provenance service to an EU region alongside the rest of the data plane.