Securing AI Models and Agent Workloads

Implementing security and privacy controls for AI/ML systems means preventing training data, prompts, and models from leaking or being misused by accident. The control plane combines governance of data flows, encryption of pipelines and storage, and integrity checks on models from collection through training to inference. Training data carries the highest risk for bias and leakage, so minimization, de-identification, lineage, and audit logging apply across the full lifecycle.

1.1Minimize and De-Identify Training Data

Data minimization is the privacy principle of collecting, keeping, and using only data strictly necessary for the business goal. Collecting extra personally identifiable information (PII) increases privacy risk and can create biased models when sensitive attributes enter training. Pipelines preserve utility while reducing exposure with pseudonymization, de-identification, generalization such as bucketing exact values into ranges, and use of synthetic or fully anonymized data where possible.

Minimization also depends on labeling and lifecycle control. A data labeling job adds informative tags to raw data to create structured training data, which reduces ambiguity that can lead to bias. Cloud Storage (opens in a new tab) lifecycle controls limit how long objects stay available, so training datasets, intermediate artifacts, and stored prompts are not exposed longer than needed.

1.2Discover and Protect Sensitive Data with Sensitive Data Protection and Model Armor

Sensitive Data Protection (opens in a new tab) is the Google Cloud service that discovers, classifies, and protects sensitive data in training data, pipelines, and large language model (LLM) interactions. Discovery starts with inspection jobs that scan storage and pipelines at the organization, folder, or project level, and results flow from inspection jobs into BigQuery data profiles and from BigQuery into Knowledge Catalog (opens in a new tab) for central governance. Sensitive Data Protection combined with Model Armor adds data loss prevention for prompts and responses by blocking unauthorized exposure of sensitive data in LLM interactions.

Protection is enforced before training and at serving time. Pipelines run Sensitive Data Protection checks to find PII before it reaches training or inference. At serving time, Model Armor enforces a minimum safety threshold and applies a Sensitive Data Protection DeidentifyTemplate that redacts or masks sensitive information before the response reaches the user, even if the model is compromised. The template reference flows from the Model Armor configuration to the de-identification service to the endpoint response.

1.3Govern AI Data with Knowledge Catalog, Lineage, and Audit Logging

Knowledge Catalog is the organization-wide governance platform that discovers, manages, monitors, and governs data and AI artifacts. Data flows from systems such as BigQuery, Cloud Storage, and Pub/Sub into the catalog for inventory, then flows from the catalog back to engineering teams as governed datasets, feature metadata, and model artifacts. The platform unifies governance across BigLake and open-format tables such as Iceberg and Delta, with integration to Dataproc Metastore for compatibility across engines.

Knowledge Catalog supports governance through related capabilities:

• Manage data lineage, including column-level lineage in BigQuery, to track where data came from and what transformations were applied.
• Manage data quality checks and data profiles, including automatic quality checks and inspection results sent from BigQuery.
• Manage data discovery, exploration, and processing across different data marts.
• Manage feature metadata and model artifacts, with scheduled monitoring of features in Vertex AI Feature Store.
• Create a business glossary with aspects and aspect types to standardize vocabulary.
• Build a data mesh that decentralizes ownership while keeping security and accessibility.

Lineage and quality together help detect poisoning and drift. Validation checks on formats, ranges, and distributions plus anomaly detection in BigQuery help flag training-data anomalies. Differential privacy complements de-identification by adding noise during analysis or training so individual records are hard to identify while overall patterns remain learnable. With SQL in BigQuery, teams build features with differentially private aggregations for counts, sums, and averages over sensitive groups, trading some statistical precision for a stronger guarantee against re-identification in small slices.

1.4Encrypt and Isolate AI Pipelines and Storage

Encryption and isolation for AI pipelines protect stored data with customer-controlled keys and moving data with secure transport. Cloud Key Management Service (Cloud KMS) (opens in a new tab) provides customer-managed encryption keys (CMEKs) used by integrated services including Vertex AI, Cloud Storage, BigQuery, Cloud SQL, and Spanner. Data in transit between clients, pipelines, and AI services is encrypted with HTTPS for all AI and ML API calls, enforced with HTTPS load balancers.

