From c18600f629e80c92a191f47a303b4798a0e41b61 Mon Sep 17 00:00:00 2001 From: Cristian-Venticinque Date: Mon, 14 Sep 2026 18:04:22 -0300 Subject: [PATCH 1/2] Renaming Universal to Open --- modules/ROOT/nav.adoc | 2 +- modules/ROOT/pages/af-get-started.adoc | 2 +- modules/ROOT/pages/agent-fabric-overview.adoc | 10 +-- modules/ROOT/pages/exp-glossary.adoc | 6 +- .../exp-governance-policy-library-apply.adoc | 18 ++--- .../ROOT/pages/exp-policies-activity-log.adoc | 4 +- .../ROOT/pages/exp-policies-apply-manage.adoc | 6 +- modules/ROOT/pages/exp-policies-open.adoc | 68 +++++++++++++++++++ modules/ROOT/pages/exp-policies-overview.adoc | 4 +- .../exp-policies-provider-reference.adoc | 10 +-- .../ROOT/pages/exp-policies-universal.adoc | 67 ------------------ .../exp-scanners-prerequisites-reference.adoc | 2 +- .../ROOT/pages/learning-map-agent-fabric.adoc | 2 +- 13 files changed, 101 insertions(+), 100 deletions(-) create mode 100644 modules/ROOT/pages/exp-policies-open.adoc delete mode 100644 modules/ROOT/pages/exp-policies-universal.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 709c7914e..f4ca42d35 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -38,7 +38,7 @@ *** xref:exp-scanners-manage.adoc[] *** xref:exp-providers-manage.adoc[] ** xref:exp-policies-overview.adoc[] - *** xref:exp-policies-universal.adoc[] + *** xref:exp-policies-open.adoc[] *** xref:exp-policies-apply-manage.adoc[] *** xref:exp-policies-activity-log.adoc[] *** xref:exp-policies-provider-reference.adoc[] diff --git a/modules/ROOT/pages/af-get-started.adoc b/modules/ROOT/pages/af-get-started.adoc index 12192e295..01b058544 100644 --- a/modules/ROOT/pages/af-get-started.adoc +++ b/modules/ROOT/pages/af-get-started.adoc @@ -265,7 +265,7 @@ You also need these permissions: | Apply, edit, enable, disable, or remove policies | API Manager: Manage Policies |=== -Learn more: xref:exp-instances-add.adoc[], xref:exp-policies-apply-manage.adoc[], and xref:exp-policies-universal.adoc[]. +Learn more: xref:exp-instances-add.adoc[], xref:exp-policies-apply-manage.adoc[], and xref:exp-policies-open.adoc[]. === Create Governance Strategies diff --git a/modules/ROOT/pages/agent-fabric-overview.adoc b/modules/ROOT/pages/agent-fabric-overview.adoc index ab5a25367..16054cd47 100644 --- a/modules/ROOT/pages/agent-fabric-overview.adoc +++ b/modules/ROOT/pages/agent-fabric-overview.adoc @@ -1,7 +1,7 @@ = Agent Fabric Overview :keywords: mulesoft agent fabric, mcp server, mcp bridge, mcp connector, a2a bridge, a2a connector, agent broker, enterprise actionability, ai agents, mulesoft integration, model context protocol -Teams build AI agents, MCP servers, and APIs across multiple platforms. As a result, it's challenging to easily reuse, apply consistent security controls, or track end-to-end cost. Agent Fabric is the AI control plane for that landscape. With Agent Fabric, gain visibility across every asset, let agents take action in your existing tech stack, enforce universal policies at runtime, and see and optimize what your AI investments are costing. +Teams build AI agents, MCP servers, and APIs across multiple platforms. As a result, it's challenging to easily reuse, apply consistent security controls, or track end-to-end cost. Agent Fabric is the AI control plane for that landscape. With Agent Fabric, gain visibility across every asset, let agents take action in your existing tech stack, enforce open policies at runtime, and see and optimize what your AI investments are costing. [[how-agent-fabric-works]] @@ -209,17 +209,17 @@ Use governance strategies when agents, APIs, and MCP servers must follow the sam Learn more: xref:exp-governance-work-with-strategies.adoc[] -=== Universal Policies +=== Open Policies -On a multi-vendor gateway landscape, the same control is a different native policy on each platform, so gaps appear. Author the intent once with Universal Policies. MuleSoft translates it for each API gateway. +On a multi-vendor gateway landscape, the same control is a different native policy on each platform, so gaps appear. Author the intent once with Open Policies. MuleSoft translates it for each API gateway. * Author a policy once and apply it across gateways from multiple vendors. * Enforce common controls such as API key enforcement, CORS, header manipulation, IP allowlisting, and JWT validation. * Keep the same governance as services move or scale across platforms. -Use Universal Policies when you run gateways from more than one vendor and need the same controls on all of them. +Use Open Policies when you run gateways from more than one vendor and need the same controls on all of them. -Learn more: xref:exp-policies-universal.adoc[] +Learn more: xref:exp-policies-open.adoc[] === Cross-Gateway and Third-Party API Governance diff --git a/modules/ROOT/pages/exp-glossary.adoc b/modules/ROOT/pages/exp-glossary.adoc index 20f720423..4e6c7446a 100644 --- a/modules/ROOT/pages/exp-glossary.adoc +++ b/modules/ROOT/pages/exp-glossary.adoc @@ -122,8 +122,8 @@ A governance control that filters or modifies tool inputs and outputs before the Unmanaged instance:: A lighter-weight instance deployment that does not route traffic through Omni Gateway. Choose unmanaged instances when a full managed path does not match your operating model. -Universal (canonical) policy:: -A provider-agnostic policy you configure once and apply across a mix of gateway providers. Anypoint translates a universal policy into each provider's native policy. Universal is a creation experience, not a managed entity: after you apply it, only native policies exist. Those native policies behave like any other native policy on the provider. You can edit, remove, enable, or disable them where the provider supports those actions. In the UI, universal policies carry a *Universal* badge. +Open (canonical) policy:: +A provider-agnostic policy you configure once and apply across a mix of gateway providers. Anypoint translates an open policy into each provider's native policy. Open is a creation experience, not a managed entity: after you apply it, only native policies exist. Those native policies behave like any other native policy on the provider. You can edit, remove, enable, or disable them where the provider supports those actions. In the UI, open policies carry an *Open* badge. View-only policy:: -A discovered policy that Anypoint displays but can't create or edit, such as any policy that isn't one of the supported universal-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled. +A discovered policy that Anypoint displays but can't create or edit, such as any policy that isn't one of the supported open-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled. diff --git a/modules/ROOT/pages/exp-governance-policy-library-apply.adoc b/modules/ROOT/pages/exp-governance-policy-library-apply.adoc index 6df1bea7b..262439eed 100644 --- a/modules/ROOT/pages/exp-governance-policy-library-apply.adoc +++ b/modules/ROOT/pages/exp-governance-policy-library-apply.adoc @@ -1,9 +1,9 @@ -= Apply Universal Policies -:keywords: policy library, universal policies, canonical policies, governance policies, apply policy, policy catalog += Apply Open Policies +:keywords: policy library, open policies, canonical policies, governance policies, apply policy, policy catalog -Governance provides two entry points for applying *universal policies*: the *Apply Policy* flow on the Governance Strategies page, and the *Policy Library* on an individual API instance. A universal policy expresses a policy once and applies it as the correct vendor-native policy on each supported gateway, so you can enforce consistent controls across MuleSoft, Google Apigee, Kong Gateway, and Azure API Management without authoring a policy per gateway. +Governance provides two entry points for applying *open policies*: the *Apply Policy* flow on the Governance Strategies page, and the *Policy Library* on an individual API instance. An open policy expresses a policy once and applies it as the correct vendor-native policy on each supported gateway, so you can enforce consistent controls across MuleSoft, Google Apigee, Kong Gateway, and Azure API Management without authoring a policy per gateway. -This topic covers both entry points and the apply flow. For the full universal policy model, the apply and management workflow, activity tracking, and per-provider support, see xref:exp-policies-overview.adoc[] and xref:exp-policies-universal.adoc[]. +This topic covers both entry points and the apply flow. For the full open policy model, the apply and management workflow, activity tracking, and per-provider support, see xref:exp-policies-overview.adoc[] and xref:exp-policies-open.adoc[]. == Before You Begin @@ -26,9 +26,9 @@ For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experien Policy write actions respect your permissions. If you don't have permission for an action, that action is unavailable and the experience explains that the action isn't permitted. If the platform can't verify your permissions for an instance, the actions remain available and the gateway enforces authorization when you submit the request. See xref:exp-policies-apply-manage.adoc[]. ==== -== Browse Universal Policies +== Browse Open Policies -You can start applying a universal policy from two places: +You can start applying an open policy from two places: * On the Governance Strategies page, select *Add Strategy*, then *Apply Policy*. * On an API instance, select the *Apply Policy* action to open the Policy Library. @@ -42,7 +42,7 @@ Each policy appears with its name, category, and a short description of what it Select *All Domains* to see every policy, or *Custom* to see policies that don't fall into the preceding categories. Each filter shows the number of policies it contains. -== Apply a Universal Policy +== Apply an Open Policy The apply steps vary depending on where you start. @@ -67,12 +67,12 @@ When you apply a policy, the platform validates it against your governance confi Applying a policy is an asynchronous, tracked operation, not a fire-and-forget action. When you apply a policy to more than one instance, each instance reports its own result, so you can see which instances succeeded and which failed. To confirm the outcome on each target, review the *Activity log* tab of the instance. See xref:exp-policies-activity-log.adoc[]. -For how universal policies map to each provider's native policy, and which policies you can then edit, enable, disable, or remove afterward, see xref:exp-policies-universal.adoc[] and xref:exp-policies-apply-manage.adoc[]. +For how open policies map to each provider's native policy, and which policies you can then edit, enable, disable, or remove afterward, see xref:exp-policies-open.adoc[] and xref:exp-policies-apply-manage.adoc[]. == See Also * xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] +* xref:exp-policies-open.adoc[] * xref:exp-policies-apply-manage.adoc[] * xref:exp-policies-activity-log.adoc[] * xref:exp-policies-provider-reference.adoc[] diff --git a/modules/ROOT/pages/exp-policies-activity-log.adoc b/modules/ROOT/pages/exp-policies-activity-log.adoc index 52700a986..66a845cd7 100644 --- a/modules/ROOT/pages/exp-policies-activity-log.adoc +++ b/modules/ROOT/pages/exp-policies-activity-log.adoc @@ -22,7 +22,7 @@ The *Activity log* tab lists recent policy operations for the API instance. By d Each entry has these columns: -* *Action*: the type of operation, such as *Apply*, *Update* (edit), *Toggle* (enable/disable), *Remove*, or *Universal* (a universal policy apply). +* *Action*: the type of operation, such as *Apply*, *Update* (edit), *Toggle* (enable/disable), *Remove*, or *Open* (an open policy apply). * *Policy*: the policy the operation applies to. * *Status*: one of three states: ** *Running* @@ -42,5 +42,5 @@ For a failed operation, open it to see why. The failure detail explains the erro * xref:exp-policies-overview.adoc[] * xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-universal.adoc[] +* xref:exp-policies-open.adoc[] * xref:exp-policies-provider-reference.adoc[] diff --git a/modules/ROOT/pages/exp-policies-apply-manage.adoc b/modules/ROOT/pages/exp-policies-apply-manage.adoc index 31a4138f5..ff36aff9c 100644 --- a/modules/ROOT/pages/exp-policies-apply-manage.adoc +++ b/modules/ROOT/pages/exp-policies-apply-manage.adoc @@ -28,12 +28,12 @@ Button state is a hint, not the final authorization. The *Policies* tab enables Policy naming applies to Apigee only, where the name is the policy's unique identity on the gateway, not just a label. Choose it deliberately: the name is required at creation and you can't change it later. Other providers don't use policy names. See <>. . Apply the policy. Anypoint accepts the request and performs it in the background. Confirm the outcome in the *Activity log* tab. See xref:exp-policies-activity-log.adoc[]. -To apply a universal policy across multiple providers at once, use the *Policy Library* instead. See xref:exp-policies-universal.adoc[]. +To apply an open policy across multiple providers at once, use the *Policy Library* instead. See xref:exp-policies-open.adoc[]. [[policy-edit-restrictions]] == Policy Edit Restrictions -Having permissions is necessary but not sufficient to edit a policy. Anypoint supports editing the curated set of policies that back the universal use cases, plus several additional native Kong policies (see xref:exp-policies-universal.adoc[]); other recognized policies are view-only. Native policies created from a universal use case are editable like any other supported native policy. When *Edit Configuration* is unavailable, the UI explains why. Common reasons include: +Having permissions is necessary but not sufficient to edit a policy. Anypoint supports editing the curated set of policies that back the open use cases, plus several additional native Kong policies (see xref:exp-policies-open.adoc[]); other recognized policies are view-only. Native policies created from an open use case are editable like any other supported native policy. When *Edit Configuration* is unavailable, the UI explains why. Common reasons include: * Anypoint doesn't recognize the policy's template, or doesn't yet support managing policies with its schema. * The policy's configuration doesn't match its expected schema. To resolve this issue, open a support case. @@ -66,7 +66,7 @@ An Apigee edit that tries to change the name is rejected, because the name is th == See Also * xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] +* xref:exp-policies-open.adoc[] * xref:exp-policies-activity-log.adoc[] * xref:exp-policies-provider-reference.adoc[] * xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-policies-open.adoc b/modules/ROOT/pages/exp-policies-open.adoc new file mode 100644 index 000000000..0a0ebdfa0 --- /dev/null +++ b/modules/ROOT/pages/exp-policies-open.adoc @@ -0,0 +1,68 @@ += Open Policies +:keywords: open policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform +:page-aliases: exp-policies-universal.adoc + +An open policy is a provider-agnostic authoring experience. You configure one policy once, and Anypoint 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 Anypoint 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*. + +== Open Use Cases + +At launch, there are five open use cases. Each maps to a specific native policy per provider. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[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. Anypoint also supports several additional native Kong policies. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[Supported Policies and Native Equivalents]. Other recognized policies are view-only. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[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 xref:exp-policies-activity-log.adoc[]. + +[NOTE] +==== +When an open policy targets Anypoint instances, there is currently no Activity log record for those targets, so there's no in-product way to confirm the outcome on Anypoint 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 vs. Automated vs. Governance + +These three are easy to confuse. Use this comparison to choose the right tool: + +[cols="1,2,2,2",options="header"] +|=== +| | Open | Automated Policies | Governance + +|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. +|Anypoint native (Omni and Mule), applied automatically by matching rules. +|Across APIs and instances. +|=== + +For automated policies and governance strategies, see xref:exp-governance-work-with-strategies.adoc[]. + +== See Also + +* xref:exp-policies-overview.adoc[] +* xref:exp-policies-apply-manage.adoc[] +* xref:exp-policies-activity-log.adoc[] +* xref:exp-policies-provider-reference.adoc[] +* xref:exp-governance-work-with-strategies.adoc[] diff --git a/modules/ROOT/pages/exp-policies-overview.adoc b/modules/ROOT/pages/exp-policies-overview.adoc index c988f88dc..3efda2321 100644 --- a/modules/ROOT/pages/exp-policies-overview.adoc +++ b/modules/ROOT/pages/exp-policies-overview.adoc @@ -22,7 +22,7 @@ There are two distinct ways you interact with provider policies: == The Editability Rule -Anypoint recognizes and displays every policy it discovers, but you can create and edit only a curated set: the policies that back the universal use cases, plus several additional native Kong policies. See xref:exp-policies-universal.adoc[]. Other recognized policies are view-only. +Anypoint recognizes and displays every policy it discovers, but you can create and edit only a curated set: the policies that back the open use cases, plus several additional native Kong policies. See xref:exp-policies-open.adoc[]. Other recognized policies are view-only. You can remove, enable, and disable policies more broadly than you can edit them, so it's normal to see a policy where *Edit Configuration* is unavailable while *Remove Policy* and the enable and disable actions remain available, as long as the provider supports that action. See xref:exp-policies-apply-manage.adoc[] and xref:exp-policies-provider-reference.adoc[]. @@ -32,7 +32,7 @@ Every policy change on an external provider, such as apply, edit, enable, disabl == See Also -* xref:exp-policies-universal.adoc[] +* xref:exp-policies-open.adoc[] * xref:exp-policies-apply-manage.adoc[] * xref:exp-policies-activity-log.adoc[] * xref:exp-policies-provider-reference.adoc[] diff --git a/modules/ROOT/pages/exp-policies-provider-reference.adoc b/modules/ROOT/pages/exp-policies-provider-reference.adoc index b9cd6119b..8bde7143f 100644 --- a/modules/ROOT/pages/exp-policies-provider-reference.adoc +++ b/modules/ROOT/pages/exp-policies-provider-reference.adoc @@ -35,7 +35,7 @@ Before getting started, make sure you have: [NOTE] ==== -* Apply and Edit are further limited to the supported (universal-backed) policies. A Yes in the Edit column means the provider supports editing, not that every policy is editable. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[Policy Edit Restrictions]. +* 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 xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[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. ==== @@ -89,11 +89,11 @@ Any custom role or higher-scope grant that includes the five permissions also wo [[supported-policies-and-native-equivalents]] == Supported Policies and Native Equivalents -At launch, Anypoint supports five universal 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. +At launch, Anypoint supports 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. [cols="1,1,1,1,1",options="header"] |=== -|Universal Use Case |Anypoint |Google Apigee |Azure API Management |Kong Gateway +|Open Use Case |Anypoint |Google Apigee |Azure API Management |Kong Gateway |API Key Enforcement |Client ID Enforcement @@ -132,12 +132,12 @@ At launch, Anypoint supports five universal use cases. Each maps to a native pol * Some use cases map to more than one native policy. For example, Header Manipulation applies separate request/response (or inbound/outbound) policies, and Anypoint's Header Manipulation is two policies (injection and removal). ==== -Beyond the universal use cases, Anypoint also supports 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`. +Beyond the open use cases, Anypoint also supports 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 * xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] +* xref:exp-policies-open.adoc[] * xref:exp-policies-apply-manage.adoc[] * xref:exp-policies-activity-log.adoc[] * xref:exp-scanners-add-from-providers.adoc[] diff --git a/modules/ROOT/pages/exp-policies-universal.adoc b/modules/ROOT/pages/exp-policies-universal.adoc deleted file mode 100644 index a5d9966c1..000000000 --- a/modules/ROOT/pages/exp-policies-universal.adoc +++ /dev/null @@ -1,67 +0,0 @@ -= Universal Policies -:keywords: universal policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform - -A universal policy is a provider-agnostic authoring experience. You configure one policy once, and Anypoint 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 Anypoint instances at the same time. In the UI, universal policies carry a *Universal* badge, indicating that they work across all gateways. - -You apply universal policies from the *Policy Library*, which walks you through four steps: *Select Policy*, *Configure Policy*, *Select Instances*, and *Review & Apply*. - -== Universal Use Cases - -At launch, there are five universal use cases. Each maps to a specific native policy per provider. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[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. Anypoint also supports several additional native Kong policies. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[Supported Policies and Native Equivalents]. Other recognized policies are view-only. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[Policy Edit Restrictions]. - -== Universal Is a Creation Experience - -Use a universal policy to implement a use case across multiple native gateways from a single starting point. Only native policies remain on each provider. No separate universal 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 universal object to manage separately. - -== Confirming What Happened - -Because universal is only a creation experience, there is no dedicated universal activity view. To see the outcome on each target, open that instance's *Activity log* tab. Universal applies appear there with the *Universal* action type. See xref:exp-policies-activity-log.adoc[]. - -[NOTE] -==== -When a universal policy targets Anypoint instances, there is currently no Activity log record for those targets, so there's no in-product way to confirm the outcome on Anypoint targets. This is a known limitation. For external providers (Apigee, Azure, and Kong), you can follow the outcome in each instance's *Activity log*. -==== - -== Universal vs. Automated vs. Governance - -These three are easy to confuse. Use this comparison to choose the right tool: - -[cols="1,2,2,2",options="header"] -|=== -| | Universal | Automated Policies | Governance - -|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 universal 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. -|Anypoint native (Omni and Mule), applied automatically by matching rules. -|Across APIs and instances. -|=== - -For automated policies and governance strategies, see xref:exp-governance-work-with-strategies.adoc[]. - -== See Also - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-policies-provider-reference.adoc[] -* xref:exp-governance-work-with-strategies.adoc[] diff --git a/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc b/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc index a4b161d04..745bb243c 100644 --- a/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc +++ b/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc @@ -286,7 +286,7 @@ Policy write lets you apply, enable, disable, and remove policies on connected t Policy write reuses the same connection you configure for scanning; there's no separate policy-write connection. Before you can write policies, confirm these prerequisites in addition to the discovery prerequisites in the matrix: * *Write permissions on the connection:* The scanner connection's identity must have the provider's write scope, not just read access. A connection with read-only access to the provider can discover and read policies, but policy actions remain unavailable. -* *Write scope:* The write scope covers enabling, disabling, and removing existing vendor-native policies, and creating and editing universal (canonical) policies, at both the instance and service scope. Creating and editing native vendor policies isn't supported. +* *Write scope:* The write scope covers enabling, disabling, and removing existing vendor-native policies, and creating and editing open (canonical) policies, at both the instance and service scope. Creating and editing native vendor policies isn't supported. * *Provider write permissions:* Grant the provider-specific *Write scope (policy apply)* listed for each API gateway provider in the Scanner Prerequisites Matrix. The following table summarizes the read and write scopes for each API gateway provider that supports policy write. diff --git a/modules/ROOT/pages/learning-map-agent-fabric.adoc b/modules/ROOT/pages/learning-map-agent-fabric.adoc index 204ab3953..f67cbcbb0 100644 --- a/modules/ROOT/pages/learning-map-agent-fabric.adoc +++ b/modules/ROOT/pages/learning-map-agent-fabric.adoc @@ -69,7 +69,7 @@ Put Omni Gateway in the request path so authentication, monitoring, and policy r - xref:exp-instances-add.adoc[] - xref:exp-policies-apply-manage.adoc[] - xref:exp-governance-work-with-strategies.adoc[] -- xref:exp-policies-universal.adoc[] +- xref:exp-policies-open.adoc[] - xref:exp-governance-govern-third-party-apis.adoc[] - xref:exp-governance-monitor-cross-gateway-conformance.adoc[] - xref:exp-detect-and-contain-rogue-agents.adoc[] From f191850c049880d4186ccd7ca9ab97701776c63e Mon Sep 17 00:00:00 2001 From: Cristian-Venticinque Date: Mon, 14 Sep 2026 18:25:03 -0300 Subject: [PATCH 2/2] edit --- modules/ROOT/pages/exp-policies-open.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/exp-policies-open.adoc b/modules/ROOT/pages/exp-policies-open.adoc index 0a0ebdfa0..73c676c55 100644 --- a/modules/ROOT/pages/exp-policies-open.adoc +++ b/modules/ROOT/pages/exp-policies-open.adoc @@ -33,13 +33,13 @@ Because open is only a creation experience, there is no dedicated open activity When an open policy targets Anypoint instances, there is currently no Activity log record for those targets, so there's no in-product way to confirm the outcome on Anypoint 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 vs. Automated vs. Governance +== Open Policies vs. Automated vs. Governance These three are easy to confuse. Use this comparison to choose the right tool: [cols="1,2,2,2",options="header"] |=== -| | Open | Automated Policies | Governance +| | Open Policies | Automated Policies | Governance |What it is |A create-only authoring experience: configure once, applied as each provider's native policy across many instances, including external providers.