Microsoft Foundry for SQL Server Professionals: Hub, Projects, Connections, and the DBA’s Role

Microsoft Foundry is showing up in every serious enterprise AI conversation in 2026. It is the infrastructure platform where organizations build, deploy, and govern AI agents and applications on Azure. If your organization is building AI systems that interact with SQL Server data through MCP or RAG pipelines, Foundry is the platform those systems run on. Understanding its architecture, how its governance model works, and where the DBA’s role sits within it is no longer optional knowledge for data professionals.

The good news is that Foundry’s architecture maps directly onto concepts SQL Server DBAs already understand. The hub and project model is the same governance hierarchy as SQL Server instances and databases. Connections work like linked servers and database-scoped credentials. RBAC on Foundry resources follows the same least-privilege principles DBAs apply to SQL Server logins. Once that mapping clicks, the whole platform makes sense quickly.

This article covers what Foundry is, how the hub and project hierarchy works, how connections are governed, the private networking model, and specifically where SQL Server data fits into a Foundry-based AI deployment.

1 What Microsoft Foundry Is and Why It Exists Beginner

Microsoft Foundry is a unified Azure platform-as-a-service designed for enterprise AI operations. It combines model access, agent orchestration, governance, and monitoring under one management surface. Before Foundry, building enterprise AI applications required assembling multiple separate Azure services: Azure OpenAI for the model, Azure AI Search for retrieval, Azure Storage for data, Azure Container Apps for agent runtime, and then wiring them together with custom infrastructure. Each piece had its own access controls, its own billing, and its own monitoring setup.

Foundry provides a single management layer over all of those components. It gives organizations a unified RBAC model, centralized network policy enforcement, shared connection management across multiple AI projects, and a single place to trace, monitor, and evaluate agent behavior. The platform supports MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols natively, making it the runtime environment for the kind of AI-to-SQL-Server connections covered in the SQLYARD MCP guide.

The model catalog in Foundry provides access to over 11,000 AI models including Azure OpenAI models, open source models from Hugging Face, and specialized models from third-party providers. For SQL Server teams the relevant models are the embedding models used to generate vector representations of documents for RAG pipelines, and the reasoning models used to generate SQL and interpret query results.

2 Foundry Projects vs Hub-Based Projects Beginner

This distinction is one of the first things that confuses people navigating the Foundry portal. Microsoft Foundry has two project types that exist alongside each other and the portal UI can make it unclear which one you are creating.

3 The Hub and Project Hierarchy: The SQL Server Parallel Beginner

The Foundry governance hierarchy has a direct parallel to SQL Server that makes it immediately understandable for DBAs. Once you see the mapping, the purpose of each layer becomes obvious.

The practical implication of this hierarchy is that shared AI infrastructure can be provisioned once at the hub level and consumed by multiple project teams without each team managing their own copy. An organization with five AI projects all using the same Azure AI Search service provisions that search service once, connects it at the hub level, and all five projects inherit the connection automatically. Each project uses it without needing its own credentials or its own copy of the service.

4 Connections: Hub-Level vs Project-Level Intermediate

Connections are how Foundry projects access external Azure services and data sources. A connection stores the endpoint URL, authentication credentials, and connection type for a resource. When a Foundry agent needs to search an index, query a database, or read from storage, it uses a named connection to do so.

The governance decision is whether to create a connection at the hub level (shared) or the project level (isolated). The decision maps directly to the same question DBAs answer when deciding whether to create a server-scoped or database-scoped credential in SQL Server.

Hub-Level Connections: Use When

• Multiple teams need access to the same resource (shared AI Search index, shared OpenAI deployment)
• You want centralized credential management so rotating one credential updates access for all projects
• The resource contains shared reference data that all projects use (company knowledge base, product catalog)
• You want to enforce a consistent configuration across all projects from one place

Project-Level Connections: Use When

• A resource is specific to one application and should not be accessible to other teams
• Different projects need different access levels to similar resources
• Isolation is a compliance requirement (a project handling sensitive data should not share connections with projects handling public data)
• You need to test a new resource configuration without affecting other projects

# Azure CLI: Create a hub-level connection to Azure AI Search
# This makes the connection available to all projects in the hub

az ml connection create \
  --file ai-search-connection.yaml \
  --resource-group YourResourceGroup \
  --workspace-name YourHubName

