--- schema_version: "1" id: ffab51d29e2f754d88f3b2094f5cb23ea3e9458e5357a41c64c8108a8484b289 title: Open Policies collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/exp-policies-open.md canonical_url: https://docs.mulesoft.com/general/exp-policies-open source_site: docs.mulesoft.com content_type: documentation content_hash: c11572f60bd69e178a475a9c395c5fedf15f92807efbd515e1f8a13ff7e865a8 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started keywords: open policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform --- # Open Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt An open policy is a provider-agnostic authoring experience. You configure one policy once, and MuleSoft translates it into each provider’s native policy and applies it across the instances you select, even a mix of Google Apigee, Azure API Management, Kong Gateway, and Omni instances at the same time. In the UI, open policies carry an **Open** badge, indicating that they work across all gateways. You apply open policies from the **Policy Library**, which walks you through four steps: **Select Policy**, **Configure Policy**, **Select Instances**, and **Review & Apply**. > [!NOTE] Automate open policy application using the MuleSoft MCP Platform Server. For details, see > [apply\_universal\_policy](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#apply-universal-policy) > in the MuleSoft MCP Platform Server Tool Reference. ## Open Use Cases At launch, there are five open use cases. Each maps to a specific native policy per provider. See [Supported Policies and Native Equivalents](https://docs.mulesoft.com/general/exp-policies-provider-reference#supported-policies-and-native-equivalents): - API Key Enforcement - CORS (Cross-Origin Resource Sharing) - Header Manipulation - IP Allowlist - JWT Validation These are the primary policies you can create and edit across providers. Open policies also support several additional native Kong policies. See [Supported Policies and Native Equivalents](https://docs.mulesoft.com/general/exp-policies-provider-reference#supported-policies-and-native-equivalents). Other recognized policies are view-only. See [Policy Edit Restrictions](https://docs.mulesoft.com/general/exp-policies-apply-manage#policy-edit-restrictions). ## Open Is a Creation Experience Use an open policy to implement a use case across multiple native gateways from a single starting point. Only native policies remain on each provider. No separate open object exists, so you can’t edit or remove it. After creation, the resulting native policies behave like any other native policy on each provider. From the **Policies** tab, you can edit, remove, enable, or disable them where the provider supports those actions. There is no open object to manage separately. ## Confirming What Happened Because open is only a creation experience, there is no dedicated open activity view. To see the outcome on each target, open that instance’s **Activity log** tab. Open applies appear there with the **Open** action type. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). > [!NOTE] When an open policy targets Omni instances, there is currently no Activity log record for > those targets, so there’s no in-product way to confirm the outcome on Omni targets. This is a > known limitation. For external providers (Apigee, Azure, and Kong), you can follow the outcome in > each instance’s **Activity log**. ## Open Policies vs. Automated Policies vs. Controls These three are easy to confuse. Use this comparison to choose the right tool:
Open PoliciesAutomated PoliciesControls

What it is

A create-only authoring experience: configure once, applied as each provider’s native policy across many instances, including external providers.

Policies that auto-attach to any API matching a set of criteria (runtime, technology, environment, and so on), applied by rule, not to one hand-picked target.

Reporting and compliance only: conformance reports for an API or instance. Doesn’t apply policies.

Lifecycle

None after creation. There’s no open object to edit or delete.

Fully managed: create, edit, delete, and coverage changes as APIs come in and out of scope.

Read-only reports.

Scope

Multi-provider, applied to the instances you select.

Native to Omni and Mule, applied automatically by matching rules.

Across APIs and instances.

For automated policies and governance strategies, see [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies). ## See Also - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies)