Skip to content

Deploy your first agent application

Deploy a private reference application with a web chat and a Foundry-hosted agent. The web chat is the user interface (UI). Complete these five stages on one page:

  1. Prepare the deployment and application login.
  2. Provision the private infrastructure.
  3. Connect to the Windows jumpbox and complete configuration.
  4. Finish application login and publish the agent.
  5. Test a task, denied access and a request trace.

This path uses Bicep, the reference application, Hosted execution and conversational mode. It creates a standalone Azure virtual network (VNet), Azure Firewall, NAT Gateway, Windows jumpbox and Azure Bastion.

Bastion provides browser-based access to the jumpbox without a public VM endpoint. The jumpbox is an administrator's virtual machine (VM) inside the private VNet.

Azure Container Registry (ACR) Tasks builds images in a VNet-connected agent pool. Local Docker is unnecessary.

The result is a configured pilot, not production-readiness certification. The first task uses supplied, non-sensitive text. Shared-document ingestion, retrieval-augmented generation (RAG), workflows, Model Context Protocol (MCP), SQL, history and feedback are later tasks. The reference agent is not a custom business application.

Cost and private access

Charges start when Azure resources are created, before application acceptance. This profile includes Firewall, Bastion, a VM and an ACR Tasks pool. Model use, runtime, storage and monitoring also incur charges.

Approve the resource inventory and cost estimate before provisioning. Keep the environment private throughout this procedure. Do not enable public service access or anonymous login to repair a failure.

1. Prepare the deployment and login

Computer: your initial Windows computer. Shell: PowerShell 7.

Confirm people, access and capacity

  1. Select one Azure subscription, tenant, supported region and unique azd environment name.
  2. Ask the Azure administrator to approve these permissions for the deployment operator.

    Operation Required access
    Deploy resources Contributor-equivalent actions on all three destination groups; permission to create missing groups
    Assign resource roles Scoped Microsoft.Authorization/roleAssignments/write, such as Role Based Access Control Administrator
    Configure services and build images Selected service data roles, App Configuration Data Owner, secret-management permissions and registry/build permissions
    Publish Hosted agents Foundry User-equivalent authoring on the exact project, plus Foundry account read access
    Recover jumpbox access Authorized VM password reset if the provisioning credential is unavailable
    Find the acceptance trace Foundry project access and Log Analytics Reader; protected tables can require Privileged Monitoring Data Reader

    Contributor alone cannot assign resource roles. Subscription Owner is not required when the approved scoped roles cover these operations. The permissions reference lists the selected service roles.

  3. Ask the Entra application administrator to perform the registration and consent actions below.

  4. Select one approved pilot user and one separate user outside the admission lists.
  5. Record both users' tenant IDs and user object IDs in the approved environment record.
  6. Confirm resource-provider registration, Responsible AI terms, regional service availability and model quota with the Azure administrator.
  7. Check the regional capacity caveats for the selected region.
  8. Stop if permissions, tenant consent, budget or capacity remain unapproved.

Separate identities serve separate purposes: the deployment operator, frontend, Hosted runtime and signed-in user are not interchangeable. CLI login authenticates the operator; it does not grant application admission or tenant consent.

Install tools and initialize the project

  1. Install Azure CLI, Azure Developer CLI, Git, PowerShell 7 and Python 3.12.
  2. Open PowerShell 7 on the initial computer.
  3. Initialize the project in an empty directory outside existing checkouts:
    $ErrorActionPreference = "Stop"
    $PSNativeCommandUseErrorActionPreference = $true
    New-Item -ItemType Directory agent-landing-zone
    Set-Location agent-landing-zone
    azd init --template Azure/agent-landing-zone --branch v7.1.0 --environment <environment-name> .
    

Initialization creates and selects the local environment. It does not deploy Azure resources.

  1. Keep the trailing . in the initialization command.
  2. Do not add --up or create the same local environment again.
  3. Confirm azure.yaml, manifest.json and main.parameters.json exist in the project root.
  4. Run all subsequent lifecycle commands from this project root.
  5. Prepare the Python environment:

    python -m venv .venv
    .\.venv\Scripts\Activate.ps1
    python -m pip install -r config/requirements.txt
    azd extension install azure.ai.agents
    
  6. Keep this Python environment active for lifecycle commands.

  7. Stop if organization policy blocks required tools or Python activation.
  8. Replace every command placeholder with an approved value before execution.
  9. Sign in to both CLIs:
    az login --tenant <tenant-id>
    azd auth login --tenant-id <tenant-id>
    az account set --subscription <subscription-id>
    azd env set AZURE_SUBSCRIPTION_ID <subscription-id>
    azd env set AZURE_RESOURCE_GROUP <foundry-resource-group>
    azd env set AZURE_APP_RESOURCE_GROUP <application-resource-group>
    azd env set AZURE_NETWORK_RESOURCE_GROUP <network-resource-group>
    azd env set AZURE_LOCATION <region>
    

The three new, dedicated groups contain Foundry, application and network resources respectively. Deployment scripts, called hooks, create missing application and network groups. The Azure Developer CLI creates the root Foundry group. One provision operation targets all three groups.

  1. Record the environment name, subscription, tenant, region and three group names in the approved nonsecret deployment record.
  2. Keep development, test and production resources, identities, configuration, secrets and data separate.

Register and authorize application login before provision

Entra application administrator — Microsoft Entra admin center

  1. Open Microsoft Entra admin center.
  2. Select App registrations > New registration.
  3. Enter a name for this environment's UI application.
  4. Select Accounts in this organizational directory only.
  5. Select Register.
  6. Record the Application (client) ID and Directory (tenant) ID in the environment's approved nonsecret deployment record.
  7. Open Expose an API in this registration.
  8. Set the Application ID URI to api://<client-id>.
  9. Add an enabled delegated scope named user_impersonation.
  10. Set api.requestedAccessTokenVersion to 2 in the registration's manifest.

The same registration is the UI's confidential web client and its exposed API. The UI needs an access token for this API, not an ID token or Microsoft Graph access token.

Do not enable public client flows to work around a token error.

Microsoft's registration and exposed-scope procedure describe the portal fields. The final callback needs the provisioned UI URL.

Check: The tenant/client IDs, API URI, enabled scope and version-2 token setting identify the intended environment.

Entra application administrator — UI app registration

  1. Open API permissions in the UI app registration.
  2. Add the UI API's delegated user_impersonation permission.
  3. Add the Foundry resource's delegated user_impersonation permission for downstream on-behalf-of (OBO) calls.
  4. Grant the consent required by tenant policy before onboarding users.
  5. Confirm the Foundry endpoint's token audience with its owner before provisioning.

These are two different APIs, despite their identical scope names. For the standard Foundry-resource authorization scheme (AzureRbac, also called Entra), the downstream scope is https://ai.azure.com/.default.

Do not substitute the UI API scope or a management-plane audience for the Foundry scope.

Protected native retrieval additionally needs Foundry-managed Search consent for https://search.azure.com/.default. The UI does not acquire or forward that Search credential. Shared Blob/ADLS citation downloads additionally need delegated Azure Storage user_impersonation consent for https://storage.azure.com/.default. These permissions do not grant source access.

Retain the source's role-based access control (RBAC) and access-control list (ACL) checks.

The Foundry client authorization procedure describes the downstream permission and consent. The UI exchanges the user's API token server-side. Consent does not grant permission to invoke the agent.

Check: Both API permissions have the required consent, and the Foundry audience matches the deployed authorization scheme.

This pilot uses user_delegated authentication. It uses OBO to invoke Foundry as the signed-in user. The standard Foundry-resource audience is used below.

Stop if the endpoint owner has not approved https://ai.azure.com/.default.

Select the private profile

Deployment operator — initial computer, selected azd environment

  1. Apply this profile before the first provision:

    azd env set ORCHESTRATION_HOST hosted
    azd env set APPLICATION_MODE conversational
    azd env set HOSTED_AGENT_AUTH_MODE user_delegated
    azd env set HOSTED_AGENT_RESOURCE_SCOPE https://ai.azure.com/.default
    azd env set DEPLOY_INGESTION_CONTAINER_APP false
    azd env set DEPLOY_AGENT_APP_MCP false
    azd env set ENABLE_CHAT_HISTORY false
    azd env set ENABLE_USER_FEEDBACK false
    azd env set ENABLE_PRIVATE_ATTACHMENTS false
    azd env set NETWORK_ISOLATION true
    azd env set DEPLOYMENT_MODE standalone
    azd env set USE_EXISTING_VNET false
    azd env set DEPLOY_AZURE_FIREWALL true
    azd env set DEPLOY_NAT_GATEWAY true
    azd env set DEPLOY_JUMPBOX true
    azd env set DEPLOY_BASTION true
    azd env set BASTION_SKU_NAME Standard
    azd env set BASTION_ENABLE_TUNNELING false
    azd env set DEPLOY_ACR_TASK_AGENT_POOL true
    azd env set HOSTED_AGENT_CAPTURE_MESSAGE_CONTENT false
    

    Note

    Some values already match the template defaults. You do not need to set them in a new environment. They are shown here to make the selected profile explicit.

  2. Ask the network operator to approve the new VNet's address plan in root main.parameters.json.

  3. Keep the selected subnets nonoverlapping with networks this environment must reach.
  4. Keep publicIngress.enabled set to false in root main.parameters.json.
  5. Save the reviewed root parameter file and all approved nonsecret environment inputs for the computer handoff.
  6. Do not edit the generated infra/bicep/main.parameters.json.

The baseline can provision backing services for later native retrieval. This procedure does not load documents or claim document authorization. The separate Agent App Ingestion service remains disabled.

Check: Registration and consent are complete; the selected environment has the approved private profile.

2. Provision the private infrastructure

Computer: initial computer. Identity: deployment operator.

  1. Review the selected components' declared outbound destinations:

    python -m config.deployment.egress --plan --environment <environment-name>
    
  2. Approve the selected destinations and purposes with the network operator.

  3. Set explicit post-provision deferral before creating resources:

    azd env set RUN_FROM_JUMPBOX false
    
  4. Validate the application binding before provisioning:

    azd hooks run preup
    
  5. Provision the infrastructure:

    azd provision
    
  6. Confirm the hook's Continue with Zero Trust provisioning? prompt after approving the private profile.

The secure vmAdminPassword input uses azd's $(secretOrRandomPassword) expression. There is no documented default password or guaranteed Key Vault copy. An unavailable credential requires an authorized VM password reset, described below.

Do not put passwords in source, shell commands, history or logs.

  1. Wait for successful infrastructure provisioning and the explicit deferral message:

    Post-provision configuration explicitly deferred; application setup is incomplete.
    
  2. Stop if provisioning fails or the expected deferral is absent.

  3. Record the deployed jumpbox VM and Bastion names from the network resource group in Azure portal.
  4. Preserve the original .azure/<environment-name>/resource-groups.json through the approved secure file-transfer process.

  5. Record the original parameter-file and binding hashes:

    Get-FileHash main.parameters.json -Algorithm SHA256
    Get-FileHash ".azure/<environment-name>/resource-groups.json" -Algorithm SHA256
    
  6. Record the bound application ID:

    azd env get-value AGENTLZ_APP_ID
    

The reference application's ID is agent-lz-default.

Expected result: The private network and access hosts exist. Application configuration, images and user acceptance remain incomplete. Placeholder responses do not prove application readiness.

3. Connect to the jumpbox and complete configuration

Open the Windows desktop through Bastion

Computer: initial computer. Browser: Azure portal.

  1. Open the deployed jumpbox VM in the network resource group.
  2. Use the VM's approved provisioning credential if it is available.
  3. Ask the authorized VM administrator to reset the password if that credential is unavailable.

For a reset, the VM administrator performs these actions in Azure portal:

  1. Open the jumpbox VM's Help > Reset password page.
  2. Select Reset password.
  3. Enter the deployed administrator username, normally testvmuser.
  4. Enter a new strong password from the organization's approved credential manager.
  5. Select Update.
  6. Transfer access to that credential through the approved secure process.

Do not put the password in a command, source file, screenshot or deployment record. Stop if the reset fails or the administrator cannot authorize it.

The connecting operator then performs these actions:

  1. Open the VM's Connect > Bastion page.
  2. Select the deployed Bastion instance.
  3. Enter the deployed VM administrator username and approved password.
  4. Select Connect to open the Windows desktop.

Computer handoff: All remaining deployment commands and private-service browsing run inside the jumpbox. The ACR Tasks pool does not connect the initial computer to private services. Portal Bastion access does not require native RDP tunneling.

Restore the same source, inputs and destination binding

Computer: jumpbox. Shell: PowerShell 7. Identity: the same approved deployment operator.

  1. Install or verify the tools listed in stage 1 on the jumpbox.
  2. Open PowerShell 7 inside the jumpbox.
  3. Fetch the exact source revision:

    $ErrorActionPreference = "Stop"
    $PSNativeCommandUseErrorActionPreference = $true
    git clone https://github.com/Azure/agent-landing-zone.git
    Set-Location agent-landing-zone
    git checkout --detach ef03a1248a9ee1de0a6023225a25fff7bae9577f
    git rev-parse HEAD
    
  4. Compare the reported commit with ef03a1248a9ee1de0a6023225a25fff7bae9577f.

  5. Stop if the revisions differ.
  6. Prepare Python and the Foundry extension in this checkout:

    python -m venv .venv
    .\.venv\Scripts\Activate.ps1
    python -m pip install -r config/requirements.txt
    azd extension install azure.ai.agents
    
  7. Authenticate both CLIs as the approved deployment operator:

    az login --tenant <tenant-id>
    azd auth login --tenant-id <tenant-id>
    az account set --subscription <subscription-id>
    
  8. Create the absent local environment once in this new checkout:

    azd env new <same-environment-name>
    

If that local environment already exists, use azd env select <same-environment-name> instead. Neither command provisions resources.

  1. Restore these artifacts through the organization's approved secure file-transfer process:

    Artifact from initial computer Destination on jumpbox
    Reviewed root main.parameters.json This exact checkout's root main.parameters.json
    Approved nonsecret deployment record Operator's protected working record
    Original .azure/<environment-name>/resource-groups.json Same relative path in this checkout
  2. Verify the transferred parameter file and binding match the originals with SHA-256 file hashes.

    Get-FileHash main.parameters.json -Algorithm SHA256
    Get-FileHash ".azure/<same-environment-name>/resource-groups.json" -Algorithm SHA256
    
  3. Do not transfer tokens, credentials, the virtual environment or the entire .azure directory.

  4. Do not generate or edit a replacement resource-group binding.
  5. Reapply the original target values:

    azd env set AZURE_SUBSCRIPTION_ID <same-subscription-id>
    azd env set AZURE_RESOURCE_GROUP <same-foundry-resource-group>
    azd env set AZURE_APP_RESOURCE_GROUP <same-application-resource-group>
    azd env set AZURE_NETWORK_RESOURCE_GROUP <same-network-resource-group>
    azd env set AZURE_LOCATION <same-region>
    
  6. Reapply the entire private-profile command block from stage 1 with the original approved values.

  7. Reapply any additional approved nonsecret inputs from the deployment record.
  8. Refresh the existing deployment outputs:
    azd env refresh
    

Refresh restores outputs, not the complete deployment configuration or immutable multi-group destination binding. The root group alone is insufficient.

  1. Compare the subscription and all three group names with the original deployment record.
  2. Stop if any target, input or binding differs from the original environment.
  3. Do not run another provision operation merely to reconstruct local state.
  4. Confirm the original application ID and this checkout's app-definition.json both identify agent-lz-default.
  5. Restore the same local application binding with the supported helper:
    python -m config.appdefinition --bind --env-name <same-environment-name>
    

