Azure AI Foundry workloads are landing in production, often before security has reviewed them. A developer opens the model catalog, picks a model, and has a deployment serving traffic in minutes. Security teams find out afterward. Then come the questions. Which models are approved? Is local authentication turned off? Is content filtering on? Where do the prompts and responses go?
The answer is the same prevention-first approach that already protects the rest of your cloud. Prevention works in layers: block what should never happen at the access layer, and keep the right configuration in place at runtime. AI workloads are no exception.
Turbot Guardrails now includes prevention objectives for Azure AI Foundry, covering approved models, account authentication, network isolation, encryption, and Responsible AI. This post follows one of them end to end, from an empty objective to enforcement across layers.
Hold Deployments to Approved Models
The catalog is what makes AI Foundry fast to build on, and it is the easiest place to go wrong. A developer can deploy almost anything it offers: an unsupported preview model, an open-weight model nobody vetted, or one whose license your compliance team never cleared. Every deployment is one more place your prompts and responses can end up.
The objective Restrict Azure AI Foundry deployments to approved models holds every deployment to a list your governance team controls, by model name and by publisher. A deployment of gpt-4o from OpenAI passes. A deployment of an unreviewed model does not.
Approved models is one of a growing set of prevention objectives for Azure AI Foundry, organized into the same prevention categories you use elsewhere in Guardrails:
- Account security: disable local authentication, require Private Link, close public network access, require a managed identity, encrypt with a customer-managed key, and keep diagnostic logs.
- Model and deployment governance: hold deployments to approved models, SKUs, and versions.
- Responsible AI: require an approved content policy, turn on prompt and completion content filtering, and lock the filtering mode so it cannot be quietly switched off.
Each objective ships with a ready-to-use example: an Azure built-in policy, a Guardrails control, or both.
Prevention objectives for Azure AI Foundry, from approved models to content filtering
Recommendations for Improvement
For each objective, Guardrails shows your current posture and the steps to close the gap. It reads the objective, the resources in scope, and the preventions already in place, then proposes ranked ways to enforce it across layers, each with the steps to deploy.
Guardrails recommends how to enforce the objective, ranked across layers
Teams running Azure governance already know built-in policies, so that is where Guardrails starts. The approved-models objective maps to the built-in policy Cognitive Services Deployments should only use approved Registry Models, shipped as a ready-to-use example. Assign it to the subscription that holds your AI Foundry accounts, set the effect to Deny, and list the model registries and publishers you allow. Now try to deploy a model that is not on the list: Azure rejects it at the control plane, before the deployment is ever created.
Guardrails picks up the assignment on its own. Prevention discovery reads the policy, translates it into plain language, and matches it to the objective it satisfies, so the access layer shows coverage and new deployments are held to the approved list.
Guardrails discovers the built-in policy assignment and counts it toward the objective at the Access layer
Runtime Prevention
The built-in policy stops new violations, but it has limits. It does not touch the deployments you already have, and it only reaches the subscriptions where it is assigned.
A Guardrails control covers the rest. Set Azure > AI Foundry > Deployment > Approved Model Name to check every deployment against your approved list, and name the models you allow: gpt-4o, gpt-4o-mini, text-embedding-3-large. A companion policy does the same for the publisher.
Guardrails evaluates every deployment in scope, including the ones that already existed. In check mode, a deployment running an unapproved model flips from ok to alarm and names the offending model, leaving it in place for your team to review. In enforce mode, Guardrails cleans it up for you: since a deployment's model cannot be swapped in place, it deletes the non-compliant deployment.
The runtime control flags the experimental-assistant deployment: it is running text-embedding-3-small, a model the team never approved.
Back on the objective, the preventions are in place across both layers. The built-in policy blocks new unapproved deployments at the door, and the control watches the ones already running.
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.