What is the biggest security risk in Google Vertex AI?

Over-privileged service accounts are the most critical risk. By default, Vertex AI's Per-Project, Per-Product Service Agent (P4SA) is granted broad permissions including read access to all Cloud Storage buckets in the project, access to Artifact Registry repositories, and OAuth 2.0 scopes that could expose Google Workspace data. Palo Alto Networks Unit 42 demonstrated in April 2026 that a compromised or misconfigured agent can exploit these defaults to become a 'double agent' that exfiltrates data while appearing to function normally.

What is BYOSA and how does it improve Vertex AI security?

BYOSA stands for Bring Your Own Service Account. Instead of accepting the default P4SA that Google creates automatically, you create a dedicated service account for each Vertex AI Agent Engine deployment and grant it only the specific IAM roles it needs. This replaces broad default permissions with a minimal, auditable permission set. Google recommends BYOSA as the primary mitigation for the over-privilege vulnerabilities disclosed by Unit 42.

How does prompt injection work in Vertex AI applications?

In Vertex AI applications connected to enterprise data sources, indirect prompt injection occurs when malicious instructions are embedded in documents, calendar entries, or other content that the agent retrieves and processes. The GeminiJack attack pattern demonstrated that instructions placed in a Google Doc or calendar event, when retrieved via Workspace search, can cause the agent to exfiltrate conversation history to attacker-controlled infrastructure. Vertex AI's Gemini safety filters do not reliably block instructions embedded in retrieved content rather than the user's direct input.

Is Google Vertex AI HIPAA compliant?

Yes, Google Vertex AI supports HIPAA compliance when properly configured. You must execute a Business Associate Agreement (BAA) with Google before processing protected health information. Required controls include VPC Service Controls to prevent data exfiltration, customer-managed encryption keys (CMEK) via Cloud KMS, and Data Access audit logs enabled for Vertex AI read and write operations. HIPAA compliance is a shared responsibility: Google secures the platform, but data governance, access controls, and configuration are the customer's responsibility.

What is the ModeLeak vulnerability in Vertex AI?

ModeLeak is a privilege escalation attack discovered by Palo Alto Networks Unit 42 in which a malicious actor uploads a poisoned model to a public registry. When deployed in Vertex AI as a custom prediction or custom job, the poisoned model exploits the job service account permissions to steal proprietary ML models and fine-tuned LLM adapters from the victim's Vertex AI project. The attack chain begins with a public model repository and can reach internal, commercially sensitive fine-tuned models.

How do I enable audit logging for Vertex AI?

In Google Cloud Console, go to IAM and Admin, then Audit Logs. Find the Vertex AI API and enable Data Read and Data Write audit log types (these are disabled by default). Admin Write logs are on by default. Without Data Read logs, there is no record of who invoked a model, which endpoint was queried, or what prompts were submitted. Route audit logs to a Cloud Logging bucket with a minimum 90-day retention policy and, for regulated environments, export to a separate security project using log sinks.

Google Vertex AI Security: Enterprise Guide

Google Vertex AI security is now a critical concern for any enterprise deploying Gemini models, custom ML pipelines, or autonomous agents on Google Cloud Platform (GCP). In April 2026, Palo Alto Networks Unit 42 disclosed a chain of misconfigurations and design gaps in Vertex AI Agent Engine that allows a compromised agent to read every Cloud Storage bucket in a project, access internal Google-owned container images, and potentially reach Google Workspace data including Gmail and Drive. This guide covers the complete threat model: over-privileged service accounts, prompt injection patterns specific to Vertex AI, model theft through custom job abuse, and the concrete hardening steps that close the gaps.

Key Takeaways

Vertex AI's default Per-Project, Per-Product Service Agent (P4SA) is over-privileged by design. Every Vertex AI Agent Engine deployment inherits this broad access unless you replace it with a dedicated service account using the BYOSA pattern.
The Unit 42 "Double Agents" research (April 2026) demonstrated that a misconfigured Vertex AI agent can read all GCS buckets, pull internal Artifact Registry images exposing Google Cloud infrastructure details, and access Google Workspace data through overly permissive OAuth scopes.
Indirect prompt injection via enterprise data sources (Google Docs, Calendar, Drive) is a validated attack path in Gemini-connected Vertex AI applications. Instructions embedded in retrieved content bypass input-level safety filters.
The ModeLeak attack chain begins with a public poisoned model upload and ends with proprietary fine-tuned LLM adapter exfiltration from a victim's Vertex AI project.
Data Access audit logs for Vertex AI are disabled by default. Without enabling them, there is no record of model invocations, endpoint queries, or prompt content.
VPC Service Controls, CMEK, and BYOSA together form the minimum viable security posture for regulated industries using Vertex AI.

Vertex AI Architecture: The Enterprise Security Surface

Vertex AI is a managed machine learning platform on GCP. For enterprise security teams, three deployment patterns matter most:

Vertex AI Model Garden and Gemini API: Foundation model inference through a unified API. Customers call predict or generateContent. Google operates the model infrastructure; the customer controls what data enters the model and how responses are handled.

Vertex AI Agent Engine (formerly Reasoning Engine): Managed runtime for deploying LLM-based agents with tools, memory, and orchestration. Agents are invoked via the apps.reasonEngines.query API and can call Google Cloud services, external APIs, and custom functions. This is where the most serious security issues concentrate.

Vertex AI Pipelines and Custom Jobs: Serverless ML workflow orchestration. Custom jobs run arbitrary containerized code with service account credentials. This surface enables the ModeLeak attack class.

Vertex AI Feature Store, Model Registry, and Endpoints: Storage and serving infrastructure for ML artifacts, including fine-tuned adapters. These contain the proprietary models that adversaries target in model theft scenarios.

Google Cloud operates under a Shared Responsibility Model. Google secures the physical infrastructure, hypervisor, and core platform. The customer is responsible for IAM configuration, service account scoping, network controls, data governance, and monitoring. The security issues disclosed in 2025 and 2026 consistently exploit the customer-responsibility side of this boundary.

The "Double Agent" Problem: Over-Privileged Service Accounts

The most significant architectural risk in Vertex AI Agent Engine is the default service account model. When you deploy an agent to Agent Engine, Google automatically creates a Per-Project, Per-Product Service Agent (P4SA). This service account is granted permissions designed for broad platform compatibility rather than the principle of least privilege.

Unit 42 researchers published their findings in April 2026 under the name "Double Agents." Their analysis of the default P4SA permissions found that a single compromised or manipulated agent could:

Read every GCS bucket in the consumer's GCP project, not just the buckets the agent was intended to access.
Pull from internal Artifact Registry repositories containing container images that form the core of Vertex AI Reasoning Engine infrastructure, exposing internal Google Cloud implementation details.
Access Google Workspace data through OAuth 2.0 scopes that are provisioned by default but are unnecessary for most agent use cases, creating latent exposure to Gmail, Drive, and Calendar content.

The attack does not require a vulnerability in Google's code. It requires a misconfigured agent (or an agent manipulated through prompt injection) that exploits the over-broad default permissions it was legitimately given.

The BYOSA mitigation: Google's recommended response is to use Bring Your Own Service Account. Instead of accepting the P4SA defaults, you create a dedicated IAM service account before deploying each Agent Engine application and pass it explicitly at deployment time. This service account should hold only the specific roles the agent legitimately needs.

A minimal example for an agent that reads from one GCS bucket and calls one Vertex AI endpoint:

Service account: vertex-agent-prod@PROJECT_ID.iam.gserviceaccount.com

Roles granted:
- roles/storage.objectViewer on bucket: gs://prod-rag-documents
- roles/aiplatform.user on resource: projects/PROJECT_ID/locations/us-central1/endpoints/ENDPOINT_ID

No wildcard project-level roles. No Workspace OAuth scopes unless the agent explicitly needs them. Review the service account with gcloud iam service-accounts get-iam-policy and verify that no unintended principals have iam.serviceAccountTokenCreator on it, as that role allows any holder to impersonate the service account.

For a broader review of how cloud AI platforms handle service account scoping, see our AWS Bedrock security guide and Azure OpenAI security guide, which cover the analogous risks in those platforms.

Prompt Injection and Indirect Attacks in Vertex AI

Prompt injection is the top-ranked vulnerability in the OWASP LLM Top 10 (2025), covering both direct attacks against user input and indirect attacks via external data sources. Vertex AI applications face both variants.

Direct prompt injection: An attacker submits crafted input to a Vertex AI endpoint that overrides the system prompt, reveals confidential instructions, or forces the model to call tools it should not. This applies to any endpoint that accepts user-controlled text without input validation. Gemini's safety filters operate at the content-policy level (harm categories, dangerous instructions) and are not designed to detect system-prompt override attempts.

Indirect prompt injection via enterprise data sources: This is the more serious threat in Vertex AI deployments that connect to Google Workspace. The GeminiJack attack pattern, which researchers validated against Workspace-connected Gemini deployments, demonstrates the following:

An attacker creates or edits a Google Doc, calendar event, or email containing hidden instructions (white text, zero-font-size characters, or instruction text appended to a legitimate document).

When a user invokes a Vertex AI agent with access to Workspace search, the agent retrieves the malicious document as context.

The embedded instructions execute in the model's context. In demonstrated attacks, the agent exfiltrates conversation history to an attacker-controlled URL via an image request or API call.

Gemini's grounding-time content filters do not reliably block instructions embedded in retrieved documents because the model processes the document as context rather than user input. The distinction is architectural, not a content-policy failure.

Defensive controls for Vertex AI prompt injection:

Apply strict output parsing. If the agent's output is a structured API call, validate every field against an expected schema before execution. Reject any tool invocation that does not match the defined schema.
Use VPC Service Controls with an access policy that prevents egress to non-approved external endpoints. An exfiltration attempt via HTTP image request will fail if the agent's network perimeter does not allow outbound traffic to unknown destinations.
Separate read and write agent roles. An agent that reads Workspace documents should not also have the ability to make external API calls or write to persistent storage.
Log all tool invocations. Every function call made by a Vertex AI agent should produce a structured audit record. Anomalous tool calls (calls to unexpected endpoints, unusual parameter patterns) are the primary indicator of a successful injection.

Model Theft via Privilege Escalation: The ModeLeak Attack

Vertex AI Pipelines and Custom Jobs are a distinct attack surface from Agent Engine. These services run arbitrary containerized workloads and inherit the permissions of the attached service account.

Palo Alto Networks disclosed the ModeLeak attack chain, which demonstrates how a public poisoned model can reach proprietary, commercially sensitive models inside a victim's Vertex AI project:

An attacker uploads a poisoned model to a public model hub (Hugging Face or a public Google Artifact Registry repository).

A developer or automated pipeline imports the model into a Vertex AI Custom Job, intending to use it as a base for fine-tuning.

The poisoned model's initialization code runs inside the Custom Job's service account context.

If the service account has aiplatform.models.get or storage.objects.get at the project level (common in development environments), the poisoned code can download fine-tuned adapters, feature store data, and other proprietary model artifacts.

The practical impact: a company that has invested in domain-specific fine-tuning (medical NLP, legal document analysis, code generation trained on internal repositories) can lose those models entirely through a single dependency import in a Custom Job.

Mitigations for model import pipelines:

Treat imported models as untrusted code. Run a static analysis pass over model files before importing them into Vertex AI. Libraries like ModelScan (protectai/modelscan) detect serialized code execution attempts in pickle-format model files.
Use a separate, sandboxed GCP project for model evaluation. Give the service accounts in that project no access to production model registries or feature stores.
Inventory your model dependencies. Maintain a model bill of materials (MBOM) that records the source, version, and hash of every base model in use. Validate hashes before importing.
Apply iam.deny policies to prevent Custom Job service accounts from accessing the production Model Registry unless the job is an explicitly approved promotion pipeline.

Compliance Requirements for Regulated Industries

Vertex AI holds a broad set of compliance certifications: SOC 1, SOC 2, SOC 3, ISO 27001, ISO 42001, HIPAA, PCI-DSS v4.0, and FedRAMP High. These certifications cover Google's platform operations. Customer deployments must still configure Vertex AI correctly to meet their own compliance obligations.

HIPAA: If you process protected health information (PHI) through Vertex AI, you must execute a Business Associate Agreement (BAA) with Google before go-live. Required technical controls include:

VPC Service Controls perimeter that prevents PHI from leaving the approved network boundary.
Customer-managed encryption keys (CMEK) via Cloud KMS for models, datasets, and pipeline artifacts.
Data Access audit logs enabled for Vertex AI Data Read and Data Write operations.
IAM Conditions that enforce access only from approved networks or during approved time windows.

PCI DSS v4.0: Payment card data must not flow through general-purpose Vertex AI endpoints without scoped controls. Use VPC Service Controls to create a dedicated perimeter for payment-related workloads. Ensure that prompt content is never logged to a storage location that is not itself in-scope for PCI DSS.

