Prepare and test your skills
Prepare and test your skills
Enforce Network Security and Model Governance Controls to Halt Exfiltration is the layered defense that stops model weights and training data from leaving authorized boundaries. VPC Service Controls (opens in a new tab) blocks cross-perimeter data movement, Identity and Access Management (IAM) (opens in a new tab) decides which identity can use which endpoint or dataset, customer-managed encryption keys control readability, and audit logs record who moved what. Together these controls protect Vertex AI endpoints, Model Registry, BigQuery, and Cloud Storage against theft, model inversion, and unauthorized transfer.
VPC Service Controls perimeters are service boundaries that enclose Vertex AI and data services inside a Virtual Private Cloud (VPC). The perimeter includes Vertex AI endpoints, datasets, pipelines, Model Registry, plus BigQuery and Cloud Storage, so API calls and data flows from inside the perimeter to an external project or the public internet are denied by default. Data flows from a training job or prediction endpoint to the outside only when an explicit ingress or egress rule allows it, which stops exfiltration even when an identity has valid credentials. Always validate a new perimeter in dry run mode before enforcement, because dry run logs what would be blocked without breaking legitimate pipeline or serving traffic.
Private connectivity is the network design that keeps model traffic off the public internet by moving it through private paths. Private Service Connect (opens in a new tab) provides private endpoints that enable access to Vertex AI models from within a VPC network, and custom training jobs can use a Private Service Connect interface plus a private IP address to communicate privately with other authorized Google Cloud services. IAM is not directly applied to the private endpoint itself, but the target Vertex AI service uses IAM to manage access to the underlying model, so network reachability and identity authorization remain separate checks. Firewall rules add a second network layer by denying all traffic by default and explicitly allowing only required ports, protocols, and sources for AI resources.
To secure serving traffic at the application layer, front inference endpoints with Apigee for enterprise-grade security and governance or API Gateway for straightforward authentication. Apigee and API Gateway enforce API keys, authentication, authorization, and rate limiting and throttling, which controls request volume from a single IP address or user. Rate limiting matters for model governance because a sudden spike in query volume or thousands of slightly different sequential queries can indicate denial-of-service, model theft, or model inversion probing to reverse-engineer weights or recover training data.
Exam tip: A Vertex AI private endpoint controls network reachability inside the VPC, while IAM on the target Vertex AI service controls which identity can use the model — both must allow the request.
Fine-grained IAM roles are least-privilege grants that give each human, service account, and pipeline only the permissions it needs on specific Vertex AI endpoints, datasets, pipelines, and Model Garden models. Create dedicated service accounts for MLOps pipelines, for example a training pipeline service account that can read data from only one Cloud Storage bucket and write model artifacts only to Model Registry. Use IAM Conditions to enforce conditional, attribute-based access control, such as allowing a service account to trigger a Vertex AI pipeline only if the request originates from a trusted Cloud Build trigger.
Additional IAM and context controls narrow access further around sensitive AI data:
Encryption control with customer-managed encryption keys (CMEKs) gives the organization control over the keys that encrypt AI data at rest in Cloud Key Management Service (Cloud KMS) (opens in a new tab). When CMEKs are used, CMEK-integrated services encrypt stored data for Vertex AI datasets, models, metadata stores, Feature Store, and endpoints, plus Cloud Storage, BigQuery, Cloud SQL, and Spanner. Key revocation or destruction then breaks decryption across Vertex AI artifacts, pipelines, and data stores, which halts further use of exfiltrated ciphertext. For Cloud Storage, use server-side encryption to store CMEKs so keys and associated data stay protected even if an externally managed key store is compromised.
Encryption in transit protects prediction and management traffic between clients, load balancers, and AI APIs. Use HTTPS for all API calls to AI and ML services and enforce HTTPS with HTTPS load balancers. This ensures training features, prompts, and prediction responses flow over encrypted channels rather than cleartext, reducing interception and session hijacking that can lead to data leakage.
Audit logging and detection is the observability layer that records Vertex AI actions and flags post-authentication anomalies. Cloud Audit Logs (opens in a new tab) provides Admin Activity audit logs that are enabled by default and record endpoint creation, model deployment, and configuration updates. Data Access audit logs record every read and write operation, including who accessed or modified data and models and when, but they must be explicitly enabled for Vertex AI and for stores such as BigQuery, Cloud Storage, Cloud SQL, AlloyDB, Firestore, Spanner, and Bigtable. Enable Data Access logging for Vertex AI at the organization or project level, then analyze logs with Observability Analytics and route logs to long-term or third-party destinations for investigation.
Detection depends on baselining normal access and alerting on anomalies that bypass network and IAM checks. Configure alerts in Cloud Logging for abnormal query patterns that do not reflect normal user behavior, sudden spikes in request volume from one user or IP, and geographic and temporal anomalies such as a massive spike in logins from a new country at 3 AM. Feed Vertex AI Model Monitoring drift and skew signals, endpoint traffic metrics, and audit findings back into retraining, access review, and perimeter rule updates, so a suspected inversion probe or unauthorized transfer triggers throttling, key rotation, or perimeter tightening before weights or sensitive data leave the boundary.
Prevent Sensitive Data Exposure Using Cloud Data Protection Tools is the practice of ensuring personally identifiable information (PII) and confidential enterprise data never leak into or out of foundation models. Sensitive Data Protection (opens in a new tab) provides discovery, classification, and de-identification, while Model Armor (opens in a new tab) enforces those controls on prompts and responses at the model boundary. Together they form a preprocessing filter before the model and a postprocessing filter after the model.
Data minimization is the practice of not collecting, keeping, or using data that is not strictly necessary for the business goal. For AI workloads, minimization means preferring synthetic or fully anonymized data for training and evaluation, and de-identifying any operational dataset that must retain utility. De-identification preserves analytical value while removing direct identifiers, so a model can learn patterns without learning identities.
Sensitive Data Protection implements minimization through transformation methods that replace or generalize sensitive values:
Choose de-identification when training data, retrieval context, or logging pipelines must flow toward foundation models but must not carry raw PII or intellectual property.
Discovery and classification is the continuous process where Sensitive Data Protection inspects stored data, labels what it finds, and publishes those results for governance. Inspection jobs scan sources such as BigQuery tables, Cloud Storage objects, and training datasets to discover, classify, and protect sensitive data including PII and intellectual property. The findings then flow from Sensitive Data Protection into Knowledge Catalog (opens in a new tab) as inspection-result aspects, where data lineage, data profiles, and business metadata make the exposure visible to owners.
Knowledge Catalog centralizes that visibility by linking a raw source to its processed datasets, feature metadata, and model artifacts. BigQuery can also provide column-level lineage, so a sensitive column found by inspection can be traced forward to the dataset version used for training. This traceability lets teams audit data access, detect unauthorized access attempts, and prevent unwanted access before poisoned or sensitive data enters a pipeline.
Prompt and response screening is the inline enforcement where untrusted text is checked on entry to the model and rechecked on exit from the model. Preprocessing screening validates and sanitizes user inputs, retrieved documents, and tool outputs before they reach the foundation model, blocking prompt injection payloads and stripping PII that would otherwise be memorized or logged. Postprocessing screening validates generated outputs before they reach the user, redacting secrets the model repeated, inferred, or hallucinated from its context.
An expert deployment chains both checkpoints into one ordered data flow:
DeidentifyTemplate, which redacts or masks any sensitive data before release.| Protection point | Direction of flow | Risk blocked |
|---|---|---|
| Preprocessing on prompts | User and retrieval data flows into Model Armor and then into the foundation model | PII, credentials, and intellectual property leaking into prompts, training logs, or retrieval stores |
| Postprocessing on responses | Model output flows through Model Armor de-identification and then to the user | Memorized PII, extracted secrets, or policy-violating content leaking out through generation |
The table shows why both points are required: preprocessing protects the model from sensitive inputs, while postprocessing protects the user from sensitive outputs even when the model is compromised or tricked.
Model Armor data protection is the platform-level control that enforces minimum safety thresholds and mandatory de-identification on model endpoints. Model Armor screens prompts and responses for common risks such as injection and harmful content, and its data_protection_config binds that screening to a Sensitive Data Protection DeidentifyTemplate. The template defines which detectors to run and whether to redact, mask, or tokenize each finding, so enforcement does not depend on application code remembering to call the API.
A configuration references the template by its full resource name in projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID and pairs it with thresholds such as injection: HIGH and harmful_content: MEDIUM. Traffic flows from the Vertex AI endpoint to Model Armor evaluation first, then to the foundation model on ingress and through de-identification on egress. Because the policy applies to the endpoint rather than the prompt author, sensitive information is redacted or masked before it is returned to the user even if the model itself is compromised.
Exam tip: Use a Sensitive Data Protection DeidentifyTemplate referenced in Model Armor data_protection_config to guarantee redaction on egress, rather than relying only on application-level filtering that a jailbreak can bypass.
Lineage and access tracking is the governance layer that proves which sensitive data moved where and who touched it. Knowledge Catalog records lineage from raw source through transformation to dataset version and registered model version, while Model Registry (opens in a new tab) links each model version to its training parameters, evaluation metrics, and source dataset. Cloud Audit Logs and Data Access audit logs capture API calls, data access events, and configuration changes, and they flow into Cloud Logging for real-time analysis, alerting, and visualization.
This dependency closes the loop: Sensitive Data Protection depends on accurate inventory to inspect, Model Armor depends on templates and thresholds to enforce, and governance depends on logs and lineage to verify. When an output incident occurs, teams trace backward from the prediction to the model version, to the dataset version, to the inspection finding that should have masked it. That end-to-end traceability supports compliance for data privacy (opens in a new tab), limits blast radius from data exfiltration, and guides remediation of the preprocessing or postprocessing rule that failed.
Defend Against Prompt Injections, Jailbreaks, and Malicious Inputs is the discipline of preventing attacker-controlled text from overriding system instructions or exfiltrating data. Model Armor (opens in a new tab) screening, safety thresholds, system instruction boundaries, and code-level sanitization work together against direct and indirect attacks. A direct injection comes from the end-user prompt that tries to override the system prompt, while an indirect injection hides instructions in external data the agent fetches, such as a web search result or third-party document. A jailbreak is a special case that tries to bypass safety boundaries to produce harmful content or unauthorized actions.
Input validation in AI systems treats every prompt and every piece of retrieved data as untrusted until it is checked. The untrusted sources include end-user text and agent-fetched content from external tools, documents, and search results, which all flow from the outside into the model context. Secure coding validates and sanitizes both inputs and outputs in application code to prevent model manipulation and system exploits. In data ingestion and preprocessing scripts for Gemini Enterprise Agent Platform Pipelines or BigQuery, validation in Python checks data types, formats, and ranges before training or inference, so malformed or malicious values do not reach the model.
Screening with Model Armor and safety thresholds is the platform-level inspection of prompts before they reach the model and responses before they return to the user. The request flow runs from the user prompt to Model Armor pre-screening to the Vertex AI endpoint to Model Armor post-screening to the user, with Sensitive Data Protection redaction applied even if the model is compromised. Model Armor is enabled on a serving endpoint with the Google Cloud CLI, which activates built-in protection against injection and jailbreaking vectors:
gcloud ai endpoints update ENDPOINT_ID \
--region=REGION \
--enable-model-armor
Minimum safety thresholds and data protection are enforced through a configuration file that sets detection sensitivity and references a de-identification template. The configuration defines safety_thresholds such as injection: HIGH and harmful_content: MEDIUM, and data_protection_config points to a Sensitive Data Protection DeidentifyTemplate like projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID to redact or mask PII. As an alternative or complement, a fine-tuned large language model (LLM) can automatically screen prompts and responses for common risks, with a human in the loop to validate changes proposed by coding assistants such as CodeMender.
Secure agent design limits model freedom because open-ended plan and execute architectures decouple high-level task specification from mechanical execution and let injected text steer control flow. The action-selector pattern restricts the model to translating a user request into one of a small, pre-defined set of safe functions, while the hard-coded action logic outside the LLM cannot be modified by prompt text. The dual-LLM pattern separates duties between a primary action LLM that performs the core task and a secondary guardrail LLM that pre-screens the user prompt for malicious intent and post-screens the action output for unauthorized actions or data leakage.
| Pattern | Model role | How injection is contained |
|---|---|---|
| Action-selector pattern | Model selects one safe function | Control flow lives in hard-coded code, so injected text cannot create new actions |
| Dual-LLM pattern | Action LLM acts, guardrail LLM checks | Guardrail LLM blocks malicious prompts before execution and blocks leaks after execution |
Choose the action-selector pattern when the task maps to a closed set of operations, and choose or add the dual-LLM pattern when free-form reasoning is required but every input and output must still be checked by an independent, highly-secure model.
Tool governance ensures an agent calls only the tools necessary for its task and cannot expand its own privileges. Orchestration code must prohibit dynamic tools, meaning the agent cannot dynamically register new tools or change permissions of existing tools. Allowlist enforcement declares the permitted functions or database tables in both the initial system prompt and the backend code, so the backend denies anything outside the list even if the prompt is manipulated.
General database tools create the highest leakage risk in multi-tenant applications without a trusted human in the loop. A general execute_sql tool lets the caller execute queries against any data that IAM and database permissions allow, so a malicious user can trick the agent into reading another user's rows. The safe alternative builds narrow custom tools with MCP Toolbox for Databases (opens in a new tab), where the identity filter is set outside agent control. For an Orders table holding all users' orders, the unsafe flow is user prompt to agent to execute_sql to full table, while the safe flow is user prompt to agent to lookup_active_order where backend code injects the authenticated user ID into the query filter. Instructing the agent in natural language to enforce access rules is not sufficient protection.
Exam tip: Enforce tenant isolation outside the model with a custom tool and backend allowlist; a general execute_sql tool plus a prompt instruction still allows injection-driven leakage.
Post-authentication defense assumes an attacker has bypassed authentication and authorization and then attacks the system internally through the network, application, and inference layers. VPC Service Controls (opens in a new tab) creates a service perimeter around Model Registry, BigQuery, and Vertex AI resources to prevent data exfiltration from the VPC, with ingress and egress rules controlling data flow and dry run mode used to validate impact before enforcement. Identity-Aware Proxy (IAP) (opens in a new tab) protects web-based tools such as notebooks, while Apigee provides enterprise-grade request validation, traffic control, and authentication for inference endpoints, with API Gateway as the lighter option for straightforward authentication.
Behavioral monitoring detects probing, theft, and denial-of-service (DoS) that pass initial checks:
Auditing and evaluation provide visibility into what the agent did and whether injected inputs could succeed. Cloud Audit Logs (opens in a new tab) must have Data Access audit logs enabled for Model Context Protocol (MCP) and for BigQuery, Cloud SQL, AlloyDB, Firestore, Spanner, and Oracle Database@Google Cloud, because only Admin Activity audit logs are enabled by default. Data Access logs record every read and write operation performed by the agent service account, and Cloud Logging alerts can trigger on high-risk patterns such as service-account data writes to Firestore. Resilience is tested before and after deployment by checking for common data corruptions and malicious modifications, running adversarial attack simulations for security-critical models, verifying container signatures with Binary Authorization, and using Model Monitoring to detect drift and skew that may signal tampering or poisoning.
data_protection_config and a DeidentifyTemplate enforces tokenization, masking, or redaction on prompts before the model and on responses after the model.execute_sql tool allows injection-driven cross-tenant reads, while a narrow custom tool such as lookup_active_order enforces tenant isolation by injecting the authenticated user ID in backend code outside agent control.A Vertex AI private endpoint controls network reachability inside the Virtual Private Cloud (VPC) while Identity and Access Management (IAM) on the target Vertex AI service controls which identity can use the model, and both must allow the request. Private Service Connect provides private endpoints for access from within a VPC network, but Identity and Access Management is not directly applied to the private endpoint itself so network reachability and identity authorization remain separate checks.
Choose the action-selector pattern when the task maps to a closed set of operations, and choose or add the dual-large language model pattern when free-form reasoning is required but every input and output must still be checked. The action-selector pattern restricts the model to selecting one safe function while hard-coded logic outside the model controls execution, while the dual-large language model pattern uses a guardrail model to screen prompts before execution and outputs after execution.
Model Armor enforces preprocessing screening on prompts before they reach the foundation model and postprocessing screening on responses before they reach the user, with the template defining which detectors run and whether to redact, mask, or tokenize each finding. Preprocessing blocks personally identifiable information, credentials, and intellectual property from leaking into prompts, training logs, or retrieval stores, while postprocessing redacts or masks sensitive data before release even if the model itself is compromised.
Last updated