Secure pipelines move data through an ordered flow where each phase inherits classification, encryption, and access policy:

1. Ingestion: Data flows from source systems into Cloud Storage or BigQuery where validation checks formats and distributions, Sensitive Data Protection inspects and de-identifies PII, and data-quality profiles are captured.
2. Processing: Data flows from raw storage through transformation and feature engineering where lineage links raw sources to processed datasets, BigQuery anomaly detection flags outliers, and feature monitors track Feature Store groups.
3. Storage and serving: Data flows from processed datasets to durable buckets, governed lakehouse tables, and Model Registry where lifecycle rules expire temporary data, versioning preserves artifacts, and audit logs record access.

Network controls prevent exfiltration between phases. VPC Service Controls (opens in a new tab) defines a service perimeter around AI resources with ingress and egress rules, validated first in dry-run mode. Firewall policies deny all traffic by default and allow only required ports and sources, while cross-boundary sharing uses BigQuery sharing through Analytics Hub, BigQuery data clean rooms, and authorized views instead of copying raw tables.

Access follows role-based access control with least privilege, granting only the no-access, read-only, or write access needed for the role. Granularity is enforced with IAM roles, IAM policies with conditions, bucket and managed-folder policies, and row-level and column-level security. Enable Data Access audit logs for AI services and storage, stream them to Cloud Logging for real-time alerting, export them to BigQuery for long-term retention, and integrate them with a security information and event management (SIEM) system. Experiment logs must not contain PII or confidential data.

1.5Secure Model Versions and Harden Serving Endpoints

Model security and integrity controls prove that a production model is the exact approved artifact and that attackers cannot tamper with it or extract data from it. Vertex AI Model Registry is the central repository that versions each trained model and links it to metadata needed to audit and redeploy it. A training pipeline writes its output artifact to the registry, and the registry applies the version number so every iteration is distinguishable and retrievable.

Each registered version must carry provenance that connects the model to its inputs and code:

• Training parameters, hyperparameters, and framework or foundation-model details.
• Evaluation metrics from validation pipelines and responsible-AI checks.
• Dataset version used for training, with lineage traced to the catalog entry.
• Code version and serving container definition.

The signing flow runs from build to deployment in a signed to verified to deployed lifecycle. Cloud Build signs the artifact, the signed artifact is stored with its hash and provenance, and verification runs before traffic reaches the new version. Only after verification succeeds does the controller promote the version to serving. Binary Authorization verifies signatures for containerized models before the container runs, while models deployed directly to Vertex AI endpoints require custom hash or signature checks in deployment scripts before promotion.

Hardening defends serving endpoints against inversion and extraction attacks where callers send many varied queries to reconstruct training examples. Reducing memorization starts before training with minimization, pseudonymization, bucketing, and differential privacy. Secure serving places Model Registry and sensitive data inside a VPC Service Controls perimeter, serves inference through private endpoints based on Private Service Connect, fronts public inference with Apigee for validation, authentication, and throttling, and defines strict input and output schemas. Behavioral monitoring flags thousands of slightly different sequential queries, volume spikes from one identity, and geographic anomalies, while rate limiting caps requests per identity and controlled rollout with traffic splitting and automated rollback limits blast radius.

Determining security requirements for IaaS-hosted and PaaS-hosted training models means matching network, hardware, identity, and artifact controls to who manages the training infrastructure. In PaaS managed training Google secures the underlying compute while the customer controls perimeters, keys, and identities around it. In IaaS self-managed training the customer additionally hardens the operating system, cluster, and runtime that hold data and weights.

2.1Isolate PaaS Training with Perimeters and Private Connectivity

PaaS isolation in Vertex AI blocks exfiltration from Google-managed training compute attached to the customer Virtual Private Cloud (VPC). Vertex AI (opens in a new tab) custom training jobs, Vertex AI Pipelines, managed datasets, Model Registry, and Workbench notebooks all run as managed resources that must be attached to the customer VPC. The Vertex AI training project, Cloud Storage training buckets, and related APIs are placed inside the same VPC Service Controls perimeter, and any call that tries to leave the perimeter is denied unless an explicit ingress or egress rule allows it.

