W-23435636 EME scanner read policy GA jh

modules/ROOT/nav.adoc

@@ -23,6 +23,7 @@
     *** xref:model-proxy-token-reports.adoc[]
     *** xref:model-proxy-try-out.adoc[]
   ** xref:exp-scanners-add-from-providers.adoc[]
+    *** xref:exp-scanners-prerequisites-reference.adoc[]
     *** xref:exp-scanners-manage.adoc[]
   ** xref:exp-providers-manage.adoc[]
   ** xref:exp-instances-add.adoc[]

modules/ROOT/pages/exp-scanners-add-from-providers.adoc

@@ -1,7 +1,7 @@
 = Adding Scanners from Providers
 :keywords: scanners, providers, add scanner, scanner configuration, workflow, anypoint platform, security scanning
 
-A scanner is the configured link between the system and a supported cloud provider that lets discovery jobs find services—such as APIs, agents, and MCP servers—and register them in the right *Portfolio* catalogs. Scanners enable automated discovery so your catalogs stay current without manual registration. Configure a scanner once to turn on discovery for a provider, then extend it as your organization adds catalogs or enabled features.
+A scanner is the configured link between the system and a supported cloud provider that lets discovery jobs find services—such as APIs, agents, and MCP servers—and register them in the right *Portfolio* catalogs, and to discover and read policies from API configurations. Scanners enable automated discovery so your catalogs stay current without manual registration. Configure a scanner once to turn on discovery for a provider, then extend it as your organization adds catalogs or enabled features.
 
 For how provider connection and catalogs fit together, see xref:exp-services-connect-providers-to-add.adoc[] and xref:exp-services-add-to-portfolio.adoc[].
 
@@ -33,6 +33,10 @@ Discovered services appear in *Portfolio* where teams can govern, monitor, and d
 +
 Scheduled or on-demand scans pick up releases and configuration drift according to the options your administrator allows.
 
+* Policy-visibility
++
+When a scanner is enabled, it can discover and read policies from API configurations. This allows the system to enforce policies on the discovered services. This is especially useful for API-based policies, such as web application firewall (WAF) policies.
+
 == Workflow Entry Points for Adding a Scanner
 
 The system exposes the same underlying connect-and-configure wizard from more than one place; the label depends on context:
@@ -57,11 +61,14 @@ Regardless of entry point, adding a scanner establishes trust and scope. You spe
 
 When the scanner is active, it applies discovery results according to its settings and your organization's rules. You review outcomes on the *Providers* page and on scanner detail pages, and you manage discovered services from the relevant *Portfolio* catalogs.
 
+For API scanners, policy-read results are visible from each discovered API in *Portfolio* > *APIs* > *Policies*. This includes read policies from Amazon API Gateway, Google Apigee, Azure API Management, and Kong Gateway. Use this view to verify imported controls and confirm scanner coverage by provider.
+
 For ongoing operations (pause, edit, or delete), see xref:exp-scanners-manage.adoc[].
 
 == See Also
 
 * xref:exp-services-connect-providers-to-add.adoc[]
+* xref:exp-scanners-prerequisites-reference.adoc[]
 * xref:exp-scanners-manage.adoc[]
 * xref:exp-services-add-to-portfolio.adoc[]
 * xref:exp-services-view-details.adoc[]

modules/ROOT/pages/exp-scanners-manage.adoc

@@ -5,19 +5,22 @@ After you configure scanners, you run them day to day. Most of that work happens
 
 == Available Scanner Actions
 
-* Run discovery on demand.
+* *Run Discovery Scan*
 +
 Start a manual scan when you want fresh metadata without waiting for the next scheduled window. Successful runs update or add services in the matching *Portfolio* catalogs according to your rules.
-* Review status and history.
+* *View Scanner*
 +
 Inspect connection health, the last completed run, and scan history to verify whether discovery is healthy, slow, or failing authentication.
-* Pause scheduled scans.
+* *Pause Scheduled Runs*
 +
 Temporarily stop scheduled triggers when you need a quiet period—for example during maintenance or while you fix credentials—without deleting the scanner.
-* Edit configuration.
+* *Resume Scheduled Runs*
 +
-Change names, descriptions, credentials, provider scope, or scan-related settings your product exposes, then save so future runs use the new definition.
-* Delete a scanner.
+Re-enable scheduled scanning after a pause.
+* *Scanner Settings*
++
+Change names, descriptions, credentials, provider scope, or scan-related settings your product exposes, then save, so future runs use the new definition.
+* *Delete Scanner*
 +
 Remove the scanner from *Providers* when the provider link is no longer authorized or useful. Consider the impact on discovered services in *Portfolio* and on dependent teams before you delete the scanner.
 

modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc

@@ -0,0 +1,211 @@
+= Provider Prerequisites Reference
+:keywords: scanner prerequisites, exchange scanners, provider scanners, required roles, required credentials, scanner setup
+
+Scanner prerequisites by provider help you confirm required roles, credentials, and permissions before creating a scanner. Use this reference to prevent connection test failures and incomplete discovery by validating provider-specific access in advance. Each scanner still requires Exchange Administrator permission and the correct business group context.
+
+== Before You Begin
+
+Before adding any scanner, make sure you have:
+
+* Exchange Administrator permission.
+* Access to, and active context in, the business group where you want to add the scanner.
+
+== Scanner Prerequisites Cross-Reference
+
+In the table, bullets prefixed with *Policy Read* identify permissions, roles, or scopes required specifically for policy-read scanning.
+
+[cols="1,1,1,2",options="header"]
+|===
+| Scanner
+| Scanner Type
+| Required Roles
+| Required Credentials and Permissions
+
+| Amazon Bedrock
+| Agent
+| Exchange Administrator
+a|
+* AWS region knowledge
+* Access key ID and secret access key
+* `bedrock:ListAgents`
+* `bedrock:GetAgent`
+* `bedrock:ListAgentAliases`
+* `bedrock:GetAgentAlias`
+* `bedrock:ListAgentVersions`
+* `bedrock:GetAgentVersion`
+* Optional for agent invocation workflows: `bedrock:InvokeModel`, `bedrock:InvokeAgent`, `bedrock:InvokeInlineAgent`
+* Policy Read permissions: `bedrock:ListAgents`, `bedrock:GetAgent`, and `bedrock:ListAgentAliases`
+* Agents must have an alias linked to a version and an invocable URL
+
+| Amazon Bedrock AgentCore Runtime
+| Agent
+| Exchange Administrator
+a|
+* Active AWS account and AgentCore access
+* AWS region
+* Access key ID and secret access key
+* `bedrock-agentcore:ListAgentRuntimes`
+* `bedrock-agentcore:ListAgentRuntimeEndpoints`
+* `bedrock-agentcore:GetAgentCard`
+* `bedrock-agentcore:GetAgentRuntime`
+* `bedrock-agentcore:ListAgentRuntimeVersions`
+* `bedrock:GetAgent`
+* `bedrock:ListAgents`
+* Agents must be published with an active endpoint/version
+
+| Anthropic Claude Managed Agents
+| Agent
+| Exchange Administrator
+a|
+* Paid Anthropic account
+* Claude API key
+
+| Databricks Agent Bricks
+| Agent
+| Exchange Administrator
+a|
+* Databricks workspace access
+* Workspace URL
+* Client ID and client secret
+* Service principal `CAN_QUERY` on serving endpoints
+* `CAN_VIEW` or higher on endpoint metadata APIs
+* Discoverable agents must be custom Unity Catalog models in `READY` state
+
+| GoDaddy ANS
+| Agent
+| Exchange Administrator
+a|
+* API key
+* API secret
+
+| Google Gemini Agent Enterprise Platform
+| Agent
+| Exchange Administrator, Vertex AI Viewer
+a|
+* GCP project ID
+* Service account email
+* Private key
+
+| LangChain LangSmith
+| Agent
+| Exchange Administrator
+a|
+* LangSmith Plus plan (or higher) workspace
+* LangSmith API key
+* LangSmith workspace ID
+* Optional API host for region routing (for example, US or EU cloud host)
+
+| Microsoft Azure Copilot
+| Agent
+| Exchange Administrator, Copilot Studio Scanner Role
+a|
+* Azure app registration
+* Tenant ID, client ID, client secret
+* App added as an Application User in Power Platform
+* Scope set to Dataverse environment URL
+
+| Microsoft Foundry
+| Agent
+| Exchange Administrator, Azure AI Developer
+a|
+* Active Azure subscription
+* Azure app registration
+* Tenant ID, client ID, client secret
+* Project endpoint URLs (discovery is project-specific)
+
+| Snowflake Cortex AI
+| Agent
+| Exchange Administrator, Snowflake ACCOUNTADMIN
+a|
+* Snowflake account with Cortex Agents enabled (Enterprise edition)
+* A user with `ACCOUNTADMIN` privileges for one-time setup only
+* At least one Cortex Agent created in a schema to be scanned
+* Scanner egress IP ranges from your Anypoint deployment team (`<SCANNER_EGRESS_CIDRS>`)
+* Snowflake account URL
+* Programmatic access token (PAT)
+
+| Amazon API Gateway
+| API
+| Exchange Administrator
+a|
+* IAM read-only policy for API Gateway (for example, `apigateway:GET`)
+* Policy Read permission: `apigateway:GET`
+* Policy Read action group: `apigateway:GET*` on REST and HTTP API resources
+* Policy Read resource scope (REST APIs): `arn:aws:apigateway:{region}::/restapis/*`
+* Policy Read resource scope (HTTP APIs): `arn:aws:apigateway:{region}::/apis/*`
+* Policy Read note: For web application firewall (WAF) policies, the scanner also uses `software.amazon.awssdk:wafv2` and `software.amazon.awssdk:route53`
+* AWS region knowledge
+* AWS access key ID and secret access key
+
+| Azure API Management
+| API
+| Exchange Administrator, API Management Service Reader
+a|
+* Policy Read role scope: API Management Service Reader at APIM resource or resource group scope
+* Policy Read OAuth scope: `https://management.azure.com/.default`
+* Tenant ID
+* Client ID
+* Client secret
+* Subscription ID
+* Resource group
+* Service name
+
+| Google Apigee
+| API
+| Exchange Administrator, Apigee Read-only Admin
+a|
+* Policy Read role: service account with Viewer role or an Apigee permission role with equivalent read access
+* GCP project ID
+* Service account email
+* Private key
+
+| Kong Gateway
+| API
+| Exchange Administrator, Kong Control Plane Viewer
+a|
+* Kong Gateway region
+* Personal access token (PAT)
+* Policy Apply read scope: Admin API read permission required to read policy in target environments
+// (for Write policy GA)* Policy Apply write scope: Admin API write permission required to apply policy in target environments
+
+
+| Amazon Bedrock AgentCore MCP
+| MCP
+| Exchange Administrator
+a|
+* Active AWS account
+* AWS region
+* Access key ID and secret access key
+* `bedrock-agentcore:ListAgentRuntimes`
+* `bedrock-agentcore:GetAgentRuntime`
+* `bedrock-agentcore:ListAgentRuntimeVersions`
+* `bedrock-agentcore:ListAgentRuntimeEndpoints`
+* `bedrock-agentcore:InvokeAgentRuntime`
+* Policy Read permissions: runtime read actions, including `bedrock-agentcore:ListAgentRuntimes` and `bedrock-agentcore:GetAgentRuntime`
+
+| Azure API Management MCP Server
+| MCP
+| Exchange Administrator, API Management Service Reader
+a|
+* Tenant ID
+* Client ID
+* Client secret
+* Subscription ID
+* Resource group
+* Service name
+
+| Snowflake MCP Server
+| MCP
+| Exchange Administrator, Snowflake ACCOUNTADMIN
+a|
+* Snowflake Enterprise account with MCP servers enabled
+* Snowflake account URL
+* Programmatic access token (PAT)
+
+|===
+
+== See Also
+
+* xref:exp-scanners-add-from-providers.adoc[]
+* xref:exp-providers-manage.adoc[]
+* xref:exp-scanners-manage.adoc[]

