--- schema_version: "1" id: 2ce95e350836e1bb1086927e9fb71c508ffc7cf24874ef08fbdab63f376ed5f3 title: Adding Scanners from Providers collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/exp-scanners-add-from-providers.md canonical_url: https://docs.mulesoft.com/general/exp-scanners-add-from-providers source_site: docs.mulesoft.com content_type: documentation content_hash: e79e75dbc7fbf9baae8b09e63c6a9fcea884757d7f08105ba4ae4728108aa104 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started keywords: scanners, providers, add scanner, scanner configuration, workflow, anypoint platform, security scanning --- # Adding Scanners from Providers > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) and [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio). > [!NOTE] Automate scanner creation using the MuleSoft MCP Platform Server. For details, see > [create\_scanner](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#create-scanner) in the > MuleSoft MCP Platform Server Tool Reference. Watch this video to see how to discover services with providers and scanners: ![](https://play.vidyard.com/YjcnPMHjRae7fhq9sxZ3xc.jpg) ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). For provider-specific roles, credentials, and permission scopes, see [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). ## Benefits of Provider Scanners - Keep catalogs current New and changed services in the provider appear in the system without manually re-entering each registration. - Centralize visibility Discovered services appear in **Portfolio** where teams can govern, monitor, and deploy from one place. - Stay aligned with the provider 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. - Policy write For API gateway providers that support policy write (Azure API Management, Google Apigee, and Kong Gateway), a scanner connection whose credentials carry the provider’s write scope lets you apply, enable, disable, and remove policies on discovered APIs directly from Anypoint. For write scopes and requirements, see [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). ## 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: - **Home** Start from the general **Add Services** area and choose the path that connects a provider and defines a scanner (**Connect to Provider**). - **Providers** Use the area dedicated to provider and scanner management if your navigation includes it. Add or refine scanners alongside other provider work. The Akamai API Security scanner doesn’t import services; it scans third-party provider security policies and surfaces vulnerability findings for related APIs, agents, and MCP services already in **Portfolio** catalogs. - **Portfolio** Open the catalog that matches the service type you want (**Agents**, **APIs**, **MCP Servers**, and others your tenant supports). Use that catalog’s add control—the label indicates the type (for example **Add API**)—then choose provider connection to scan and discover services to add to that catalog. Not all services have a catalog. If the service doesn’t have a catalog, you can still add it to the system by using the **Add Service** button on the **Providers** page. Navigation labels can vary by catalog, enabled features, and release. ## Akamai API Security Scanner The Akamai API Security scanner behaves differently from import-based scanners. It doesn’t discover and import services from third-party providers into **Portfolio** catalogs. Instead, it scans third-party provider security policies and observed security data, correlates those results to existing services, and surfaces risk scores and vulnerability findings in related **Portfolio** catalogs. **Akamai API Security** appears in the provider list only when your administrator has enabled the Akamai API Security feature for your organization. When you save an Akamai API Security scanner, the system automatically starts **Akamai Correlation Policy** application. This policy is required for Akamai to attribute security findings to your MuleSoft APIs by stamping correlation headers on API responses. For setup details, policy behavior, and result interpretation, see [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation). ### Monitor Correlation Policy Status After creating an Akamai scanner, the scanner detail page shows an **Akamai Correlation Policy** section with the live policy application status: - **Correlation policy not applied** — amber warning with an **Apply policy now** button. - **Partial** — a progress indicator showing how many environments are covered while the apply workflow runs. - **Applied** — green badge confirming all environments are covered. When the policy is applied, the section shows a table with one row per environment and runtime combination. The table includes columns for Environment, Runtime (Omni Gateway or Mule 4), Status (Applied or Disabled), APIM Policy ID, and Asset Version. If some environments show no policy binding, select **Check again** to retry the policy application for those environments only. The operation is safe to repeat. ## Scanner OAuth Authorization Microsoft Copilot Studio and Google Vertex AI scanners authenticate through OAuth-based authentication. Create, authorize, and test the provider connection before you continue scanner setup. Each scanner supports two authentication methods: - **Microsoft Copilot Studio** - **OAuth**: Uses client credentials. Tenant ID is required, and you validate the connection directly without an interactive sign-in. - **OAuth (Authorization Code)**: Uses an interactive Microsoft sign-in and consent. Tenant ID is optional; if you don’t provide one, the connection defaults to the home tenant ID after authorization. This scheme requires a pre-configured customer OAuth application. Configure the OAuth application in Azure to request the Dynamics CRM `user_impersonation` scope, and set the OAuth callback URL to `[https:///secrets-manager/api/v1/connections/oauth/callback](https://\/secrets-manager/api/v1/connections/oauth/callback)`. - **Google Vertex AI** - **Service Account Key**: Uses a Google Cloud service account key. You validate the connection directly without an interactive sign-in. The service account must have the **Vertex AI Viewer** role. - **OAuth (Authorization Code)**: Uses an interactive Google sign-in and consent. This scheme requires a pre-configured customer OAuth application. Configure the OAuth application in Google Cloud to grant access to the Vertex AI API, and set the OAuth callback URL to `[https:///secrets-manager/api/v1/connections/oauth/callback](https://\/secrets-manager/api/v1/connections/oauth/callback)`. To authorize the connection: 1. From **Platform** > **Providers**, select the provider: - For a Microsoft Copilot Studio scanner, select **Microsoft**. - For a Google Vertex AI scanner, select **Google**. 2. In **Connect to Provider**, under **Platform**, select the platform (**Microsoft Copilot Studio** or **Google Vertex AI**). 3. Under **Authentication**, select an authentication scheme. 4. Enter connection values: - For **Microsoft Copilot Studio**: - **Tenant ID**: Microsoft Entra tenant ID. Required for **OAuth**; optional for **OAuth (Authorization Code)**. - **Client ID**: OAuth 2.0 client ID from your Azure app registration. - **Client Secret**: OAuth 2.0 client secret from your Azure app registration. - **Scope**: Dataverse environment URL, for example, `[https://.api.crm.dynamics.com](https://\.api.crm.dynamics.com)`. Required for **OAuth (Authorization Code)**; optional for **OAuth**. - For **Google Vertex AI**: - **GCP Project ID**: Google Cloud project ID that hosts the Vertex AI resources. Required for **Service Account Key**. - **Client ID**: OAuth 2.0 client ID from your Google Cloud OAuth application. Required for **OAuth (Authorization Code)**. - **Client Secret**: OAuth 2.0 client secret from your Google Cloud OAuth application. Required for **OAuth (Authorization Code)**. 5. Complete the connection: - For a direct-validation scheme (**OAuth** or **Service Account Key**), click **Test Connection** and confirm the connection succeeds. - For **OAuth (Authorization Code)**, click **Create & Authorize Connection**. In the provider popup window, sign in and grant consent, then wait for status to progress through **Connection created**, **Authorized**, and **Tested**. 6. Confirm the connection succeeds or a **Connected to ** message appears, then click **Continue**. > [!NOTE] The OAuth (Authorization Code) flow opens a provider sign-in popup. If your browser blocks > popups, authorization can’t complete and scanner setup stays in the authorizing state. ## Kong Gateway Scanner The Kong Gateway scanner connects to a Kong control plane and discovers services on one of two platforms that you select during setup: - **Kong Gateway (APIs)**: Discovers, imports, and syncs APIs from Kong Gateway into the **APIs** catalog. - **Kong Gateway (MCP)**: Discovers, imports, and syncs MCP servers from Kong Gateway into the **MCP Servers** catalog. Both platforms use the same connection credentials and setup steps. Only the platform you select differs. ### Add a Kong Gateway Scanner 1. From **Platform** > **Providers**, select **Kong**. 2. In **Connect to Provider**, under **Platform**, select the platform to scan: - **Kong Gateway (APIs)** to discover APIs. - **Kong Gateway (MCP)** to discover MCP servers. 3. Enter connection values: - **Kong Gateway Region**: Select the Kong Gateway region. - **Personal Access Token**: Enter the personal access token. 4. Click **Test Connection** and confirm the connection succeeds. 5. Click **Continue**, then name, schedule, and save the scanner to complete setup. ### OpenAPI Specifications To discover accurate, typed API definitions from Kong Gateway, link each Kong Gateway service to a Catalog API that has an attached OpenAPI Specification (OAS). The scanner reads the OAS from the linked Catalog API to build a complete, typed service definition. Uploading an OAS file directly to a Kong Gateway service only creates Kong routes—it doesn’t store a spec or endpoint definition that the scanner can read. Without a Catalog-linked spec, Kong infers routes from the gateway configuration. Inferred routes are untyped and produce a lower-quality service definition and degraded MCP bridging. To attach an OAS so the scanner can read it: 1. In the Kong **Catalog** section, create an API. 2. Attach the OAS spec to the Catalog API. 3. Link the Catalog API to a gateway service in Kong Gateway. For more information, see the [Kong API catalog documentation](https://developer.konghq.com/api-catalog/). > [!NOTE] If a Kong Gateway service isn’t linked to a Catalog API with an attached OAS, only the > first route per path is discovered. For example, if the `/items` path has both `GET` and `POST` > routes, only one of those routes appears in the discovered definition. Link the service to a > Catalog API with an attached OAS to discover all routes and methods for each path. ### Protocol to Service Type Mapping When you scan with the **Kong Gateway (APIs)** platform, the scanner assigns a service type to each discovered service based on the service’s Kong protocol and plugins.
ProtocolPluginService type

grpc / grpcs

No matching plugin

gRPC

http / https

graphql-*

GraphQL

No matching plugin

REST

The scanner currently detects gRPC and GraphQL protocols only. > [!NOTE] Services that use other protocols are registered as service type REST for now. MuleSoft > plans to support more protocols in a future release. On the **Kong Gateway (APIs)** platform, the scanner assigns a service type to a service the first time it discovers that service. Later scans don’t update that service type, even if the service’s protocol changes in Kong Gateway. To change the service type, remove the service, and let the scanner import it again. ## Scanner Configuration Overview Regardless of entry point, adding a scanner establishes trust and scope. You specify which provider platform to reach, how the system authenticates, and how you validate connectivity. You also name and schedule the scanner—or configure another trigger—so discovery runs on the cadence your team expects. Saving the configuration activates the scanner for the catalogs and features your administrator enabled. For API gateway providers that support policy write, supply connection credentials that include the provider’s write scope during setup. If the connection has only read access, the scanner discovers and reads policies, but the affected APIs appear as **Read-Only** and policy actions are unavailable until the connection’s identity is granted the provider’s write scope. For provider-specific read and write scopes, see [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). ## After the Scanner Runs 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 [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage). ## See Also - [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference) - [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details)