# ai-search-connection.yaml content:
# name: hub-aisearch-connection
# type: azure_ai_search
# endpoint: https://your-search-service.search.windows.net
# api_key:   # or use Entra ID (see Section 5)
# is_shared: true  # makes it available to all projects

# Azure CLI: List all connections on a hub
az ml connection list \
  --resource-group YourResourceGroup \
  --workspace-name YourHubName \
  --output table

5 Authentication: Account Keys vs Entra ID Intermediate

Foundry connections support two authentication types for most Azure resources: Account Keys (API keys, storage keys) and Microsoft Entra ID (identity-based authentication using managed identities). The choice between them is a security and operational decision with clear guidance for production environments.

The production pattern for Foundry connections is to disable key access on Azure Storage accounts entirely and use only Entra ID managed identity authentication. This eliminates the credential management problem completely. There are no keys to rotate, no keys to leak, and no keys to store in connection strings. The Foundry project’s managed identity is the credential and Azure handles its lifecycle automatically.

6 Private Networking: The Enterprise Configuration Intermediate

The default Foundry configuration allows public internet access to Azure services, which is acceptable for development but not for enterprise production deployments. The private networking configuration places all Foundry infrastructure inside a virtual network with private endpoints, ensuring that all AI agent traffic stays within your Azure network boundary and never traverses the public internet.

A standard private networking setup uses a VNet with two dedicated subnets:

The agent subnet is delegated to Microsoft.App/environments which is the Container Apps environment that runs AI agent workloads. The private endpoint subnet hosts the private endpoints for every Azure service the agents connect to. Traffic from agents to those services stays on the private subnet and never leaves the VNet.

7 Setting Up Hub-Level Shared Connections Intermediate

8 Setting Up Entra ID Authentication on Connections Intermediate

Switching from account key authentication to Entra ID on a Foundry connection requires two steps that must happen in the right order. Creating the connection before assigning the RBAC role produces authentication errors that are not obvious to diagnose.

# Step 1: Get the project's managed identity principal ID
# You need this to assign the RBAC role

az ml workspace show \
  --name YourProjectName \
  --resource-group YourResourceGroup \
  --query "identity.principal_id" \
  --output tsv

# Store the result: e.g. a1b2c3d4-e5f6-7890-abcd-ef1234567890

# Step 2: Assign Storage Blob Data Contributor role to the managed identity
# on the storage account BEFORE creating the connection

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee  \
  --scope /subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/

# Step 3: Verify the role assignment before proceeding
az role assignment list \
  --assignee  \
  --output table

# Step 4: Create the connection with Entra ID auth
# In the portal: Add Connection > Storage Account > Microsoft Entra ID
# You will see "No key available" in the key column - this confirms
# the connection is using identity-based authentication correctly

# Step 5: Disable key access on the storage account (production only)
az storage account update \
  --name YourStorageAccountName \
  --resource-group YourResourceGroup \
  --allow-shared-key-access false

9 RBAC: Getting the Assignment Order Right Intermediate

The most common mistake when setting up Entra ID connections in Foundry is creating the connection before assigning the RBAC role. The error messages that result are authentication failures on the connection that do not explicitly tell you the RBAC assignment is missing.

The correct sequence is: assign the role first, verify the assignment, then create the connection. A missing role assignment is the cause of most “connection failed” errors on Foundry Entra ID connections.

-- SQL Server parallel: RBAC in Foundry maps to login and user management

-- In SQL Server:
-- Step 1: Create the login at the instance level (the identity exists)
-- Step 2: Create the user in the database (grant access to the resource)
-- Step 3: Assign the role (grant specific permissions)

-- In Foundry with Entra ID:
-- Step 1: The managed identity is created automatically with the project
-- Step 2: Assign the RBAC role on the Azure resource (grant access)
-- Step 3: Create the connection using that identity (configure the access)

-- The ORDER matters in both cases.
-- Trying to use the login before the user exists fails.
-- Trying to create the connection before the RBAC role exists fails.
-- Same pattern, different platform.

10 Where SQL Server Fits in a Foundry Deployment Intermediate

SQL Server integrates with Foundry-based AI deployments in two distinct ways: as a knowledge base for RAG pipelines and as a live data source for AI agents through MCP connections.

