Cannot deploy model in AI Foundry "715-123420: unusual activity for your account"

Edmund Pafko 0 Reputation points
2026-08-20T08:47:17.78+00:00

I set up a new subscription and can't deploy any model in AI Foundry. Every attempt fails instantly with: "715-123420: Our system has detected this request as unusual activity for your account."

Trace ID: ab416755-49f7-452b-ae3a-d9bcb8515e52

Client request ID: fc36fd5b-b6d8-4c6e-9914-04bbdfd71b7e

Service request ID: 4c87fff9-51f2-4ea0-a011-dbb5246e84c6

The subscription is new but has an active payment method, and I have quota available for the model. I first created a Foundry resource in Poland Central, deleted it, and made a new one in Sweden Central the error started after that, so I suspect the delete/recreate tripped some automated check.

It's not a portal issue: the same deployment via Azure CLI fails identically. Billing support says it needs a paid technical plan.

Has anyone hit this? Does the flag clear on its own?

Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Ganesh Gurram 7,320 Reputation points Microsoft External Staff Moderator
    2026-09-04T04:58:37.2833333+00:00

    Hi @Edmund Pafko

    Thank you posting your query in MS Q&A forum.

    Could you please let us know if the issue has been resolved? if not, we have contacted you through a private message and requested additional details. Please share the requested information to help us proceed with the investigation.

    Was this answer helpful?

    0 comments
  2. Jerald Felix 18,680 Reputation points Volunteer Moderator
    2026-08-20T16:14:14.5333333+00:00

    Hello Edmund Pafko,

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

    The error you are seeing is not a quota, RBAC, or regional availability problem. Error 715-123420 is generated by Microsoft's automated fraud and abuse detection system that runs behind Azure AI Foundry and Azure OpenAI deployments. It is a subscription-level risk flag, separate from the resource provider itself, which is why the failure is instant and identical whether you go through the portal or the CLI. New subscriptions are scored more aggressively by this system, and creating a Foundry resource, deleting it, and immediately recreating one in a different region is a very common trigger, since that pattern resembles behavior seen in abuse attempts (rapid resource churn across regions on a fresh subscription).

    This flag does not clear on its own in most cases and there is no portal setting or CLI flag that resets it. It has to be reviewed and lifted manually on Microsoft's backend.

    Here is how to proceed:

    1. Open an Azure support ticket specifically as a "Subscription Management" or "Quota" issue, not a general technical issue. Because this is a fraud/risk flag rather than a code or configuration bug, it should not require a paid technical support plan. If billing support redirected you, ask them to re-route the case to the Subscription and Billing support team as a subscription unblock request rather than closing it, since these fraud-flag cases are typically handled without a paid plan.
    2. Include all three identifiers you already captured in the ticket: Trace ID ab416755-49f7-452b-ae3a-d9bcb8515e52, Client request ID fc36fd5b-b6d8-4c6e-9914-04bbdfd71b7e, and Service request ID 4c87fff9-51f2-4ea0-a011-dbb5246e84c6, along with the UTC timestamps of your deployment attempts and the subscription ID. These let the backend team locate the exact fraud detection event without needing to reproduce it.
    3. Mention the resource churn explicitly (created in Poland Central, deleted, recreated in Sweden Central) since that is very likely what the detection system flagged, and naming it up front speeds up triage.
    4. Do not delete and recreate the resource again while waiting. Additional churn on the same subscription can reinforce the flag rather than clear it.
    5. Once the ticket is filed, deployments typically resume within one to a few business days after manual review, though there is no published SLA for this specific flag since it is a fraud control rather than a standard service limit.

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

    Best Regards,

    Jerald Felix.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.