Contact Us 1-800-596-4880
  1. Homepage
  2. Enhanced MuleSoft Experience
  3. Adding Scanners from Providers

  4. Scanner Prerequisites by Provider

Scanner Prerequisites by Provider

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 also requires Exchange Administrator permission and the correct business group context.

For API gateway providers that support policy write, discovery access alone isn’t enough to apply policies. Policy write reuses the same scanner connection you configure here, so the connection’s credentials must also carry the provider’s write permissions (write scope). Review the additional write prerequisites in [_policy_write_prerequisites]. Write scopes are noted in the matrix as Write scope (policy apply).

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 Prerequisite Matrix

Provider Type Required Credentials, Roles, and Setup

Amazon Bedrock

Agent

Credentials: Access key ID and secret access key; AWS region

Permissions:

  • bedrock:ListAgents

  • bedrock:GetAgent

  • bedrock:ListAgentAliases

  • bedrock:GetAgentAlias

  • bedrock:ListAgentVersions

  • bedrock:GetAgentVersion

Optional (for agent invocation workflows):

  • bedrock:InvokeModel

  • bedrock:InvokeAgent

  • bedrock:InvokeInlineAgent

Setup: Agents must have an alias linked to a version and an invocable URL

Amazon Bedrock AgentCore Runtime

Agent

Credentials: Access key ID and secret access key; AWS region

Account: Active AWS account with AgentCore access

Permissions:

  • bedrock-agentcore:ListAgentRuntimes

  • bedrock-agentcore:ListAgentRuntimeEndpoints

  • bedrock-agentcore:GetAgentCard

  • bedrock-agentcore:GetAgentRuntime

  • bedrock-agentcore:ListAgentRuntimeVersions

  • bedrock:GetAgent

  • bedrock:ListAgents

Setup: Agents must be published with an active endpoint/version

Anthropic Claude Managed Agents

Agent

Credentials: Claude API key

Account: Paid Anthropic account

Databricks Agent Bricks

Agent

Credentials: Workspace URL; client ID and client secret

Account: Databricks workspace access

Permissions: Service principal CAN_QUERY on serving endpoints; CAN_VIEW or higher on endpoint metadata APIs

Setup: Discoverable agents must be custom Unity Catalog models in READY state

GoDaddy ANS

Agent

Credentials: API key and API secret

Google Gemini Agent Enterprise Platform

Agent

Credentials: GCP project ID; service account email; private key

Role: Vertex AI Viewer

LangChain LangSmith

Agent

Credentials: LangSmith API key; LangSmith workspace ID

Account: LangSmith Plus plan (or higher) workspace

Setup: Optional API host for region routing (for example, US or EU cloud host)

Microsoft Azure Copilot

Agent

Credentials: Azure app registration; client ID and client secret. Two authentication schemes are supported:

  • OAuth (Authorization Code): Interactive sign-in and consent in a Microsoft popup. 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://<your_anypoint_host>/secrets-manager/api/v1/connections/oauth/callback. Tenant ID is optional; if you don’t provide one, the connection defaults to the home tenant ID after authorization.

  • OAuth: Uses client credentials, with no interactive sign-in. Tenant ID is required.

Role: Copilot Studio Scanner

Setup: App added as an Application User in Power Platform; scope set to Dataverse environment URL, https://<org-id>.crm.dynamics.com

For setup steps, see exp-scanners-add-from-providers.adoc#microsoft-copilot-studio-scanner-oauth-authorization.

Microsoft Foundry

Agent

Credentials: Azure app registration; tenant ID, client ID, client secret

Account: Active Azure subscription

Role: Azure AI Developer

Setup: Project endpoint URLs (discovery is project-specific)

Salesforce Agentforce

Agent

Connection: Enable the connection to a Salesforce organization that has an established tenant relationship with your Anypoint Platform organization.

Setup: Enable generative AI in Anypoint Platform, accept the terms and conditions, and set a default Salesforce organization

Permissions: Exchange Administrator permission

Snowflake Cortex AI

Agent

Credentials: Snowflake account URL; programmatic access token (PAT)

Account: Snowflake account with Cortex Agents enabled (Enterprise edition)

Role: ACCOUNTADMIN, for one-time setup only

Setup: At least one Cortex Agent created in a schema to be scanned; scanner egress IP ranges from your Anypoint deployment team (<SCANNER_EGRESS_CIDRS>)

Amazon API Gateway

API

Credentials: Access key ID and secret access key; AWS region

