Deploy Agent Mission Control

AMC is delivered as an Azure managed application. Deploying it creates a dedicated, single-tenant instance inside your own subscription, and your data never leaves it.

Applies to: release 2026.10.16 (October 2026). Release versions use the date-based format YYYY.MM.DD; this release carries the same code as the earlier 0.0.25 build.

Time required: about 15 minutes of your attention, plus roughly 25 minutes of unattended deployment.

Before you begin

Permissions

If your organization separates these duties, a directory administrator can do the Entra work (Steps 1 and 3). Only Step 2 needs subscription permissions.

Resource providers

The deployment fails early with MissingSubscriptionRegistration if any of these providers isn't registered in the target subscription. Most subscriptions already have them:

Microsoft.Solutions · Microsoft.App · Microsoft.ContainerInstance · Microsoft.Sql · Microsoft.Cache · Microsoft.KeyVault · Microsoft.ServiceBus · Microsoft.OperationalInsights · Microsoft.Insights · Microsoft.Storage · Microsoft.Network · Microsoft.ManagedIdentity · Microsoft.Security

One more provider, Microsoft.EventGrid, isn't used by the deployment itself but by malware scanning of uploaded files (Microsoft Defender for Storage), which creates an Event Grid system topic next to the file storage account. The deployment succeeds without it; scanning doesn't work. Register it before you deploy, and read the known issue below.

az provider register --namespace Microsoft.ContainerInstance

Choosing a region

Pick a region that supports Azure Container Apps, Azure SQL Database and Azure Managed Redis. Managed Redis is the most restricted, so check it first. This release is validated in West US 2.

What gets created

Everything below lives in a managed resource group that Azure creates alongside the instance. You can view these resources, but the group is locked for writes: the application owns its own infrastructure.

Known issue: malware scanning of uploaded files

In release 2026.10.16, on-upload malware scanning may not activate on a managed instance even though the deployment reports success. The setting is written, but Defender's own follow-up (its scanner role and Event Grid topic inside the managed resource group) doesn't always complete, and the setting then reads back as disabled. On an affected instance every uploaded file stays in Scanning… and can't be opened or downloaded; human-in-the-loop requests, runs and everything else work normally. We've seen this on upgraded instances and haven't yet verified a fresh installation either way.

If you hit it, contact the publisher with the instance's name and managed resource group. Re-enabling scanning is done on our side, and the fix for the deployment template is tracked. Registering Microsoft.EventGrid beforehand is a prerequisite for the fix, not a fix by itself.

Step 1: Register the sign-in application in Microsoft Entra ID

AMC signs your users in with your own Entra directory. It never stores passwords and never sees your users' Entra tokens beyond the sign-in exchange. Create the registration in advance (recommended); the inline option on the deployment form doesn't expose every setting.

1. 1In the Azure portal, go to Microsoft Entra ID > App registrations > New registration.
2. 2Enter a name, for example Agent Mission Control.
3. 3Under Supported account types, select Accounts in this organizational directory only (single tenant). The portal preselects a multi-tenant option; change it.
4. 4Leave Redirect URI empty and select Register. You add redirect URIs in Step 3.
5. 5On Overview, copy the Application (client) ID. You need it in Step 2.

Create a client secret

1. 1Go to Certificates & secrets > Client secrets > New client secret.
2. 2Enter a description and an expiry. We recommend 12 months.
3. 3Select Add, then copy the secret Value immediately. Entra shows it only once.

Add the email optional claim

AMC identifies users by their Entra object ID and displays their email address. Work accounts don't receive an email claim by default.

1. 1Go to Token configuration > Add optional claim.
2. 2Select ID, then email, then Add.

If you skip this, users can still sign in, but their display email is derived from their user principal name, which isn't always their real address.

Step 2: Deploy the managed application

1. 1In the Azure portal, open the AMC offer and select Create.
2. 2Complete the wizard using the tables below.
3. 3On Review + create, select Create.

Basics

Identity & Tenant

Choosing how to claim the Super Admin role

Every installation needs one first administrator. Fill in the Super Admin object ID, or leave it blank:

Start the deployment

1. 1Select Review + create. The portal validates your entries and reports any field it can't accept.
2. 2Select Create.

Deployment takes about 25 minutes, mostly the database, the cache and the Container Apps environment. The application containers start last, after a one-time setup task applies the database schema, seeds your tenant and creates the instance's signing key.

You can close the portal; the deployment continues. To follow it, open your resource group and select Deployments, or watch the managed application's Overview. When the provisioning state reaches Succeeded, continue with Step 3.

If the deployment fails, there's nothing to repair in place. Delete the managed application, fix the cause (see Troubleshooting), and deploy again with a new managed resource group name.

Step 3: Register the redirect URIs

1. 1When the deployment succeeds, open the managed application and select Settings > Parameters and Outputs.
2. 2Copy the values of clientUrl and entraRedirectUri (or read them with the CLI command below).
3. 3Open your app registration from Step 1 and select Authentication.
4. 4Under Platform configurations, select Add a platform > Web (or edit the existing Web platform).
5. 5Add both URIs from the table below, then select Save.

az managedapp show --resource-group <group> --name <instance> \
  --query "properties.outputs.{clientUrl:clientUrl.value, redirect:entraRedirectUri.value}"

Step 4: First sign-in

1. 1Browse to the clientUrl value.
2. 2Sign in with an Entra account from your directory.

