Your Foundry Agents Are Live in Azure. Today, You Can See What They Run As — and What They Can Reach.
Azure AI Foundry is where developers ship agents on top of Azure OpenAI, Azure AI Search, third-party model deployments, and the broader Azure platform. Each Foundry agent runs against a model deployment, calls tools, reads vector stores and indexes, and crosses into other Azure services through managed identities and service principals.
That’s a lot of moving parts — and most of it is invisible to security teams. The hard governance question stays the same:
Which Foundry agents exist, what identity do they run as, and what data and services can they actually reach in our Azure tenant?
That changes today. Veza is expanding AI Agent Security to Azure AI Foundry — bringing the same Access Graph that already governs agents on AWS Bedrock, Amazon Bedrock AgentCore, Google Cloud Vertex AI, Microsoft Copilot Studio, Salesforce Agentforce, and ServiceNow into Azure.
For every customer building agents in Azure AI Foundry, Veza now answers the question we were built to answer:
What can take what action on what data — across every AI Agent in Foundry?
Key takeaways
- Every Foundry agent is a non-human identity. Veza captures it as AzureAiFoundryAgent and classifies it as an AI Agent in the Access Graph.
- Service principals and managed identities are where the real blast radius lives. Foundry agents inherit Azure RBAC through the identity they’re tied to — and that’s where Veza traces every Storage, Key Vault, AI Search, SQL, and Cosmos DB resource the agent can reach.
- Discovery is automatic. Once a Foundry account and project exist in the tenant, Veza picks up agents, model deployments, vector stores, indexes, connections, tools, and identity bindings on the next extraction.
- Inbound and outbound are both modeled. Who can invoke or manage each Foundry agent (inbound) and what each agent can reach across the Azure tenant (outbound) live in the same graph.
- Foundry joins the AI Agent Security family. Veza now governs AI agents end-to-end across the five major agentic platforms enterprises actually use.
Why Azure AI Foundry Needs Identity-First Governance, and Why Now
Enterprises are accelerating agent development on Azure faster than security teams can map. Foundry sits at the center of Microsoft’s AI strategy, and the agents being built on it touch the most sensitive data in the tenant — Storage Accounts, Key Vaults, AI Search indexes, SQL databases — through identities that often started life as a developer’s quick demo and were never reviewed.
Today, Veza closes that gap. Foundry agents become first-class identities in the Access Graph, sitting alongside humans, service principals, and managed identities — reviewed, alerted on, and governed exactly the same way.
What Veza Discovers in Azure AI Foundry
Veza extends the existing Azure integration to model the full Foundry hierarchy — accounts, projects, agents, model deployments, and the connections, tools, vector stores, and indexes that back them. Discovery is automatic on the next extraction.
The following entities and relationships are now visible:
- Azure AI Foundry Agents — every agent or assistant in the project, captured as AzureAiFoundryAgent and classified as an AI Agent
- Bot Service service accounts — when an agent is exposed via Azure Bot Service, Veza captures the backing service account as AzureAiFoundryBotServiceAgent
- Foundry Accounts and Projects — the account-level hub and project-level workspace, captured as AzureAiFoundryAccount and AzureAiFoundryProject
- Model Deployments — the deployed model endpoints (GPT-4o, Claude, and others) backing each agent, captured as AzureAiFoundryModelDeployment
- Vector Stores and Indexes — the RAG layer behind each agent, captured as AzureAiFoundryVectorStore and AzureAiFoundryIndex
- Connections — external service connections wired into the project, captured as AzureAiFoundryConnection
- Tools — agent tool definitions including code interpreters and function calls, captured as AzureAiFoundryTool
- Guardrails — content safety and moderation policies attached to agents, captured as AzureAiFoundryGuardRail
- Service principals and managed identities — the Azure AD identities each agent runs as, resolved through Azure RBAC
A note on scope: Veza extracts agents created in the new Azure AI Foundry portal. Agents created in the Foundry (classic) portal are not in scope at launch — that’s on the roadmap.
A Worked Example: A Sales Intelligence Foundry Agent on AI Search
Picture a Foundry agent named sales-intelligence-agent running for an enterprise B2B SaaS company:
- It runs as a managed identity tied to the sales-research-mi service principal
- That managed identity holds Storage Blob Data Reader on the sales-collateral Storage Account and Search Index Data Reader on a regulated AI Search index containing pipeline data
- It uses an AzureAiFoundryModelDeployment of gpt-4o
- It calls one tool defined as a function over a CRM API
- It is wired to a vector store backing the company’s product knowledge corpus
- 36 Azure AD principals across 4 resource groups can invoke it through the project
Before Veza, surfacing all of that meant pulling Azure RBAC assignments, Foundry project configs, Cognitive Search index permissions, and managed identity role bindings from four different blades — and even then, no one could traverse it. With Veza, a security architect opens the Access Graph, types “show me what sales-intelligence-agent can read in AI Search and Storage,” and gets the answer in one query — with the human invokers upstream and the managed identity hop in between.
That’s the difference identity-first modeling makes for AI agents on regulated Azure data.
Answering Critical Security Questions
How do I see what a Foundry agent can actually reach in Azure?
Foundry agents do not hold permissions directly. They use Azure RBAC through service principals and managed identities, and that identity is where the real blast radius lives. Veza models the delegation as a clear graph path:
Foundry Agent → RUNS_AS → Service Principal / Managed Identity
→ HAS_RBAC_ROLE → Subscription / Resource Group / Resource
→ HAS_EFFECTIVE_PERMISSION → Storage / Key Vault / SQL / AI Search
Questions answered in a single query:
- Which agents can read or write specific Storage Accounts, Key Vaults, Cosmos DB containers, or Azure SQL databases?
- Does any agent’s managed identity hold Owner, Contributor, or other broadly privileged Azure roles?
- Which agents share a managed identity, and therefore share blast radius?
- Which agents reach across into AI Search indexes that contain regulated content?
Who can invoke or manage a Foundry agent?
In Azure, the right to invoke or administer a Foundry agent flows through Azure RBAC at the project, account, or subscription level. Veza wires those bindings into the graph:
Azure AD Principal → HAS_RBAC_ROLE → Foundry Project / Account
→ ON_RESOURCE → Foundry Agent
Questions answered:
- Who in the tenant can invoke or modify each Foundry agent — including service principals and groups?
- Which agents are exposed broadly via subscription-level roles versus locked down at the project?
- When a developer changes team or leaves, which agents do they retain — or lose — the ability to invoke?
- Which agents are visible to external guest users in the tenant?
What models, tools, and data sources are running under the hood?
Foundry binds agents to Model Deployments, Vector Stores, Indexes, Connections, and Tools. Veza inventories all of it:
- Which Model Deployments exist in the tenant — Azure OpenAI, third-party, or custom — and which agents use each?
- Which Vector Stores and Indexes back each agent’s RAG behavior, and what content lives in them?
- Which external Connections are wired into each project, and what credentials are stored on those connections?
- Which Guardrails are applied to which agents — and which agents are running without one?
- When a model is deprecated, which agents and capabilities are impacted?
What This Unlocks for Security and IAM Teams
For every Azure AI Foundry agent, Veza now surfaces:
- The agent and the service principal or managed identity it runs as
- The Azure RBAC roles and bindings that identity inherits across the subscription, resource group, and resource scopes
- The Storage, Key Vault, AI Search, and other Azure resources it can effectively reach
- The Model Deployments, Vector Stores, Indexes, Tools, and Connections wired into the project
- The Guardrails attached to each agent — and the ones missing
- The Azure AD principals that can invoke or manage each agent
That visibility plugs into everything Veza already does:
- Access Reviews — Foundry agents become reviewable entities alongside humans, service principals, and managed identities
- Blast Radius — over-privileged agents surface against the same risk model as any other identity in Azure
- Rules & Alerts — trigger on a new agent without an owner, a managed identity granted Owner at the subscription, an agent without a Guardrail, or an agent newly bound to a regulated AI Search index
- Access Graph search — natural-language and graph queries traverse the full chain from Azure AD principal to Foundry agent to underlying data
Frequently Asked Questions
Do I need a new connector to enable Veza for Azure AI Foundry? No. If you already have the Veza Azure integration in place, Foundry discovery is automatic on the next extraction. There’s no separate connector, no additional datasource, and no agent runtime to deploy.
Does Veza cover both the new Azure AI Foundry portal and the classic Foundry portal? At launch, Veza extracts agents created in the new Azure AI Foundry portal. Coverage of agents created in the Foundry (classic) portal is on the roadmap.
How does Veza handle the managed identity or service principal a Foundry agent runs as? The RUNS_AS edge is captured as a distinct hop, and the RBAC bindings on that identity are fully traversed across the subscription, resource group, and resource scopes. So you can answer “what can this agent reach” without leaving the Access Graph.
Can I run access reviews on Foundry agents the same way I do for human users? Yes. Foundry agents become reviewable entities in Veza Access Reviews, with the same campaign cadence, reviewer assignment, and risk-based prioritization you already use for humans, service principals, and managed identities.
Does Veza alert when a Foundry agent runs without a Guardrail? Yes. Rules & Alerts can fire on missing Guardrail attachments, agents whose managed identities hold Owner or Contributor, or agents newly bound to a regulated AI Search index.
How does this fit alongside Veza’s existing coverage of Microsoft Copilot Studio? They’re complementary. Copilot Studio governs business-user-built bots in Dataverse; Foundry governs developer-built agents in Azure. Veza models both as AI Agents in the Access Graph so security teams can reason about agents across the Microsoft cloud in one place.
Getting Started
Veza AI Agent Security for Azure AI Foundry is available now for existing Azure integrations. There is no separate deployment — once a Foundry account and project are in the tenant, Veza picks up agents, model deployments, vector stores, indexes, connections, tools, and identity bindings on the next extraction.
- Existing Veza for Azure customers — reach out to your account team to confirm enablement.
- New customers — request a demo to see the full Access Graph in action, including a live walkthrough of a Foundry agent traced from managed identity to AI Search index.
- Want to go deeper? Read the Veza AI Agent Security overview and the Veza for Azure solution brief.
Related Reading
Veza Expands AI Agent Security to Microsoft Copilot (launch blog)
Inside Veza’s AI Agent Security for Amazon Bedrock Agents (deep dive)
Inside Veza’s AI Agent Security for Google Cloud Vertex AI (deep dive)
Inside Veza’s AI Agent Security for Salesforce Agentforce and Einstein Bots (deep dive)