Permissions: IAM read-only policy for API Gateway:

  • Read permission: apigateway:GET

  • Read action group: apigateway:GET* on REST and HTTP API resources

  • Resource scope (REST APIs): arn:aws:apigateway:{region}::/restapis/*

  • Resource scope (HTTP APIs): arn:aws:apigateway:{region}::/apis/*

For web application firewall (WAF) policies, the scanner also uses software.amazon.awssdk:wafv2 and software.amazon.awssdk:route53.

Azure API Management

API

Credentials: Tenant ID; client ID; client secret; subscription ID; resource group; service name

Role: API Management Service Reader

Write scope (policy apply): API Management Service Contributor role (ARM) at the API Management resource or resource group scope

Google Apigee

API

Credentials: GCP project ID; service account email; private key

Role: Apigee Read-only Admin

  • Read role: Service account with the Viewer role, or an Apigee permission role with equivalent read access

Write scope (policy apply): API Admin role (Management API), or an Apigee permission role with equivalent write access

Kong Gateway

API

Credentials: Personal access token (PAT); Kong Gateway region

Role: Kong Control Plane Viewer

  • Apply read scope: Admin API read permission required to read policy in target environments

Write scope (policy apply): Admin API write permission required to apply, enable, disable, or remove policy in target environments

Akamai Security

API Security

Credentials: Akamai Security base URL; client ID and client secret

Permissions: Access to create service accounts in Akamai Security; access to apply Akamai correlation policy in target environments

Setup: Existing services in Portfolio catalogs for correlation targets; create a connected app in MuleSoft; configure Akamai-side sync with the MuleSoft connected app. For details, see Correlating Risk Using Akamai API Security.

Amazon Bedrock AgentCore MCP

MCP

Credentials: Access key ID and secret access key; AWS region

Account: Active AWS account

Permissions: IAM user with an inline policy that allows:

  • 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

Credentials: Tenant ID; client ID; client secret; subscription ID; resource group; service name

Role: API Management Service Reader

Snowflake MCP Server

MCP

Credentials: Snowflake account URL; programmatic access token (PAT)

Account: Snowflake Enterprise account with MCP servers enabled

Role: ACCOUNTADMIN

Amazon (AWS Secrets Manager)

Vault

Credentials: AWS Static (Access Key ID and Secret Access Key) or AWS Assume Role (Access Key ID and Secret Access Key, plus Role ARN and External ID)

Setup: Vault URL; AWS region; optional Secret Name Prefix

Microsoft (Azure Key Vault)

Vault

Credentials: Azure Sp Secret (Client Secret) or Azure Sp Certificate (Client Certificate and Private Key, in PEM format)

Setup: Vault URL; Client ID; Tenant ID

HashiCorp (HashiCorp Vault)

Vault

Credentials: HashiCorp Approle (Role ID and Secret ID, plus an optional TLS CA Certificate in PEM format)

Setup: Vault URL; KV Version; Engine Type; Mount; Path; optional Namespace for Vault Enterprise

Policy Write Prerequisites

Policy write lets you apply, enable, disable, and remove policies on connected third-party gateway APIs directly from Anypoint, with no Anypoint gateway in the request path. Policy write is available for API gateway providers only: Azure API Management, Google Apigee, and Kong Gateway. Agent, API Security, and MCP scanners don’t support policy write.

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.

  • Provider write permissions: Grant the provider-specific Write scope (policy apply) listed for each API gateway provider in the [_scanner_prerequisite_matrix].

The following table summarizes the read and write scopes for each API gateway provider that supports policy write.

Provider Read Scope Write Scope ////

Amazon API Gateway

apigateway:GET

apigateway:PUT, apigateway:POST, apigateway:DELETE ////

Azure API Management

Reader role (ARM)

API Management Service Contributor role (ARM)

Google Apigee

Viewer role (Management API)

API Admin role (Management API)

Kong Gateway

Admin API read

Admin API write

Read-Only APIs

When a scanner connection has only read access to a gateway, its API instances appear as Read-Only and policy actions are unavailable. To enable policy write, grant the connection’s identity the provider’s write scope, then update the connection from the API instance.

Tracked Applies

Every policy write is tracked and records an applied or failed state alongside the scanner-read configuration. Anypoint logs each write as compliance evidence, including the policy, the target, the vendor, the timestamp, and the result. To follow the outcome of a policy operation, use the Activity log tab on the API instance. See Tracking Policy Operations in the Activity Log.

Anypoint doesn’t manage vendor policy lifecycle, versioning, or CI/CD.

See Also