Edit

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 take action, understand that Foundry provides infrastructure actions, not just runtime governance. When you disable, 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 disabling a Foundry agent, or stopping an agent application, over deletion when you need to take action against an agent. Disabling and stopping are 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 Foundry 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 affect the agent's underlying resources:

  • Disable and Enable take a Foundry agent's endpoint offline or bring it back online. The agent and its versions remain intact, but while disabled the agent rejects requests across all channels (Teams, Microsoft 365 Copilot, Foundry, APIs).
  • Stop and Start deallocate or provision the compute behind an agent application's deployments. The application and its deployments remain intact, but while stopped the agent rejects requests across all channels (Teams, Microsoft 365 Copilot, Foundry, APIs).
  • Delete permanently removes Azure resources. For agent applications, deletion includes the 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 disabling a Foundry agent, or stopping an agent application, over deletion. These actions preserve the option to resume 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 Foundry Owner) from the specific Foundry projects or resource groups.

    Important

    The Foundry RBAC roles were recently renamed. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager were previously named Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. You might still see the previous names in some places while the rename rolls out. The role IDs and core permissions are unchanged by the rename.

    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
View Foundry User
(Reader isn't sufficient)
Disable or enable Foundry User
Delete Foundry User

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. For Foundry agents, the preferred action is to disable the agent endpoint, which takes it offline without deleting anything. You can enable it again later. For agent applications, the equivalent action is to stop the application's deployments. Your choice of action and agent type determines which interface you use. Use the tabs in each section to identify the right interface for your scenario.

For Foundry agents, disable and enable the agent endpoint through the REST API or the Azure CLI. The Foundry portal supports deletion. Microsoft 365 Admin Center doesn't include actions for Foundry agents.

Interface Supported actions
Microsoft 365 Admin Center Not available
Foundry portal Delete
REST API or CLI Disable, Enable, Delete

The REST API examples use az rest commands to simplify authentication. The easiest way to run these commands is through Azure Cloud Shell. Cloud Shell requires no installation and uses your current Azure sign-in session. If you prefer to work locally, install the Azure CLI and sign in first.

For each REST API example, replace the placeholder values with your own subscription, resource group, Foundry account, project, and other resource names.

Disable or stop an agent

Take an agent offline without deleting it. For Foundry agents, disable the agent endpoint. For agent applications, stop the application's deployments. Both approaches are reversible and preserve the underlying resources.

Microsoft 365 Admin Center doesn't currently include disable and enable actions for Foundry agents. To disable or enable a Foundry agent, use the REST API tab.

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.

Microsoft 365 Admin Center doesn't support deleting Foundry agents. Use another interface to delete if truly necessary.

Related content

  • Last updated on