For compute isolation, managed training supports private-only communication through a Private Service Connect (PSC) interface and private Internet Protocol (IP) addressing. Traffic flows from the custom training job to Cloud Storage, Vertex AI datasets, and other authorized Google Cloud services through the PSC interface inside the perimeter, and the training workers are not exposed to public traffic. Use dedicated projects or dedicated VPCs to isolate training environments, deny all firewall traffic by default while allowing only required ports and sources, and use Shielded VMs or Confidential Computing when sensitive code and data must be protected during execution.

Choose VPC Service Controls when the risk is copying data to an outside project or service, and choose PSC with private IP when the risk is exposure of the training workers themselves to the internet.

2.2Control Workbench Access and Encrypt PaaS Resources

Workbench control prevents managed notebooks from becoming an exfiltration path through browsers, terminals, or public networking. Harden Vertex AI Workbench networking by blocking public IP addresses, blocking use of the default VPC network, requiring attachment to a designated private VPC subnet, and enabling Private Google Access so notebooks reach Google APIs without internet routes. Access is re-evaluated on every authentication by Access Context Manager combined with Chrome Enterprise Premium and Identity-Aware Proxy (IAP), which enforce context-aware rules based on IP address and device attributes.

Customer-managed encryption keys (CMEK) in Cloud Key Management Service (Cloud KMS) give the customer control over keys that encrypt Vertex AI data at rest, replacing Google-managed defaults for regulated workloads. Keys can be software-based or hardware-backed in Cloud Hardware Security Module (HSM), auto-provisioned with Autokey, or sourced externally with Cloud External Key Manager. CMEK must be enabled per resource type and does not automatically inherit from the bucket to the model, so each layer needs its own key assignment, including Cloud Storage training buckets, Vertex AI datasets and Feature Store, BigQuery tables, models, endpoints, custom jobs, pipelines, ML Metadata stores, TensorBoard resources, Model Registry artifacts, and Workbench disks. Organization policy gcp.restrictNonCmekServices can require CMEK for services such as BigQuery, and detective controls flag any resource missing CMEK.

2.3Harden IaaS Training with Shielded VMs and Confidential Computing

Hardened Infrastructure as a Service (IaaS) training isolates self-managed model training on Compute Engine (opens in a new tab) and Google Kubernetes Engine (GKE) from unauthorized infrastructure access. Isolation starts by placing training in dedicated projects or dedicated VPC networks so traffic flows from training virtual machines (VMs) to storage, logging, and Google Cloud services only through private paths. Organization policies can disable external IP allocation, prevent automatic creation of the default network, restrict resource creation to specific locations, and disable creation of service accounts or keys.

Shielded VMs protect the boot chain of Compute Engine training VMs by authenticating boot components such as the bootloader and kernel during startup. Secure Boot blocks rootkits and bootkits that would otherwise load before the operating system and then steal training data or tamper with model weights. Secure Boot does not apply to all configurations, including GKE instances covered by node-level controls, Compute Engine disks with graphics processing unit (GPU) accelerators that do not use Container-Optimized OS, guest operating systems that do not use Unified Extensible Firmware Interface (UEFI), or Serverless VPC Access resources.

Confidential Computing, implemented as Confidential VMs, protects data while it is in use in system memory. Google Cloud encrypts data at rest and in transit by default, but data in memory is not encrypted by default, so an attacker with host-memory access could undermine confidentiality and integrity during execution. A Confidential VM runs the workload in a trusted execution environment that encrypts memory, so sensitive datasets and intermediate model state remain protected even while training actively uses them.

2.4Secure GKE, Host Access, and Accelerators for Self-Managed Training