Check private access and finish post-provision

  1. Read the selected environment's App Configuration endpoint:

    azd env get-value APP_CONFIG_ENDPOINT
    
  2. Resolve that endpoint's hostname from the jumpbox:

    Resolve-DnsName <app-configuration-hostname>
    Test-NetConnection <app-configuration-hostname> -Port 443
    
  3. Confirm the service address is private and the TCP check succeeds.

  4. Ask the network operator to repair DNS, routing or firewall failures before continuing.
  5. Clear deferral on the jumpbox:
    azd env set RUN_FROM_JUMPBOX true
    azd env set AZURE_SKIP_NETWORK_ISOLATION_WARNING false
    azd hooks run postprovision
    

The hook checks connectivity, configures services, reconciles selected roles and publishes platform outputs. RUN_FROM_JUMPBOX does not bypass connectivity checks.

  1. Stop if the hook reports a configuration, permission or private-link readiness failure.

For a reported Search shared private-link request, the resource owner must approve only that exact request. The request identifies its target and connection.

  1. Open the reported target resource's Networking > Private endpoint connections in Azure portal.
  2. Match the connection to the exact Search request reported by the hook.
  3. Approve that connection only after confirming its ownership and purpose.
  4. Rerun azd hooks run postprovision after the approved connection becomes ready.

Do not approve every pending connection or bypass the readiness gate.

  1. Verify published platform outputs without resolving credentials:

    az appconfig kv show --endpoint <app-configuration-endpoint> --key AGENTLZ_PLATFORM_OUTPUTS --label agent-lz --auth-mode login
    azd env get-value ACR_TASK_AGENT_POOL
    
  2. Confirm the ACR Tasks pool output is nonempty.

  3. Record the frontend Container App HTTPS URL from the application resource group's Container App Overview.

Expected result: Private configuration completes successfully. The selected services and VNet-connected build pool are ready for application publication. The UI still needs its final login settings.

4. Finish login and publish the application

Computer: jumpbox, including the browser used for private Azure services.

Configure the callback, secrets and admission before deploy

Entra application administrator — UI app registration

  1. Open Authentication > Add a platform > Web.
  2. Register the exact UI HTTPS callback:

    https://<frontend-hostname>/auth/oauth/azure-ad/callback
    
  3. Record the UI origin as https://<frontend-hostname>, without a trailing slash.

  4. Use this origin for CHAINLIT_URL in the application settings.
  5. Include any supported deployment prefix consistently in the origin and callback.
  6. Keep previous callbacks only while they remain approved and required.

Check: The callback matches the browser-facing scheme, host and path exactly. It is not the Foundry endpoint.

Entra application administrator and configuration operator — UI registration, environment Key Vault and App Configuration

  1. Open Certificates & secrets in the UI app registration.
  2. Create a client secret under the tenant's expiry policy.
  3. Open Secrets > Generate/Import in this environment's Key Vault.
  4. Select Manual.
  5. Name the secret ui-oauth-client-secret.
  6. Enter the client secret's value, not its secret ID, through the approved secure process.
  7. Select Create.
  8. Record the secret's expiry and rotation owner.

Do not copy the value into source, shell commands or logs.

  1. Open Configuration explorer in this environment's App Configuration store.
  2. Create a Key Vault reference named OAUTH_AZURE_AD_CLIENT_SECRET, with label agent-lz, pointing to ui-oauth-client-secret.
  3. Select the Key Vault reference type, not an ordinary string containing a secret or URI.
  4. Generate a stable CHAINLIT_AUTH_SECRET of at least 32 UTF-8 bytes through the approved credential-management process.
  5. Open Secrets > Generate/Import in the same Key Vault.
  6. Select Manual.
  7. Name this secret ui-session-signing-secret.
  8. Enter the generated session-signing value through the approved secure process.
  9. Select Create.
  10. Create its Key Vault reference named CHAINLIT_AUTH_SECRET, with label agent-lz, in the same App Configuration store.