• •You nominated a Super Admin: the role is assigned automatically when that person signs in. Others can sign in too, but hold no permissions until an administrator grants them.
• •You left the fields blank: the app shows Finish setting up this installation and asks for the setup code. Read superAdminBootstrapCode from Parameters and Outputs (or with the command below), enter it, and select Claim Super Admin.

az managedapp show --resource-group <group> --name <instance> \
  --query "properties.outputs.superAdminBootstrapCode.value" -o tsv

The role is granted immediately and the code is destroyed: the deployment's copy stops working and the stored secret is deleted. It can't be claimed again, including after you later remove that administrator. An installation left with no Super Admin is recovered with the publisher's help: a redeployment into the same managed resource group issues no new code, and a new deployment starts with an empty database.

Step 5: Verify the deployment

Step 6: Connect email

AMC sends no email until a tenant connects its own SMTP service in Settings > Notifications. A Tenant Admin configures their own tenant; a Super Admin can configure any tenant by signing in to it. Until then, that tenant's notifications are logged as skipped and its admins see an email-off banner. Everything else works without email.

• •Presets: Exchange Online (OAuth), and Other SMTP server (any service with a username and password, SendGrid included). A preset fills in the server, port, TLS mode and login method; you enter the secret.
• •TLS is required: STARTTLS on port 587 or implicit TLS on port 465. The server needs a public internet address.
• •The secret (password, API key or client secret) is stored in the instance's Key Vault and never shown again.
• •Send test email sends to your own address and shows the result at once.

For the in-app steps, see Set up email notifications (SMTP).

Troubleshooting

For a support request, include the managed application's name, its managed resource group name, the deployment's correlation ID, and the postdeployStatus output.

Operate and maintain

Connecting a workflow or agent

The deployment asks nothing about your orchestrator. You connect workflows and agents inside the application once it's running, each with its own endpoint and credentials. Register as many as you need, from more than one orchestrator, and change them without redeploying. See Register your agent.

• •A key you provide: stored in the instance's Key Vault and presented on every call. Nothing else is required.
• •The instance's managed identity: AMC calls the endpoint as itself, with no shared secret to distribute or rotate. Available for Microsoft Foundry endpoints, and it needs one grant on your side. For an endpoint of your own it's not available on a Marketplace installation: the installation-wide list of endpoints allowed to receive the managed-identity token is empty and isn't part of the deployment form, so the registration is refused with a message to use an API key instead. Use a key for your own endpoints.

Granting the instance's identity access

For managed-identity authentication, grant the instance's identities access to the resource after you register it. The instance runs under six identities and all six need the grant: different parts of AMC call your endpoint (starting, executing and streaming runs, polling status, and starting budget-released and scheduled runs). Granting only one leaves scheduled or executed runs failing with a permission error on an otherwise healthy instance. Collect all six principal IDs from Parameters and Outputs.

For a Microsoft Foundry endpoint, assign the built-in role Foundry User (53ca6127-db72-4b80-b1b0-d745d6d5456d) to each principal ID at the scope of the Foundry account, not the project.

An endpoint of your own can't use the managed identity on a Marketplace installation (see above), so there's nothing to grant for it.

Rotating the client secret

Deleting an instance

Deleting the managed application deletes its managed resource group and everything in it, including the database. Export anything you need first. The Key Vault stays recoverable for up to 90 days and its name derives from the managed resource group name, so a replacement deployment must use a new name.

Upgrading an instance

An instance upgrades in place: the release's deployment template re-runs into the existing managed resource group. Nothing is recreated, the database and managed identities are kept, and the application stays reachable throughout (a proven run takes 5 to 17 minutes). You don't redeploy the managed application or touch Microsoft.Solutions.

Email after an upgrade

After upgrading from a release without per-tenant SMTP, email stays off for every tenant until a Tenant Admin or Super Admin configures it in Settings > Notifications (Step 6). Nothing else is affected.

The promotion gate

A release reaches instances only after the publisher promotes it: a reviewed, human-approved step that moves the release pointer every instance's update check reads. Until then an instance reports no update. Promotion is per release, so once promoted, every instance is offered the same release.

What the Update button does

In Settings > System, a Super Admin sees the promoted release and can select Request update. AMC sends a signed request to the publisher, which verifies it came from your instance and queues it. The request moves from Requested to InProgress when the publisher's upgrade executor picks it up, and ends as Applied <version> or Failed <reason>. The executor runs in the publisher's own subscription under a managed identity, and acts only on an instance's own verified request for a release a human has already promoted.

What the executor refuses, and why

The executor stops and records a one-word reason rather than guess. A refusal never changes the instance, every outcome shows in Settings > System, and every start is logged on the publisher side.

If you need the publisher to act

Tell your publisher the instance identifier (the instanceId deployment output) and the version you expect. The publisher can start the same upgrade by hand, review the preview, and run it with any tolerance the release needs.

Rolling back

A rollback is the publisher running the same procedure with the previous version, forced past the already-newer check. Images and configuration converge back; the database schema doesn't. That's why every release's schema changes are expand/contract (add first, remove one release later): a release never drops or renames anything the previous release still uses. A release that deliberately drops something says so in its release notes and is never rolled back across the drop; the way forward is the next release.

Reference

Deployment outputs

The deployment also emits six managed-identity principal IDs: apiPrincipalId, streamingPrincipalId, statusSyncWorkerPrincipalId, budgetWorkerPrincipalId, schedulerWorkerPrincipalId and runExecutorPrincipalId. You need them only if you connect a workflow that authenticates AMC by managed identity. See Connecting a workflow or agent.

Related content

• •Register an application with the Microsoft identity platform
• •Optional claims in Microsoft Entra ID
• •Azure managed applications overview