Google Vertex AI Security Guide: Securing Models, Agents and Data

Google's managed AI platform hands models, notebooks, training jobs and deployed agents a set of service identities that can reach Cloud Storage, BigQuery and external tools, and most exposure comes from those identities and from data settings left at their defaults. In April 2026 Google renamed Vertex AI to Gemini Enterprise Agent Platform (usually shortened to Agent Platform), but the API is still aiplatform.googleapis.com and the IAM roles are still roles/aiplatform.*, so most teams still call it Vertex AI. This guide covers the identity and access model, privileged roles, service agents and agent identity, logging, data retention, network perimeters and guardrails. It is written for cloud security, platform and AI engineers running these workloads in production. For the AWS equivalent see the Amazon Bedrock Security Guide.

Key takeaways

• The names changed, the controls did not. Agent Engine is now Agent Runtime and Vertex AI Studio is now Agent Studio, but IAM roles, the API name and audit log service names stay under aiplatform, so policies, SIEM rules and Terraform keep working.
• Service agents are the real blast radius. A deployed agent can reach everything its service account can reach, and Google warns that aiplatform.customJobs.create effectively grants editor-level access to other services in the project.
• Agent identity is the better default for agents. It gives each agent a SPIFFE-based identity with a 24-hour certificate and certificate-bound tokens, no keys and no impersonation, instead of a shared project service account.
• Data Access audit logs are off by default. Without them you cannot see who called a model or agent; Admin Activity logs alone show configuration changes only.
• Zero data retention is a set of settings, not a switch. Implicit caching is on by default, some features store data for days, and security controls such as CMEK and VPC Service Controls do not apply to preview models.

How identity and access work in Vertex AI

Vertex AI uses standard Google Cloud IAM. Every call to aiplatform.googleapis.com, whether a generateContent request to a Gemini model, a prediction against a custom endpoint or a query to a deployed agent, is authorised against IAM allow and deny policies on the project or on individual resources. There are four kinds of principal to manage.

Two points catch teams out. First, roles/aiplatform.user is described by Google as access to use all Agent Platform resources and includes aiplatform.endpoints.predict, so it is a convenient but wide grant: anyone holding it can call every model endpoint in the project and run up spend. Second, IAM decides which models and agents a principal can call, but it does not decide what an agent then does with its own permissions. That is governed by the agent's identity, covered below. See the Google Cloud IAM and Service Accounts Guide for the underlying IAM model.

Admin roles and privileged access

The predefined roles split into platform-wide roles, agent roles (most still Beta in October 2026) and feature roles. The table lists the ones that matter for access reviews.

• Custom jobs are code execution: anyone who can create a custom training job runs arbitrary code. Google's role reference warns that aiplatform.customJobs.create is highly privileged because the custom code service agent effectively has editor-level access to other services such as Cloud Storage and BigQuery. Grant it only to pipeline identities, never to broad developer groups.
• Service agent roles are for service agents: roles such as roles/aiplatform.customCodeServiceAgent, batchPredictionServiceAgent, colabServiceAgent, agentSandboxServiceAgent and reasoningEngineServiceAgent carry a warning to grant them only to service agents. Alert on any grant of these roles to a user, group or user-managed service account.
• Separation of duties: keep the people who change agent access policies (agentsAdmin) separate from those who deploy agents (agentsCreator), and keep admin roles out of standing access. See the JIT Access Guide.

Integrations, API tokens and service accounts

Choosing the identity for a deployed agent

Agent Runtime (formerly Agent Engine, and before that Reasoning Engine) offers three options for the identity a deployed agent uses.

Google's agent identity is built on SPIFFE. Each agent gets an X.509 certificate valid for 24 hours and renewed automatically, Google Cloud access tokens are cryptographically bound to that certificate, calls to Google Cloud APIs use mutual TLS by default, and calls through Agent Gateway add DPoP so the credential is bound twice. Agent identities are not shared between workloads by default, cannot be impersonated and do not allow long-lived keys. Google states that agent identities can be named in allow and deny policies and constrained by Principal Access Boundary policies, which cap what an agent can reach regardless of its other grants. Two lifecycle rules matter: deleting an agent leaves its IAM bindings in place as inactive grants that you must remove, and redeploying an agent creates a new resource ID and principal even with the same name and code, so old bindings do not carry over. Manage these grants in Terraform, as Google recommends. See the AI Infrastructure Workload Identity Guide and the Agentic AI Identity Guide.

External credentials and tools

• Auth manager: agent identity includes an auth manager that stores API keys, OAuth client credentials and delegated user tokens for third-party tools, so secrets stay out of prompts and code. Google recommends two-legged OAuth or stored API keys and advises against HTTP basic authentication.
• Secret Manager: where an agent still needs a secret, store it in Secret Manager and grant the agent's identity access to that one secret, not project-wide secretAccessor.
• Service account keys: block key creation for AI projects with the organisation policy constraint iam.disableServiceAccountKeyCreation and use attached service accounts or Workload Identity Federation for callers outside Google Cloud. See the Google Cloud Organization Policy Guide.
• Express mode: Agent Platform Express (Beta) is a quick-start path with its own roles that typically relies on API keys. Treat any such key like a cloud credential: restrict it to the API, keep it out of client code, and decide whether express mode is allowed in production at all.
• MCP and agent-to-agent calls: agent identities can authenticate to MCP servers, endpoints and other agents as themselves or on behalf of a user. Inventory those connections like any other integration. See the MCP Security Guide.

Logging and detection

Cloud Audit Logs records four log types. Admin Activity and System Event logs are always written and cannot be disabled. Data Access audit logs are disabled by default for every service except BigQuery, so model calls, endpoint predictions and agent queries are not recorded until you enable Data Access logging for aiplatform.googleapis.com. Prompt and response content is a separate choice: request-response logging is off by default, and turning it on stores content you then have to protect and retain.

Credential theft for AI is a well-documented pattern. In the LLMjacking campaigns Sysdig listed GCP Vertex AI among the hosted LLM services attackers checked with stolen cloud credentials, and the clearest early signals were invocation spikes and changes to logging configuration. In ATT&CK terms this is T1078.004 Cloud Accounts leading to T1496.004 Cloud Service Hijacking. Since May 2026 Google adds user.id to prompt and response logs, which helps tie unusual tool use to an end user. See the LLMjacking Guide and the LLM Observability Guide.

Metrics that show the controls work:

• Percentage of AI projects with Data Access audit logs enabled for aiplatform.googleapis.com (target 100% in production).
• Number of principals holding aiplatform.admin, agentsAdmin or basic Owner/Editor on AI projects, trended monthly.
• Percentage of production agents running on agent identity or a dedicated service account rather than the default service agent.
• Inactive IAM bindings left by deleted or redeployed agents (target zero after each release).
• Model Armor block and match rates per template, and time to tune templates out of inspect-only mode.
• Time from a spend or invocation anomaly alert to credential revocation.

Hardening baseline

Data handling and retention

Google states that it does not use customer data to train or fine-tune models without prior permission or instruction. Retention still needs work if you require zero data retention:

• Caching: implicit in-memory caching is on by default for supported Gemini models, scoped to the project and deleted within 24 hours. Disable all caching with a PATCH to the cacheConfig resource setting "disableCache": true (requires roles/aiplatform.admin), or keep in-memory caching and stop durable caching with "retentionType": "EPHEMERAL".
• Feature-specific storage: set store to false for the Interactions API (it defaults to true), do not enable Gemini Live API session resumption, and avoid the Sandbox API, whose snapshots persist for the sandbox TTL. Deep Research and CodeMender sessions keep data for up to seven days.
• Grounding: Grounding with Google Search stores derived queries for up to three days and this cannot be disabled; Google points zero-retention customers to Web Grounding for Enterprise.
• Abuse monitoring: for Google models, prompts may be logged for abuse detection under the Google Cloud Platform Terms of Service. Confirm your contract terms with Google if this matters.

Perimeter, encryption and guardrails

• VPC Service Controls: put AI projects, their Cloud Storage buckets and BigQuery datasets in one perimeter and include aiplatform.googleapis.com and the Agent Identity APIs, routed through restricted.googleapis.com. Agent Runtime may need an ingress rule for its service agent, and Agent Gateway enforces perimeter rules since September 2026. Run new perimeters in dry-run mode first.
• Customer-managed keys: use CMEK where your policy demands it, but check support per feature. Google's security controls page states that data residency, CMEK, VPC Service Controls and Access Transparency are not supported for preview models, CMEK cannot be used with Memory Bank or Sessions on the global endpoint, and Access Transparency and Access Approval are unavailable for Agent Registry configurations.
• Model Armor: apply templates to prompts and responses through the Agent Platform or Agent Gateway integrations, use separate templates for input and output, set organisation-wide floor settings, start in inspect-only mode and move to inspect and block once false positives are understood. Model Armor screens each prompt as a single turn and does not decode encoded content, so it reduces rather than removes prompt injection risk (OWASP LLM01:2025).
• Patching: follow the release notes. In July 2026 Google fixed an SSRF issue in the Agent Studio /api-proxy endpoint and asked customers to regenerate apps created before 1 July.

Rollout order

1. Inventory: list AI projects, endpoints, agents, notebooks and every principal with aiplatform roles, including service agents and their extra grants.
2. Turn on visibility: enable Data Access audit logs for aiplatform.googleapis.com, set budgets and alerts, and route logs to the SIEM before you change any access.
3. Cut standing privilege: remove basic roles, move admin roles to just-in-time, restrict customJobs.create and actAs to pipeline identities. Test in a non-production project and keep the previous IAM policy (exported JSON or Terraform state) to roll back.
4. Move agents off the default service agent: pilot agent identity or dedicated service accounts on one agent, automate grants in Terraform, then migrate the rest.
5. Close the perimeter: VPC Service Controls in dry run, review Policy Denied logs for two to four weeks, then enforce. Roll back by returning the perimeter to dry run.
6. Add guardrails and retention settings: Model Armor in inspect-only, then block; apply cache and storage settings; record exceptions.

Small and large organisations: a small team gets most of the benefit from one AI project with dedicated service accounts and Model Armor floor settings. Large organisations need separate projects per environment inside a perimeter, organisation policy enforcement, and agent grants reviewed as code.

Common misconfigurations

• Granting roles/aiplatform.user project-wide to every developer: it includes prediction on every endpoint, so a leaked developer credential becomes free model access and a spend problem.
• Leaving all agents on the default Reasoning Engine service agent: one role added for one agent's BigQuery tool applies to every agent in the project, which is OWASP LLM06:2025 Excessive Agency at the identity layer.
• Treating custom training as low risk: custom jobs run arbitrary code with a service agent that Google describes as effectively editor-level on other services, so a compromised pipeline account can read data across the project. The Kubeflow cryptomining attacks showed the same pattern on self-managed ML clusters: an exposed interface plus a mounted service account.
• Assuming audit logs already show model use: Data Access logs are off by default, so the first LLMjacking investigation finds only Admin Activity records and billing data.
• Forgetting grants after redeploy or deletion: agent identity creates a new principal on redeploy and leaves inactive bindings on deletion, so manual grants drift and stale ones accumulate.
• Using preview models or features for regulated data: CMEK, VPC Service Controls, data residency and Access Transparency do not apply to preview models, and some features such as Grounding with Google Search retain data that cannot be turned off.

Framework mapping

Practitioner checklist

• Enable Data Access audit logs for aiplatform.googleapis.com in every production AI project and alert on changes to logging configuration.
• Remove basic Owner and Editor roles from AI projects and put aiplatform.admin, agentsAdmin and notebook admin roles behind just-in-time access.
• Restrict aiplatform.customJobs.create and iam.serviceAccounts.actAs to pipeline identities.
• Alert on any service agent role granted to a user, group or user-managed service account.
• Move production agents off the default Reasoning Engine service agent to agent identity or a dedicated service account, with grants managed in Terraform and Principal Access Boundary policies applied.
• Remove inactive bindings after every agent deletion or redeploy.
• Block service account key creation by organisation policy and keep tool credentials in the auth manager or Secret Manager.
• Place AI projects, buckets and datasets in a VPC Service Controls perimeter, tested in dry run first.
• Apply Model Armor templates and floor settings, moving from inspect-only to inspect and block.
• Document caching, storage and grounding settings against your retention requirements, and keep regulated data off preview models.

Standards and references

• Google Cloud: Agent identity overview
• Google Cloud: Agent Platform IAM roles and permissions
• Google Cloud: Managing access for deployed agents
• Google Cloud: Zero data retention
• Google Cloud: Model Armor overview
• Google Cloud: Cloud Audit Logs overview
• Google Cloud: Gemini Enterprise Agent Platform release notes
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Google Cloud Security Guide · Azure OpenAI and Azure AI Foundry Security Guide · Enterprise AI Copilot Security Guide · AI Security Posture Management (AI-SPM) Guide