We're a small startup dealing with roughly US$14,000 in unauthorized Azure OpenAI usage overnight. A compromised API key exhausted our Microsoft for Startups credits and created additional pay-as-you-go charges, although we're still confirming the exact split. The activity included models we don't use, unfamiliar source IPs, and a massive increase in requests. Rotating both keys immediately brought the usage back to zero, and MFA was already enabled.
We opened a support case with an incident timeline and evidence. Microsoft assigned an engineer and said they would investigate, but so far they haven't been able to process a waiver, may restore the startup credits if they confirm the compromise, and couldn't guarantee that automatic collection would be paused.
We later identified the likely cause: our website was running an outdated Next.js version with a critical unauthenticated code-execution vulnerability. The site's container had an Azure key in its environment even though the website didn't need it. After patching the application, rotating the key, rebuilding the container, restricting secrets to only the services that use them, checking the host, and enabling usage alerts and request logging, the abnormal traffic stopped.
For anyone who has experienced a similar Azure or Azure OpenAI incident: did Microsoft waive the charges, provide a partial adjustment, or restore consumed startup credits? How long did the investigation take, and were charges collected while it was ongoing? Did escalation or a one-time goodwill request make a difference? I'm especially interested in real outcomes, including cases where Microsoft refused.
3 Answers
The long-term fix is to keep secrets out of workloads that don’t need them. Store keys in a proper secrets service or key vault, use private connectivity where practical, limit permissions and network access, and give each service its own credential. Also add spend and usage alerts, request logging, and rate limits so a compromised key can’t run unchecked for hours.
Open billing and subscription support cases, and involve your cloud provider or CSP if you use one. Explain that the traffic was clearly abnormal, include the timeline, unfamiliar IP addresses, model usage, and the fact that rotating the keys stopped the activity. Keep following up and ask for escalation rather than relying on a single ticket. In one similar case, Microsoft reviewed about $40,000 in unexpected usage, confirmed there was no data movement, and refunded or voided the charges. The process took a couple of months, so a quick resolution isn’t guaranteed.
Support may be more cautious now because there are so many preventable key-exposure incidents. Be transparent about the root cause and show every remediation step, but don’t assume a waiver is automatic. Depending on how the attacker got in, Microsoft may also want evidence that the environment was checked for persistence or broader compromise. A developer mistake doesn’t necessarily rule out goodwill, but it can affect the review.
That’s what I’m worried about. We found the vulnerable website, patched it, rebuilt the container, removed the unused Azure secret, and checked the host for signs that the attacker escaped the container.
Our usual daily token spend is around $1,000 at most, but the compromised period reached roughly 400,000 tokens and dropped to zero immediately after rotation. I’m documenting that contrast and asking whether this can be handled as a one-time goodwill adjustment.