Prototyping Models with Cloud Notebooks

Collaborative and secure notebook development on Google Cloud separates per-user experimentation from governed promotion to production. Traffic flows from the notebook environment to BigQuery (opens in a new tab), Cloud Storage, Vertex AI Feature Store, and Vertex AI training and serving services, with Identity and Access Management (IAM), Virtual Private Cloud (VPC), and VPC Service Controls checking every hop. Vertex AI Workbench (opens in a new tab) provides per-user development instances, Colab Enterprise (opens in a new tab) provides a managed collaborative option, and Vertex ML Metadata, Git, container images, Cloud Build, and Vertex AI Pipelines connect prototyping to tracked deployment.

1.1Notebook Options and Team Workspace Isolation

Notebook environment options divide by control versus managed collaboration. Vertex AI Workbench instances (opens in a new tab) are user-managed environments for writing code, starting jobs, running queries, and checking status with direct access to Google Cloud data and AI services. Colab Enterprise is a collaborative managed notebook environment that inherits Google Cloud security and compliance controls.

Team isolation starts with a Workbench instance for each data scientist, treated as a virtual workspace. When one person works on multiple projects with different dependencies, each project gets its own instance, and instances are stopped when idle to control cost and reduce attack surface. The simplest access boundary stores raw data and Vertex AI datasets and models in the same Google Cloud project, while multi-project designs use IAM for corporate cross-project access control. The notebook identity depends on its attached service account and VPC configuration, so cross-project data access is governed by IAM rather than by copying data into the notebook.

1.2Shared Standards, Experiment Tracking, and Lineage

Shared development standards keep isolated workspaces compatible from notebook to pipeline. Teams use the Vertex AI SDK for Python for end-to-end workflows across PyTorch, TensorFlow, XGBoost, and scikit-learn, so notebook code calls the same dataset, training, and endpoint objects that pipelines will call later. Vertex AI TensorBoard tracks and compares experiment metrics such as loss and accuracy over time, visualizes model graphs, and projects embeddings, while Vertex AI Experiments links parameters, metrics, and dataset and model artifacts through Vertex ML Metadata. Small datasets can train inside the Workbench instance, but scheduled training or training on new data arrivals moves to Vertex AI managed training even for small data to make the run repeatable.

Version control and lineage make notebook work auditable from data source to deployed model. Vertex ML Metadata records data sources, transformations, model parameters, and experiment results with encryption at rest, Git versions notebook code and pipeline definitions, and continuous integration and continuous delivery (CI/CD) pipelines automate change tracking from commit to deployment. Lineage operates at complementary scopes:

• Vertex ML Metadata tracks the full MLOps run across data preparation, training, evaluation, and deployment.
• Knowledge Catalog, formerly Dataplex Catalog, tracks lineage of individual Vertex AI Pipelines artifacts for debugging and root-cause analysis.
• Model Registry versions each stored model so a versioned model points back to its metadata lineage.
• Cloud Audit Logs for Vertex AI track API calls and administrative actions, showing who accessed or modified data and models and when.

1.3Reproducible Containers and CI/CD Promotion to Pipelines

Reproducible notebook environments depend on containerized kernels and images rather than manually installed libraries. A Vertex AI Workbench instance associates software through a container, so network and IAM customize the Google Cloud properties while the container pins Python packages, system libraries, and framework versions. Feature engineering, training or fine-tuning, and inference each use a separate container when they require different dependencies, which lets engineers control each stage independently. Custom packages and vetted dependencies are stored in a private Artifact Registry repository, Artifact Analysis scans images for known vulnerabilities, and only approved library versions move forward.

CI/CD promotion moves tested notebook code into Vertex AI Pipelines through Cloud Build with security enforced at each handoff. Vertex AI Pipelines acts as the central orchestrator for modular components that process data, train, evaluate, and deploy, with pipeline definitions written as versioned code with the Kubeflow Pipelines (KFP) SDK or TensorFlow Extended (TFX) SDK. An automated promotion flow preserves order and traceability:

1. Source commit: A Git commit triggers a Cloud Build job, so change tracking starts the workflow.
2. Build and scan: Cloud Build builds the container image, Artifact Analysis scans dependencies, and Binary Authorization enforces policy so deployment proceeds only after images pass checks.
3. Pipeline execution: Vertex AI Pipelines runs versioned components with automated parameterization and version history.
4. Evaluation gate: Re-execution performs explainability and responsible AI checks before deployment, detecting unauthorized changes or misconfigured serving.
5. Versioned registration: Successful models register as new versions in Model Registry with signatures and build provenance.