SQL Server as a RAG Knowledge Base

In SQL Server 2025, the VECTOR data type and DiskANN vector index allow vector embeddings to be stored and searched natively inside SQL Server. The RAG pipeline chunks your documentation and schema metadata, generates embeddings using an Azure OpenAI model accessed through a Foundry connection, and stores those embeddings in SQL Server VECTOR columns. When an AI agent answers a question, it queries the SQL Server vector store to retrieve relevant context before generating a response.

This means SQL Server is a first-class data store in the Foundry architecture, not just a database the agents query for business data. It can serve both roles simultaneously: vector knowledge base for RAG context and transactional data store for agent tool calls through MCP.

SQL Server as an Agent Tool via MCP

An MCP server sits between Foundry agents and SQL Server, exposing database operations as named tools that agents can call. The agent uses the MCP connection to run queries, check current data, and retrieve structured results as part of a multi-step workflow. In Foundry this MCP connection is a project-level connection scoped to the specific agent project that needs database access.

-- Example: Foundry agent workflow connecting to SQL Server via MCP

-- 1. The Foundry project has a project-level MCP connection to SQL Server
--    Connection name: sqlserver-prod-mcp
--    Auth: Entra ID managed identity
--    Read-only SQL account with explicit schema access

-- 2. The agent receives a question:
--    "What are the top 5 customers by revenue this quarter?"

-- 3. Agent calls the MCP tool: query_database
--    Input: { "question": "top 5 customers by revenue Q2 2026" }

-- 4. MCP server translates to SQL and executes:
SELECT TOP 5
    c.CustomerName,
    SUM(o.OrderTotalUSD) AS QuarterRevenue
FROM dbo.Orders o
JOIN dbo.Customers c ON c.CustomerID = o.CustomerID
WHERE o.OrderDate >= '2026-04-01'
AND   o.OrderDate <  '2026-07-01'
AND   o.OrderStatusID = 5  -- Delivered only
GROUP BY c.CustomerID, c.CustomerName
ORDER BY QuarterRevenue DESC;

-- 5. MCP returns structured results to the Foundry agent
-- 6. Agent formats the response for the user

-- The DBA's role: set up the read-only SQL account, define which
-- queries the MCP server can execute, cap row counts, log all queries

11 The DBA's Role in Foundry Governance Beginner

Foundry governance involves skills DBAs already have applied to a new platform. The specific responsibilities that fall to the DBA or data team in a Foundry enterprise deployment are:

• SQL Server MCP server configuration. Creating the least-privilege read-only SQL account, defining which schemas and tables the AI can access, setting row caps, blocking dangerous operations, and configuring audit logging. This is database security work.
• Vector store maintenance in SQL Server 2025. Managing the VECTOR tables that store RAG embeddings, monitoring index health, refreshing stale embeddings when source documents change, and monitoring query performance of similarity searches.
• Schema documentation quality. The quality of AI-generated SQL is directly determined by the quality of extended property documentation on tables and columns. DBAs who maintain good schema documentation are directly improving AI output quality. See the SQLYARD article Your Data Is Your AI Engineer.
• Connection governance review. Reviewing which connections exist at hub and project level, verifying that production connections use Entra ID rather than account keys, and confirming that project-level connections have appropriate scope isolation.
• Private networking review for SQL Server traffic. When an MCP server connects a Foundry agent to SQL Server inside a private VNet, the SQL Server must be accessible from within that VNet either through a private endpoint or through VNet peering. Planning this network path is infrastructure work that requires DBA input on the SQL Server side.

References

• Microsoft Docs: What is Microsoft Foundry?
• Microsoft Docs: Hubs and Hub-Based Projects Overview (Classic)
• Microsoft Docs: Microsoft Foundry Models Overview
• Microsoft Docs: Use Managed Identity for Azure OpenAI Authentication
• Microsoft Docs: Assign Azure RBAC Role for Storage Access
• SQLYARD: How AI Connects to Your Company Data
• SQLYARD: MCP and SQL Server: What Every DBA Needs to Know
• SQLYARD: LLM, RAG, Agents, and MCP: The Plain English Guide
• SQLYARD: Your Data Is Your AI Engineer
• SQLYARD: From Rows to Reasoning: Designing SQL Server Databases for AI Apps