How to get rid of or edit default guardrail RAI policies in Microsoft Foundry?

Question

How to get rid of or edit default guardrail RAI policies in Microsoft Foundry?

Bob Lindenberg 80

When I provision Microsoft Foundry and a Foundry project, I see two RAI Policies that are created by default. If I look in the foundry portal at content filters (under Guardrails and Controls) these policies do not show up. But if I use the REST API to GET RAI Policies, I see the policy that I created plus two system managed policies, Microsoft.Default and Microsoft.DefaultV2.

Our security scanner objects to these two policies because they do not contain controls for indirect attacks, which it considers the most dangerous. Is it possible to modify these policies or if not, to delete them?

Bob Lindenberg 80 Reputation points

2026-04-29T22:09:34.1666667+00:00

Thank you @Karnam Venkata Rajeswari . Looking at the AI generated content, it appears that I cannot modify or delete the default policies. If that is so, I would suggest that there be an option to add additional filters beyond the basic ones to the default policies when a Foundry resource is created. That is, keep them mandatory nature but allow other types such as indirect attack to be added.

It also makes sense that the portal should display the default policies and also to make them available through the CLI.

And may I ask why there are both Default and DefaultV2 policies? DefaultV2 appears to be a superset of Default.

Of course I welcome any other suggestions you might have.
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-04-30T01:06:44.4+00:00
Hello @Bob Lindenberg ,

Regarding the default policies (Microsoft.Default and Microsoft.DefaultV2), the current design is such that these are system-managed baseline guardrails. As observed, they cannot be modified or deleted, This ensures that a minimum level of Responsible AI protection is always in place across all deployments.

At present, it is not possible to directly extend these default policies by adding additional filters (such as indirect attack protection). Instead, the supported approach is to create a custom guardrail policy that includes the required additional controls and assign it to the relevant models or agents. This effectively allows layering of stronger protections while retaining the mandatory baseline.

The observation about visibility in the portal and CLI is also valid. Currently, system-managed policies are intentionally not shown in the portal UI and are primarily accessible through API. This design helps avoid accidental changes to baseline configurations, but greater visibility in a read-only manner would certainly improve transparency for governance and compliance needs.

Regarding the presence of both Default and DefaultV2, this is related to policy versioning and platform evolution.

Microsoft.Default represents an earlier baseline configuration

Microsoft.DefaultV2 is a newer version with updated safety behavior

Both are maintained to ensure compatibility across different deployments, rather than being editable variants of one another.

Thank you
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-04-30T16:36:35.4633333+00:00

Hello @Bob Lindenberg

Checking in to see if you had any chance to review the above response

Thank you!
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-01T17:48:38.4566667+00:00

Hello @Bob Lindenberg

Just checking in to see if the above response was helpful.

Thank you
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-04T14:19:10.1966667+00:00

Hello @Bob Lindenberg ,

Just checking in to see if you have got a chance to see my response.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted with an upvote? This helps others in the community with the same question find the solution more easily.

Thank you!
Bob Lindenberg 80 Reputation points

2026-05-04T18:46:14.31+00:00

Hello @Karnam Venkata Rajeswari Apologies for taking so long to reply. Your answer is clear and covers all my questions and comments. Unfortunately, it makes our position difficult as I tried to explain. Our security scan does not consider having an additional policy to be sufficient. It examines each one separately. Perhaps Microsoft could offer two or three choices for the default policies, where the other choices offered additional guardrails such as prompt injection coverage.
Artem Kalaitan 0 Reputation points

2026-05-04T22:13:14.1433333+00:00
@Bob Lindenberg your scanner is right - the Microsoft.Default / DefaultV2 baseline doesn't include indirect prompt injection coverage as a named control, and a layered custom RAI policy doesn't satisfy a scanner that examines each policy independently. The pattern that works for other Azure Foundry deployments under the same constraint is a separate runtime layer: an inline prompt-injection check that wraps the model call and exposes its own control surface, separately auditable from the Foundry RAI policies. The scanner can validate that surface independently because it is, in fact, independent.

The two artifacts that usually clear this kind of scan:

A coverage matrix mapping the scenarios the runtime layer detects (direct injection, indirect injection via documents / RAG / email / support tickets, system-prompt leak, tool poisoning) to your scanner's prompt-injection control requirements.

An evidence trail (time-stamped log of every detection event with disposition - block / warn / log) usable as audit evidence that the control is both enforced and observed.

Most scanners accept this in lieu of a Foundry RAI policy modification because it satisfies the "control is enforced and audited" test directly.

Disclosure: I work at darkhunt.ai - we ship exactly this runtime layer (<50ms p99 latency on the inline check) plus the scenario library and evidence pack. Happy to share the coverage matrix against Microsoft.Default / DefaultV2 if useful for your scanner conversation.

