Microsoft Foundry Agent Service Security Guide

Agents hosted in Microsoft Foundry Agent Service call tools, MCP servers and Azure resources with their own Microsoft Entra identities, so a weak role assignment, a static key in a connection or a public endpoint turns one agent into an access path across the tenant. Foundry now gives each new agent its own agent identity, built on the Entra agent identity model, alongside project managed identities, user delegation and key-based connections. This guide explains how those identities work, which Foundry roles to grant, how to secure tool and MCP connections, how to isolate the network, what to log and a hardening baseline. It is for Azure platform, identity and security teams running pro-code agents in Foundry. It goes deeper than the Azure OpenAI and Azure AI Foundry Security Guide, which covers the model platform as a whole. Details were checked against Microsoft Learn on 27 October 2026; several features are in preview and role names were recently changed, so confirm against current documentation.

Key takeaways

Each new agent has its own Entra identity. An agent identity blueprint governs one or more agent identities (special service principals), so permissions and audit can be scoped per agent. Legacy agents share one project identity and lack that separation.
New agent identities start with no access. Foundry does not assign downstream permissions. Grant the narrowest Azure RBAC or data-plane role on the specific resource, using the agent identity's object ID.
Use the renamed Foundry roles precisely. Foundry User for builders, Foundry Agent Consumer for callers, Foundry Project Manager for team leads, Foundry Account Owner for admins who should not build. Avoid Foundry Owner.
Keys bypass RBAC. Key-based authentication to a Foundry resource grants full access with no role restriction, and custom-key MCP connections store static secrets. Prefer Entra authentication and agent identity for tools.
Private networking is a creation-time decision. Standard setup with your own VNet, storage, search and Cosmos DB keeps agent data in your tenant, but network injection for hosted agents cannot be added later.

How identity and access work in Microsoft Foundry Agent Service

Four identities can be involved in one agent run, and each needs separate permissions.

Identity	What it is	Used for	Key point
Agent identity blueprint	Parent Entra object that models the agent and governs its identities	Lifecycle operations and obtaining runtime tokens for its agent identities, through a Foundry-provisioned federated identity credential	No client secret or certificate to manage
Agent identity	Special service principal under the blueprint, one per agent instance	Calling downstream resources, MCP servers and A2A endpoints	Starts with no permissions; appears in the Entra admin center agent inventory
Project managed identity	System-assigned managed identity of the Foundry project	Some tool connections and, in standard setup, access to your Cosmos DB, AI Search and Storage	Hosted-agent code cannot use it; tokens default to the agent's own identity
Signed-in user	The human calling the agent	Delegated (on-behalf-of) tool access	The agent needs the delegated permission and the user needs access to the resource

How a tool call is authenticated

Blueprint authentication: Agent Service presents the blueprint's credentials to Entra ID.
Agent identity token: Entra ID issues a token for the specific agent identity, distinct from user or managed identity tokens.
Scoped token: that token is exchanged for one whose audience is the target resource, for example https://storage.azure.com. The audience is the resource that accepts the token, which may differ from the tool's endpoint URL.
Authorised call: the resource validates the token and checks its own authorisation (Azure RBAC, a data-plane role such as Cosmos DB's, app roles or service-specific policy) before granting access.

The agent can act application-only, under its own authority, or delegated, on behalf of the signed-in user. Tool support differs: Microsoft lists Work IQ MCP as on-behalf-of-user only, and support for one mode does not imply the other. Delegated access and the AgentBlueprint endpoint authorisation scheme were in preview when checked. The underlying model is covered in the Microsoft Entra Agent ID Guide.

Migration resets access: moving a legacy agent from the shared project identity or an Agent Application to the current model changes its identity, and existing role assignments do not transfer. Plan the re-grant before migrating, and remove grants from the old shared identity afterwards.
Tenant-wide governance: agent identities appear in the Microsoft Entra admin center alongside agents from other services, where Conditional Access, Identity Protection, network controls, owners, sponsors and expiration can be applied.

Admin roles and privileged access

Microsoft renamed the Foundry roles (Azure AI User became Foundry User, Azure AI Project Manager became Foundry Project Manager, Azure AI Account Owner became Foundry Account Owner and Azure AI Owner became Foundry Owner). Role IDs and permissions did not change, so existing assignments still work, but older names may appear in some places.

Role	Can build (data actions)	Publish agents	Call agent endpoints	Manage models, create resources	Assign roles	Grant to
Foundry Agent Consumer	No	No	Yes	No	No	Apps and users that only call agents, at project or single-agent scope
Foundry User	Yes	No	Yes	No	No	Developers at project scope, plus Reader on the resource
Foundry Project Manager	Yes	Yes	Yes	No	Foundry User only	Team leads
Foundry Account Owner	No	No	No	Yes	Foundry User, ACR and monitoring roles	Platform admins who should not see data
Foundry Owner	Yes	Yes	Yes	Yes	Foundry User, ACR and monitoring roles	Avoid unless no isolation is needed

Separate control and data planes: Foundry Account Owner manages models and resources without data access; Foundry User has data access without resource management. Fine-tuning needs both, which only Foundry Owner combines, so prefer pairing the two narrower roles for the people who need it.
Avoid legacy roles: Microsoft advises against Cognitive Services roles and Azure AI Developer for Foundry work, except Cognitive Services Usages Reader at subscription scope for quota visibility.
Connections are privileged: creating a project connection, which stores API keys or bearer tokens for tools, requires Foundry Project Manager. Anyone with that role can attach a credential that every agent in the project can use.
Use groups and PIM: assign roles to Entra groups rather than individuals, make Project Manager, Account Owner and Owner eligible through Privileged Identity Management rather than standing, and review them regularly. See the Entra ID Security Guide.
Portal side effect: the person who deploys a Foundry resource from the portal is assigned Foundry User automatically if they can assign roles. SDK and CLI deployments do not do this, which explains inconsistent access between environments.

Integrations, API tokens and service accounts

MCP and other tool connections are where agent credentials accumulate. Foundry supports six authentication types for remote tool connections.

Auth type	Credential	Risk	Use when
`agentic-identity`	The agent's own Entra identity, scoped token with an audience	Lowest: no stored secret, per-agent audit	Default choice where the server accepts Entra tokens
`user-entra-token`	The caller's Entra user context	Agent can do what the user can within the delegated scope	Data the agent should only see as the user
`project-managed-identity`	Project system-assigned managed identity	Shared by every agent in the project	Where a tool requires it
`oauth2`	OAuth app (Foundry-managed for a short list of servers, otherwise your own registration)	Client secret and refresh tokens to manage	Third-party SaaS servers
`custom-keys`	Static headers, for example `Authorization: Bearer` with a personal access token	Highest: long-lived, shared, rarely rotated	Only when nothing else is supported, with least-privilege tokens and rotation
`none`	No credential	Public servers only	Public, read-only data

Approvals: require_approval defaults to always. Keep it for tools that write data or change resources, use the per-tool form to relax it only for read tools, and review the tool name and arguments in each mcp_approval_request before approving.
Tool allowlists: set allowed_tools; without it the agent gets every tool the server exposes.
Untrusted servers and content: Microsoft states it does not test or verify third-party remote MCP servers. Treat tool descriptions, annotations and results as untrusted input that can carry indirect prompt injection, prefer servers hosted by the provider itself rather than proxies, and log what you send. See the MCP Security Guide.
Grant on the target, not the project: for identity-based connections, assign the agent identity, user or project managed identity the required role on the target resource, at the narrowest scope. Foundry's own role does not cover Azure Container Registry, Application Insights or custom resources that hosted agents need.
Keys on the Foundry resource: disable local (key) authentication where your clients support Entra ID; stolen AI service keys have been abused at scale, as the LLMjacking campaigns against Azure OpenAI accounts showed.

Logging and detection

Source	What it shows	Configuration notes
Foundry tracing to Application Insights	OpenTelemetry spans such as `invoke_agent` and `execute_tool`, with `tool.call.arguments` and `tool.call.results`	Connect Application Insights in the project's Tracing page; content recording via `AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED` is off by default and may capture personal data
Microsoft Entra sign-in and audit logs	Token issuance to agent identities and blueprints, role and credential changes	Stream to the SIEM; filter on agent identity object IDs. See the Entra ID Sign-In and Audit Log Detection Guide
Azure Activity Log	Role assignments, connection and capability host changes, network changes	Alert on role assignments at agent, project and account scope
Defender for AI Services	Alerts for jailbreak, data leakage, data poisoning and credential theft; works with Prompt Shields; alerts flow to Defender XDR	Covers Azure OpenAI and Azure AI Model Inference text tokens; check coverage of your agent traffic
Target resource logs	Data-plane access by the agent identity (Storage, Cosmos DB, Key Vault)	Enable diagnostic settings on each resource the agent can reach

Detections worth building: role assignments granted to agent identities at subscription or resource group scope; new custom-keys connections; an agent identity token used against an audience it has never used before; approval responses for write tools outside working hours; agent identities without an owner or sponsor; Defender for AI alerts correlated with the agent's Entra identity. For NHI-specific analytics, see the Detection Engineering for Non-Human Identities Guide.

Hardening baseline

Choose the setup up front. For production, use standard setup with private networking: bring your own Azure Storage, Azure AI Search and Azure Cosmos DB, and a dedicated subnet delegated to Microsoft.App/environments (minimum /27, /24 recommended). Network injection for hosted agents must be set at account creation.
Keep public access off. Accounts and projects default to public network access disabled; keep it that way, create private endpoints for the BYO resources yourself (they are not created automatically) and configure the privatelink DNS zones.
Grant the project managed identity data-plane roles on Cosmos DB, AI Search and Storage only, and give the provisioning identity Storage Blob Data Contributor and Cosmos DB Operator only for provisioning.
Assign Foundry roles to groups using the table above, with PIM for Project Manager, Account Owner and Owner.
Migrate legacy agents off the shared project identity so each agent has its own identity, then re-grant the minimum permissions per agent.
Prefer agent identity for tools, keep require_approval on write tools, set allowed_tools, and restrict custom-keys connections to an approved list with rotation dates.
Govern agent identities in Entra: owners, sponsors and expiration on each, Conditional Access for agents where supported, and access reviews.
Turn on evidence: tracing to a private Application Insights, Entra and Activity logs to the SIEM, Defender for AI Services on the subscription.
Pilot and roll back: test each agent in a non-production project with the same network design; to roll back an over-grant, remove the role assignment from the agent identity, which takes effect without redeploying the agent.

Framework mapping

Foundry control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat addressed
Per-agent identity, scoped RBAC, Foundry roles	AC-2 Account Management, AC-6 Least Privilege	PR.AA-05	ATT&CK T1078.004 Cloud Accounts
Agent identity for tools instead of keys	IA-5 Authenticator Management	PR.AA-05	ATT&CK T1528 Steal Application Access Token; T1552.001 Credentials In Files
Approvals and `allowed_tools`	AC-3 Access Enforcement, AC-6	PR.AA-05	OWASP LLM06:2025 Excessive Agency; ATLAS AML.T0053 AI Agent Tool Invocation
Private networking, BYO resources	SC-7 Boundary Protection	PR.PS-01	Data exfiltration through public endpoints
Untrusted tool content handling	SI-4 System Monitoring	DE.CM-09	OWASP LLM01:2025 Prompt Injection; ATLAS AML.T0051.001
Tracing, Entra logs, Defender for AI	AU-2 Event Logging, SI-4	DE.CM-09	Undetected agent misuse

Common misconfigurations

Granting the shared project identity broad access. Every legacy agent in the project inherits it, and audit cannot tell agents apart.
Assuming migration keeps permissions. After moving to per-agent identities, tools fail and teams re-grant broadly under time pressure. Script the minimum grants in advance.
Foundry Owner for everyone. It combines building, publishing, model management and role assignment, which removes the separation the other roles provide.
Static PATs in custom-key connections. One broad token becomes available to every agent in the project and is rarely rotated. Use agent identity or OAuth.
Approvals set to never for convenience. Write and delete tools then run on any instruction the model receives, including injected ones.
Assuming private networking covers everything. In the azd hosted agent preview the agent endpoint stays public, private endpoints for BYO resources must be created separately, and some tools (File Search with Blob files, Code Interpreter file handling) are limited in isolated networks.
Key authentication left enabled. Keys bypass RBAC entirely, so a key in a config file or notebook is full access to the resource.

Practitioner checklist

Inventory agents and confirm each has its own agent identity, owner and sponsor in Entra.
Grant downstream access per agent at the narrowest scope, using the agent identity's object ID.
Map people to Foundry Agent Consumer, User, Project Manager and Account Owner through groups; avoid Foundry Owner; put admin roles behind PIM.
Use agent identity or user tokens for MCP and tool connections; limit and rotate any custom-key connections.
Keep require_approval on write tools and set allowed_tools on every MCP tool.
Deploy standard setup with private networking and private endpoints for every BYO resource.
Disable key-based authentication on Foundry resources where clients support Entra ID.
Send tracing, Entra and Activity logs to the SIEM and enable Defender for AI Services.
Alert on broad role grants to agent identities and new static-key connections.

Microsoft Foundry Agent Service Security Guide: Agent Identity, RBAC, Networking and Tool Controls