Azure AI Services common annotated security key

ID

azure_ai_services_key

Severity

high

Remediation Complexity

trivial

Remediation Risk

high

Remediation Effort

low

Vendor

Azure AI Services

Family

API Token

Description

Azure AI Services resources, including Azure OpenAI and Azure AI Foundry deployments, now issue keys in Microsoft’s common annotated security key (CASK) format. The format embeds fixed markers so that a leaked key can be recognized and attributed without any surrounding context.

84 characters: 52 random base-64 characters, the JQQJ99 or JQQJ9D marker, 18 characters of date, platform and provider data, the ACOG Azure AI Services provider signature, and a 4-character checksum.

When the resource endpoint appears in the same file, it is used to check whether the key is still live; a confirmed live key is escalated to critical.

Security

A leaked Azure AI Services key grants an attacker the same access as the application that owns it:

  • Unauthorized usage is billed to your account, and automated high-volume calls can run up a large charge before anyone notices.

  • Whatever is sent through the leaked key — prompts, documents, query results — is exposed to whoever holds it.

  • The key does not expire on its own, so the exposure lasts until it is revoked.

Examples

The following is a leak of an Azure AI Services key:

AZURE_AI_SERVICES_KEY=sLaXoGN2...JQQJ99...ACOGTmnA

Mitigation / Fix

  1. Follow your policy for handling leaked secrets, which normally requires revoking the key. In the Azure portal, open the Azure AI Services / Azure OpenAI resource and go to [Resource Management > Keys and Endpoint]. Switch the application to the key that did not leak, then click "Regenerate" on the leaked one.

    Revoke the leaked key, do not merely disable it.

  2. Remove the leaked key from the source code or committed configuration file, and replace its usages with the new value. Environment variables, local files or secret vaults could be used for passing the key, instead of hardcoding the value, as documented in How to Prevent Hard-Coded Secrets.

  3. Review the usage and audit logs for the key, to confirm that it was not used by unintended actors while it was exposed.

  4. Apply the usual precautions for API keys: never commit them, pass them through environment variables or a secret manager, use a separate key per environment, monitor usage for unusual spikes, and rotate them periodically.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

Reference