Microsoft Foundry Content Filter Modified or Deleted
Description
Identifies the creation, modification, or deletion of a content filter (RAI policy) or a custom blocklist on a Microsoft Foundry (Azure AI Services) account. Content filters decide which prompt and completion categories, jailbreak attempts, and protected material a model deployment blocks. An adversary with control of the account can weaken or remove these filters so that harmful prompts and outputs are no longer blocked or logged as filtered, which removes a guardrail and the detections that depend on its verdicts.
Query · kuery
data_stream.dataset: "azure.activitylogs" and
azure.activitylogs.operation_name: (
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/RAIPOLICIES/WRITE" or
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/RAIPOLICIES/DELETE" or
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/RAIBLOCKLISTS/WRITE" or
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/RAIBLOCKLISTS/DELETE"
) and event.outcome: "success"
Investigation fields
Pivot points the source recommends for triage.
@timestampazure.activitylogs.operation_nameazure.activitylogs.identity.authorization.evidence.principal_idazure.activitylogs.identity.authorization.evidence.roleuser.namesource.ipsource.geo.country_nameazure.resource.idazure.resource.groupazure.subscription_id
Implementation guide
This rule requires Azure Activity Logs ingested via the Azure integration (azure.activitylogs data stream). RAI
policy and blocklist changes are Administrative control-plane events and are logged by default.
Known false positives
- AI platform administrators tuning content filter thresholds or blocklists for a new use case. Confirm the change with the account owner and change records.
- Infrastructure-as-code deployments that recreate RAI policies on every release. Add exceptions for the service principals that run these pipelines.
Analyst notes
Investigating Microsoft Foundry Content Filter Modified or Deleted
Microsoft Foundry content filters are stored as RAI policies on the AI Services account
(Microsoft.CognitiveServices/accounts/raiPolicies) and are referenced by each model deployment. Custom blocklists
(raiBlocklists) add term-level blocking on top of those policies. This rule fires when a policy or blocklist is
written or deleted.
Possible investigation steps
- Identify the caller from
azure.activitylogs.identity.authorization.evidence.principal_id,user.name, andazure.activitylogs.identity.authorization.evidence.role. - Review
azure.resource.idto identify the policy or blocklist name and the account it belongs to, andazure.activitylogs.operation_nameto determine whether it was a write or a delete. - Compare the policy with the previous version in the Foundry portal or with
az cognitiveservices accounttooling. Lowered severity thresholds, disabled prompt shields, or a policy switched to annotate-only mode are the changes of most concern. - Check whether any deployment on the account was changed to use the modified policy around the same time.
- Review
source.ipandsource.geo.country_namefor the caller and look for other recent changes by the same principal, such as key listing, diagnostic setting deletion, or new role assignments. - If Microsoft Foundry logs are ingested, look for a drop in filtered or jailbreak-flagged requests after the change.
False positive analysis
- Planned content filter tuning by AI platform owners. Confirm with the owner and the change ticket.
- Deployment pipelines that rewrite RAI policies. Exclude those service principals by ID.
Response and remediation
- If the change is not authorized, restore the previous content filter configuration and reassign it to affected deployments.
- Revoke the caller's sessions, reset its credentials, and review its role assignments on the account.
- Restrict
Microsoft.CognitiveServices/accounts/raiPolicies/*permissions to a small set of administrators.