Do not regenerate an existing session-signing secret during a routine update.

  1. Create the following nonsecret keys through Configuration explorer > Create > Key-value.
  2. Apply label agent-lz to each key.
  3. Enter each value as plain text.
Key Value
OAUTH_AZURE_AD_CLIENT_ID Application (client) ID from the UI registration
OAUTH_AZURE_AD_TENANT_ID Directory (tenant) ID from the UI registration
OAUTH_AZURE_AD_ENABLE_SINGLE_TENANT true
OAUTH_AZURE_AD_SCOPES api://<client-id>/user_impersonation,openid,profile,offline_access, with the UI client ID
CHAINLIT_URL Canonical UI HTTPS origin from the callback setup
ALLOW_ANONYMOUS false
HOSTED_AGENT_AUTH_MODE user_delegated for the default; service_identity only for the explicitly selected alternative

Do not add Graph scopes such as User.Read or the Foundry scope to OAUTH_AZURE_AD_SCOPES. Do not set the platform-derived RETRIEVAL_AUTH_MODE independently to bypass source authorization. Do not use arbitrary azd env set inputs to publish these UI runtime keys. Keep reviewed deployment declarations aligned with these values.

The configuration operator needs App Configuration Data Owner to write keys. The frontend needs App Configuration Data Reader and Key Vault Secrets User at the relevant scopes. The default lifecycle reconciles the frontend's secret-scoped grants from its Key Vault references during deployment. See default hosted permissions.

  1. Remove or update conflicting UI process-environment or other selected-label overrides.
  2. Preserve the platform's configuration ownership.

Application settings describes precedence.

Check: Both secrets are Key Vault references. The nonsecret keys have the intended values. The actual frontend identity must resolve the references before user acceptance.

Do not display resolved credentials as verification.

Configuration operator — environment App Configuration store

  1. Create ALLOWED_USER_PRINCIPALS with label agent-lz in Configuration explorer.
  2. Enter only approved users as comma-separated tenant-id:object-id values.

ALLOWED_USER_NAMES is an alternative list of sign-in names. The two lists combine with OR. Empty lists admit all successfully authenticated users. The callback does not fetch Graph group membership. These lists restrict UI admission, not Foundry access or document ACLs.

Do not leave both admission lists empty for a restricted pilot. Remove unapproved entries from either admission list.

Check: Only the approved pilot users appear in the admission settings. Each approved user also needs a separate Foundry caller grant.

  1. Include only the approved pilot user in the admission settings.
  2. Confirm the second test user is absent from both admission lists.
  3. Verify the Foundry project's Application Insights connection identifies this environment's monitoring resource.
  4. Keep prompt and response-content capture disabled.
  5. Stop if callback registration, secret references or admission settings remain incomplete.

Basic request traces do not require message-content capture.

Publish from the configured foundation

Deployment operator — jumpbox PowerShell 7, project root, selected environment

  1. Deploy the application:
    azd deploy
    

Deployment prepares the pinned Hosted image, publishes the agent and deploys the frontend. The private ACR Tasks pool builds the images; no local Docker installation is required. The lifecycle reconciles the actual Hosted runtime identity and frontend secret grants.

  1. Wait for successful agent publication and frontend deployment.
  2. Stop if a build, publication, role reconciliation or frontend deployment fails.
  3. Verify the frontend identity has App Configuration Data Reader on this environment's configuration store.
  4. Verify the frontend identity has Key Vault Secrets User on its two referenced authentication secrets.
  5. Allow new role assignments to propagate before testing.

The UI caches authentication settings at startup. A later login-setting change requires frontend restart or redeployment, then a new user sign-in. It does not require a Hosted-agent restart for a UI-only authentication change.

Grant the pilot user access to the published agent

