When to use this
- A model API key or credential is exposed publicly.
- Unknown traffic appears on your model endpoint.
- Legal, safety or vendor reasons require you to stop using a model now.
This is the platform-level switch. It stops everything using the endpoint, including legitimate apps. Tell stakeholders before or as you pull it.
Azure OpenAI levers
| Lever | Effect | Speed | Command |
|---|---|---|---|
| Regenerate both keys | Leaked key stops working; apps using keys break | Minutes | az cognitiveservices account keys regenerate -g rg-ai -n aoai-prod --key-name key1 (then key2) |
| Disable key auth | All key-based callers blocked; Entra ID callers continue | Minutes | az resource update --ids <id> --set properties.disableLocalAuth=true |
| Remove role assignments | Specific identities blocked | Minutes (token lifetime may delay) | az role assignment delete --assignee <id> --role "Cognitive Services OpenAI User" --scope <id> |
| Disable public network access | Only private endpoint traffic allowed | Minutes | az resource update --ids <id> --set properties.publicNetworkAccess=Disabled |
| Delete the model deployment | That model stops for everyone | Immediate, but recreating it takes time and quota | az cognitiveservices account deployment delete -g rg-ai -n aoai-prod --deployment-name gpt-4o |
Typical leaked-key sequence: disable key auth (if apps already use Entra ID) or regenerate keys and update the apps that need them from Key Vault.
Caution
Regenerating both keys at once breaks every app still using keys. If you can, regenerate the leaked key first, move apps to the other key, then regenerate the second.
Check who called during the exposure window: enable diagnostic logs (RequestResponse, Audit) to Log Analytics if not already on, and look for unknown IPs and identities.
Amazon Bedrock levers
Bedrock has no API keys in the classic sense; access is through IAM (and short-term/long-term Bedrock API keys where enabled; check your account settings).
| Lever | Effect | Command / place |
|---|---|---|
| Deny policy on a role or user | That principal blocked | aws iam put-role-policy --role-name app-role --policy-name deny-bedrock --policy-document file://deny-bedrock.json |
| Deactivate leaked access keys | Leaked IAM key stops working | aws iam update-access-key --user-name svc-x --access-key-id AKIA... --status Inactive |
| SCP deny at account / OU | Everything in the account(s) blocked from Bedrock | AWS Organizations → policies |
| Remove model access | Model no longer available in that account/region | Bedrock console → Model access |
deny-bedrock.json:
{ "Version": "2012-10-17",
"Statement": [{ "Effect": "Deny", "Action": "bedrock:*", "Resource": "*" }] }
Explicit denies win over allows, so this works even if other policies grant access. Narrow bedrock:* to the invoke actions if you want management access to keep working.
Verify the cut-off
- Azure: metrics
Requestsdrop to zero (or only expected callers); test call with the old key returns 401. - AWS: CloudTrail shows
AccessDeniedforInvokeModelfrom blocked principals; Bedrock invocation metrics drop.
Restore in a controlled way
- Issue new credentials only to known apps, from Key Vault / Secrets Manager.
- Prefer identity-based access (Entra ID, IAM roles) over keys, so the next incident is smaller.
- Re-enable network access or model deployments last, once callers are verified.
- Review usage and cost for the exposure window.
Prevent it next time
- No API keys in code or config files; secrets scanning on repos.
disableLocalAuth=trueon Azure OpenAI; managed identities only.- Private endpoints for model resources; gateway in front.
- Runbook with these exact commands, resource IDs filled in, tested in a drill.