The pipeline depends on least-privilege execution identities and network boundaries. Dedicated service accounts grant only minimum permissions, such as read from one Cloud Storage bucket and write to Model Registry, and IAM Conditions add attribute-based control so a service account can trigger a pipeline only when the request originates from a trusted Cloud Build trigger.

1.4Notebook Identity, Access Controls, and Network Perimeters

IAM for notebook resources separates human access from workload access. Every user receives only minimum permissions such as no-access, read-only, or write, while a separate notebook service account is the workload identity that code uses to call Vertex AI, read training data, and write artifacts. Teams create dedicated least-privilege service accounts for each workload and restrict downloaded service account keys because key material persists in configuration files and repositories where it can be copied. Production controls block key creation with the constraints/iam.disableServiceAccountKeyCreation organization policy and require audit logging for Vertex AI.

User permissions combine IAM roles with layered limits that can deny a request even when a role would allow it. IAM Conditions add attribute-based rules for granular access to data and model configurations, while principal access boundary (PAB) policies limit resources a principal can reach, Privileged Access Manager provides just-in-time elevation, Identity-Aware Proxy (IAP) restricts access by IP and device, and Access Context Manager with Chrome Enterprise Premium evaluates context on each authentication to Workbench. Application-level granularity differs by data plane:

Network controls place a trust boundary around Vertex AI and data APIs so credentials outside the boundary cannot exfiltrate data. VPC Service Controls defines a service perimeter around AI resources and sensitive data, includes Vertex AI and storage APIs in that perimeter, and controls data flow with ingress and egress rules. Teams use private IP addresses for training and notebook-adjacent compute, Private Service Connect for private communication between custom jobs and other Google Cloud services, dedicated projects or VPCs, deny-all firewall policies, and hardened hosts with Shielded VM or Confidential Computing and disabled public IPs.

1.5Data Encryption, Loss Prevention, and Governed Access

Data governance in notebook environments combines encryption, loss prevention, classification, and auditing. Data flows from ingestion sources such as Cloud Storage or Pub/Sub through a Dataflow de-identification pipeline into BigQuery, while Knowledge Catalog governs lineage and quality and Cloud Logging and Cloud Audit Logs record access. VPC Service Controls perimeters, firewall rules, and customer-managed keys enclose that flow so notebooks explore trusted data without exposing sensitive values.

Encryption starts with default Google encryption and adds customer control with customer-managed encryption keys (CMEKs) in Cloud Key Management Service (Cloud KMS). CMEK-integrated services encrypt data at rest on behalf of the notebook workload, while HTTPS protects API calls in transit. The CMEK must be in the same location as the protected resource, rotates by default every 30 days, and can be enforced with the gcp.restrictNonCmekServices organization policy. Integrated services include Gemini Enterprise Agent Platform for training artifacts and workbench resources, Cloud Storage, BigQuery, Cloud SQL, and Spanner. For stronger control, keys can be HSM-protected with Cloud HSM or held outside Google Cloud with Cloud External Key Manager (Cloud EKM).

Sensitive Data Protection, formerly Cloud DLP, provides discovery, classification, and de-identification before notebooks read data. Data profiler scans BigQuery tables and writes profiles with predicted information types, risk, and sensitivity levels, while de-identification runs in Dataflow to tokenize confidential fields before loading into BigQuery. Loss prevention also applies to operations: notebooks must not log personally identifiable information (PII) in experiment logs, and Cloud Storage lifecycle controls limit prolonged retention of staged data. BigQuery column-level security then hides tagged columns unless explicitly granted, requiring both IAM on the table and Data Catalog policy tags on the column. The secured-warehouse taxonomy creates a hierarchy where higher access implies lower access: 3_Confidential for data such as credit card numbers, 2_Private for sensitive PII such as first name, and 1_Sensitive for non-public data such as credit limit. Dynamic data masking applies a masking rule at query runtime, while column-level encryption with authenticated encryption with associated data (AEAD) creates dual-access control because the user needs permission to both the table and the encryption key.

Framework development in cloud notebooks moves from interactive prototyping to repeatable managed training and serving. A prototype starts in a Vertex AI Workbench (opens in a new tab) instance or Colab Enterprise notebook using PyTorch, scikit-learn, and JAX through the Vertex AI SDK for Python, then moves to managed training and orchestration. Data flows from BigQuery (opens in a new tab) for structured data and from Cloud Storage for unstructured data into the training loop, and artifacts flow from the notebook to Cloud Storage, Vertex AI Model Registry, and Vertex AI Endpoints.

2.1Prototype Code and Managed Custom Training Jobs

Vertex AI Custom Training is the managed service, delivered through the Gemini Enterprise Agent Platform Managed Training service, that runs modular training code outside the notebook on Google Cloud infrastructure. Vertex AI Workbench instances are recommended for experimentation and development, including writing code, starting jobs, running queries, and checking status. Training inside the Workbench instance is sufficient for small datasets or subsets of a larger dataset, while the training service is needed for larger datasets or distributed training.

The same Managed Training service is also recommended to productionize training even on small datasets when training runs on a schedule or in response to new data arrival. In practice, data flows from BigQuery or Cloud Storage into the training job, and the trained artifact flows from the job to the Model Registry. The Vertex AI SDK for Python supports this move because it provides an end-to-end workflow that works with PyTorch, TensorFlow, XGBoost, and scikit-learn from the same notebook code that launches jobs.

2.2Experiment Tracking with Experiments and TensorBoard

Vertex AI Experiments is the system for logging and linking parameters, metrics, and dataset and model artifacts across many training runs. Vertex AI Experiments integrates with Vertex ML Metadata to build lineage that connects which dataset, hyperparameter set, and code produced which metrics and which model artifact. When architectures, input datasets, hyperparameters, and hardware vary, Experiments preserves the comparison through aggregate metrics such as accuracy, precision, and recall on test datasets.

Vertex AI TensorBoard is the managed visualization service for analyzing those tracked experiments. Vertex AI TensorBoard enables tracking experiment metrics like loss and accuracy over time, visualizing the model graph, projecting embeddings to a lower dimensional space, and comparing runs by hyperparameters. Together, Experiments provides the governed record of what was tried and what was produced, while TensorBoard provides the visual comparison of how each run behaved, which lets teams track, compare, and share results securely. Hyperparameter tuning extends this loop through Vertex AI Vizier, which tests different configurations on Google Cloud processing infrastructure to maximize predictive accuracy and returns optimal values based on the target metric.

2.3Modular Pipelines and Governed Model Registry

Vertex AI Pipelines is the managed orchestration service that automates every step of the ML lifecycle from data preparation to model training, evaluation, and deployment. A pipeline moves artifacts through an ordered sequence where output from one step becomes input to the next:

1. Data preparation: Data flows from source systems into BigQuery or Cloud Storage and through preprocessing into training-ready datasets.
2. Training and tuning: The packaged PyTorch, scikit-learn, or JAX module runs as a Custom Training or tuning step on managed compute.
3. Evaluation: Metrics and explanations flow from the trained model into evaluation against test data and business criteria.
4. Deployment preparation: The validated model artifact flows to the Model Registry for versioning and release.

Vertex AI Pipelines supports scheduled runs for recurring retraining, execution metrics for monitoring workflow runs, and reusable templates for standardized workflows across projects. This orchestration reduces manual effort and enables continuous training where new data automatically triggers retraining through integration with Cloud Build and BigQuery analysis.

Vertex AI Model Registry is the governed store for trained framework artifacts where teams organize, track, and version models. The Model Registry receives the model artifact from a Custom Training job or pipeline run, then preserves its version history and its linkage back to Experiments and Vertex ML Metadata. From the Model Registry, teams can evaluate models, deploy models to an endpoint, create batch predictions, and view details about specific model versions. This registry boundary separates experimentation from production: notebooks and jobs produce candidate artifacts, while the registry controls which version is approved, deployed, and monitored.

2.4Framework Runtimes, Accelerators, and Capacity Planning

Configuring framework runtimes means binding a notebook runtime to the compute profile required by the model. Notebook runtimes run on central processing unit (CPU) virtual machine (VM) types, graphics processing unit (GPU) types, and tensor processing unit (TPU) capacity, and the same selection logic applies when a prototype moves to custom training or prediction. Because inference and training demand different ratios of CPU, memory, GPU throughput, and TPU throughput, historical GPU or TPU utilization and throughput rates are used to forecast future demand and to justify quota increases before production scale.

