Rediger

Govern agent infrastructure as a Microsoft Entra administrator

As a Microsoft Entra administrator, you might need to take action on Microsoft Foundry agents in your tenant. Before you do, understand that Foundry gives you infrastructure actions, not just runtime governance. When you stop or delete an agent, you operate on Azure resources. These resources might serve multiple tenants or teams.

This article helps you:

  • Get the access you need
  • Understand how admin center actions map to Azure resource operations
  • Make informed decisions about when and how to intervene

The guidance here focuses on infrastructure-level governance of agents built with Foundry Agent Service as a fallback for situations that require direct administrative action.

Important

Always prefer Stop over Delete when you need to take action against an agent. Stopping is reversible. Deletion permanently removes Azure resources and can affect other tenants.

Prerequisites

Important

AI Administrators: You can't perform the access elevation procedure yourself. You should coordinate with the agent owner first, who can either:

  • Take the infrastructure actions on your behalf
  • Grant you necessary Azure role assignments on the specific resources

If you can't identify or reach the agent owner, coordinate with a Global Administrator as an alternative.

Understand how agent infrastructure works

Foundry agents live within projects. Projects are part of a Foundry account resource in an Azure subscription. A project gives developers a shared workspace to build, test, and collaborate on agents. Each project has its own compute, storage, and a shared agent identity. Multiple agents can exist within a single project. Actions against the project affect all agents in that project.

Developers create Foundry agents within a project. Each agent gets a unique identity and endpoint for interaction. Foundry automatically registers each agent with the Agent 365 registry using the agent's unique identity.

Agents can have multiple agent versions as developers iterate and improve their functionality. Each version represents a snapshot of the agent's configuration and behavior at a specific point in time.

Note

Prompt agents can also use a common endpoint that serves all agents in the project. Agents that run this way share the project's infrastructure and identity. Don't use project endpoints for production. Foundry doesn't create more registrations in Agent 365 for project endpoints or project identities.

When a developer publishes an agent, Foundry creates a dedicated agent application resource. This resource has its own endpoint and Entra agent identity. The application identity is separate from the individual agent identities created earlier. Foundry also registers the application in the Agent 365 registry using the application's unique identity.

Agent applications can have multiple agent deployments. Each deployment references an existing agent version as its definition.

For a full description of agent lifecycle operations, see Manage agents in Foundry Control Plane. To learn more about Foundry concepts referenced in this section, see:

Infrastructure actions vs. admin center actions

The actions available in the Foundry Control Plane are infrastructure operations on Azure resources. They're different from the Block and Unblock actions you might be familiar with in Microsoft 365 Admin Center.

Block actions in Microsoft 365 Admin Center and Teams Admin Center affect agent visibility to users:

  • Scope: Only affects agent projection in Teams and Microsoft 365 Copilot
  • Impact: Users can't access the agent through these specific channels
  • Foundry Access: The agent remains fully functional in Foundry portal and other integration points
  • Infrastructure: No impact on underlying Azure resources or compute

Infrastructure actions in Foundry Control Plane affect the agent's underlying resources:

  • Stop and Start operate on individual deployments by deallocating or provisioning compute. They affect the underlying Azure infrastructure and make the agent unavailable across all channels (Teams, Microsoft 365 Copilot, Foundry, APIs).
  • Delete permanently removes Azure resources. For published agents, deletion includes the agent application and its deployments. This action can't be undone.

If an agent application serves a multitenant scenario, infrastructure actions affect all consumers of that agent, not just your tenant's users.

Always prefer Stop over Delete. Stopping preserves the option to restart later. Delete should be a last resort, used only after you coordinate with resource owners and confirm the agent should never run again.

Identify the Foundry resource type for an agent

The Agent 365 registry shows a unified inventory of Foundry agents and agent applications. Both are "agents", but they have different management capabilities. To know what options you have, you first need to identify which Foundry resource type you're dealing with.

Foundry registers both types with a Foundry Azure resource ID:

Resource type Resource ID pattern1
Foundry agent .../projects/{project-name}/agents/{agent-name}
Agent application .../projects/{project-name}/applications/{application-name}

1 The full resource ID pattern is omitted for brevity. Both share a common prefix: /subscriptions/{sub-id}/resourceGroups/{group}/providers/Microsoft.CognitiveServices/accounts/{account-name}/projects/{project-name}/.... The key differentiator is the segment after the project: either agents/{agent-name} or applications/{application-name}.

In Microsoft 365 Admin Center, you can find these values in the "Platform details" section. The admin center automatically detects the resource type. For agent applications, it shows Stop or Start buttons or prompts you for elevation if you're eligible.

Coordinate with resource owners

Foundry agents require Azure resources organized within specific subscriptions, resource groups, and projects. Those resources have owners. Before you take infrastructure-level action, identify and work with those owners whenever possible.

When to coordinate vs. act independently

Situation Recommended approach
Active security threat or policy violation Act first (stop the agent), then notify the resource owners.
Routine compliance review or audit finding Contact the resource owners and work together on remediation.
Agent consuming unexpected resources or cost Notify the resource owners. Consider stopping the agent only if costs are critical and owners are unresponsive.
Agent misbehaving but not a security risk Contact the resource owners before taking action. Stop only if the behavior is actively harmful.