GKE hardening isolates containerized training jobs at the node, pod, and network layers. Private nodes remove public IP addresses so inbound traffic flows only from the VPC or authorized private paths, while network policies and pod security controls restrict which pods can communicate and which privileges they can use. Access to applications in the cluster is verified through IAP integrated with GKE Ingress, so only authenticated users with the correct Identity and Access Management (IAM) role reach the endpoint.

Container and host controls further limit blast radius:

• Use trusted and verified container images, scan images with Artifact Analysis, and add GKE Sandbox for kernel-level isolation around pods to contain escapes.
• Place training jobs with different sensitivity levels on separate node pools and require Container-Optimized OS as the node baseline.
• Require OS Login to centralize Secure Shell (SSH) identity, restrict external IPs, prevent IP forwarding so a compromised VM cannot route for another host, and disable nested virtualization with the compute.disableNestedVirtualization constraint.

Remediation for a noncompliant boot configuration follows a fixed order:

1. Create a new node pool with Secure Boot enabled under the corrected Shielded VM settings.
2. Migrate training workloads from the old pool to the new pool until the old pool is empty.
3. Delete the original pool only after migration is complete so no workload remains on untrusted nodes.

Secure accelerator allocation uses the accelerator-optimized machine family to bind specific accelerators to isolated training VMs, with a workload manager such as Slurm scheduling resources across the fleet. Google Kubernetes Engine (GKE) (opens in a new tab) automates cluster management while Compute Engine with Slurm provides maximum control for proprietary intellectual property but requires Slurm and Linux expertise.

2.5Enforce Least-Privilege Identities and Protect Training Artifacts

Least-privilege IAM and artifact protection gives pipelines only the identity, network path, and storage access they need. Cloud Storage (opens in a new tab) training buckets hold input data and checkpoints, BigQuery datasets hold training inputs, and Model Registry holds versioned weights with provenance. A training pipeline service account, for example, reads data from only one specific bucket and writes model artifacts only to Model Registry, but it does not hold export or production-endpoint write rights.

Artifact flow depends on IAM and perimeter checks at every hop. Data flows from the build in Cloud Build to Artifact Registry and then to the training cluster or Cloud Run service. Artifact Registry centralizes custom packages and images, with remote repositories caching external artifacts from Docker Hub, Maven Central, Python Package Index (PyPI), Debian, or CentOS and virtual repositories prioritizing private packages to reduce dependency-confusion risk. Artifact Analysis scans base images and language packages, generates a software bill of materials (SBOM), and accepts Vulnerability Exploitability eXchange (VEX) statements, while Binary Authorization enforces deployment policy so GKE and Cloud Run (opens in a new tab) run only images that pass checks. Enable Cloud Audit Logs for training to record endpoint creation, deployment, and data access, extend lineage with ML Metadata and Knowledge Catalog, and refine grants with IAM Conditions such as requiring a trusted Cloud Build trigger as the request origin.

Implementing security controls for the Gemini Enterprise Agent Platform means protecting agent identities, runtime infrastructure, and AI data as one connected system. The platform governs which users and agents can invoke which agents, tools, and data sources, isolates training and prediction inside private boundaries, and classifies and encrypts data from ingestion through prediction. Google secures the physical infrastructure and platform foundation while the customer configures access, networks, and data controls.

3.1Authorize Agent Interactions with IAM and Service Accounts

Agent authorization uses Identity and Access Management (IAM) as the authorization system for all Google Cloud resources. Human users obtain capabilities through platform roles: the Gemini Enterprise Agent Platform (opens in a new tab) User role (roles/aiplatform.user) grants access to most platform capabilities, while the Administrator role (roles/aiplatform.admin) grants full control of platform resources. Additional setup requires the Service Usage Admin role to enable APIs, the Notebooks Administrator role plus Service Account User role for Workbench instances, and Cloud Storage and Artifact Registry permissions for artifacts.

Agents act with their own identities rather than borrowing broad user permissions. The Identity function manages agent service accounts and their permissions, and Policy Enforcement defines and applies IAM and Model Armor policies to agents. When a Gemini Enterprise app calls a custom agent, the request flows from the app to the agent endpoint using the Discovery Engine Service Agent identity, and the network path and IAM check depend on where the agent is hosted. This separation lets administrators grant an agent only the permissions needed for its specific tools and data sources, even when many agents share one registry.

3.2Enforce Granular Access for Agents, Tools, and Admin Surfaces

Granular enforcement applies least privilege to users, agents, and tool invocations across hosting platforms. For users, IAM roles should be granted to a developer or operator group rather than to individual users, because individual assignments increase management and auditing complexity. Authentication requires accounts managed by Cloud Identity, Google Workspace, or a federated identity provider, hardened with single sign-on, 2-step verification, and enforced password requirements.

For agent-to-agent and app-to-agent calls, authorization depends on the hosting target registered in the discovery service. When a user references @agent_name or the assistant delegates, the app looks up the agent name in the registry to find the Agent Runtime resource URI or Agent-to-Agent (A2A) agent URL, then invokes that endpoint with the Discovery Engine Service Agent identity.

Admin surfaces separate platform policy, application membership, and Workspace data control. Agent Platform is the central console for lifecycle governance including registry, gateway, policy, observability, identity, security, and audit logging. Gemini Enterprise Admin controls licenses, instances, data connectors, attachment to Agent Gateway, and which registry agents and tools are added, including bring-your-own Model Context Protocol (MCP) and A2A agents. The Google Workspace Admin Console controls whether the service is enabled for Workspace users and domain policies on agent data access.

3.3Isolate Agent Infrastructure with Private Networks and Perimeters

Agent infrastructure isolation keeps training and runtime environments inside private network boundaries with controlled paths for required traffic. Isolation mitigates model tampering, protects training data, maintains uptime and compliance, and builds user trust. To obtain isolation, run training on managed services such as Cloud Run, GKE, Managed Service for Apache Spark, or Agent Platform serverless training, and place sensitive training in dedicated projects or VPCs.

Compute hardening and workload separation reduce the blast radius of a compromise. Use Shielded VMs or Confidential Computing to protect sensitive data and code during execution, use trusted images scanned with Artifact Analysis for GKE training, and use GKE Sandbox, workload isolation, Container-Optimized OS, and Cloud Run execution-environment protections to contain escapes. Use Model Registry for versioned, access-controlled artifacts and restrict Model Garden access by role. Training jobs must not be exposed to public traffic: custom jobs communicate privately with authorized services through a Private Service Connect interface, connections use private IP for security and lower latency, and production VMs must not carry public IPs.

Network boundary control combines VPC firewall rules that filter traffic with VPC Service Controls perimeters that contain data movement. Firewall policy starts from deny-all by default and then allows only traffic meeting defined criteria for source, destination, port, and protocol. Data flows from custom training jobs to authorized services through the Private Service Connect interface without traversing the public internet. Data flows from clients inside a VPC to models through private prediction endpoints protected by a VPC Service Controls perimeter, and online prediction uses Private Service Connect for that private access. IAM is not applied directly to the private prediction endpoint; the target service behind the endpoint uses IAM to manage access to the models.

Secure external connectivity encrypts transit and authenticates callers. All AI API calls use HTTPS, HTTPS load balancers enforce encrypted transport, and model APIs fronted by Apigee or API Gateway check API keys, authentication, authorization, and rate limits. Enable VPC Flow Logs and Cloud Audit Logs for endpoint creation, deployment, and configuration updates, verify SSL and HTTPS enforcement, and block high-risk database, directory, management, mail, and remote-access ports except for explicitly approved exceptions.

3.4Govern Agent Data with Classification, Encryption, and Residency Controls

Data governance for agent workflows classifies, encrypts, retains, and confines training data, prompts, and outputs. Sensitive Data Protection (opens in a new tab) discovers, classifies, and de-identifies sensitive data in datasets, prompts, and outputs. Discovery scans Agent Platform datasets at the organization, folder, or project level and writes data profiles to BigQuery, where teams label sensitivity to prevent PII from entering training. For live workloads, Data Loss Prevention filters for Gemini screen prompts and responses and support custom block lists.

When sensitive data must remain usable, transformation preserves utility rather than removing data outright. Pseudonymization replaces identifiers with reversible tokens, de-identification removes or masks PII while keeping analytical structure, and generalization such as bucketing reduces precision by grouping exact ages into ranges. Transformed data then flows from Cloud Storage or BigQuery sources into labeling and training jobs, while logging pipelines hide sensitive values before writing experiment logs. Teams must not log PII in experiments because logs expand the exposure surface.

Cloud Key Management Service (Cloud KMS) (opens in a new tab) provides customer-managed encryption keys that encrypt AI data at rest, while Google still manages the underlying operations. Data flows from the customer-managed key to each integrated service, including Agent Platform, Cloud Storage, BigQuery, Cloud SQL, and Spanner, and each service depends on that key to decrypt data for authorized use. If the key is revoked or destroyed, the dependent data becomes unreadable. Data minimization limits how much data exists by avoiding collection beyond business goals and preferring synthetic data, while Cloud Storage lifecycle controls automatically transition or delete objects after age or version conditions.

The perimeter boundary sits between trusted resources inside and external networks and unauthorized projects outside. Teams include AI resources and sensitive data inside the perimeter, deny firewall traffic by default, keep prediction traffic inside the VPC with Private Service Connect, and share across privacy boundaries only through governed frameworks such as BigQuery sharing, data clean rooms, and Looker Action Hub rather than open export.

3.5Monitor Agent Behavior with Logging and Threat Detection

Monitoring for agent interactions combines platform audit logs, workload telemetry, and data-access transparency. Audit Logging in Agent Platform tracks administrative changes and access events, and Gemini Enterprise supports audit logging plus Access Transparency for visibility into Google access. The Cloud Observability suite of Cloud Trace, Cloud Logging, Cloud Monitoring, and Topology collects traces, logs, and metrics by default for agents deployed with the Agent Development Kit (ADK), using OpenTelemetry protocols to collect execution paths, events and errors, and latency and token usage from Agent Platform, Agent Gateway, and Model Armor.

This unified telemetry supports forensic analysis across systems. Traces show the full path from user chat to Gemini Enterprise app to registry lookup to tool invocation, logs record failures and policy decisions, and metrics expose cost and performance anomalies. Knowledge Catalog (opens in a new tab) centrally discovers and governs data and AI artifacts with lineage, quality checks, discovery, feature metadata, and business glossary, while ML Metadata logs sources and transformations and Model Registry versions each model. Google Workspace Audit Logging records agent interactions with Workspace data, and analysis with Observability Analytics shows who accessed or modified data and models and when.

Threat detection depends on Security Command Center (opens in a new tab) integration and control of federation administration. The Security function integrates findings with Security Command Center so anomalous activity and misconfigurations surface alongside other cloud findings, and Compliance Manager can audit against frameworks such as FedRAMP. The IAM Workforce Identity Pool Admin and Workforce Pool Editor roles can modify attribute mappings where an incorrect change enables impersonation, so they must be granted only to trusted administrators through Privileged Access Manager entitlements and monitored through federated audit logs integrated into a SIEM.

Key Facts

• Sensitive Data Protection discovers PII before training, while Model Armor with a Sensitive Data Protection DeidentifyTemplate redacts sensitive data from endpoint responses even if the model is compromised.
• Vertex AI Model Registry versions each model with provenance linking training parameters, dataset version, code version, and evaluation metrics, and Binary Authorization verifies signatures for containerized models before they run.
• VPC Service Controls creates a service perimeter around Vertex AI APIs, training jobs, and storage that denies data movement outside except through configured ingress and egress rules, while Private Service Connect with private IP keeps training traffic off the public internet.
• Shielded VMs with Secure Boot verify boot integrity against rootkits and bootkits, while Confidential VMs encrypt data in use in memory.
• Custom agents invoked with the Discovery Engine Service Agent require Cloud Run Invoker for Cloud Run targets but no extra invoker grant for Agent Runtime targets, and only Gemini Enterprise Agent Platform supports all four controls of data residency at rest, CMEK, VPC-SC, and Access Transparency.