Azure AI API key compromise: Can Microsoft recover historical source IPs without diagnostic logs?

Hi Tony Cephas & thx for join me at Q&A platform,

u've already identified the main limitation correctly. Azure Monitor metrics can confirm request volume, throttling, and usage patterns, but they can't identify the source IPs behind individual API requests. And if diagnostic logging wasn't enabled during October 10–16, those historical request logs can't be generated retroactively.

However, that doesn't necessarily mean Microsoft has no internal telemetry from that period. Azure services maintain operational telemetry for various purposes, but whether the Azure AI service team retains historical client IP information, how long it's retained, and whether it can be disclosed to customers aren't publicly guaranteed. Only Microsoft engineering can confirm what's available for this particular resource and incident window.

I'd open a technical support case under Azure AI Services / Azure OpenAI and explicitly request a suspected API key compromise investigation, rather than a general monitoring or logging question. Ask support to engage the service engineering or security incident team and verify whether any retained backend request metadata can identify client IPs, network origins, or other useful indicators for October 10–16.

Regarding the support plan, Developer is the lowest-cost paid Azure technical support option, but it's limited to Severity C and business-hours responses. For a production security incident, Standard support is the more appropriate option, as it supports higher-severity cases and 24/7 engagement. Billing support is free, but it isn't a substitute for this technical investigation.

Even if Microsoft can't provide historical IP addresses, I'd ask whether engineering can confirm request patterns, affected deployments, API operations, response codes, token consumption, and any unusual traffic characteristics from retained service telemetry. They may be able to validate some of these details internally without necessarily being able to export raw request records.

It's also worth separating suspected compromise from confirmed compromise. Hundreds of thousands of successful requests and HTTP 429 responses are definitely worth investigating, but they don't prove that an external party obtained the key. An application retry loop, leaked credential, or unexpected client workload could produce similar metrics.

For evidence outside the Azure AI resource, check whether requests passed through API Management, Application Gateway, Front Door, or another proxy that was already collecting access logs. Existing application logs might also contain request IDs or outbound connection timestamps. Azure Activity Log can help investigate management operations such as key retrieval or regeneration, but it doesn't provide a history of every inference request authenticated using an API key.

If the key hasn't been rotated yet, I'd treat it as compromised and rotate it immediately, while preserving the existing evidence. There's no reason to wait for Microsoft to confirm the source IP before containing potentially unauthorized access.

For the support case, provide the resource ID, exact UTC incident window, exported metrics, estimated unauthorized usage, and any available request or correlation IDs. Ask Microsoft to preserve and review whatever relevant backend telemetry is still within its retention period.

The main question for Microsoft is whether historical data-plane request metadata exists for this resource and can be used in a customer security investigation. That's not something Azure Monitor or a Q&A moderator can determine, and I wouldn't promise that engineering can recover or disclose those IPs.

If the incident also generated unexpected charges, I'd open a separate billing case referencing the technical investigation, so the usage dispute and security review can be tracked together.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer