Foundry Tools: Deployment Blocked by Unusual Activity — Persistent Error Since September 11, 2026

Hi GeneWhitley-6894 & thx for join me at Q&A platform,

Error 715-123420 is different from a normal quota, region, or deployment configuration failure. The message “Our system has detected this request as unusual activity for your account” indicates that the request is being rejected by an automated eligibility/risk check before the normal model deployment reaches Resource Manager.

The fact that it happens from both the portal and IaC, across different models/resources, and even with a second subscription makes a problem with text-embedding-3-small or the individual Foundry resource unlikely. It also explains why there is no corresponding failed deployment in the Activity Log: the request is being rejected before the ARM operation is created.

I wouldn't continue repeatedly recreating resources or submitting deployment attempts. Quota changes, resource-provider registration, or moving to another Foundry project won't normally clear this type of restriction.

This needs escalation to the Azure OpenAI/Foundry eligibility and abuse/risk review team. Provide the affected subscription IDs, tenant ID, exact UTC timestamps, error 715-123420, request/correlation IDs if available, and mention that the same failure reproduces in a second subscription. Ask support specifically to review the account/tenant eligibility state rather than troubleshoot the model deployment itself.

If Microsoft confirms that 715-123420 is being generated by their risk controls, there isn't a customer-side setting that can remove it. The restriction has to be reviewed and, if appropriate, cleared by the responsible Microsoft backend team.

rgds,

Alex

Hello @GeneWhitley-6894 ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

The current behavior suggests that the deployment request may be failing during an earlier validation stage before the model provisioning process begins. The error message itself does not expose the exact validation reason, so confirmation requires additional backend investigation.

Possible areas that may require review include:

• Subscription eligibility validation
• Subscription-level authorization checks
• Automated risk or trust validation controls
• Model deployment access validation

Regarding the request for an RTFP review, the available information does not conclusively confirm that an RTFP restriction is present. However, the observed pattern is consistent with scenarios where additional backend validation may be required to determine whether a subscription-level condition is preventing deployments from completing.

The following checks can help rule out common deployment blockers before backend investigation.

1. Confirming Model Availability Verify that the selected models are supported in the intended region and deployment type. Checks:
   • Confirm model availability for the selected Azure region.
   • Confirm that the selected deployment type (for example, Global Standard) is supported for the model.
2. Validating Quota and Capacity Availability Confirm that sufficient quota is available for:
   • Subscription
   • Region
   • Selected model deployment
   Quota or capacity issues normally return more specific quota-related messages. However, validating quota helps eliminate standard deployment limitations.
3. Verifying Resource Provider Registration Confirm that the required resource providers are registered and in a healthy state:
   • Microsoft.CognitiveServices
   • Microsoft.MachineLearningServices
   Expected status: Registered
4. Reviewing Governance and Policy Restrictions Review Azure Policy assignments that may restrict:
   • AI model deployments
   • Allowed regions
   • Resource types
   • Deployment configurations
5. Performing Additional Deployment Validation To determine whether the issue is limited to a specific deployment method or occurs at the service level:
   • Retry after a short interval to rule out temporary service behavior.
   • Attempt a deployment with a new deployment name to exclude deployment-specific inconsistencies.
   • Test deployment through Azure AI Foundry portal.
   • If possible, test through Azure CLI or ARM/Bicep to confirm whether the failure occurs at the service layer.

As an additional verification , please note that

For sponsored subscriptions, it may also be useful to confirm that the selected models appear under the appropriate model collection in Azure AI Foundry, as model eligibility and billing behavior can vary depending on the model source.

The following references might be helpful , please check them out

• Region availability for Foundry Models sold by Azure - Microsoft Foundry | Microsoft Learn
• Azure OpenAI in Microsoft Foundry Models Quotas and Limits - Microsoft Foundry | Microsoft Learn
• Azure resource providers and types - Azure Resource Manager | Microsoft Learn
• Overview of Azure Policy - Azure Policy | Microsoft Learn
• az cognitiveservices account deployment | Microsoft Learn
• Sponsorship Coverage for Microsoft Foundry Models | Microsoft Learn

We have reached out to you on private messenger for further assistance

Thank you