Who else is involved

The list is short on purpose, and it is worth being exact about what “short” means. The code that runs the service — the eighteen workspaces under services/, packages/ and connectors/ — names four external packages directly: a PostgreSQL driver, a Cloud SQL connector, a Google authentication library and a schema validator. Those four pull in the rest of their own trees, so the production dependency closure those workspaces actually install is 96 packages, measured with pnpm list --prod --depth Infinity. Four is what AAG chose; 96 is what AAG runs, and a reviewer should be given the second number as well as the first. Neither number includes an error-tracking agent, an analytics agent, a monitoring vendor or a content delivery network, because there is none of any of them. (The undeployed internal prototype under apps/portal has its own, larger tree and is not part of either count.)

This website sets no cookies, runs no analytics, loads no third-party script, font, image or stylesheet, and makes no request to any host but its own. The one thing it stores in your browser is a light or dark preference, kept on your own device, readable only by this site, and not transmitted anywhere.

Credential material is held in Google Secret Manager and encrypted at rest with a customer-managed key. The separation that key buys is by principal rather than by project: the grants on it are to Google’s own Secret Manager and Cloud Storage service agents, so neither a Connector runtime nor the path that accepts new material may use the key directly. A Connector runtime is granted read access to exactly one secret — its own Credential Binding — and the path that accepts new material may add a version and may never read one.

Control-plane audit logs are retained for 400 days. That is the retention period governing audit evidence, and it is not a general schedule: other periods exist for operational reasons — a database point-in-time-recovery window, for one — and no product-wide retention schedule has been set or is published here.

AAG’s platform infrastructure is deployed in a single Google Cloud region in the United States, on multi-zone managed services. Three things sit outside that region. Database backups and Terraform state are held in Google’s United States multi-region, so they leave the region and stay in the country. The public DNS zones that make a Gateway reachable by name are served by Google’s global name servers, which leaves the country as well: what those zones publish is the hostnames themselves and no customer content. Per-customer data residency is not offered. No customer-facing Gateway is running in production yet, so no customer business data is being processed anywhere today. No code enforces that; it is a statement about the live estate on the date at the top of this page.

AAG trusts two identity issuers — Google, and Microsoft Entra — and trusting one is an explicit decision rather than a default. Two issuers is not two issuer strings: Google is recognised as either of two exact spellings of itself, while Entra mints a value scoped to each tenant and is recognised by shape rather than from a list, so no allowlist of tenants narrows it. Only the Google path is built. A token minted by the other is refused today, and the refusal distinguishes an issuer AAG has not decided to trust from one it trusts and has not finished: the key-fetching path Entra needs does not exist on this estate yet, and the tenant policy behind it is an unmade decision. So an organization whose people hold only Microsoft work accounts cannot reach AAG through them today, whatever else this site says about being onboarded.

A person proves who they are to their own organization’s identity provider, which hands AAG a signed token rather than a password; AAG never receives one and so has none to keep. An identity is keyed by issuer and subject together — a bare subject is not an identity, and an email address is never used as the key, so the same address at two issuers is two identities and cannot be confused for one.

Keeping the public website and the service on separate domains, in separate DNS zones, on separate load balancers and certificates, is deliberate. Both zones are in Google Cloud DNS; what is kept apart is the zone, the load balancer and the certificate, so a problem with the marketing surface does not become a problem with the part of the system that holds credentials.

Systems AAG connects to on a customer’s instruction

When a customer connects an external account, AAG reaches that provider using credentials the customer supplied, for that customer’s own data. Today the one integration that exists is Google Ads, and it is read-only. Those providers are the customer’s own vendors, not AAG’s subprocessors, and AAG holds no account with them on any customer’s behalf.

What that integration can actually reach, stated accurately. The Connector Type declares its destinations in its manifest — for Google Ads, exactly two — and the firewall rule is built from that declaration, above a default deny. But an FQDN firewall object resolves a name periodically and then enforces on the resulting addresses, not on the name, and Google API hostnames share address space. So against a Google-hosted provider this rule does not separate this integration’s own Google API from any other Google API. What it does still do, and what matters against exfiltration, is deny every non-Google destination on the internet. The limit is stated at greater length, with its second consequence, in the honest limitations section of the security overview.

Vendors AAG does not use

To save you the question: AAG runs no error-tracking service, no application performance monitoring vendor, no analytics or product-telemetry service, no customer data platform, no content delivery network, no email delivery service and no payment processor. If one is ever added, it appears on this page before it is used.

What this page does not settle

AAG’s domains are registered through GoDaddy Inc., the registrar of record. A registrar is an administrative relationship rather than a data-processing one: it holds the registration, and it neither hosts this website nor answers DNS for it. It is not listed here as a subprocessor.

This page is the current list. AAG has no contractual notice period for adding a subprocessor, because no customer agreement establishing one has been executed — which is stated plainly rather than left for a customer to discover. Any notice commitment will come from a signed agreement, not from this page.

Questions about this list, or a request to be told when it changes: jose@aiaccessgateway.com.