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 the Scanner Prerequisites Matrix. 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:
Optional (for agent invocation workflows):
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:
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 Setup: Discoverable agents must be custom Unity Catalog models in |
||
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:
Role: Copilot Studio Scanner Setup: App added as an Application User in Power Platform; scope set to Dataverse environment URL, |
||
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 |
||
ServiceNow AI Agents |
Agent |
Credentials: Instance URL; OAuth client ID and client secret Permissions: Table API integration user with read access to the Setup: Application Registry entry in ServiceNow to generate the OAuth client ID and client secret; AI Asset Governance enabled and synced on the ServiceNow instance |
||
Snowflake Cortex AI |
Agent |
Credentials: Snowflake account URL; programmatic access token (PAT) Account: Snowflake account with Cortex Agents enabled (Enterprise edition) Role: Setup: At least one Cortex Agent created in a schema to be scanned; scanner egress IP ranges from your Anypoint deployment team ( |
||
Amazon API Gateway |
API |
Credentials: Access key ID and secret access key; AWS region Permissions: IAM read-only policy for API Gateway:
|
||
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
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
Write scope (policy apply): Admin API write permission required to apply, enable, disable, or remove policy in target environments Setup: To discover accurate, typed API definitions, link each Kong Gateway service to a Catalog API that has an attached OpenAPI Specification (OAS). For the required workflow and route-discovery limitations, see Kong Gateway Scanner. |
||
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:
Policy read permissions: Runtime read actions, including |
||
Azure API Management MCP Server |
MCP |
Credentials: Tenant ID; client ID; client secret; subscription ID; resource group; service name Role: API Management Service Reader |
||
Kong Gateway MCP Server |
MCP |
Credentials: Personal access token (PAT); Kong Gateway region Role: Kong Control Plane Viewer Read scope: Admin API read permission required to discover MCP servers in target environments Setup: Create the MCP servers for the scanner to discover in one of two ways:
Each MCP server must have a linked gateway service. The scanner doesn’t discover MCP servers that have no linked gateway service. The MCP servers reflect only the routes present in the control plane gateway services. For route-discovery limitations, see Kong Gateway Scanner. |
||
Snowflake MCP Server |
MCP |
Credentials: Snowflake account URL; programmatic access token (PAT) Account: Snowflake Enterprise account with MCP servers enabled Role: |
||
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 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.
| Provider | Read Scope | Write Scope |
|---|---|---|
Amazon API Gateway |
|
Not supported |
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. |