AegisAI uses Workload Identity Federation to propagate the calling user's identity to BigQuery, Vertex AI, Cloud SQL, and Spanner — without distributing service account keys, without long-lived credentials, and without breaking organization-policy guardrails.
✓ LIVE: BigQuery with Workload Identity Federation. testIamPermissions check framework. Service account JSON-free auth path.
⧉ EARLY ACCESS · Q3 2026: Cloud SQL IAM database auth, BigQuery row access policy enforcement under per-user federated identity, VPC Service Controls perimeter preservation
⧉ ROADMAP · Q4 2026: Vertex AI Search per-user document scoping, Agent Builder tool-call identity propagation, Gemini grounding ACL honoring, Spanner FGAC per principal, AlloyDB column-level grants
WIF + STS token exchange is built once and reused per GCP service. Each new data plane integration is ~5 engineer-days against a customer GCP sandbox.
Workload Identity Federation, VPC Service Controls, Organization Policies, BigQuery row access policies, Vertex AI grounding — Google's identity tooling is genuinely best-in-class. The naive AI assistant pattern: a service account JSON key in an environment variable. Every modern control above gets bypassed.
Each AI integration creates a service account. Each service account gets a JSON key. Each key lives in some .env or secrets manager somewhere. Compromised key = full data access. Google's own docs say "don't use service account keys" but the AI tutorials all do.
VPC SC perimeters protect BigQuery datasets from exfiltration. A service account inside the perimeter that calls out to an external AI vendor = perimeter break. Per-user identity preserves the perimeter semantics.
BigQuery row access policies (RAPs) evaluate SESSION_USER(). A service account makes that meaningless. Per-user identity propagation makes RAPs work as designed.
AegisAI exchanges the user's OIDC token for a Google STS token via Workload Identity Federation. The Google token impersonates the user identity. BigQuery, Vertex AI, and Cloud SQL evaluate IAM against the actual user. No keys distributed, no long-lived credentials anywhere.
Dataset-level IAM, table-level IAM, row access policies, column-level masking — all evaluate against the calling user. BigQuery Audit Logs in Cloud Audit Logs attribute queries to actual users for SOC 2 and FedRAMP audits.
SESSION_USER() is realVertex AI Search uses per-user OAuth scopes. Agent Builder and Gemini grounding can call BigQuery / Cloud SQL under user identity instead of the Vertex AI service account. Per-user quotas, content filter logs, and prompt audit all attribute correctly.
IAM database authentication for Cloud SQL maps the user's federated identity to a Postgres or MySQL principal. Spanner fine-grained access control and AlloyDB column-level grants fire against the actual user.
postgres superuser everywhere)Organization-level policy enforcement still applies. VPC Service Controls perimeters protect dataset egress at the organizational layer. Cloud Audit Logs answer "who accessed this dataset?" with the actual user, not the integration service account.
Workload Identity Federation eliminates the JSON-key-in-environment-variable anti-pattern. Compromised AI tooling can no longer leak persistent credentials.
Exfiltration protections at the org perimeter remain enforceable. AI access doesn't become a perimeter bypass.
Row access policies based on SESSION_USER() finally do what your data engineering team intended.
Forensic investigations get real user identities, not a sea of "service-account@..." entries.
30-minute architecture call. We open the operator console and run real queries through your stack — AWS, Azure, GCP, or all three. You see the audit chain tick up in real time.