Azure RBAC administrator — jumpbox PowerShell 7, approved subscription

  1. Obtain the published agent name, Foundry account name and project name from this deployment.
  2. Sign in to Azure CLI as the authorized RBAC administrator:

    az login --tenant <tenant-id>
    
  3. Substitute the approved pilot user's user object ID, not the UI client ID:

    $subscriptionId = "<subscription-id>"
    $agentScope = "/subscriptions/$subscriptionId/resourceGroups/<foundry-resource-group>/providers/Microsoft.CognitiveServices/accounts/<foundry-account>/projects/<project>/agents/<published-agent-name>"
    $pilotUserObjectId = "<approved-user-object-id>"
    az account set --subscription $subscriptionId
    az role assignment create --assignee-object-id $pilotUserObjectId --assignee-principal-type User --role "eed3b665-ab3a-47b6-8f48-c9382fb1dad6" --scope $agentScope
    

The role is Foundry Agent Consumer, scoped to this individual published agent. It allows invocation, not authoring. The portal's consumer-role picker currently uses account scope; this CLI command uses agent scope.

  1. Allow the caller grant to propagate before acceptance.
  2. Do not grant the denied test user UI admission.
  3. Do not replace a failed user grant with broader Owner or service credentials.

Expected result: The approved user has both UI admission and agent-scoped Foundry caller access. Tenant consent, UI admission, Foundry access and source permissions remain separate controls.

Note

This example grants access to one pilot user. For multiple users, assign Foundry Agent Consumer to a Microsoft Entra security group instead. Group members receive access to the agent.

5. Test a task and verify the boundaries

Computer: jumpbox. Browser: separate signed-out and test-user sessions.

Run a self-contained, non-sensitive task

  1. Open the frontend HTTPS URL in a signed-out browser session.
  2. Confirm chat is unavailable before login.
  3. Sign in as the approved pilot user.
  4. Confirm the browser returns through the registered HTTPS callback.
  5. Send this synthetic task:

    Use only the following non-sensitive planning note. Do not search or call tools.
    Prepare a short research draft for human review.
    Give three bullets: the objective, the next action, and one unresolved question.
    Do not invent dates, owners, prices or facts.
    
    Note: A community library wants to compare two workshop formats.
    Volunteers proposed an online session and an in-person session.
    The team has not chosen a budget, date or accessibility requirements.
    Its next action is to collect attendee preferences.
    
  6. Check that the answer compares the proposed workshop formats.

  7. Check that the next action collects attendee preferences.
  8. Check that the unresolved question concerns an unspecified budget, date or accessibility requirement.
  9. Reject invented facts, claims of tool execution or unsupported source citations.
  10. Record the request time, deployed agent version and available response or trace identifier.

Wording can vary; a literal response match is unnecessary. This tests the supplied-text reference-agent task, not ingestion, protected retrieval or document ACLs.

Confirm denied access

  1. Open a separate browser session as the user outside both admission lists.
  2. Confirm the application denies that user's access.
  3. Stop acceptance if signed-out chat or unapproved-user chat succeeds.
  4. Use only sanitized status and correlation fields to investigate failures.
  5. Do not capture tokens, secrets or private message content.

Find the request trace

Investigating operator — jumpbox browser, deployed Foundry project

  1. Open Agents > Traces in the deployed Foundry project.
  2. Select the published Hosted agent.
  3. Select a time range containing the recorded request.
  4. Find the request by trace ID, response ID or recorded time.
  5. Open its hosting operation and nested Agent Framework/model spans.
  6. Confirm the operation succeeded for the deployed agent version.

Service invocation telemetry alone does not establish that application spans were exported. Missing traces can indicate ingestion delay, wrong project, wrong Application Insights connection, insufficient access or exporter failure.

  1. Keep acceptance incomplete until the request trace is located.
  2. Do not enable message-content capture merely to find a trace.

Done: The approved user completed the task, signed-out chat was blocked, the unapproved user was denied, and the request trace exists. Documentation checks do not replace these live acceptance steps.

Next steps

Confirm ownership, retention and backups before resource deletion. Treat purge as a separate irreversible decision, not a deployment retry.

© 2026 Azure AI Landing Zones