SOC 2 Type II: Your own SOC 2 audit will need to cover the Vertex AI components you operate. Auditors will look for evidence of least-privilege IAM (BYOSA), logging retention policies, change management for model updates, and incident response procedures for AI-specific events.

EU AI Act: For Vertex AI deployments classified as high-risk AI systems under the EU AI Act, you need documented risk assessments, bias evaluation reports, and post-market monitoring. Vertex AI's Model Evaluation and Explainability features provide some of the necessary technical evidence, but governance processes must be built around them.

For more on compliance frameworks relevant to AI deployments, see the BeyondScale compliance resources.

Vertex AI Security Hardening Checklist

The following controls address the primary risks documented in this post. Use this as a baseline before launching any Vertex AI workload in a production environment.

Identity and Access Management

[ ] Replace the default P4SA with a dedicated service account per Agent Engine application (BYOSA).
[ ] Scope all service account roles to specific resources (bucket ARN, endpoint resource name) not project-level wildcards.
[ ] Audit iam.serviceAccountTokenCreator on all Vertex AI service accounts quarterly.
[ ] Enable Org Policy iam.disableServiceAccountCreation in non-development projects to prevent unauthorized service account creation.

Network Controls

[ ] Configure VPC Service Controls for all Vertex AI APIs (aiplatform.googleapis.com).
[ ] Restrict OAuth scopes for Workspace-connected agents to the minimum set required.
[ ] Use Private Service Connect to route Vertex AI traffic through the internal network.

Logging and Monitoring

[ ] Enable Data Access audit logs (Data Read and Data Write) for the Vertex AI API in Cloud Logging.
[ ] Set a minimum 90-day retention policy on Vertex AI audit log buckets.
[ ] Export logs to a separate security project using log sinks to prevent tampering.
[ ] Create log-based alerts for anomalous tool invocations, unusual egress patterns, and service account impersonation events.

Model Governance

[ ] Use a separate sandboxed project for evaluating external or third-party models before promotion to production.
[ ] Scan imported models with ModelScan before use in Vertex AI Custom Jobs.
[ ] Maintain a model bill of materials with source, version, and SHA256 hash for all base models.
[ ] Apply iam.deny policies to prevent Custom Job service accounts from accessing production model registries.

Data Protection

[ ] Enable CMEK via Cloud KMS for all Vertex AI datasets, models, and pipeline artifacts.
[ ] Configure dataset access controls in Vertex AI Feature Store with field-level IAM where possible.
[ ] Review what data sources are accessible to each Workspace-connected agent and apply document-level access controls.

Security Assessment for Vertex AI Deployments

Security assessments for Vertex AI require evaluating both cloud configuration and model behavior. Configuration review covers IAM policy analysis, VPC Service Controls validation, audit log completeness, and service account permission mapping. Model behavior testing covers prompt injection resilience, tool abuse resistance, and data exfiltration paths through agent tool calls.

A point-in-time assessment is not sufficient. Vertex AI configurations drift as models are updated, new agents are deployed, and Workspace integrations are added. Continuous monitoring of IAM changes and tool invocation patterns is required to detect exploitation attempts before they become breaches.

The BeyondScale AI security assessment covers the full Vertex AI threat surface: IAM configuration review, agent architecture analysis, prompt injection testing against your actual deployment, and monitoring gap identification. Security teams that have reviewed their AWS Bedrock or Azure OpenAI deployments should treat Vertex AI as a separate assessment scope, as the attack surfaces, default behaviors, and mitigation patterns differ meaningfully across platforms.

Conclusion

Google Vertex AI introduces a distinct set of security risks that enterprise teams need to treat separately from general GCP security hygiene. The Unit 42 Double Agents research published in April 2026 confirmed that default configurations in Vertex AI Agent Engine create over-privileged service accounts that give attackers a broad foothold from a single compromised agent. Prompt injection via enterprise data sources, model theft through Custom Job abuse, and disabled default audit logging compound the risk.

The mitigations exist and are documented: BYOSA replaces the over-privileged P4SA, VPC Service Controls contain exfiltration paths, Data Access logging closes the visibility gap, and model scanning addresses the supply chain risk. The challenge for enterprise teams is ensuring these controls are applied consistently across every Vertex AI deployment, not just the ones built by the security-aware developers.

If your organization uses Vertex AI in production and has not done a focused security review of your agent configurations, IAM policies, and logging posture, request an AI security assessment to get a clear picture of your current exposure before the next incident.

Sources: