Deploy Microsoft Foundry so one failed control is not a breach

A working guide for platform and security teams. Trace an attack through the guardrails, switch a control off to see what still holds, then follow the deployment one checked step at a time.

Trace a threat Start the deployment

What Foundry is

Microsoft Foundry, formerly Azure AI Foundry and before that Azure AI Studio, is Azure's platform for building, deploying and governing generative AI applications and agents.

One top level Foundry resource holds the governance: networking, encryption, model deployments and policy. Child projects hold the development work: agents, threads, files and evaluations. Storage, Key Vault, AI Search and Cosmos DB are connected resources with their own network and access boundaries, so locking down Foundry does nothing for them. Leaving one of them public while Foundry is private is the most common gap in reviews.

Build new estates on the Foundry resource model. Hub based projects are legacy and new features land on the Foundry resource first.

Foundry resource model
Resource	ARM type	Holds
Foundry resource	`Microsoft.CognitiveServices/accounts`, kind `AIServices`	Model deployments, network rules, customer managed key, connections, guardrail policies
Foundry project	`Microsoft.CognitiveServices/accounts/projects`	Agents, threads, files, evaluations, project managed identity
Connected resources	Storage, Key Vault, AI Search, Cosmos DB, App Insights	Separate resources with their own network and RBAC boundaries

Who it is for

Platform engineers own the resource, network and quotas. Security architects and the SOC own guardrails, policy and detection. Developers build agents inside a project. Data owners decide what agents may read and where it is processed. Risk and audit need evidence against ISO 27001, ISO 42001, NIST AI RMF and the EU AI Act.

The problem it answers

Without a governed platform each team stands up its own Azure OpenAI account, its own keys and its own vector store, and security finds out afterwards. Foundry gives many teams one place to build while one platform team keeps control of networking, identity, data residency, model choice and spend.

Sanctioned, not shadow

A private internal endpoint with logging gives staff an approved alternative to pasting data into public chatbots.

No keys in config

Local auth disabled; Entra ID and managed identities only, so every call is attributable.

Known models only

Azure Policy allow lists decide which models can be deployed, at deployment time.

Injection screened

Prompt Shields inspect user input, documents and tool responses before the model acts on them.

Data stays put

Regional or Data Zone deployments, and threads, files and vectors in your own stores.

Evidence for audit

Traces, evaluations and Defender alerts in Log Analytics and Sentinel.

Trace a threat through the guardrails

Choose an attack, switch off any control, then trace it. The result tells you where the attack stopped, which gaps it passed through, and whether anything recorded it.

Scoping a penetration test of these paths? Read the attack paths with reasoning, test cases and effort.

Landing zones, hybrid and multi-cloud

Foundry lives in an application landing zone and inherits networking, DNS, identity and policy from the Azure landing zone instead of bringing its own.

Shared platform or one Foundry per application

Pattern	Use when	Trade off
Central AI platform: one Foundry per environment and region, a project per use case	Many small use cases and a strong central team	Shared quota, one blast radius for a misconfiguration
Foundry per application landing zone	Regulated or high risk use cases, distinct data classifications	More resources to govern, model deployments duplicated
Both, behind one APIM gateway (recommended)	Most enterprises	Needs written criteria for which use case goes where

A workable rule: personal data, financial decisions or agents that can write get a dedicated Foundry resource; internal knowledge assistants on Official data share the central one.

Step by step deployment

You hold the pen. Each phase gives the commands, what you should see, and a check that fails loudly if the phase is wrong. Do not start the next phase until the check passes.

Order matters. Policy goes first so nothing is born non compliant. The network goes in before Foundry because agent subnet injection cannot be added afterwards for hosted agents. The data stores go in before the project because the agent capability host binds to them when the project is created.

Threat library

The threats that matter most are not the model being hacked. They are an agent steered by content it reads, an identity holding more access than its task needs, and people deploying or training models outside approval.

Search threats

ID	Threat	Primary controls	Detection	OWASP, ATLAS

STRIDE by component

Each component of the architecture mapped against Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege, with the threat IDs above so both views stay traceable.

Component

STRIDE	Threat	Control	Threat IDs

Guardrails in layers

Policy stops bad configuration at creation, identity limits who can act, the network limits where traffic goes, content safety inspects what enters and leaves the model, and monitoring catches what the others miss. Every layer is required.

Identity

Entra ID only: disableLocalAuth on Foundry, AI Search and Cosmos DB, allowSharedKeyAccess: false on Storage.
Foundry User for builders, Foundry Project Manager for leads, Foundry Account Owner for the platform team only, all through PIM with approval.
Conditional Access on the portal and APIs: phishing resistant MFA, compliant device, sign in risk.
Managed identities and workload identity federation for automation; no client secrets.
A dedicated Entra agent identity for every published agent, with Conditional Access for agents applied at the blueprint.

Network

Public network access disabled on Foundry and every connected resource, with no IP exceptions in production.
Agent compute injected into a delegated subnet, one subnet per Foundry resource.
Default route to the hub firewall with an FQDN allow list; all other outbound denied.
APIM in internal mode as the only way in for applications.

Data

Standard agent setup, bringing your own Cosmos DB, Storage and AI Search, for anything personal or confidential.
One project per data classification; customer managed keys where classification requires them.
Security trimming in AI Search so retrieval never returns what the user could not open.
Regional deployments for UK only processing, Data Zone for an EU or US boundary, Global only where the DPIA allows it.

Model and content

Prompt Shields blocking on user input, documents and tool responses.
Harm filters on input and output, protected material on output, groundedness for retrieval answers.
Guardrails on tool calls and tool responses for agents that use tools.
No secrets in system prompts; structured outputs validated against a schema; maximum tokens on every call.

Policy

Foundry model deployments should only use approved models and should meet eligibility requirements, set to Deny.
Deny public network access and local authentication on all five resource types.
DeployIfNotExists diagnostic settings to the central workspace.
A custom policy denying AI Services accounts outside the AI subscriptions, which stops shadow accounts.

Evaluation and monitoring

Quality and safety evaluations in CI on every agent or prompt change; a regression fails the release.
The AI Red Teaming Agent before go live and every quarter.
Defender for Cloud AI threat protection, Purview DSPM for AI, Sentinel analytics rules.

Preventing rogue agents

A rogue agent is any agent acting outside the purpose it was approved for: misled by injected content, built with more power than it needed, left running after its owner left, or created without approval.

Control	Means	How in Foundry
Known	No agent exists outside the inventory	Production agents created only by the pipeline; the Foundry control plane and Entra Agent ID registry reconciled weekly with the approved register
Owned	Every agent has a named owner and an expiry date	Owner and expiry in agent metadata; access review of agent identities every 90 days; the leaver process disables owned agents
Narrowly empowered	The agent can do only its task	Dedicated agent identity, RBAC on exactly the indexes and APIs it needs, read only tools by default
Bounded	Every run has hard limits	Token and step limits per run, a run timeout, a daily token budget at APIM, guardrails on tool calls and responses
Watched	Every tool call is traced	OpenTelemetry spans with agent ID, thread ID and tool name; Sentinel rules on unusual tool use
Stoppable	Any agent stops in under 15 minutes	The kill switch below, rehearsed every quarter

Build rules

Agent definitions, instructions and tool lists live in the repository and reach production only through the pipeline.
Tools are allow listed by exact MCP server URL or OpenAPI spec version; a schema change needs a new review.
Approval is required before any tool that writes, sends, pays, deletes or changes access.
No agent identity holds a role that can create agents, assign roles, or grant Graph permissions such as Application.ReadWrite.All.
Code interpreter stays off unless the agent charter needs it.

Kill switch, least disruptive first

Block the calling app at APIM. Stops new user traffic straight away.
Disable the agent identity. The agent can no longer get tokens for tools or data.
Remove its data role assignments. Cuts access at the next token refresh.
Revoke the tool connection. Tool calls fail.
Roll back the agent version. Removes faulty instructions or tools.
Set deployment capacity to zero. Last resort: stops every app on that deployment.
Preserve evidence. Export threads and traces and place a hold on the logs.

Issued tokens stay valid until they expire, often up to an hour. That is why step one and egress filtering matter: they stop the effect while revocation catches up.

Preventing unapproved model training

Two questions need answers. Does the provider train on your data? That is contractual. Can your own people fine tune or give a model persistent memory without approval? By default, yes, so you have to build the control.

Microsoft's published position for models sold directly by Azure is that prompts, completions and fine tuning data are not used to train the foundation models. Confirm it for your contract in the Product Terms and Data Protection Addendum, because partner and open models in Foundry can carry their own terms, and record the result in the DPIA.

Route to learning	Risk	Control
Fine tuning	Personal data embedded in weights cannot be selectively erased	Custom builder role without fine tuning actions; training only in one approved project through PIM
Fine tuned deployment outside the training scope	Unassessed model in production	Custom policy denying deployments whose model name contains `.ft-`, excluding only the training project
Developer deployment type	No residency guarantee, no SLA	Deny outside the training subscription
Stored completions reused as training data	Customer data repurposed without a lawful basis	No `store: true` in production unless the DPIA covers it
Agent memory across sessions	Profiling and retention beyond purpose	Off by default; enabled per agent with purpose, retention and user notice
Training on Azure ML compute or GPU VMs	Bypasses every Foundry policy	Deny ML compute and GPU SKUs outside the training subscription

List the exact fine tuning action names in your tenant before writing the custom role, rather than trusting a guide:

az provider operation show --namespace Microsoft.CognitiveServices \
  --query "resourceTypes[].operations[?contains(name,'fine') || contains(name,'files')].name" -o tsv

Remember that notDataActions subtracts from one role only; it is not a deny. The person must hold no other role that grants the same action.

Operate and detect

An estate stays secure only if someone looks at it on a schedule. Column names in diagnostic tables vary by resource and API version, so run getschema once and make each rule fail on a test event before you trust it to stay quiet.

Review cadence

When	Activity	Owner
Daily	Triage Defender for AI and Sentinel incidents	SOC
Weekly	Reconcile the agent inventory with the approved register	Platform team
Weekly	Token spend per project and per APIM consumer	FinOps
Monthly	Policy compliance for the AI management group	Platform team
Monthly	Content filter block rates and false positives	Service owners
Quarterly	Access review of human roles and agent identities	Identity team
Quarterly	Red team evaluation of each production agent; kill switch tabletop	Security, SOC
On retirement notice	Evaluate the replacement model, update the allow list, re-run evaluations	Platform, service owners

Take the checklist with you

Choose the parts you need and download them as a plain text file. It is built in your browser; nothing is sent anywhere.

Checklist parts

About this guide

Written by Saleem Yousaf, cloud and cyber security architect and director of Cyber Spartans Ltd. It is independent and not endorsed by Microsoft. Foundry changes quickly and several features described here are in preview; check API versions, role names and policy display names against Microsoft Learn before a production change.

Sources, checked October 2026: