715-123420 "unusual activity" on Microsoft.CognitiveServices/accounts preflight – only for one service principal, user validation succeeds

Support case 2610120050003557 was redirected to Q&A, so I am posting the details here. Identifiers (subscription, tenant, service principal, resource names, tracking IDs) are available via private message.

Problem

ARM preflight for Microsoft.CognitiveServices/accounts (API version 2026-05-01) intermittently fails with inner error 715-123420:

Our system has detected this request as unusual activity for your account. If you are confident this is in error, please contact support.

Setup

• Three existing Cognitive Services accounts (two AIServices in West Europe, one OpenAI in Switzerland North) with model deployments, managed as Bicep deployment stacks.
• Deployments run from GitHub Actions; authentication is a dedicated Entra service principal via OIDC federation (no secret or certificate). It is used only by one private repository.
• The error is returned during preflight (deployments/validate as part of az stack group create), so nothing is deployed.

What we observed

• First occurrence: 2026-09-07, on the third apply that day. Earlier the same day the service principal had just received Contributor on the resource group, and its first two applies (which created the deployment stack and PUT the accounts and model deployments) succeeded.
• Eight blocked preflights in total: 2026-09-07 (3x), 2026-09-22, 2026-09-23, 2026-10-07 (2x), 2026-10-12.
• In between, the same service principal and template applied successfully many times (accounts/write, accounts/deployments/write, raiPolicies/write, including creating a new account on 2026-10-02).
• The September blocks were gone within 15 to 23 hours (the 2026-09-22 block still applied to a retry about 21 hours later; the attempt after that succeeded). After the 2026-10-07 blocks we did not retry until 2026-10-12, when the first Cognitive Services write attempt in five days was refused again. We have not retried since.
• The template was unchanged in several of the blocked runs, so it is not tied to a specific property change.

Isolation test (requested by support)

On 2026-10-12, 52 minutes after the service principal was refused, we ran the same template as validate-only under a user account in the same tenant:

az deployment group validate --resource-group <rg> --template-file ai.bicep

Result: Succeeded. The Microsoft.CognitiveServices/accounts preflight passed without 715-123420. So the block appears specific to the service principal (or its automated request path), not to the subscription or the resources. Quota, region availability, provider registration and policy are not the cause: the same template validates for a user and previously applied for the service principal.

Mitigation on our side

We moved the AI resources into their own deployment stack that is applied only on demand, so routine infrastructure applies no longer re-PUT the Cognitive Services accounts. We are not retrying until the block is reviewed, to avoid adding to the signal.

Request

Could a Microsoft moderator please route this to the Real-Time Fraud Protection (RTFP) backend team, as was done for the similar thread "how to fix 715-123420" (July 2026), so the block on our service principal can be reviewed and lifted? I can share the subscription ID, resource IDs, service principal IDs and all tracking IDs by private message. We would also like to know which request pattern triggers it, so we can adjust our automation and avoid it.