Agents, identity, workflows, and routines

An agent identity is a Microsoft Entra ID identity type built for AI agents. Foundry creates and manages it through the agent lifecycle so the agent can reach tools and data without you pasting secrets into prompts, connection strings, or code. The same model applies to text-based prompt agents and voice-based prompt agents: when the agent calls a tool, Entra knows which agent is acting, not just which human signed in to the portal.

Concept 7 showed how to build a prompt agent with tools. Production agents often call Azure Storage, Logic Apps, Cosmos DB, Microsoft Graph, MCP servers, or other agents. Agent identity separates what the AI did from what people or other workloads did, keeps access right-sized, and scales when you create or delete many agents quickly.

• Governance: administrators can inventory agents, apply policies, and audit activity in Entra.
• Tool authentication: the agent reaches downstream systems with short-lived tokens instead of embedded passwords.
• Least privilege: you grant roles to the agent identity, not to every developer's personal account.
• Voice agents: Foundry manages the real-time voice session while the same identity authenticates tool calls.

Foundry ties each agent to two Entra objects you should recognize by name. An agent identity blueprint is the template for a class of agents (for example, all agents of one product line). It governs lifecycle operations and proves that Agent Service may act for that class. An agent identity is the runtime principal you assign permissions to when the agent needs access to a resource. When you create your first agent in a Foundry project, Foundry provisions a default blueprint and a default agent identity for that project.

• Shared project identity: all unpublished or in-development agents in the same project share one identity so you configure permissions once while experimenting.
• Find it in the Azure portal on your Foundry project Overview pane: select JSON View and choose the latest API version to copy identity details.
• Distinct agent identity: when permissions, audit trails, or lifecycle needs differ, publish the agent. Publishing creates a dedicated blueprint and identity bound to the agent application resource.
• After publish, tool calls use the new identity. Role assignments on the shared project identity do not carry over; assign roles again on the published agent's identity.

Unpublished agents authenticate to tools with the shared project identity. Published agents use their unique agent identity. Voice-based agents follow the same split. Treat the shared identity as a wider blast radius: if one agent needs tighter controls or its own audit trail, publish it and assign roles to the new identity only.

When an agent invokes a tool, Agent Service runs an OAuth token exchange with Microsoft Entra ID and the downstream resource. You do not store or refresh tokens in your app. At a high level, Agent Service proves it may act for the blueprint, Entra issues a token for the specific agent identity, Agent Service requests a new token scoped to the target service, and the tool endpoint receives that scoped token before it checks role assignments.

• Blueprint authentication: Agent Service uses the blueprint's credentials (often via the project's managed identity federated trust) to prove it may represent agents of that type.
• Agent identity token: Entra returns a token that identifies the agent as its own actor in the directory.
• Scoped token: Agent Service exchanges that token for an access token whose audience matches the downstream service you are calling.
• Tool call: the MCP server or agent-to-agent endpoint validates the token and applies RBAC or other authorization on the agent identity.

Agent identities support two authentication patterns. In an attended run, the agent works on behalf of a signed-in user: the app passes the user's token to Agent Service, which exchanges it so the agent carries both the agent identity and the user's delegated permissions. The agent can only reach resources that user already consented to. In an unattended run, the agent acts under its own authority with no human in the loop; access comes entirely from RBAC roles and other policies on the agent identity.

Assign Azure RBAC roles to the agent identity the same way you assign them to any service principal. Use the identity value from JSON View on the project or agent application as the assignee. Grant only what tools need at the narrowest scope (resource or resource group). For MCP and agent-to-agent tools, create a project connection that sets authentication to agent identity and the correct audience for the target service. Only some tools support agent identity authentication today; confirm in the tool documentation before you design around it.

Foundry offers three ways to package agent behavior. A prompt agent is defined by a model deployment, instructions, and tools; Foundry runs it with no container of your own. A hosted agent runs code you deploy, such as a Microsoft Agent Framework app or a LangGraph graph, on Foundry's managed runtime. A workflow is a visual sequence of steps, built in the portal builder, that runs multiple agents and business steps together. Pick the smallest shape that meets the requirement, then add complexity only when a single agent is not enough.