Proactive resource management uses telemetry to anticipate requirements for high-demand GPUs and TPUs. Telemetry flows from the runtime to Cloud Monitoring and Cloud Logging, then to analysis in BigQuery or Data Studio for forecasting demand based on growth or new models. Capacity estimates are validated through load testing that simulates traffic with tools such as Apache JMeter or LoadView. Behavior under stress is tracked with latency from request to response, throughput including model queries per second (QPS) and token throughput, errors during overload, and GPU and TPU utilization showing headroom or saturation.

Optimizing availability and obtainability means matching workload stability to the correct purchasing and scheduling control:

Cluster Director manages accelerator groups with colocation for multi-GPU training, Ray on Vertex AI abstracts distributed infrastructure so applications request resources without managing VMs, and vLLM dynamically uses TPUs and GPUs to address fluctuating inference needs.

2.5Enterprise Data Paths and Production Serving Transition

Enterprise data integration separates operational sources from ML-optimized storage before training begins. Structured data is extracted into BigQuery, including intermediate processed tables, while image, video, audio, and unstructured data is stored in Cloud Storage buckets and directories. The notebook reads training data through high-throughput APIs rather than querying operational systems directly, which preserves production performance. Access depends on workload-specific service accounts, VPC networks and VPC Service Controls, and separate development, staging, and production projects. For feature reuse, Vertex AI Feature Store centralizes features with BigQuery as the offline source and an online store plus feature views for low-latency serving.

Data loading throughput is determined by storage format, file sizing, and the framework reader. For maximum training speed, materialized BigQuery tables are preferred over views or subqueries, and data is read through the BigQuery Storage API. For Cloud Storage, many small media files are combined into large container formats because large sequential reads increase throughput.

Unstructured data follows a parallel split where TensorFlow uses sharded TFRecord files and other frameworks use Avro files, grouped by buckets and directories with a target of at least 100 MB per file and between 100 and 10,000 shards per dataset. When preprocessing exceeds notebook memory, Dataflow with Apache Beam converts unstructured data to binary formats, Managed Service for Apache Spark handles existing Spark codebases, and BigQuery transformations (opens in a new tab) provide the most cost-effective preprocessing for tabular data.

The production transition moves the prototype artifact to managed serving in order:

1. Save model locally: Save the trained model to a local notebook directory such as ./model/.
2. Stage to Cloud Storage: Upload model files to a Cloud Storage bucket directory.
3. Upload to Model Registry: Create a model resource pointing to the Cloud Storage artifact URI with a serving container image.
4. Create Endpoint: Create a Vertex AI Endpoint resource in the target project and location.
5. Deploy to Endpoint: Deploy the registered model with a selected machine type, which runs as a long-running operation that can take more than five minutes.

Connecting and scaling that endpoint controls latency and resilience. Traffic flows from the prediction client to the model server, and Vertex AI private endpoints create a peer-to-peer connection when the application and serving binary are in the same local network, keeping traffic inside VPC instead of internet routing. Online prediction turns on automatic scaling by setting minimum and maximum nodes, with a minimum of two nodes supporting high availability. For fluctuating demand, GKE Inference Gateway places models behind a load balancer with model-aware routing so traffic distributes across instances.

Vertex AI Model Garden is the central catalog for discovering, evaluating, and prototyping with foundation models inside Google Cloud. Model Garden aggregates first-party Google models, third-party partner models, and open-source models in one searchable inventory, and each listing exposes its modalities, license terms, deployment options, and notebook-ready sample code. Prototyping happens by opening a model card and launching it directly into Vertex AI Workbench or Colab Enterprise, where the notebook inherits the project identity, dependencies, and Vertex AI SDK access needed to test prompts and APIs.

3.1Model Categories and Baseline Selection

First-party, third-party, and open-source model categories organize Model Garden by publisher and operating model, which determines support, tuning, and deployment control. First-party models are Google-built models such as Gemini for text, code, reasoning, and multimodal work, plus Imagen for images and Veo for video, and they are served as fully managed APIs with enterprise support. Third-party models are commercial partner models such as Anthropic Claude, Meta Llama, Mistral AI, and AI21, curated as managed APIs or deployable weights with publisher-defined terms. Open-source models are community weights such as Llama, Mistral, Gemma, and Falcon variants that can be previewed in the catalog and then deployed to a dedicated Vertex AI Endpoint for full control over serving, scaling, and fine-tuning.

Baseline selection balances capability, license, and hardware against business constraints. The selection starts from the model card, flows into a managed notebook where prompts and evaluation datasets run against candidate APIs, and ends with a documented choice of one managed baseline plus one deployable challenger when customization is in scope. Notebook code calls all three categories through the same Vertex AI SDK patterns, so a prototype can swap baselines without rewriting the surrounding data pipeline. Choose Gemini when the workload needs broad multimodality, long context, and native integration with Vertex AI Search and grounding; choose third-party models when evaluation shows a measurable advantage that justifies separate terms; choose open-source models when the solution requires VPC-contained serving, weight-level auditing, or fine-tuning on proprietary data.

3.2Modalities, Licensing, and Hardware Footprint

Modality defines what a model accepts as input and produces as output, and Model Garden exposes this on every model card as text, code, image, audio, video, or multimodal combinations. A Gemini multimodal model accepts interleaved text, images, audio, and video and returns text or code, while Imagen and Veo specialize in text-to-image and text-to-video generation. Effective baseline evaluation in a notebook follows an ordered comparison:

1. Define the task metric: Establish accuracy, latency, cost per 1K tokens, and safety thresholds before testing any model.
2. Prompt the managed API: Send representative prompts from Workbench or Colab Enterprise to first-party and third-party APIs to measure zero-shot and few-shot quality without provisioning hardware.
3. Stress modality limits: Test long context, multi-image reasoning, audio length, and structured output at production input sizes.
4. Compare against tunable baselines: Deploy one or two open-source candidates only after managed APIs establish the quality bar.

Licensing determines whether outputs and weights can be used commercially, redistributed, or fine-tuned. First-party and third-party managed APIs are consumed under Google Cloud terms and publisher policies, where payment is per API call or per generated token and no weight redistribution occurs. Open-source models carry their own licenses, from permissive Apache 2.0 to community licenses such as Llama Community License and Gemma Terms of Use, which may restrict redistribution or limit use by very large platforms. Choose a managed API when the priority is speed to prototype and pay-as-you-go cost; choose an open-source deployable model when the priority is weight inspection, on-tenant serving, or avoiding per-token fees at high volume, accepting ownership of monitoring and scaling.

Hardware constraints apply differently to APIs and self-deployed weights. Managed APIs hide accelerators entirely, exposing only quotas, rate limits, regions, and context-window tiers. Open-source deployments expose the full footprint, where model size determines minimum accelerator memory, replica count, and quantization strategy. A large dense model requires multiple high-memory GPUs such as NVIDIA A100 80GB or H100 instances and scales by adding replicas, while a smaller or quantized model fits on a single L4 or T4 GPU, starts faster, and costs less per hour. The notebook prototype must record tokens per second, time to first token, concurrent request behavior, and GPU utilization, because a model that wins on quality but exceeds latency or cost budget is not viable.

3.3SDK Experimentation and Agent Identity Access

Notebook integration with SDK-based experimentation lets managed notebook code query Google Cloud APIs and deploy prototypes without managing service account keys. The runtime uses Agent Identity to supply credentials automatically, so the flow runs from the runtime to the metadata server to the client library to the Google Cloud service. The metadata server issues a short-lived token, the client library attaches the token to API calls, and Google Cloud authorizes the calls with IAM. Agent Identity authentication (opens in a new tab) lets the same notebook or agent code work across environments without credential files.

Granting agent access means binding an IAM role to the agent identity at the scope of a single agent, a project, or an organization. The binding connects a principal identifier to a target resource defined by service and resource name, such as storage with a bucket name or BigQuery with a dataset ID. The three principal scopes differ by identifier format and blast radius:

Choose a single-agent principal when least privilege matters, and choose a project or organization principal set only when all agents in that container require the same role. Referencing Agent Identity in code means letting Application Default Credentials resolve to the agent token instead of hard-coding credentials. For example, a tool built with the Agent Development Kit (ADK) creates a Cloud Vision API client with retrieved credentials, builds an image object from a Cloud Storage URI, and calls label detection, with the response flowing back as success with label descriptions or failure with an error message.

3.4Prototype Deployment with Secure Runtime Identity

