---
schema_version: "1"
id: 83f0a1b8b390711e3b4afc5ba56a7b8de13c5babcaca1d68eb462e16838e2f17
title: Provider Support and Limitations for Policies
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/exp-policies-provider-reference.md
canonical_url: https://docs.mulesoft.com/general/exp-policies-provider-reference
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 8d58f7ebf6137671c1b27ca9eb7b903779fc55e0e5419d37d6c4e78bc2d7bb1a
description: MuleSoft Documentation Site
latest: true
---
---
product: Getting Started
keywords: policy provider support, apigee, azure api management, kong, aws, injection points, policy permissions, anypoint platform
---

# Provider Support and Limitations for Policies

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

External gateways differ substantially in what they support and how they behave. This reference
summarizes per-provider policy support, the setup each provider requires on your side, injection
points, and locking behavior during operations.

## Before You Begin

Before getting started, make sure you have:

- An Anypoint Platform account.

- A connected scanner for each external provider whose policies you want to manage. Policy
  management reuses the scanner connection’s credentials. See
  [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers).

## Supported Actions by Provider

<table><colgroup><col> <col> <col> <col> <col> <col> <col></colgroup><thead><tr><th>Provider</th><th>Apply</th><th>Edit</th><th>Remove</th><th>Enable/Disable</th><th>View</th><th><a href="https://docs.mulesoft.com/general/exp-governance-create-strategy">Track/Govern</a></th></tr></thead><tbody><tr><td><p>Omni Gateway</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr><tr><td><p>Kong Gateway</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr><tr><td><p>Google Apigee</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>No (no native concept)</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr><tr><td><p>Azure API Management</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>No (no native concept)</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr><tr><td><p>Amazon API Gateway</p></td><td><p>No</p></td><td><p>No</p></td><td><p>No</p></td><td><p>No (not supported yet)</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr></tbody></table>

> [!NOTE]
>
> - Apply and Edit are further limited to the supported (open-backed) policies. A Yes in the Edit
>   column means the provider supports editing, not that every policy is editable. See
>   [Policy Edit Restrictions](https://docs.mulesoft.com/general/exp-policies-apply-manage#policy-edit-restrictions).
>
> - Apigee and Azure API Management have no native enabled/disabled state (a policy is either
>   attached or not), so the enable/disable actions aren’t available there.
>
> - Amazon API Gateway is not supported for policy write yet.
>
> - View and Track/Govern reflect read-only visibility and governance reporting, which every
>   provider supports regardless of write access. See
>   [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy).

## Per-Provider Permissions

Because policy management reuses the scanner connection, the permissions you see reflect what that
connection’s identity is allowed to do on the provider, not a separate login.

- Google Apigee: The enhanced MuleSoft experience checks the connected Google service account’s
  actual permissions on Google Cloud. See
  [Apigee Required Permissions and Roles](#apigee-required-permissions-and-roles).

- Azure API Management: The enhanced MuleSoft experience checks the connected Azure principal’s
  role-based permissions on the API resource, including permissions inherited from higher scopes.

- Kong Gateway: access is based on your Kong Konnect roles and team memberships for the instance’s
  control plane. Admin and power teams get full access; otherwise a matching role is required.

- Omni Gateway: uses the same Anypoint Platform permissions as elsewhere in the product, with no
  separate provider-side check.

## Injection Points

An injection point is where a policy runs relative to the request and response. Each policy template
declares the injection points that it allows. If you choose an unsupported injection point, the
system rejects the choice.

- Google Apigee: you can choose request or response. On the Apigee side, both map to the proxy-level
  `PreFlow` (request and response map to the corresponding `PreFlow` section).

- Azure API Management: supports `inbound`, `outbound`, and `backend`. Azure’s error-handling
  section is not editable through the enhanced MuleSoft experience.

- Kong Gateway: the injection point is informational only; Kong’s plugin phase is fixed, so it
  doesn’t change placement.

## Instance Locking During Operations

To prevent conflicting concurrent changes, an in-progress operation takes a lock. The scope of that
lock differs by provider:

- Azure API Management and Google Apigee lock the entire API instance. While one policy operation is
  running, no other policy operation on that instance can start. Wait for the running one to finish.
  On Azure, an instance’s policies live in a single document, so any change touches the whole thing.
  On Apigee, a change re-deploys the whole proxy, so it’s inherently instance-wide.

- Kong Gateway locks only the specific policy that you modify. You can work with other policies on
  the same instance simultaneously.

- Omni Gateway takes no such lock.

If an operation is already in progress, another operation is mid-flight on that instance (Azure or
Apigee) or on that same policy (Kong). Wait for the operation to complete. You can track it in the
**Activity log**. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log).

## Apigee Required Permissions and Roles

For Apigee, the connected Google service account requires these permissions for policy create, edit,
and remove operations to work. They cover the read-import-deploy cycle every Apigee change performs:

- `apigee.proxies.get`

- `apigee.proxyrevisions.get`

- `apigee.proxies.create`

- `apigee.deployments.list`

- `apigee.deployments.create`

To get these permissions, you can use one of these predefined Apigee roles:

- Apigee API Admin

- Apigee Environment Admin

Any custom role or higher-scope grant that includes the five permissions also works. The enhanced
MuleSoft experience checks the account’s effective permissions, not the role name.

## Supported Policies and Native Equivalents

At launch, open policies support five open use cases. Each maps to a native policy on each provider.
These native policies are the ones you can create and edit, along with the additional native Kong
policies listed after this table. Other recognized policies are view-only.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Open Use Case</th><th>Omni Gateway</th><th>Google Apigee</th><th>Azure API Management</th><th>Kong Gateway</th></tr></thead><tbody><tr><td><p>API Key Enforcement</p></td><td><p>Client ID Enforcement</p></td><td><p>Verify API Key</p></td><td><p>— (not available)</p></td><td><p>Key Auth</p></td></tr><tr><td><p>CORS</p></td><td><p>CORS</p></td><td><p>CORS</p></td><td><p>CORS</p></td><td><p>CORS</p></td></tr><tr><td><p>Header Manipulation</p></td><td><p>Header Injection + Header Removal</p></td><td><p>Assign Message (request &amp; response)</p></td><td><p>Set Header (inbound &amp; outbound)</p></td><td><p>Request Transformer + Response Transformer</p></td></tr><tr><td><p>IP Allowlist</p></td><td><p>IP Allowlist</p></td><td><p>Access Control</p></td><td><p>IP Filter</p></td><td><p>IP Restriction</p></td></tr><tr><td><p>JWT Validation</p></td><td><p>JWT Validation (Mule 4 &amp; Flex Gateway)</p></td><td><p>Verify JWT</p></td><td><p>— (not available)</p></td><td><p>JWT Signer</p></td></tr></tbody></table>

> [!NOTE]
>
> - A dash (—) means that the provider doesn’t offer the use case because it lacks a native
>   equivalent.
>
> - Some use cases map to more than one native policy. For example, Header Manipulation applies
>   separate request/response (or inbound/outbound) policies, and Omni Gateway’s Header Manipulation
>   is two policies (injection and removal).

Open policies also support these native Kong policies: `acl`, `acme`, `basic-auth`,
`header-cert-auth`, `ldap-auth`, `ldap-auth-advanced`, `mtls-auth`, `opa`, `tls-handshake-modifier`,
and `tls-metadata-headers`.

## See Also

- [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview)

- [Open Policies](https://docs.mulesoft.com/general/exp-policies-open)

- [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)

- [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers)