Understand Microsoft Foundry Agent Service
Microsoft Foundry Agent Service is the current, generally available service for building, deploying, and scaling AI agents in Microsoft Foundry. It replaces the earlier hub-based Azure AI Agent Service (classic), which is deprecated and retires on March 31, 2027. Use current Microsoft Foundry Agent Service guidance for new agent workloads and migration plans.
An agent is an AI application that combines a model, instructions, and tools to reason over requests, access data, and take actions. Foundry Agent Service manages hosting, scaling, identity, observability, and enterprise security for prompt agents, workflow agents (preview), and Hosted agents (preview), so you can focus on agent logic.
A managed service doesn't remove your security responsibilities. Plan controls in these categories:
- Authentication and authorization: Require Microsoft Entra ID authentication where possible. Use Foundry RBAC instead of keys because keys bypass role restrictions. Assign Foundry roles at Foundry resource and Foundry project scopes, and use least privilege.
- Managed identities and tool access: Use agent identities, project managed identities, or OAuth On-Behalf-Of (OBO) when tools need delegated user access to Azure resources or external APIs. Give the actual calling principal only the permissions needed for its tools.
- Data-source scoping: Limit each agent's connected data sources and tools to the data it should retrieve or change. Prefer scoped connections and data-plane roles over broad account keys.
- Network isolation: Distinguish inbound private endpoints from outbound private agent isolation. All Standard setups require BYO Azure Storage, Azure AI Search, and Azure Cosmos DB resources so agent data stays in your Azure tenant. When you combine Standard Setup with private networking, private endpoints for those BYO resources aren't created automatically and must be configured separately. Basic setup can use inbound private access, but it doesn't provide outbound private network isolation for agents. Azure AI Search in a private virtual network requires keyless Microsoft Entra authentication with the project managed identity.
- Content safety and prompt-injection defenses: Apply guardrails and content filters to user input and output. Agent guardrails are in preview. When assigned to an agent, an agentic guardrail fully overrides the underlying model's guardrail for that agent; if no agentic guardrail is assigned, the agent inherits the model's guardrail. Model guardrails alone don't scan tool calls or tool responses. Tool call and tool response scanning works only when you configure those intervention points, only for supported tools, and only for risks that are supported for agents. Include Prompt Shields controls for user prompt attacks and document attacks (indirect prompt injection via untrusted content such as retrieved documents or tool responses). In the guardrails system, document attacks correspond to the Indirect attacks risk category. Apply these controls at the supported intervention points (user input and, for supported tools, tool response).
- Monitoring and observability: Enable tracing, metrics, logs, and Application Insights integration to review model calls, tool invocations, safety events, and operational health. Tracing is generally available for prompt agents only; workflow, Hosted, and custom agent tracing is in preview. Treat traces as sensitive telemetry because they can contain prompts, outputs, tool arguments, tool results, secrets, and personal data.
Important
Hosted agents have extra RBAC and runtime identity requirements. The agent creator needs Foundry Project Manager at the Foundry project scope to create the agent and assign Foundry User to the agent identity. To publish agents or deploy agent applications, the same role is required at the Foundry resource (account) scope instead. At runtime, the Hosted agent's agent identity (the dedicated Microsoft Entra ID that Foundry creates automatically at deploy time) needs Foundry User on the project, and the project managed identity needs Azure Container Registry pull permissions, such as Container Registry Repository Reader or AcrPull, on the registry that stores the agent image. A project managed identity with Foundry User on the Foundry resource alone isn't sufficient for Hosted agent deployment or runtime image pulls.
These controls help reduce the blast radius of agent actions while keeping the agent observable and governable through Microsoft Foundry.