modules/ROOT/pages/exp-services-view-details.adoc

@@ -1,9 +1,7 @@
 = View Service Details
 :keywords: view service details, service detail page, anypoint exchange, exchange services, service tabs, mulesoft exchange
 
-Open a catalog entry in *Portfolio* to see its service detail page: a single view of one service, such as an agent, MCP server, Model proxy, API, or gateway. From this page, review status and cost, relationships to other services, deployments, policies, monitoring, conformance, and change history without switching contexts.
-
-//placeholder for image of service detail page
+View scanner read policies, deployments, monitoring, and conformance for a service from one detail page in *Portfolio*. Open any service, including an API, agent, MCP server, Model Proxy, or gateway, to review current status, cost, and relationships. Use this page to validate applied controls and track changes without switching contexts.
 
 == Before You Begin
 
@@ -37,7 +35,7 @@ The page is organized into tabs. The following table lists each tab, what it sho
 |Yes |Yes |Yes |Each Model Proxy is exactly one instance so there is no *Instances* tab. |No
 
 |*Policies*
-|Governance policies attached to the service or its instances (access, data, performance, compliance, and related domains your organization uses). If the instance uses a Kong gateway, the listed policies are gateway-level policies (plugins). Other service-level policies (plugins) can also apply.
+|Governance policies attached to the service or its instances (access, data, performance, compliance, and related domains your organization uses). For APIs discovered by scanners, this tab shows read policies from Amazon API Gateway, Google Apigee, Azure API Management, and Kong Gateway. If the instance uses a Kong gateway, the listed policies are gateway-level policies (plugins). Other service-level policies (plugins) can also apply.
 |Yes |Yes |Yes |Yes |No
 
 |*Monitoring*
@@ -62,6 +60,17 @@ The page is organized into tabs. The following table lists each tab, what it sho
 . Use the search box to find the service by name or description, or scan the list or grid.
 . Select the service card to open its detail page.
 
+== View Read Policies Discovered by Scanners
+
+If a provider scanner has policy-read scopes configured, the *Policies* tab shows discovered policy entries for that API instance. The tab lists policy names and mapped governance context, such as category and apply level, when the provider returns that metadata. For providers that expose policy status, the tab also shows whether a policy is enabled so teams can validate scanner coverage and conformance inputs from the latest scan snapshot.
+
+. In *Portfolio*, open *APIs* and select an API discovered by a provider scanner.
+. Open the *Policies* tab on the service detail page.
+. Review read policies imported from Amazon API Gateway, Google Apigee, Azure API Management, or Kong Gateway.
+. Use the policy list to confirm applied controls before governance reviews or conformance analysis.
+
+Policy visibility depends on the last successful scanner run, not on a live provider query. If required provider scopes or roles are missing, policy results can be incomplete or unavailable. Policy fields such as status, apply level, and detail can vary by provider. If expected policies are missing, check scanner run status and history in *Providers*.
+
 == See Also
 
 * xref:exp-overview.adoc[]