Skip to content

9.2 Trust Boundaries

A trust boundary is a line that data or a request crosses between a place we control and one we do not. Every crossing is where something can go wrong, so every crossing has a control: who may cross, how they prove it, and what is checked on the way.

9.2.1 The Crossings

flowchart LR internet([Internet users<br/>and farm clients]) staff([Staff]) vendors[Vendor clouds] providers[Model providers] subgraph ours [Google Cloud, our projects] edge[Edge<br/>load balancer, Cloud Armor] services[Our services] sql[(Cloud SQL)] end internet -- "1 · HTTPS, token" --> edge --> services staff -- "2 · IAP" --> edge services -- "3 · private IP, IAM sign-in" --> sql services -- "4 · HTTPS, key" --> vendors services -- "5 · ai-gateway" --> providers
# Crossing Control
1 Users and farm clients reach our services Only through the edge: HTTPS, Cloud Armor, then a token signed by access and checked by the system that receives the request. Farm clients upload raw files through short-lived signed URLs, never through the API
2 Staff reach the Console, and staff and testers reach stage: there IAP admits infra-admins and the stage testers' group, stage-testers@moonitoring.com (decided 2026-11-12), on the hosts of the apps and, since 2026-11-13, of the systems; the first stage trial admits internal @moonitoring.com testers only (2026-11-11). The CI reaches the Console's host to upload builds (2026-11-13) Identity-Aware Proxy: a Google Workspace sign-in before any page loads; for the CI, a short-lived Google ID token of its Google service account, which access admits only when a staff service account is linked to it, never a key. It grants nothing in the product: the tester still signs in with our own tokens
3 Services reach the database Cloud SQL has no public address: only services inside the environment's network reach it, over TLS, signing in with their own identity. PostgreSQL privileges must restrict each component to its system's database, hosted in the environment's database project
4 Services pull from vendor clouds Outbound only, with the vendor's key from Secret Manager; what comes back is treated as untrusted input and parsed, never executed
5 Prompts reach model providers Only through ai-gateway, which holds the keys, checks prompts with Model Armor and sends personal data only to Vertex AI in the EU

Nothing crosses inward into a farm: the farm sync client always calls us, so no farm network is ever opened to the internet.

The database boundary above is a required control, not a result of naming databases separately. Stage phase 1 provisioned databases and Google identities, verified on 5 November 2026, without new SQL users or access grants. Isolation from existing SQL users remains pending until phase 2 closes the new databases' default PUBLIC access and verifies the per-component privileges.

9.2.2 Inside the Boundary

Being inside our projects does not grant trust by itself:

  • Each service runs as its own service account and may reach only what it needs.
  • Systems must not read each other's tables: they have separate databases even when they share a Cloud SQL instance or runtime project, and call each other's APIs with tokens.
  • Environments are separate networks that are never peered (see Network).