Vertex AI has become a core part of how teams build on GCP. They deploy foundation models, stand up endpoints, screen traffic with Model Armor, and develop in Workbench notebooks. Each of these has configurations and access to protect, and each drifts out of policy: an unapproved model gets deployed, a safety filter is turned down, a notebook comes up with a public IP.
Preventive security for Vertex AI brings the same prevention-first approach that protects the rest of your cloud. Know where your preventive controls stand today, enforce the right configuration, and correct drift in real time so it does not linger. Prevention works in layers: block what should never happen with a GCP Organization Policy, and continuously enforce and repair the rest with Turbot Guardrails controls.
Govern the Models That Run
Not every model is approved for every project. Guardrails lets you enforce an allow-list of approved Vertex AI models, covering foundation models, publisher models, and the GenAI and Gemini model family, through a predefined Organization Policy constraint that Guardrails discovers automatically. You can prohibit the consumer Gemini API so generative traffic stays on the governed Vertex AI surface, and restrict advanced partner-model features such as web search to prevent unintended data exposure.
The Vertex AI prevention objectives, from model approval to endpoint encryption to notebook hardening
Hold the Model Armor Safety Floor
Model Armor screens what models receive and return, inspecting prompts and responses for prompt injection and jailbreak attempts, malicious URLs, sensitive data, and harmful content. A floor setting is the project-wide baseline for Model Armor, set at the project, folder, or organization: it declares the minimum every Model Armor template must meet, so individual templates cannot be created with the screening turned down, and it can apply that screening directly to Vertex AI traffic. Guardrails turns each part of that floor into its own policy, so you can set each filter individually rather than flipping the whole floor on or off.
Each floor filter checked independently across the detection and Responsible AI categories
Keep Encryption and Isolation in Place
The surrounding infrastructure matters as much as the models. Guardrails can require customer-managed encryption keys for Vertex AI endpoints, so model-serving data is encrypted with keys your organization controls. The same discipline extends to Workbench, the notebooks where teams develop against your models: instances can be required to use customer-managed encryption, shut down when idle, run without a public IP, and have root access disabled, hardening the interactive surface that is easy to leave exposed.
Recommendations for Improvement
For each objective, Guardrails shows your current posture and the steps to close the gap.
Take the approved-models allow-list. Guardrails flags the current posture: no Vertex AI organization policy is gating model access, so every project can reach any model. It recommends deploying the approved-models Organization Policy (vertexai.allowedModels and vertexai.allowedGenAIModels), so only sanctioned foundation and GenAI models can run. The recommendation includes the deployment steps to roll it out across your projects.
Each objective comes with its posture, implementation options, and deployment steps
Runtime Prevention
An Organization Policy blocks misconfiguration as resources are created, but it does not repair the projects already running, and a live setting can still be loosened by anyone with the right permissions. Runtime prevention closes that gap, keeping each objective in its intended state continuously.
Consider the Model Armor floor. Your organization requires prompt-injection and jailbreak detection at every project's floor. Set the GCP > Model Armor > Floor Setting > Settings control to Enforce with your declared minimum, and Guardrails monitors the live floor against it.
Point-and-click enforcement: declare the minimum Model Armor floor for the project
When someone disables a filter on the live floor, the control moves from ok to alarm and re-applies the required floor automatically, raising it back to the declared minimum.
A required filter is turned down on the live floor; the control alarms and re-applies the floor to the declared minimum
Prevention-First Security for Your Entire Stack
Preventive security for AI brings the same prevention-first approach that enterprise teams rely on for AWS, Azure, GCP, GitHub, and OCI. Block what should never happen at the access layer, enforce the right configuration at runtime, and correct drift automatically, the same defense in depth that protects the rest of your cloud. It is one part of a broader set of AI preventions launching this week.
Interested in bringing preventive security to your AI environment? Connect with us to get your free preventive security posture assessment.