Listen to this Post
Introduction:
Microsoft Foundry introduces a strong governance separation between projects and connected Azure services, improving scalability but inadvertently creating new attack paths. Attackers can exploit misconfigured shared connections, weak RBAC boundaries, and overreaching managed identities to pivot across AI projects and exfiltrate sensitive data from Key Vault or Azure AI Search. Understanding these risks is critical for security teams defending AI infrastructure.
Learning Objectives:
- Identify and mitigate shared connection compromise risks in Microsoft Foundry’s resource hierarchy.
- Harden RBAC scopes, managed identities, and Key Vault access policies to prevent cross-project lateral movement.
- Implement network segmentation and centralized logging to detect abuse of Foundry agents and shared deployments.
You Should Know:
- Shared Connection Compromise – Pivoting Across Projects via Misconfigured Links
Shared connections at the Foundry resource layer allow multiple projects to reuse Azure services like Storage, Key Vault, or AI Search. A single over-permissive connection can become an attacker’s bridge to pivot laterally.
Step‑by‑step guide to identify and fix risky connections:
Step 1: Enumerate all Foundry shared connections using Azure CLI
Login to Azure az login List all Foundry resources in a subscription az resource list --resource-type Microsoft.Foundry/foundries --output table For a specific Foundry, list its connections az foundry connection list --foundry-name <your-foundry> --resource-group <rg>
Step 2: Audit each connection’s permission scope
- Check if the connection uses a broad scope (e.g., entire subscription) instead of a specific project.
- Use Azure Policy to deny connections with wildcard resource IDs.
Step 3: Remediate – break shared connections per project
– Create isolated connections for each project.
– Apply least‑privilege RBAC on the target service (Storage Blob Data Reader instead of Contributor).
Windows PowerShell alternative for Azure Resource Graph queries:
Search-AzGraph -Query "resources | where type =~ 'microsoft.foundry/foundries' | project name, resourceGroup, properties.connections"
Step 4: Monitor for anomalous cross-project access
Enable Azure Monitor and set alerts on `StorageBlobRead` events originating from unexpected project identities.
- Cross-Project Agent Abuse – Locking Down RBAC and Identity Boundaries
Foundry agents often run with managed identities that can be reused or over‑privileged. Weak RBAC boundaries allow an agent compromised in one project to call APIs or read secrets in another.
Step‑by‑step guide to harden agent identities:
Step 1: List all managed identities attached to Foundry agents
az identity list --resource-group <rg> --output table az role assignment list --assignee <managed-identity-client-id> --include-inherited
Step 2: Apply the principle of “no implicit trust” between projects
– Create separate user-assigned managed identities per project.
– Restrict each identity’s role assignments to only its own project’s resource group.
Step 3: Implement conditional access policies for agent authentication
In Azure AD, create a Conditional Access policy requiring:
– Compliant device (if agent runs on managed VM)
– IP range restriction (only Foundry’s control plane IPs)
Step 4: Rotate agent tokens frequently
Force refresh of managed identity token (Linux using systemd)
az account get-access-token --resource https://vault.azure.net --query accessToken -o tsv | jq -R 'split(".")[bash] | @base64d' | jq '.'
Step 5: Audit agent cross-project API calls
- Forward Foundry diagnostic logs to Log Analytics.
- Query for `callerIdentity` fields that show a managed ID accessing resources outside its designated project.
Linux command to search logs for cross‑project requests:
az monitor log-analytics query --workspace <workspace-id> --analytics-query "AppRequests | where callerIdentity has 'projectA' and resourceUrl contains 'projectB'"
- Connected Resource Overreach – Tightening Key Vault and Storage Access Policies
Key Vault and Azure AI Search remain independent trust boundaries, but excessive permissions (e.g., `Key Vault Administrator` orSearch Service Contributor) can leak secrets or training data across Foundry projects.
Step‑by‑step guide to lock down connected resources:
Step 1: Inventory all Key Vaults linked to Foundry connections
az keyvault list --query "[].{name:name, resourceGroup:resourceGroup}" -o table
az keyvault show --name <kv-name> --query "properties.networkAcls"
Step 2: Enforce network restrictions and private endpoints
- Deploy private endpoints for Key Vault, Storage, and AI Search.
- Disable public network access (except for approved dev/test).
Example Azure CLI to enable private endpoint for Key Vault:
az keyvault update --name <kv-name> --default-action Deny az network private-endpoint create --name pe-kv --resource-group <rg> --vnet-name <vnet> --subnet <subnet> --private-connection-resource-id $(az keyvault show --name <kv-name> --query id -o tsv) --group-id vault
Step 3: Implement just‑in‑time (JIT) access for Key Vault permissions
– Use Azure Privileged Identity Management (PIM) for roles like Key Vault Secrets User.
– Require approval for any elevation.
Step 4: Validate that Foundry projects use different access policies
PowerShell: List all secrets and which projects have GET permission
Get-AzKeyVaultSecret -VaultName <kv-name> | ForEach-Object {
$secretName = $_.Name
Get-AzKeyVaultSecret -VaultName <kv-name> -Name $secretName | Select-Object Id, Attributes
}
Step 5: Automate drift detection for Key Vault policies
Deploy a custom Azure Policy that denies creation of new access policies with wildcard secret permissions.
- Logging and Monitoring Across Foundry and Connected Resources
Without unified monitoring, shared connection compromises can go undetected. Centralized logging is your last line of defense.
Step‑by‑step guide to enable cross‑resource logging:
Step 1: Stream all Foundry diagnostic logs to a central Log Analytics workspace
az monitor diagnostic-settings create --resource <foundry-id> --name "foundry-logs" --workspace <workspace-id> --logs '[{"category":"Audit","enabled":true}]'
Step 2: Enable data collection for Azure resources connected via Foundry
– Storage: Enable blob logging and send to same workspace.
– Key Vault: Enable diagnostic settings for `AuditEvent` category.
Step 3: Create a KQL alert for lateral movement indicators
let suspiciousEvents = union (StorageBlobLogs | where OperationName == "GetBlob" and CallerIpAddress != "<expected-cidr>"), (KeyVaultAuditEvent | where OperationName == "SecretGet" and IdentityType == "ManagedIdentity"), (FoundryAudit | where ActivityType == "CrossProjectAccess") ; suspiciousEvents | summarize count() by CallerIdentity, TargetResource, bin(TimeGenerated, 5m) | where count_ > threshold
Step 4: Send alerts to Microsoft Sentinel or a SIEM
az sentinel alert-rule create --resource-group <rg> --workspace-name <workspace> --name "Foundry-Lateral-Movement" --query "suspiciousEvents | where count_ > 5" --severity High
What Undercode Say:
- Shared connections are the new lateral movement highways. Treat each Foundry connection as a potential attack bridge and enforce per-project isolation with network policies and Azure AD Conditional Access.
- Identity boundaries must be coded, not just documented. Overprivileged managed identities are the 1 enabler of cross‑project agent abuse. Regularly audit role assignments and enforce JIT for secret access.
The post’s emphasis on Foundry’s weak isolation is a wake‑up call for AI security. Most teams focus on model poisoning or prompt injection, but the real damage in production AI pipelines will come from credential theft and lateral movement across shared Azure services. In the coming year, expect red teams to weaponize misconfigured Foundry connections to pivot from a low‑privilege AI developer account into a subscription‑wide credential dump. Organizations should immediately treat Foundry projects as multi‑tenant systems and apply the same zero‑trust controls used in Kubernetes clusters—network policies, mutual TLS between services, and continuous identity validation. The future of AI infrastructure security is not better model firewalls; it’s ironclad identity, logging, and resource segmentation.
Prediction:
As Microsoft Foundry and similar AI platforms (e.g., AWS SageMaker, Google Vertex) adopt “workspace” architectures, attackers will shift focus from AI model theft to abusing platform orchestration layers. By 2027, we will see the first major breach where a shared connection between an AI project and a legacy storage account leads to exfiltration of millions of customer records. Defenders who proactively implement the hardening steps above—RBAC per project, private endpoints, and unified logging—will gain a 12‑18 month advantage over those who rely solely on platform defaults.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Elishlomo Ai – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