Parameter-efficient tuning and prototype endpoint deployment takes a notebook-developed prototype, including approaches such as LoRA and PEFT, and deploys it directly to a managed runtime for validation. The deployment path runs from notebook code through the Vertex AI SDK to an Agent Runtime instance, where Agent Identity provides a system-attested principal for calling Google Cloud services. The notebook initializes a vertexai.Client with project, location, and api_version="v1beta1" for Agent Identity support, wraps framework code such as an ADK agent in AdkApp, and calls client.agent_engines.create() with identity type set to Agent Identity plus requirements and staging bucket.

Deploying with Agent Identity enabled activates the identity binding in a fixed order:

1. Initialize the Vertex AI client: Create vertexai.Client with project, location, and http_options set to api_version="v1beta1".
2. Wrap the agent: Wrap the framework agent in AdkApp so the runtime can invoke it.
3. Create with identity type: Call client.agent_engines.create with identity type set to Agent Identity and requirements including google-cloud-aiplatform[agent_engines,adk].

An identity can be provisioned before code is ready to allow IAM setup before validation, then code is added later with an update call. Lightweight tooling sets the same flag: the Agents CLI deploys with an agent-identity option, and ADK deployment uses a configuration file containing identity type before running deploy. Agent Identity itself is a SPIFFE-based principal with format principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME, where the trust domain is auto-provisioned when the Agent Platform API is enabled and the namespace and agent name are immutable resource paths.

Securing prototype endpoints with Context-Aware Access applies the default Google-managed policy that makes credentials unreplayable outside their intended runtime. The policy enforces Demonstrating Proof of Possession (DPoP) for the agent access token beyond the Agent Gateway and requires mutual Transport Layer Security (mTLS) to access the gateway. Certificate-bound tokens can then be used only from their intended trusted runtime, such as a Cloud Run container, which protects against credential theft and account takeover. Opting out removes token binding and leaves short-lived tokens vulnerable to theft or replay, so it is reserved for rare token-sharing, header-injection, or unrecoverable 401 UNAUTHENTICATED cases by setting GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES to False.

3.5Prototype Interface Access Through Component Gateway

Component Gateway provides secure browser and API access to web interfaces on the first master node without SSH tunnels or inbound firewall changes. When Component Gateway is enabled, the platform adds Apache Knox and Inverting Proxy to the cluster first master node to proxy a specific subset of services. Component Gateway serves default and optional component interfaces and REST APIs such as Hadoop YARN, Apache Livy, and history servers, but it does not proxy arbitrary node:port addresses, which still require an SSH SOCKS proxy. Users must hold the dataproc.clusters.use permission to open the proxied interfaces.

A Component Gateway-enabled cluster is created through the console, gcloud CLI, API, or Terraform with the same effect. The console path uses this ordered workflow:

1. Open creation: Open the Create cluster page in the Google Cloud console.
2. Expand options: Open Additional configuration, then edit Optional components.
3. Enable gateway: Select the Enable components checkbox to enable Component Gateway.
4. Save options: Save the optional-component configuration.
5. Create: Configure remaining settings and create the cluster.

The equivalent programmatic controls are the enable-component-gateway flag, the enable HTTP port access endpoint setting, and the Terraform endpoint configuration block. The default Knox Gateway SSL certificate is valid for 13 months from cluster creation, and all Component Gateway URLs become inactive after expiry until the certificate is regenerated.

Key Facts

• Vertex AI Workbench provides per-user customizable notebook instances while Colab Enterprise provides a managed collaborative notebook environment with Google Cloud security and compliance controls.
• Training inside a Workbench instance fits small datasets or subsets, while managed Custom Training is required for larger datasets, distributed training, scheduled runs, or retraining on new data arrival.
• Vertex AI Experiments integrates with Vertex ML Metadata to link datasets, hyperparameters, code, metrics, and model artifacts, while Vertex AI TensorBoard visualizes loss, accuracy, model graphs, and embeddings.
• BigQuery column-level security requires both IAM on the table and policy tags on the column, with hierarchical access across 3_Confidential, 2_Private, and 1_Sensitive classifications.
• Agent Identity is a SPIFFE-based principal that lets Agent Runtime code authenticate to Google Cloud services without keys, secured by default Context-Aware Access with Demonstrating Proof of Possession (DPoP) and mutual Transport Layer Security (mTLS).