Infrastructure governance is a shared responsibility. Global administrators have the access to act. Resource owners have the context to understand the impact. Coordinating leads to better outcomes.

Identify resource owners

Start by checking the owners listed in the agent registration details in Microsoft 365 Admin Center. You can also identify owners and sponsors through the Entra objects.

If you can see the Azure resources (elevate access if you can't - see the next section), check which users have permission over the resources:

  1. In the Azure portal, navigate to the resource group that contains the agent's Foundry project.
  2. Select Access control (IAM) > Role assignments to see who has permissions over the resource.

Resource stakeholders might have many different roles. Privileged roles like Owner or Contributor are a good signal. However, not all stakeholders have these privileged roles.

Check the Activity Log for the resource. The log shows who took management actions recently. This approach helps you identify current resource managers, even if they don't have privileged role assignments.

Elevate access to manage Azure subscriptions

Microsoft Entra ID and Azure use separate access control systems. Your administrator role doesn't automatically give you access to Azure subscriptions. To see and manage Azure resources that back Foundry agents, you need Azure role assignments. If you don't have the right permissions, elevate your access.

The elevation procedure requires the Global Administrator role. AI Administrators should coordinate with agent owners or Global Administrators. See the Prerequisites for details.

Elevation assigns you the User Access Administrator role at root scope (/). This role gives you visibility into all subscriptions and management groups in your tenant.

For the full procedure, see Elevate access to manage all Azure subscriptions and management groups.

Important

Remove your elevated access as soon as you finish. Elevation at root scope is a powerful permission, and the principle of least privilege applies. Follow the de-elevation procedure when you complete your tasks.

If your organization uses PIM, deactivate your Global Administrator role assignment after you remove the elevation toggle.

Remove elevated access

When you finish your admin tasks, remove your elevated permissions in reverse order:

  1. Remove Azure role assignments: Remove any Azure AI roles you gave yourself (such as Azure AI Owner) from the specific Foundry projects or resource groups.

    Azure portal:

    1. In the Azure portal, navigate to the resource where you assigned yourself roles.
    2. Select Access control (IAM) > Role assignments.
    3. Find your user account in the role assignments list.
    4. Select the assignment and choose Remove.

    Azure CLI:

    # List current role assignments to find the assignment ID
az role assignment list --assignee <your-email> --scope <resource-scope>

# Remove the specific role assignment
az role assignment delete --ids <assignment-id>

  2. Remove User Access Administrator role: Remove the root-level User Access Administrator role from the elevation procedure.

    Azure portal:

    1. In the Azure portal, go to Microsoft Entra ID > Properties.
    2. Under Access management for Azure resources, set the toggle to No.
    3. Select Save.

    Azure CLI:

    # Remove the User Access Administrator role at root scope
az role assignment delete \
  --assignee <your-email> \
  --role "User Access Administrator" \
  --scope "/"

This two-step process ensures you remove both the specific permissions you granted yourself and the broad elevation that enabled those grants.

Assign the right roles

After you elevate your access, assign yourself the minimum role needed for your action. Don't stay at root scope longer than necessary.

Action Minimum built-in role for Foundry agent objects Minimum built-in role for Agent applications
View Azure AI User
(Reader isn't sufficient)		 Reader
Stop/Start Not supported Azure AI Owner
Delete Azure AI User Azure AI Owner

Assign roles at the narrowest scope possible. For Foundry agents, assign the role over just the Foundry project resource you want to work with. For agent applications, assign the role at the application scope. If you only need to manage agents in a single resource group, assign the role at the resource group scope. Don't assign these roles at the subscription or management group scope.

If your organization uses PIM, consider creating eligible assignments instead of permanent ones. Eligible assignments require activation. This approach creates an audit trail and enforces time limits.

Take action on an agent

When you need to intervene, choose the least disruptive action for your situation. Your choice of action and agent type determines which interface you use to manage the agent. Use the tabs in each section to identify the right interface for your scenario.

Microsoft 365 Admin Center includes Foundry agents in your full agent inventory. You can conveniently stop and start agent applications directly from the registry entry.

Agent type Supported actions in Microsoft 365 Admin Center
Agent applications Stop, Start
Foundry agents None - use another interface

Stop an agent

Stopping an agent is the preferred approach for most situations. Stopping disables the agent without destroying resources. You can restart the agent later.

When you open the agent details page for a Foundry agent application, Microsoft 365 Admin Center automatically checks if you have the necessary permissions to manage the agent. If you do, a Stop or Start button is available at the top of the page, based on the current state of the application. If you don't see these buttons but are a Global Administrator, follow the prompt to automatically elevate your access and grant yourself the Azure AI Owner role over the agent application.

If your agent application is currently running, select Stop to stop it. This action stops every agent deployment associated with the application. The agent application and its deployments still exist. You can start them again later.

When you're ready to start the agent application again, select Start. This action starts the agent application's most recent deployment. If you need to start other deployments, use the REST API.

If you elevated your access, make sure to remove it when you're done.

Delete an agent (last resort)

Deletion permanently removes agent resources and can't be undone. Before you delete, verify that no other tenants or teams depend on the agent, and confirm that the resource owners agree with permanent removal.

Deleting Foundry agents isn't supported in Microsoft 365 Admin Center. Use another interface to delete if truly necessary.

Related content

  • Last updated on