Separately: the broader ask you made to Microsoft (offer different default-policy variants with prompt-injection coverage built in) is the right product feedback - would save a lot of teams this exact conversation.
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-05T00:52:57.6866667+00:00

Hello @Bob Lindenberg ,Thank you for sharing us your concern.Please allow us some time while we work on this concern.

Thank you.

Answer accepted by question author

Pavankumar Purilla 11,655 Moderator

Hello Bob Lindenberg,
Hope you are doing well.

The policies Microsoft.Default and Microsoft.DefaultV2 are system-managed baseline policies automatically created by the platform. These policies are currently not editable or deletable, as they are designed to ensure a minimum level of Responsible AI protection for all deployments. They are mainly visible through the REST API and are not currently shown in the Foundry portal UI.

Microsoft.Default is the earlier baseline policy, while Microsoft.DefaultV2 is the newer version with updated safety improvements. Both exist to support compatibility across different deployments.

Regarding indirect prompt injection protection, your observation is correct. At present, additional protections cannot be added directly to these Microsoft-managed default policies. The supported approach is to create a separate custom RAI/content filtering policy with the required protections and apply it alongside the default policies.

We also understand that some security scanners may still flag the default policies independently even when additional custom protections are applied. For stricter security and compliance requirements, the recommended approach is to use layered protection by combining the default policies, custom guardrails, and additional runtime prompt injection detection controls.

0 comments

2 additional answers

Your answer

Bob Lindenberg 80 Reputation points

2026-04-29T22:09:34.1666667+00:00

Thank you @Karnam Venkata Rajeswari . Looking at the AI generated content, it appears that I cannot modify or delete the default policies. If that is so, I would suggest that there be an option to add additional filters beyond the basic ones to the default policies when a Foundry resource is created. That is, keep them mandatory nature but allow other types such as indirect attack to be added.

It also makes sense that the portal should display the default policies and also to make them available through the CLI.

And may I ask why there are both Default and DefaultV2 policies? DefaultV2 appears to be a superset of Default.

Of course I welcome any other suggestions you might have.
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-04-30T01:06:44.4+00:00

Hello @Bob Lindenberg ,

Regarding the default policies (Microsoft.Default and Microsoft.DefaultV2), the current design is such that these are system-managed baseline guardrails. As observed, they cannot be modified or deleted, This ensures that a minimum level of Responsible AI protection is always in place across all deployments.

At present, it is not possible to directly extend these default policies by adding additional filters (such as indirect attack protection). Instead, the supported approach is to create a custom guardrail policy that includes the required additional controls and assign it to the relevant models or agents. This effectively allows layering of stronger protections while retaining the mandatory baseline.

The observation about visibility in the portal and CLI is also valid. Currently, system-managed policies are intentionally not shown in the portal UI and are primarily accessible through API. This design helps avoid accidental changes to baseline configurations, but greater visibility in a read-only manner would certainly improve transparency for governance and compliance needs.

Regarding the presence of both Default and DefaultV2, this is related to policy versioning and platform evolution.

Microsoft.Default represents an earlier baseline configuration

Microsoft.DefaultV2 is a newer version with updated safety behavior

Both are maintained to ensure compatibility across different deployments, rather than being editable variants of one another.

Thank you
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-04-30T16:36:35.4633333+00:00

Hello @Bob Lindenberg

Checking in to see if you had any chance to review the above response

Thank you!
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-01T17:48:38.4566667+00:00

Hello @Bob Lindenberg

Just checking in to see if the above response was helpful.

Thank you
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-04T14:19:10.1966667+00:00

Hello @Bob Lindenberg ,

Just checking in to see if you have got a chance to see my response.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted with an upvote? This helps others in the community with the same question find the solution more easily.

Thank you!
Bob Lindenberg 80 Reputation points

2026-05-04T18:46:14.31+00:00

Hello @Karnam Venkata Rajeswari Apologies for taking so long to reply. Your answer is clear and covers all my questions and comments. Unfortunately, it makes our position difficult as I tried to explain. Our security scan does not consider having an additional policy to be sufficient. It examines each one separately. Perhaps Microsoft could offer two or three choices for the default policies, where the other choices offered additional guardrails such as prompt injection coverage.
Artem Kalaitan 0 Reputation points

2026-05-04T22:13:14.1433333+00:00

@Bob Lindenberg your scanner is right - the Microsoft.Default / DefaultV2 baseline doesn't include indirect prompt injection coverage as a named control, and a layered custom RAI policy doesn't satisfy a scanner that examines each policy independently. The pattern that works for other Azure Foundry deployments under the same constraint is a separate runtime layer: an inline prompt-injection check that wraps the model call and exposes its own control surface, separately auditable from the Foundry RAI policies. The scanner can validate that surface independently because it is, in fact, independent.

The two artifacts that usually clear this kind of scan:

A coverage matrix mapping the scenarios the runtime layer detects (direct injection, indirect injection via documents / RAG / email / support tickets, system-prompt leak, tool poisoning) to your scanner's prompt-injection control requirements.

An evidence trail (time-stamped log of every detection event with disposition - block / warn / log) usable as audit evidence that the control is both enforced and observed.

Most scanners accept this in lieu of a Foundry RAI policy modification because it satisfies the "control is enforced and audited" test directly.

Disclosure: I work at darkhunt.ai - we ship exactly this runtime layer (<50ms p99 latency on the inline check) plus the scenario library and evidence pack. Happy to share the coverage matrix against Microsoft.Default / DefaultV2 if useful for your scanner conversation.

Separately: the broader ask you made to Microsoft (offer different default-policy variants with prompt-injection coverage built in) is the right product feedback - would save a lot of teams this exact conversation.
Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-05-05T00:52:57.6866667+00:00

Hello @Bob Lindenberg ,Thank you for sharing us your concern.Please allow us some time while we work on this concern.

Thank you.

Answer 1

Hello @Bob Lindenberg

Welcome to Microsoft Q&A .Thank you for reaching out to us.

The behavior you are seeing aligns with the current design of Responsible AI (RAI) guardrail management in Microsoft Foundry.

The policies Microsoft.Default and Microsoft.DefaultV2 are system-managed RAI guardrail policies that are automatically provisioned when a Foundry project or resource is created.

These default policies cannot be modified or deleted as they are

System-managed
Immutable (read-only)
Not editable or deletable
Not extensible

They provide a platform-enforced baseline safety layer that ensures a minimum level of Responsible AI protections is always applied across Foundry deployments.

They not visible in the Foundry portal as

The Foundry portal displays only user-created or user-managed guardrail (RAI) policies
System-managed baseline policies are intentionally hidden in the UI
However, they are fully visible through:
- REST API
- CLI tooling in some environments

Thus ,they do not appear under Guardrails and Controls in the portal ,but are returned via API calls

There two policies: Microsoft.Default and Microsoft.DefaultV2 as both represent system-managed baseline generations.

Microsoft.Default → earlier baseline policy
Microsoft.DefaultV2 → updated baseline policy with newer safety configurations

Please note that

These are not strict “parent-child” versions
They are parallel system baselines maintained by the platform
Both of them are retained to support platform evolution and backward compatibility across existing deployments

Scanner is likely expecting explicit visibility of controls such as indirect prompt injection protection within a single policy definition.

Since system-managed policies cannot be modified, please check if the following help

Creating a custom RAI policy - Define a custom policy with the required controls, such as
- stricter content filtering
- indirect prompt injection mitigation (where supported)
- additional compliance-specific safety rules
- Prompt Shield integration for injection scenarios
Assigning the custom policy Please assign the custom policy to:
- a Foundry project, or
- specific model deployments / agents (depending on your architecture)
This ensures the custom policy becomes the effective enforcement layer at runtime, while system policies remain as baseline safeguards.
Validating effective enforcement To support compliance or security validation:
- Confirm that the custom policy is actively assigned to deployments
- Ensure it includes required protections like prompt injection mitigation controls
- Document that system-managed policies remain as a non-configurable baseline layer
Microsoft.Default and Microsoft.DefaultV2 are mandatory system baselines which cannot be replaced, extended, or removed.They remain active alongside any custom guardrail policies.Thus,custom policies are the supported mechanism for additional governance and compliance requirements

The following references might be helpful , please check them out

Thank you

Answer 2

Default safety policies such as Microsoft.Default and Microsoft.DefaultV2 are part of the built-in guardrails for Azure OpenAI models in Microsoft Foundry. These defaults provide baseline protections (content filters, blocklists, prompt protection, etc.) and are applied automatically to ensure a responsible-by-default experience.

These Microsoft Default guardrails cannot be modified or deleted. The documented behavior is:

Default safety policies are applied to all models by default.
All safety policies are configurable by creating and assigning custom guardrails.
However, “Microsoft Default” guardrails themselves (for example, Default.V2) cannot be edited.

To satisfy stricter security or compliance requirements (such as adding controls for indirect prompt attacks), the supported approach is:

Create a custom guardrail in Foundry with the desired controls (for example, Prompt Shield for indirect attacks, protected material, custom blocklists, etc.).
Assign that custom guardrail to the relevant models and/or agents so that it overrides the default behavior for those assets.
Optionally, create guardrail policies in the Compliance workspace to mandate that deployments use guardrails with specific controls (for example, requiring indirect attack protection) and to monitor/fix noncompliant assets.

The system-managed default policies will still exist and appear via the REST API, but security posture can be enforced through custom guardrails and guardrail policies rather than by altering or removing the Microsoft.Default / Microsoft.DefaultV2 policies.

References: