GCP AI Services Security Overview
Red team methodology for GCP AI services including Vertex AI, Model Garden, and AI Platform: service enumeration, service account exploitation, and attack surface mapping.
GCP AI Services Security Overview
Google Cloud Platform's AI portfolio centers on Vertex AI as the unified ML platform, with Model Garden providing access to first-party and third-party foundation models. GCP's AI security model is built on IAM service accounts, VPC Service Controls, and Cloud Audit Logging. For red teamers, GCP AI introduces unique challenges: its service account model creates complex impersonation chains, VPC Service Controls can restrict API access at the organization level, and Google's infrastructure provides strong defaults that must be deliberately weakened for exploitation.
Service Landscape
Vertex AI
Vertex AI is GCP's unified ML platform, consolidating previously separate services (AI Platform Training, AI Platform Prediction, AutoML) into a single surface. It covers the full ML lifecycle:
| Component | Function | Attack Surface |
|---|---|---|
| Workbench | Managed Jupyter notebooks | Code execution, credential access, lateral movement |
| Training | Custom and AutoML training jobs | Training data access, compute abuse |
| Prediction endpoints | Online and batch prediction | Model extraction, endpoint abuse |
| Pipelines | ML workflow orchestration | Pipeline poisoning, step manipulation |
| Feature Store | Feature management and serving | Feature poisoning, data manipulation |
| Model Registry | Model version management | Model replacement, supply chain |
| Vector Search | Nearest neighbor search for embeddings | Index poisoning for RAG systems |
| Generative AI | Foundation model API access | Prompt injection, guardrail bypass |
For detailed Vertex AI exploitation, see Vertex AI Attack Surface.
Model Garden
Model Garden is GCP's hub for discovering, testing, and deploying foundation models from Google (Gemini, PaLM, Gemma), open-source (Llama, Mistral), and third-party providers.
| Aspect | Description | Red Team Relevance |
|---|---|---|
| First-party models | Google's Gemini, PaLM, Codey | API-based attacks, guardrail bypass |
| Open-source models | Self-deployed Llama, Mistral, etc. | Full model compromise, no provider safety net |
| One-click deploy | Quick deployment to Vertex endpoints | Potentially insecure default configurations |
| Model cards | Model documentation and limitations | Intelligence gathering for targeted attacks |
For detailed Model Garden risks, see Model Garden Risks.
Legacy AI Platform
Some organizations still use the legacy AI Platform services. While deprecated in favor of Vertex AI, these services remain operational and may have weaker security configurations:
- AI Platform Training: Legacy training job service
- AI Platform Prediction: Legacy model serving
- AI Platform Notebooks: Legacy managed notebooks (now Vertex AI Workbench)
Service Account Architecture
Default Service Accounts
GCP AI services use service accounts for authentication. Understanding which service accounts are in play is critical:
| Service Account | Used By | Default Permissions |
|---|---|---|
| Compute Engine default SA | Vertex AI training, notebooks (if no custom SA) | roles/editor (extremely broad) |
| Vertex AI Service Agent | Internal Vertex AI operations | Managed by Google, limited scope |
| Custom service accounts | Organization-defined for specific workloads | Varies by configuration |
| User-managed SA | Development and testing | Often overprivileged |
# List service accounts in the project
gcloud iam service-accounts list
# Check SA permissions
gcloud projects get-iam-policy <project-id> \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount:*vertex*" \
--format="table(bindings.role)"
# Check for SA key files (credential exposure)
gcloud iam service-accounts keys list \
--iam-account=<sa-email> \
--managed-by=userService Account Impersonation
GCP allows service account impersonation, where one identity assumes another service account's permissions. This creates chains:
# Check who can impersonate AI-related service accounts
gcloud iam service-accounts get-iam-policy <ai-sa-email>
# Look for roles/iam.serviceAccountTokenCreator or
# roles/iam.serviceAccountUser bindingsFor detailed IAM exploitation, see GCP IAM for AI.
Enumeration and Reconnaissance
Discovering Vertex AI Resources
# List Vertex AI endpoints (deployed models)
gcloud ai endpoints list --region=us-central1
# List Vertex AI models
gcloud ai models list --region=us-central1
# List training jobs
gcloud ai custom-jobs list --region=us-central1
# List notebooks (Workbench instances)
gcloud workbench instances list --location=us-central1
# List pipelines
gcloud ai pipelines list --region=us-central1
# List feature stores
gcloud ai featurestores list --region=us-central1
# List Vertex AI datasets
gcloud ai datasets list --region=us-central1
# Check for Generative AI model access
gcloud ai models list --region=us-central1 \
--filter="displayName~gemini OR displayName~palm"Project-Level Assessment
# Check enabled APIs (which AI services are active)
gcloud services list --enabled --filter="name:aiplatform OR name:ml"
# Check organization policies that affect AI services
gcloud resource-manager org-policies list --project=<project-id>
# Check VPC Service Controls (may restrict AI API access)
gcloud access-context-manager perimeters list --policy=<policy-id>Artifact Registry for ML
ML model artifacts and container images are stored in GCP Artifact Registry or the legacy Container Registry:
# List repositories (may contain ML model artifacts and training containers)
gcloud artifacts repositories list
# List Docker images (training and serving containers)
gcloud artifacts docker images list <repository>Common Misconfigurations
Default Service Account Usage
The single most common GCP AI misconfiguration. Organizations use the Compute Engine default SA for:
- Vertex AI training jobs (grants
Editorto the training container) - Workbench notebooks (grants
Editorto the notebook VM) - Prediction endpoints (grants
Editorto the serving container)
Public Endpoints
Vertex AI online prediction endpoints can be configured with various access levels:
# Check endpoint access configuration
gcloud ai endpoints describe <endpoint-id> --region=us-central1 \
--format="json(dedicatedEndpointEnabled,trafficSplit)"Missing VPC Service Controls
VPC Service Controls create a security perimeter around GCP services. Without them:
- Data can be exfiltrated from Vertex AI to external projects
- Model artifacts can be copied to attacker-controlled GCS buckets
- Training data can be accessed from any authorized identity without network restrictions
Insufficient Audit Logging
GCP Cloud Audit Logs capture AI service API calls, but data access logging must be explicitly enabled:
# Check audit log configuration
gcloud projects get-iam-policy <project-id> --format=json | \
python3 -c "import sys,json; d=json.load(sys.stdin); print(json.dumps(d.get('auditConfigs', []), indent=2))"Related Topics
- Vertex AI Attack Surface -- Detailed Vertex AI exploitation
- Model Garden Risks -- Third-party model deployment risks
- GCP IAM for AI -- IAM patterns and exploitation
- Cloud AI Security Overview -- Cross-provider comparison
A Vertex AI training job is configured without specifying a custom service account. What service account does it run as, and why is this a security concern?
During GCP AI reconnaissance, why should you check for legacy AI Platform resources in addition to Vertex AI?
References
- Vertex AI Security -- Official security documentation
- GCP Service Accounts -- Service account best practices
- VPC Service Controls -- Network security perimeters