Workflows in Microsoft Foundry are in preview and Microsoft Foundry is retiring portal workflows on December 1, 2026. For new orchestration, Microsoft points teams to Microsoft Agent Framework; the visual designer and in-portal workflow execution stop after that date, though YAML definitions can continue when deployed as a hosted agent. Hosted agents are not supported inside the workflow designer; use Agent Framework workflows from hosted agent code instead.

Workflows are UI-based tools that blend AI agents with business logic in a visual builder. Templates cover common patterns: Human in the loop asks a person before continuing, Sequential passes each result to the next agent in order, and Group chat moves control between agents based on context or rules. You need Contributor role or higher on the project to create or edit workflows.

• Sign in to Microsoft Foundry with the New Foundry toggle on, select Build, then Create new workflow and pick a pattern such as Sequential.
• Select each agent node and assign an existing project agent or create a new one with model, prompt, and tools.
• Add nodes with the plus (+) icon: Invoke agent, Logic (if/else, go to, for each), data transformation, or basic chat steps.
• Select Save in the visualizer after every change; Foundry does not autosave workflows.
• Select Run Workflow and confirm each node completes and the chat window shows expected responses.
• Optional: turn on YAML Visualizer View to edit as YAML; each save creates a new version with full version history.

Use Power Fx for Excel-like formulas on variables (prefix Local. or System. for scope). Do not put secrets in JSON schemas, prompts, or saved workflow variables. If the Workflows option is missing or edits vanish, check project role assignments and confirm you clicked Save.

Routines in Foundry Agent Service run an agent automatically when a trigger fires, without someone starting each run. A routine has exactly one trigger and one action that invokes one prompt agent or hosted agent. Input can be text or JSON. Foundry records run history with status, outputs, and links to agent responses and trace details. Use routines for lightweight automation such as daily summaries, one-time reminders, or reacting to GitHub issue or Teams channel events. When you need branching, multiple agents, or human approval, use a workflow or orchestration in code instead.

• Trigger types: timer (run once then become inactive), recurring (cron-style schedule; API type schedule; minimum interval five minutes), and event (GitHub issue opened or closed, or Teams channel message via project connections).
• Dispatch identity defaults to agent identity for every trigger. Choose creator identity only when tools need delegated user access; that means the principal who creates the routine, fixed at creation time.
• Routines reuse the normal agent invocation path, work with virtual-network-secured projects, and do not support customer-managed key encryption.
• Not available in UK West, Switzerland West, Japan West, UAE North, or Norway East. Delivery retries up to five times; each downstream agent request has a 30-second timeout.

Example: an online shop keeps a prompt agent that summarizes open support tickets from Azure Storage through an MCP tool. While experimenting, the agent uses the shared project identity with Storage Blob Data Contributor on the storage account. For production, the team publishes the agent, assigns the same role to the new distinct identity, and adds a recurring routine that runs every weekday at 7 AM with a JSON input listing the queue name. They review routine run history and traces (Concept 13) after the first week. If a ticket tool needed the creator's personal Graph calendar, they would recreate the routine with creator identity instead of agent identity.

• Assigning RBAC to the shared identity but calling tools from a published agent (or the reverse). Match roles to whichever identity the agent uses today.
• Skipping role reassignment after publish. Treat publish as a new principal.
• Setting the wrong audience on an MCP or agent-to-agent connection even when RBAC looks correct.
• Expecting creator identity to mean the agent owner or connection author; only the routine creator counts.
• Using a routine when you need multiple agents or workflow agents; routines do not support workflow agents as actions.

You now have identity for secure tool access, workflows for multi-agent orchestration (with a migration path before the 2026 retirement), and routines for time- and event-driven runs. Concept 12 goes deeper on toolboxes, connection authentication, and governance for the tools these agents call.

• Blueprint, token exchange, shared vs distinct identity, and tool authentication details. Agent identity concepts in Microsoft Foundry
• Foundry roles, scopes, and permission planning for projects and agents. Azure role-based access control in Foundry
• Portal workflow builder, templates, Power Fx, preview terms, and migration before December 1, 2026. Build a workflow in Microsoft Foundry (Preview)
• Trigger types, dispatch identity, run history, and regional limits for routines. Routines in Foundry Agent Service