Failed to create deployment. Our system has detected this request as unusual activity for your account.

Question

When trying to deploy a model to one of my resources, I get this error: "Failed to create deployment. Our system has detected this request as unusual activity for your account."
I already have some models deployed on this resource. This is the first time I am seeing this error. I checked that the model is available in the region I am trying to deploy it in.

Answer 1

Hello Rahul Gandhi ,

Greetings! Thanks for raising this question in the Q&A forum.

This message is a fraud and abuse detection block, not a quota, RBAC, or region issue, so it won't be fixed by anything on your resource configuration. Microsoft's automated fraud detection systems periodically flag deployment requests as unusual activity, most often when there's a sudden change in deployment pattern, a new model type or region being requested for the first time on that resource, or the subscription tripping a broader anomaly signal, even though everything about your setup and existing deployments is legitimate. There is no self-service way to clear this flag from the portal.

1. Do not keep retrying the deployment repeatedly. Rapid repeated attempts after a fraud flag can reinforce the system's signal rather than clear it.

Open an Azure Support request, since this can only be resolved by the Azure fraud and abuse review team, not general technical support. In the Azure portal, go to

Help + Support > Create a support request

Select Subscription Management or Billing and Subscription Management as the issue type, which does not require a paid support plan. In the description, state clearly that a Foundry model deployment attempt returned "Our system has detected this request as unusual activity for your account," and mention that you already have working deployments on this same resource, which helps support confirm this is a false positive rather than a genuine policy violation.

Include the resource name, subscription ID, and the approximate timestamp of the failed deployment attempt in the ticket, since the fraud detection review team needs this to locate the specific flagged event in their backend logs.

If you have a Microsoft account team or CSP partner, looping them in can sometimes speed up review, since fraud-detection holds are reviewed by a small internal team separate from standard Azure support queues.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.