# mulesoft Home - Full Documentation --- 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) --- product: Getting Started keywords: add services, portfolio, service registration, service types, workflow, anypoint platform --- # Adding Services to Your Portfolio > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Your **Portfolio** is organized into catalogs: **Agents**, **MCP Servers**, **Model Proxies**, **APIs**, and **Gateways**. Each catalog holds the services (or gateway entries) your organization registered or imported for governance, monitoring, and deployment. Services enter a catalog through automated provider discovery or manual registration. For procedures, use the topics linked in each section. Watch this video to see how to register services in your portfolio: ![](https://play.vidyard.com/SUqMBGoqtj3yrXE68cET34.jpg)
ApproachWhat Happens

Create a Scanner for Provider Services

You add a provider scanner from Home or from a catalog in Portfolio. Scans discover services on supported cloud platforms and register them in the matching catalog.

Correlating Risk Using Akamai API Security

The Akamai API Security scanner doesn’t import or register services. It correlates Akamai security data to existing services and surfaces risk scores, findings, and incidents in catalog views.

Register Services Manually

You start an Add … workflow from Home or from the catalog for that service type. You supply metadata, specifications, endpoints, or cards to register the service without a provider scanner.

Gateway creation starts in Anypoint Platform, which you can open from the enhanced MuleSoft experience. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Workflow Entry Points - **Home** Use **Add Services** to open provider connection or manual registration, then select the service type. - **Portfolio** Open the **Agents**, **MCP Servers**, **Model Proxies**, **APIs**, or **Gateways** catalog. Use the add control for that type (for example, **Add API** or **Add Agent**), then select the available flow. For gateways, **Add Gateway** opens gateway creation in Anypoint Platform. Navigation labels can vary by catalog, enabled features, and release. ## Service Type Registration Options **Agents** Register by uploading an agent card or connect an agent provider scanner for discovery. **MCP Servers** Register with an MCP URL or a schema file, or connect an MCP server provider. **Model Proxies** Register manually by creating a model proxy with a routing strategy that routes requests by provider or semantic matching. **APIs** Register with an API specification, or connect an API provider so scans import APIs into the **APIs** catalog. **Gateways** Create gateways in Anypoint Platform. In the enhanced MuleSoft experience, select **Add Gateway** to open the Anypoint gateway creation flow. For more information about registering any of these types, see [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) and [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add). ## 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) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: agent fabric, mcp server, mcp bridge, mcp connector, a2a bridge, a2a connector, agent broker, ai control plane, ai agents, model context protocol, registry, governance, security,cost control --- # Agent Fabric Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 You can’t apply governance, security, or cost controls to agents you don’t know about. After you capture an inventory of agents, choose the jobs you need those agents to do. ![Diagram of Agent Fabric: a visibility foundation that supports connecting agents to existing systems, governing production traffic, and controlling LLM cost](/mulesoft/current/en-us/general/_images/agent-fabric-pillars.png) - [Agent registry](#agent-registry) Find every agent, MCP server, and API, and reuse what exists instead of rebuilding assets. - [Enable agents to take action](#agent-operations) Make the APIs, applications, and agents you already run available as tools, so agents can update records and hand work to other agents without rebuilding the agents. - [AI security and governance](#govern) Put the same authentication, access, and security rules on every agent, MCP server, and LLM call, so production traffic is routed by your rules. - [AI cost control](#cost-control) See where token spend goes, cap it, and stop paying frontier models for work smaller models can do. ## Agent Registry The registry is a single inventory of agents, MCP servers, APIs, and related services, regardless of which platform built them. Find what already exists, then keep the catalog current as new assets appear. ### Registry Teams rebuild agents and tools that already exist when they can’t find those assets. Besides your own agents, MCP servers, model proxies, APIs, and gateways, the catalog includes a curated set of public MCP servers from the Official MCP Registry and Informatica. - Find and reuse registered agents, MCP servers, model proxies, APIs, and gateways. - See conformance status and instance health before you use an asset. - Govern, monitor, and manage an asset’s lifecycle from the catalog page. - Publish agents, MCP servers, and APIs so other teams can reuse them. Use the registry when you start a new agentic project and want to use existing assets or when you want to share assets built by your team. Learn more: [View Your Portfolio Overview](https://docs.mulesoft.com/general/exp-portfolio-overview) ### Scanners Agents appear on platforms faster than teams can manually register them. Scanners watch supported platforms and automatically register any agents, APIs, and MCP servers they discover to the matching catalog in the registry. - Connect cloud providers as scanner sources. - Discover and register agents, MCP servers, and APIs on a schedule or on demand. - See last-run results and how many assets each scan found. Use scanners when agents run on more than one platform and manual registration can’t keep the registry current. Learn more: [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) ## Enable Agents to Take Action An agent that can only describe a problem can’t fix it. Agent Fabric exposes your APIs, applications, and agents as tools that those agents can call for help. If needed, Agent Fabric can even coordinate multiple agents when one isn’t enough. Start by exposing existing APIs as MCP servers, and use an A2A bridge for agents that aren’t A2A-compliant. Add a broker when work spans specialized agents. Use connectors when agents need to call LLMs or other AI services directly. ### Expose APIs as MCP Servers Your APIs already do the work agents need them to do, but agents can’t call APIs as tools until you expose those APIs as MCP servers. MCP Bridge turns an existing API or SaaS system into an MCP server without custom code and without changing the underlying system. - Publish only the operations agents should call. - Apply existing governance policies to the resulting MCP server. Use MCP Bridge when agents must call APIs you already have and you don’t want to build a custom MCP server. Learn more: [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) ### MCP Connector MCP Connector uses the Model Context Protocol so AI clients can invoke APIs, connectors, and apps from a Mule application. The resulting MCP server or client runs in Mule. As a server, the app exposes API-led investments, legacy systems, and SaaS applications that don’t natively support MCP. As a client, the app can call external MCP servers. - Expose Mule apps, connectors, and APIs as MCP tools and resources. - Run an MCP server or MCP client inside Mule, without a separate hosting environment. - Use Streamable HTTP (recommended) or SSE (deprecated) for transport. Use MCP Connector when the tools agents need don’t map to a single existing API and you need custom Mule logic. Learn more: [MCP Connector](https://docs.mulesoft.com/mcp-connector/latest/) ### A2A Bridge Agent Fabric orchestrates only A2A-compliant agents, but many enterprise agents, including Agentforce agents, aren’t A2A-compliant on their own. An A2A bridge presents those agents as A2A-compliant so they can join your network without being rebuilt. - Make a non-A2A agent A2A-compliant without changing the source agent. - Govern, monitor, and orchestrate the bridged agent like any native A2A agent. Use A2A Bridge for agents that aren’t yet A2A-compliant. Use A2A Connector when you need custom Mule application logic. Learn more: [Make an Agent A2A-Compliant](https://docs.mulesoft.com/general/exp-services-create-a2a-bridge) ### A2A Connector A2A Connector implements the A2A protocol in a Mule application so that application can act as an A2A server, an A2A client, or both. - Add A2A server and client support to a Mule application. - Let agents discover capabilities and delegate specialized tasks to other agents. Use A2A Connector when existing Mule applications must participate as A2A-compliant agents. Learn more: [A2A Connector](https://docs.mulesoft.com/a2a-connector/latest/) ### Agent Broker A broker is an intelligent router that orchestrates work across specialized A2A-compliant agents. It decides which agent handles which task and routes the request to the best-suited agent or broker. You define the broker and its nodes in Agent Script (`.agent` files), a graph that mixes deterministic and non-deterministic actions. After you publish an agent network, brokers appear as specialized agents in Agent Registry and can be reused by other brokers. - Include MCP tools and other brokers in the routing graph. - Deploy the agent network, including the broker, to a CloudHub 2.0 shared or private space or to a Runtime Fabric target. - See connections and call volume in Agent Visualizer. Use a broker when work spans multiple specialized agents. Learn more: [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) ### Other AI Connectors Agents need the LLMs and knowledge stores you already operate. AI connectors give agentic workflows pre-built access to those models and vector databases so that you don’t need to write a custom integration for each one. - Invoke Agentforce agents and Amazon Bedrock foundation models from Mule. - Call LLMs through the Einstein Trust Layer or through inference APIs from multiple providers. - Use vector stores for search and RAG, and compose LLM, vector, and tool operations in Mule. Use these connectors when a Mule application must call those AI services directly. Learn more: - [Agentforce Connector](https://docs.mulesoft.com/agentforce-connector/latest/) - [Amazon Bedrock Connector](https://docs.mulesoft.com/amazon-bedrock-connector/latest/) - [Einstein AI Connector](https://docs.mulesoft.com/einstein-ai-connector/latest/) - [MuleSoft AI Chain Connector](https://docs.mulesoft.com/mulesoft-ai-chain-connector/latest/) - [MuleSoft Inference Connector](https://docs.mulesoft.com/mulesoft-inference-connector/latest/) - [MuleSoft Vectors Connector](https://docs.mulesoft.com/mulesoft-vectors-connector/latest/) - [MuleSoft WebCrawler Connector](https://docs.mulesoft.com/mulesoft-webcrawler-connector/latest/) ### Agent Visualizer Multi-agent systems are hard to operate when you can’t see how work moves through them. Agent Visualizer maps your agents, MCP servers, and LLMs, including agents from external platforms, to verify routing in development and find bottlenecks and failures in production. - See how agents, brokers, and MCP servers connect. - Watch live request flows and metrics such as latency, throughput, and error rates. - Compare historical patterns when a failure isn’t obvious in real time. Use Agent Visualizer during development to verify the network, at deployment to confirm routing, and in production to troubleshoot. Learn more: [Agent Visualizer Overview](https://docs.mulesoft.com/agent-visualizer/) ### Monitor A defined policy isn’t the same as healthy traffic. Monitoring shows latency, error rates, and request volume so that you can catch regressions and decide when to change policy or capacity. - View runtime health metrics for a service. - Compare signals across instances or environments. - Send alerts to Slack, Microsoft Teams, and email. - Use organization-wide dashboards when observability is enabled. Use monitoring during development to validate performance and in production to meet SLAs and catch issues before they affect users. Learn more: - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications) ## AI Security and Governance Agents that reach production without a defined security, identity, and compliance strategy become a risk, as different platforms enforce different rules, or even none at all. Define that strategy once, and Agent Fabric enforces it on live traffic across every agent, MCP server, and LLM call. ### Omni Gateway Omni Gateway is Agent Fabric’s runtime enforcement point: a single gateway that sits in front of your agents, APIs, MCP servers, and LLM traffic, regardless of the platform that built them. A managed instance of an API, agent, or MCP server puts Omni Gateway in the request path so policy enforcement applies across data privacy, authentication, compliance, cost controls, and monitoring. - Require authentication and authorization on agent, API, and MCP server requests. - Limit which tools and APIs an agent can call. - Keep an audit trail of traffic for security and compliance. Use a managed instance on Omni Gateway when agents or APIs handle sensitive data, call external systems, or must follow the same runtime rules in every environment. LLM traffic uses a model proxy, which you also deploy to Omni Gateway. Learn more: - [Omni Gateway Overview](https://docs.mulesoft.com/gateway/latest/) - [Getting Started with Omni Gateway](https://docs.mulesoft.com/gateway/latest/gateway-getting-started-overview) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) ### Governance Strategies Rewriting the same security, privacy, and cost rules for every agent and service doesn’t scale. A governance strategy defines those rules once and applies them across the agents, APIs, and MCP servers in scope. - Define rules once for access, data privacy, performance and cost, and compliance. - Apply them at the service or instance so live traffic matches the strategy. - See which services fail conformance. - Block or flag noncompliant activity. Use governance strategies when agents, APIs, and MCP servers must follow the same auditable rules. Learn more: [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) ### 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 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 Open Policies when you run gateways from more than one vendor and need the same controls on all of them. Learn more: [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) ### Cross-Gateway and Third-Party API Governance Services that run on a third-party API gateway still must meet your standards. Federated governance includes those APIs in the same conformance view so they don’t escape oversight. - Govern third-party APIs alongside MuleSoft-hosted APIs. - Monitor conformance across gateways from different vendors. Use cross-gateway governance when APIs that matter to the business run on a connected third-party gateway and still need to meet your standards. Learn more: - [Govern Third-Party Provider APIs](https://docs.mulesoft.com/general/exp-governance-govern-third-party-apis) - [Monitoring Cross-Gateway Conformance](https://docs.mulesoft.com/general/exp-governance-monitor-cross-gateway-conformance) ### Security A compromised, misconfigured, or malicious agent can leak data, take unauthorized actions, or drive unexpected cost. These controls detect that behavior, keep credentials in the vault you already use, and surface known risk on services you’ve already discovered. - Detect and contain rogue agents: Apply Rogue Agent Detection and Agent Kill Switch policies to each model proxy you want to protect. Detection flags risky behavior for your review. The Kill Switch policy blocks that agent’s access to the model proxy when you quarantine it. Quarantine always requires your review, and you reverse it if needed. Learn more: [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents) - External vaults: Register an external vault so credentials stay in AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. Only metadata is stored (zero-copy). Learn more: [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) - Akamai risk correlation: Correlate security findings to APIs and MCP services you’ve already discovered, so you can triage risk before it becomes an incident. Learn more: [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) ## AI Cost Control LLM token spend grows without a single place to see it, cap it, or reduce it. Budget management shows that spend and caps it. Cost optimization reduces what each call consumes. ### Model Proxy Agents that call each LLM provider directly get a different endpoint, a different policy set, and a different bill. A model proxy, deployed to Omni Gateway, is one governed endpoint for multiple providers. Routing, caching, and policy run in front of every call. Token data from those calls feeds cost management. - Route by model or by meaning (semantic routing). - Reuse similar responses with semantic caching to cut latency and spend. - Apply policies, including the security policies that detect and contain rogue agents. Use a model proxy when agents call LLMs and you need the same governance, routing, and cost visibility across providers. Learn more: - [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy) - [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service) - [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service) - [Omni Gateway Overview](https://docs.mulesoft.com/gateway/latest/) ### Budget Management Token usage and spend are visible, so you track and cap cost as needed. Set model costs so token counts read as dollars. Set budgets to limit spend or tokens over time. Use model wallets to cap a caller’s token or dollar spend against a provider. - Monitor token usage and spend across model proxies, agents, and MCP servers. - See which providers and model wallets are at risk or at their limit. - Set input and output token costs per model so reports read as dollars. - Set daily, weekly, or monthly budgets by spend or by tokens. - Cap a model-proxy caller’s token or dollar spend against a provider. After the budget is reached, the proxy blocks further requests to that provider’s models. Use budget management when you need visibility and limits on LLM spend. Model wallets require an identity provider. Budgets are approximate: Usage can briefly exceed a limit before the proxy blocks requests. Learn more: - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage) - [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs) ### Cost Optimization A frontier model for a simple task, a repeated prompt, or a bloated payload all add cost without adding value. Optimization policies reduce token consumption for MCP servers, agents, and models without changing what the instance does. - Route by model or by meaning (semantic routing) instead of always using the most expensive model. - Reuse results for similar requests with semantic caching. - Trim unnecessary tools and payload with optimization policies. Use cost optimization when token consumption is a significant cost and you want to reduce spend. Learn more: [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) ## Supporting Tools ### Anypoint Code Builder You need a place to design and test an agent network before it hits production. Anypoint Code Builder is that environment: You configure agent interactions, develop custom MCP servers, and validate routing locally. - Design and configure agent network structures with the visual canvas. - Define routing logic and agent interactions in Agent Script. - Build and test agent workflows locally before deploying. - Develop custom MCP servers for specific integration needs. - Use MuleSoft Vibes to generate and validate network configurations from natural language. Use Anypoint Code Builder when you need to design, test, or generate an agent network before you deploy it. Learn more: - [Anypoint Code Builder Overview](https://docs.mulesoft.com/anypoint-code-builder/) - [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) ### MuleSoft Vibes Hand-authoring a broker and agent network can be slow, and lead to mistakes at deploy time. MuleSoft Vibes, the AI assistant in Anypoint Code Builder, turns a description of the network you want into YAML and Agent Script and checks it against architecture best practices before you deploy it. - Describe your desired agent network in natural language and generate YAML configurations. - Validate network structure and routing logic against architecture best practices. - Move faster from initial design through testing and refinement. Use MuleSoft Vibes when you want to draft or change project files from a description instead of authoring every file by hand. Learn more: - [MuleSoft Vibes for Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/vibes-get-started) - [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) ## What’s Next - For a guided path through the registry, agent actions, governance, and cost control, get started with the [Agent Fabric learning map](https://docs.mulesoft.com/general/learning-map-agent-fabric). - For the technical foundations and capability pillars, explore the [Agent Fabric Technical Overview](https://www.mulesoft.com/lp/ebook/mulesoft-agent-fabric-technical-overview). - For architecture and orchestration design patterns, see the [Agent Fabric Deep Dive](https://architect.salesforce.com/docs/architect/fundamentals/guide/mulesoft-agent-fabric-deep-dive.html#Agent_Orchestration_Design_Patterns). ## See Also - [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) - [Connecting a Trusted Salesforce Organization to Anypoint Platform](https://docs.mulesoft.com/access-management/connecting-salesforce-orgs) - [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai) --- product: Getting Started keywords: agent fabric, agent fabric release notes, new features, fixed issues, version history --- # Agent Fabric Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Agent Fabric is the AI control plane for AI agents, Model Context Protocol (MCP) servers, and APIs built across platforms. You can see all of your services, let agents take action in your existing tech stack, enforce open policies at runtime, and track and optimize the cost of your AI investments. ## October 21, 2026 ### What’s New - You can now deploy your agent network locally and test each broker through an Agent-to-Agent (A2A) chat interface directly from Anypoint Code Builder. Use local deployments to iterate on your agent network without publishing or deploying it. For more information, see [Deploy and Test Agent Networks Locally](https://docs.mulesoft.com/agent-network/latest/af-local-deploy-and-test). - You can now configure OAuth 2.0 client credentials authentication for LLMs in agent networks. For more information, see [Agent Network YAML Reference](https://docs.mulesoft.com/agent-network/latest/af-agent-network-yaml-reference). - You can now reuse existing MCP assets from Exchange that use SSE transport. - Agent networks now support Agent Script dialect version 1.4. - You can now configure authentication for agent cards that use dual egress upstreams. For more information, see [Agent Network YAML Reference](https://docs.mulesoft.com/agent-network/latest/af-agent-network-yaml-reference). - This release fixes an issue in which deployments failed when an agent network reused an existing asset from Exchange. ### Fixed Issues
Issue ResolutionID

Declared variables are now validated when you build an agent network.

W-24455489

Deployments now preserve the proxy-aware Axios agent.

W-24195003

Builds now fail with error code 1035 when a broker has pushNotifications enabled.

W-23930153

Metadata for version 1.0 agent networks now includes an applications entry.

W-24235374

Agent network builds now detect variable name collisions.

W-24335536

## August 31, 2026 ### What’s New - You can now deploy agent networks to Anypoint Runtime Fabric (RTF) targets. Your RTF deployment must be on version 3.0.277 or later. For more information, see [Deploy Agent Network Instances](https://docs.mulesoft.com/agent-network/latest/af-deploy-agent-network-targets). - You can now deploy agent networks that do not include a registry. - Agent networks now support the [Extended Agent Card](https://a2a-protocol.org/latest/specification/#3111-get-extended-agent-card) from the Agent2Agent (A2A) Protocol specification, enabling richer agent metadata and discovery capabilities. - You can now connect the enhanced experience to AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault so API keys and other credentials stay in your secrets manager. MuleSoft stores only metadata, such as secret names and paths, not the secret values. It reads the secret from your vault when a model proxy or other service needs it. For more information, see [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). - You can now contain a rogue AI agent before it leaks data, takes unauthorized actions, or runs up costs. Stop that agent’s requests from reaching your models, then restore access if the containment was a false positive. For more information, see [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents). - Cost Management now includes budget management. Set spending budgets for your model wallets, track spend against each budget, and manage budgets across providers and models from the **Budgets** tab. For more information, see [Budgets Tab](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage#budgets-tab). - The Cost Management **Optimizations** page now includes an **Agents** tab, so you can review token usage and optimization opportunities for your agents alongside model proxies and MCP servers. For more information, see [Filter and Search](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage#filter-and-search). - You can now create, edit, delete, and list model wallets, which allocate token budgets that are granted only when a request’s claims match the wallet’s required claims. Manage model wallets from the UI or through the MuleSoft Agent. For more information, see [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage). - You can now edit instances for model proxies, APIs, agents, and MCP servers from the service detail page or the instance detail page, without switching to Anypoint Platform. - Model Proxy now supports semantic caching, TLS security for provider connections, external vault–based provider authentication, and the Model Proxy Request Compression policy. For more details about updates to model proxy, see [Model Proxy Release Notes](https://docs.mulesoft.com/release-notes/gateway/model-proxy-release-notes). - MCP Bridge now exposes tool output schemas as part of the MCP specification, so you can connect servers built with MCP Bridge to Agentforce. - These SaaS connectors are now available in the Trusted MCP catalog: Wix, WordPress.com, Hootsuite, Descript, Intercom, Front, and LiveChat. - You can now create an A2A bridge to make a non-A2A agent A2A-compliant so that Agent Fabric can discover, govern, and orchestrate it alongside native A2A agents. For more information, see [Make an Agent A2A-Compliant](https://docs.mulesoft.com/general/exp-services-create-a2a-bridge) - You can now use OAuth 2.0 Authorization Code for Microsoft Copilot Studio scanners to create, authorize, and test the provider connection before you continue scanner setup. For more information, see [Microsoft Copilot Studio OAuth Authorization](https://docs.mulesoft.com/general/exp-scanners-add-from-providers#microsoft-copilot-studio-oauth-authorization). - You can now apply universal policies to your API instances and manage the resulting native policies. A universal policy is defined once and applied as the correct native policy on each supported gateway. For more information, see: - [Apply Open Policies](https://docs.mulesoft.com/general/exp-governance-policy-library-apply) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - API scanners now write policies from these provider platforms: Google Apigee, Azure API Management, and Kong Gateway. For these providers, policy results are visible from each discovered API in Portfolio > APIs > Policies. For more information, see: - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference) - [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - You can now track remediation and scan status in the **Akamai Security Findings** table on the **Conformance** tab. For more information, see [Track Remediation and Scan Status](https://docs.mulesoft.com/general/exp-akamai-risk-correlation#track-remediation-and-scan-status). ### Fixed Issues - Improved performance for agent network operations. - Fixed issues with LLM connectivity and Gemini 3 model integration. ## August 24, 2026 ### What’s New - Use MuleSoft Vibes, Anypoint Code Builder, or the Anypoint CLI to undeploy agent networks and unpublish Exchange assets associated with those networks. For more information, see [Deploy Agent Network Instances](https://docs.mulesoft.com/agent-network/latest/af-deploy-agent-network-targets) and [Publish Agent Network Assets](https://docs.mulesoft.com/agent-network/latest/af-publish-agent-network-assets) ## August 6, 2026 ### What’s New - Previously in agent network 2.0, connection and broker IDs were restricted to lowercase letters, numeric characters, and non-trailing underscores. You can now use standard naming conventions, such as upper case letters, dashes, and periods for these IDs. - To resolve common deployment errors, see [Resolve Agent Network Deployment Errors in Anypoint Code Builder](https://docs.mulesoft.com/agent-network/latest/af-deploy-agent-network-targets#resolve-issues). ## July 14, 2026 ### What’s New Build agent networks with predictable, governed orchestration using [Agent Script](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) — a graph-based language that gives you explicit control over how brokers coordinate agents, tools, and LLMs. In Agent Network 2.0, agent brokers use guided determinism to separate LLM-powered reasoning from deterministic control flow. With guided determinism you get intelligent decision-making where you need it and guaranteed execution paths everywhere else: - Define broker orchestration as a graph of nodes, edges, and triggers in Agent Script (`.agent`) files. Each node performs a discrete step — either an LLM-powered action like classification or a deterministic action like routing — giving you full visibility and control over execution order. - Use probabilistic nodes for complex, open-ended decisions that require nuanced judgment, such as ticket severity classification or intent recognition. - Use deterministic nodes to enforce fixed execution paths once a key decision has been made, ensuring reliable, rule-based behavior across operational flows. - View a graph-based visual canvas alongside Agent Script code. - Organize projects with a dedicated `/brokers` directory containing `.agent` files alongside your `agent-network.yaml` registry and context definitions. - Communicate across agents using version 1.0 of the Agent2Agent (A2A) Protocol specification. - Create and configure agent networks using natural-language prompts in MuleSoft Vibes, including broker graph design, node configuration, and Exchange asset integration. - Build, publish, and deploy agent networks in CI/CD environments using the Anypoint CLI plugin. For more information, see [Building Agent Networks for Agent Fabric](https://docs.mulesoft.com/agent-network/latest/af-agent-networks). ## April 29, 2026 ### What’s New These Agent Fabric features are now available in Canada Cloud and Japan Cloud.
CategoryFeature

Discoverability

Agent Registry: Agent Assets

Agent Registry: MCP Assets (Including Public MCP Assets)

Agent Registry: LLM Assets

Agent Scanners

Governance

Agent, MCP, LLM instances in API Management

A2A, MCP, LLM Omni policies

Managed Omni Gateway in CloudHub 2.0

Managed Omni Gateway in Anypoint Runtime Fabric

Trusted Agent Identity

MCP Bridge

Orchestration

Agent Broker authoring with MuleSoft Vibes (Anypoint Code Builder)

Agent Broker authoring via YAML (Anypoint Code Builder)

Agent Broker deployment to CloudHub 2.0

Agent Broker deployment to Anypoint Runtime Fabric

For details, see [Hyperforce Release Notes](https://docs.mulesoft.com/release-notes/hyperforce/hyperforce-release-notes). ## February 17,2026 ### What’s New - Exchange now supports GoDaddy ANS agents. You can now add a scanner to automatically discover and register GoDaddy ANS agents. GoDaddy ANS agents are verified by GoDaddy to be safe and secure. Govern and consume the agents in other applications. For more information, see [Adding a Scanner for GoDaddy ANS](https://docs.mulesoft.com/exchange/adding-godaddy-scanner). ## February 9, 2026 ### What’s New - Agent Visualizer now includes search and filtering capabilities and MCP server and tool insights. For more information, see [Agent Visualizer Release Notes](https://docs.mulesoft.com/release-notes/agent-visualizer/agent-visualizer-release-notes). ## February 6, 2026 ### What’s New - This release includes agent network project updates. See [Agent Network Project Updates](https://docs.mulesoft.com/release-notes/code-builder/acb-release-notes#new-features-agent-networks-feb6-26). ## January 30, 2026 - In Anypoint Exchange, you can now add agent scanners to automatically discover and register AI agents across agent ecosystems on external platforms, which include Amazon Bedrock, Google Vertex AI, and Microsoft Azure Copilot. After the agents are registered, govern and consume them in other applications. For more information, see [Discovering and Cataloging External Services with Scanners](https://docs.mulesoft.com/exchange/discovering-and-importing-external-agents). ## January 23, 2026 ### What’s New - Anypoint Exchange now includes an option to publish MCPs via URLs instead of uploading a schema file. For more information, see [Anypoint Exchange Release Notes](https://docs.mulesoft.com/release-notes/exchange/anypoint-exchange-release-notes). - You can now create and manage instances for publicly available MCP servers in API Manager. For more information, see [API Manager Release Notes](https://docs.mulesoft.com/release-notes/api-manager/api-manager-release-notes). ## January 15, 2026 ### What’s New - This release includes agent network project updates and fixed issues. See [Agent Network Project Updates](https://docs.mulesoft.com/release-notes/code-builder/acb-release-notes#new-features-agent-networks-jan15-26). ## December 11, 2025 ### What’s New - This release includes agent network project updates and fixed issues. See [Agent Network Project Updates](https://docs.mulesoft.com/release-notes/code-builder/acb-release-notes#new-features-agent-networks-dec11-25). ## November 4, 2025 ### What’s New - This release includes updates to agent network projects. See [Agent Network Project Updates](https://docs.mulesoft.com/release-notes/code-builder/acb-release-notes#agent-networks-nov-25). ## October 3, 2025 ### What’s New - Discover agents and MCP servers with Anypoint Exchange. For more information, see [Anypoint Exchange Release Notes](https://docs.mulesoft.com/release-notes/exchange/exchange-release-notes). - Orchestrate agents across ecosystems with agent brokers, a context-aware routing service for agents and assets. For more information, see [Anypoint Code Builder Release Notes](https://docs.mulesoft.com/release-notes/code-builder/acb-release-notes). - Secure Omni Gateway Instances with Policies. For more information, see [API Manager 2.x Release Notes](https://docs.mulesoft.com/release-notes/api-manager/api-manager-release-notes). - Observe and visualize your agentic assets. - View metrics, logs, and traces for agentic assets in Anypoint Monitoring. For more information, see [Anypoint Monitoring Release Notes](https://docs.mulesoft.com/release-notes/monitoring/anypoint-monitoring-release-notes). - Observe every agent interaction with Agent Visualizer, a visual map for your agent network. For more information, see [Agent Visualizer Release Notes](https://docs.mulesoft.com/release-notes/agent-visualizer/agent-visualizer-release-notes). ## See Also - [Learn About Agent Fabric](https://docs.mulesoft.com/general/learning-map-agent-fabric) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started --- # Agent Fabric Use Cases > For the full documentation index, see: https://docs.mulesoft.com/llms.txt ## Why Agent Fabric Enterprises don’t struggle to build one agent. They struggle to run many — across Agentforce, Bedrock, custom Mule implementations, and vendor platforms — without losing control of cost, security, and consistency. The usual response is to solve each problem per platform: custom API adapters here, a spend dashboard there, guardrails reimplemented for every team. That work duplicates effort, drifts out of sync, and leaves gaps no one owns. Agent Fabric replaces that per-platform sprawl with one governed layer that every agent, API, model, and provider routes through. Expose APIs as agent tools without touching code, enforce the same policies and budgets everywhere, attribute every token to the team that spent it, and contain a rogue agent before it causes damage — all from a single point of control. The result is faster time-to-agent, predictable spend, and governance that holds as you scale from proof of concept to production. Each use case below maps a specific business problem to the Agent Fabric capabilities that solve it, so you can start where the pain is and build incrementally. Use the quick-reference table to match your immediate goal to the right capability. ## Find Your Use Case
If you want to…​Use caseGo to

Make existing APIs agent-ready without modifying code

Select which API operations to expose as MCP tools, apply read-only filtering, and control agent access to your APIs.

Making Your APIs Agent-Ready

Control token usage and optimize model selection

Monitor token usage across agents and applications, then route queries to cost-effective models based on complexity.

Controlling LLM Costs in Agent Fabric

## Discover and Govern Agents Across Your Organization Use a centralized registry and automated scanners to discover, catalog, and manage agents across your organization. Know what exists and where before you apply governance. For example, a business process outsourcer managing agents across multiple client platforms, or an enterprise security team asked to audit every agent in production, can use Registry and Scanners to get a complete, current picture without manually tracking deployments. For more information, see [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio). ## Make APIs Agent-Ready with MCP Bridge Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. For example, an organization with hundreds of existing Mule APIs can make them callable by agents in minutes through configuration alone, without touching the underlying implementations. For more information, see [Making Your APIs Agent-Ready](https://docs.mulesoft.com/general/af-use-case-mcp-bridge). ## Enforce Consistent Policies Across Agent Platforms Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. For example, a regulated industry deploying agents across Agentforce, Bedrock, and custom Mule implementations can enforce the same data privacy and rate limiting rules everywhere through a single Omni Gateway policy. For more information, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ## Monitor Costs and Optimize Model Selection Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. For example, a team running hundreds of daily agent interactions can route routine lookups to a smaller, cheaper model and reserve a frontier model only for tasks that require complex reasoning. For more information, see [Controlling LLM Costs in Agent Fabric](https://docs.mulesoft.com/general/af-use-case-cost-management). ## Coordinate Multi-Agent Processes with Brokers Use agent brokers and agent networks to coordinate task delegation across A2A-compliant agents with guided determinism. Define broker routing logic in Agent Script to handle complex business processes, error scenarios, and unhappy paths that require multiple specialized agents working in sequence. For example, an order management process that involves a research agent, a pricing agent, and an approval agent can be wired together in a single agent network with a broker that routes each step to the right specialist. ## Get Started New to Agent Fabric? Start with the [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) and [Agent Fabric learning map](https://docs.mulesoft.com/general/learning-map-agent-fabric) to understand the fundamentals. After you understand the basics, choose a use case to implement. ## See Also - [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) - [Learn About Agent Fabric](https://docs.mulesoft.com/general/learning-map-agent-fabric) - [Controlling LLM Costs in Agent Fabric](https://docs.mulesoft.com/general/af-use-case-cost-management) - [Making Your APIs Agent-Ready](https://docs.mulesoft.com/general/af-use-case-mcp-bridge) --- product: Getting Started keywords: ai features, data usage, data privacy, mulesoft ai, data handling, ai data policy --- # AI Features and Data Usage > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft AI features use your data to generate responses. Understanding what data each feature uses helps you make informed decisions about privacy, compliance, and how you work with AI in MuleSoft. By default, MuleSoft AI features access LLMs within the Salesforce Trust Boundary, a set of security and data governance controls that keeps your data within Salesforce-managed infrastructure. MuleSoft AI features process data you submit securely within Salesforce-managed boundaries and route it through your connected Salesforce organization for tracking and billing. If you configure or bring your own LLM (BYO-LLM), data processing is governed by your LLM provider’s terms. For clarity and without limitation, the various third-party machine learning and generative AI model building platforms that are supported within the MuleSoft Services and allow you to BYO-LLM are Non-SFDC applications. This table lists the Customer Data you submit to our services, as defined in our [Main Services Agreement (MSA)](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Salesforce_MSA.pdf), and usage data about your interactions with MuleSoft AI features. Customer Data that you submit to MuleSoft AI features is not used to train AI models or shared across customers. For more information about data usage, see Customer Data and Usage Data in the MSA. For billing information, see [Agentforce and Generative AI Usage and Billing](https://help.salesforce.com/s/articleView?id=ai.generative_ai_usage.htm&type=5).
ProductFeatureData UsedUses Generative AI

Intelligent Document Processing (IDP)

Document Analysis with Custom Schemas

This feature uses documents that you upload in supported formats (images, PDFs, and TIFFs) as input, along with natural language prompts and questions that you provide. It also uses document schema metadata that you define, such as field names, descriptions, and data types, and sample data that conveys the expected output format.

Yes

  • OpenAI GPT-4o, GPT-4o Mini, GPT-5.1, and GPT-5.2

  • Google Gemini 2.0 Flash 001 and 2.5 Flash

  • Anthropic Claude Sonnet 4.6

MuleSoft Vibes

Agent-Driven Development (flow generation, API specification generation, asset publishing, and more)

This feature uses natural language prompts that you type and, with your permission, project files such as code, requirements, and configuration, along with context that you attach such as logs, terminal output, and URLs. It grounds responses with MuleSoft metadata, such as connector and component descriptions, API design documentation, and public Anypoint Exchange metadata.

Yes

Anthropic Claude Sonnet 3.5 with OpenAI GPT-4o Mini for planning (via Amazon Bedrock)

DataWeave Generation

This feature uses input and output sample data that you provide, such as JSON, XML, and CSV, along with optional structure metadata and natural language instructions. It grounds responses with MuleSoft DataWeave function and operator documentation.

Yes

OpenAI GPT-4o

Anypoint Exchange

API Documentation Generation

This feature uses API specifications that you upload, such as RAML, OAS, SOAP, WSDL, AsyncAPI, GraphQL, and gRPC, along with asset metadata such as name, description, tags, and version.

Yes

OpenAI GPT-5

Connector Builder

AI-assisted connector generation

This feature uses OAS and API specifications that you provide, along with your natural language prompts and connector configuration metadata such as connections, operations, pagination, triggers, and value providers. It uses this data during generation, testing, packaging, and release phases of your connector project.

Yes

User’s configured model

Enhanced MuleSoft Experience

MuleSoft Agent

This feature uses natural language prompts that you type, along with the current page context within the enhanced experience and metadata accessible under your Access Management permissions, such as portfolio, governance, monitoring, cost, organization, and environment information.

Yes

OpenAI GPT-5 mini

Partner Manager

View Message Summaries

This feature uses the source or target payload that you open in Activity and summarize, including pre-translated and post-translated message content such as EDI and mapped JSON or XML. It also uses message context metadata, such as message type, sender, and receiver, along with extracted business data in the payload, such as order number, customer name, order details, and configured custom attributes like PO number or invoice number.

Yes

Einstein Generative AI

Runtime Manager

Diagnostics Agent

This feature uses Java thread dumps from your deployed applications and the Diagnostic Information Analysis File (DIAF), which includes application metadata, performance statistics, error messages and stack traces, and recent log entries. It also uses CloudHub or CloudHub 2.0 instance information and deployment configuration.

Yes

Google Gemini 2.5 Flash

## See also - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) - [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) - [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) --- product: Getting Started keywords: anypoint platform glossary, mulesoft terminology, platform concepts, definitions, anypoint terms, integration glossary --- # Anypoint Platform Glossary > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Authorized short versions of some product names are presented in parentheses, for example: Anypoint Design Center (Design Center). ## A access management Anypoint Platform features that help you manage your account and configure access and permissions within your organization. A REST API provides programmatic control of access-related resources. agent A service, such as the Runtime Manager agent, that is used by or associated with Mule but is not a Mule-managed service component. An agent is registered with the Anypoint Runtime Manager and has the same lifecycle as the corresponding Mule instance, so you can initialize and destroy resources when the Mule instance starts or stops. Anypoint CLI A scripting and command-line tool for Anypoint Platform and Anypoint Platform Private Cloud Edition (Anypoint Platform PCE). Anypoint Design Center (Design Center) A cloud-based development environment for Mule runtime engine (Mule) applications and API definitions. Anypoint Design Center API Designer (API Designer) Web-based graphical environment for designing, documenting, and testing APIs. Anypoint Exchange (Exchange) A curated catalog of reusable assets such as APIs, policies, API spec fragments, API groups, GraphQL APIs, templates, examples, custom assets, rulesets, and integration assets such as connectors. Omni Gateway An Envoy-based, ultrafast lightweight API gateway designed to manage and secure APIs running anywhere. Anypoint Management Center (Management Center) A single web interface to administer Anypoint Platform, both on-premises and in the cloud. Manage APIs and users, analyze traffic, monitor SLAs, and troubleshoot underlying integration flows. Anypoint MQ (messaging queue) Enterprise-class cloud messaging that is fully integrated with Anypoint Platform. Anypoint Object Store v2 Storage for data and states across batch processes and Mule components from within a single application. Anypoint Partner Manager v2 The web-based user interface for partner configuration, document flow, and transaction monitoring. Anypoint Platform™ A MuleSoft product to design, build, and manage APIs and integrations. Anypoint Platform Private Cloud Edition A special packaging of Anypoint Platform that is available for running on your own local servers. This implementation runs on Docker and Kubernetes, is compatible with Pivotal Cloud Foundry, and includes versions of Runtime Manager, API Manager, and Anypoint Exchange. Anypoint Runtime Fabric A container service that automates the configuration, coordination, and management (orchestration), and deployment of your Mule applications and gateways. Runtime Fabric runs on customer-managed infrastructure on AWS, Azure, virtual machines (VMs) or bare-metal servers. Anypoint Runtime Manager (Runtime Manager) A console where you deploy and manage applications built with any Mule. Deploy to servers in the cloud (currently handled by CloudHub) or on premises. Access the console in Anypoint Platform or download it as a standalone program that runs in a local server. Previously referred to as ARM. Anypoint Security Layers of features that secure your application network. These layers work together to protect both the application network and the network’s individual nodes by controlling access to APIs, enforcing policies, and proxying all inbound or outbound traffic to mitigate external threats and attacks. Anypoint Studio (Studio) An integrated development environment with visual and XML editors to design, debug and test Mule applications. Using the visual interface, you can drag and drop connectors, loggers, flow control, routers, data transformers, and much more to the design canvas. You can also debug and test from the Studio user interface. Anypoint Virtual Private Cloud (Anypoint VPC) Features that help you create a virtual, private, and isolated network segment in the cloud to host your CloudHub instances of Mule (CloudHub workers). Anypoint Visualizer Dynamically generated views of different aspects of an application network graph. API The entire API, including all its aspects. In Anypoint Platform, aspects of an API might also be called just API in context with the product that is managing them. For example, in Exchange, API might refer to the API specification, documentation, and catalog. In API Designer, API might refer to the API specification. In API Catalog, API might refer to the API instance, policies, and contracts. API aspects Parts of an API. Examples of API aspects include specifications, instances, catalog information, and documentation. API catalog information Properties related to an API’s entry in an API catalog, such as name, version, owner (contact), tags, and categories. In Anypoint Exchange, these properties are associated with APIs in asset portal information. API conformance API conformance indicates whether a validated API passes all of the required rules in one or more governance rulesets. If multiple profiles target an API, the API must pass all of the rulesets in all of those profiles to be conformant. API conformance applies only to API types supported by API Governance, such as REST API and AsyncAPI. API documentation Helps consumers understand and use the API, with content such as examples, use cases, and tutorials. API implementation A realization of the API specification to make the API functional. API instance An instantiation of the API implementation. An API can have multiple instances across different environments and gateways, which can be used by clients to make API calls. Instances that are configured but not deployed are also captured as part of this aspect. An instance can be either a proxy of an API that serves the upstream or an application endpoint. API specification Details the functional and expected behavior of an API, as well as the fundamental design philosophy and supported data types. It contains both documentation and API definitions to create a contract that people and software can read. API Governance Part of Anypoint Platform that enables you to apply governance rules to your APIs and monitor conformance to those rules. API Manager Part of Anypoint Platform that enables you to manage, govern, and secure your APIs. API Portal An access point where you can present an API to attract users. API proxy A feature of Anypoint API Manager that supplies a layer of protection against attacks on MuleSoft APIs. Manage APIs with the UI instead of having to write code. Formerly called API Gateway. APIkit APIkit is a tool for building Mule REST or SOAP APIs. Formerly called SOAPkit. application network A network that connects applications, data, and devices through APIs. The network allows consumers from other parts of the business to discover and use assets. ## C CloudHub Integration platform as a service that lets you manage applications in the cloud. When deploying an application to the cloud through the Runtime Manager console, CloudHub is used in the background. clustering Using a set of Mule instances that act as, and can be managed as, a unit. A cluster is a virtual server composed of multiple nodes. You can manage cluster instances from the cloud. component 1. In Anypoint Platform, a POJO, Spring bean, Java bean, or a script such as Groovy, Ruby, Python, or JavaScript that contains the business logic for processing messages passing through Mule. These components typically take the whole message - or just the payload - as input. They return an object that becomes the message payload for the next element in the message processor chain. 2. Generically, an architecturally specific portion of a software package. configuration builder A class that parses a configuration file. The default configuration builder is the `org.mule.config.MuleXmlConfigurationBuilder` class, which parses a Mule XML configuration file. connector A self-contained component that allows you to integrate Mule applications with the APIs of other, external applications, such as Salesforce, CMIS, and Twitter. A set of connectors is included in Mule 4. Other connectors created by MuleSoft or third parties are available on Anypoint Exchange. control plane Programmatic access to network administration. In Anypoint Platform, the control plane consists of Anypoint Design Center, Anypoint Management Center, and Anypoint Exchange. ## D dataloader.io The data loader for Salesforce. DataSense A feature of Anypoint Studio that uses message metadata to facilitate application design. With DataSense, Anypoint Studio proactively acquires information such as data type and structure, in order to prescribe how to accurately map or use this data in your application. DataWeave The DataWeave Language queries and transforms data for integrations. ## E Edge Anypoint Security feature to help you manage edge security. ## F flow Within a Mule application, a flow is a block of executable components, including any connector operations, that Mule runtime executes sequentially on a Mule event. A flow can also contain an event source, which triggers the creation of the event and the execution of the flow. ## G governed APIs APIs are governed if they’re identified by the selection criteria of at least one governance profile. If an API is governed, all versions of that API are considered one governed API. Subscription limits are set based on your organization’s purchased capacity. The UI gives information about usage and shows alerts when you near or exceed your subscription capacity. governance profiles A governance profile applies selected governance rulesets to a filtered group of APIs. API Governance then validates the APIs against the rulesets to determine governance conformance. ## H hybrid deployment Deploying a Mule Application via the cloud console of the Anypoint Runtime Manager to an on-premises server that hosts Mule runtime engine. This deployment is hybrid in the sense that the hosting of your application is on-premises, while application management is in the cloud. ## M message filter A message processor that controls whether a message is processed by a filter. message processor A basic building block used to construct flows. A message processor controls how messages are sent and received within a flow. message receiver A Java class used by a connector to read the incoming data, package it as a message, and pass it to a service component’s inbound router. The message receiver can use a transformer if necessary to convert the data. mocking service Provides a public URI to test or explore an API. module A group of components. Modules add flexibility to your apps by allowing you to aggregate values, compress data, use Java features, and process JSON. Mule® application A Mule application is an integration solution built using the Mule runtime engine, which processes and transforms data through a series of flows. These flows consist of message sources and processors that define how messages are received, processed, and routed to destinations. Mule applications can handle various types of data, including messages from different external sources such as HTTP endpoints, and support sophisticated processing mechanisms like transactions and batch jobs. Mule configuration file (configuration XML) An XML file in which you configure Mule applications, domains, and policies. Mule Enterprise Edition (EE) The enterprise version of Mule, available for 30-day trial download. The Enterprise Edition includes full development cycles, testing, technical support, maintenance releases and hot fixes, and management and monitoring tools from MuleSoft. Mule® runtime engine (Mule® or Mule) Java-based integration runtime engine for Anypoint Platform. ## O organization The container for everything in your Anypoint Platform account. ## P Pivotal Cloud Foundry A cloud computing platform as a service (PaaS) provided by the company Pivotal. Anypoint Platform integrates with Pivotal Cloud Foundry, allowing you to deploy Mule applications to dynamically created virtual machines on your own private network. See deployment strategies. Previously referred to as PCF. policy An object that controls authentication, access, consumption rates, and service level access (SLA) to API resources. Anypoint Platform provides both preconfigured and tools to create custom policies. ## R RAML® RESTful API Modeling Language (RAML) provides a specification language that you use to define an API. Runtime Manager agent The Runtime Manager agent mediates communication between the Anypoint Runtime Manager console and the Mule instances running on servers. Using the Mule agent, you can monitor and control Mule servers. Previously referred to as Runtime agent. runtime plane The contract between the control plane and data plane for runtime control. In Anypoint Platform, the runtime plane consists of Mule runtime engine and runtime services managed with tools like Anypoint Runtime Fabric. ## S secrets manager A feature that stores and controls access to private keys, passwords, certificates, and other secrets. ## T tokenization Substituting a non-sensitive equivalent for a sensitive data element. transformer A feature that transforms message payloads (data) to and from different types, such as the XSLT Transformer. Transformations can also be defined using DataWeave. transport A feature that carries messages on a specific messaging protocol, such as FTP. Several connectors incorporate transports. ## U universal message object (UMO) Obsolete name for service component. UMO is still visible in some MuleSoft APIs. ## X XA transaction A transaction that enlists multiple managed resources and provides guaranteed reliability. Mule runtime engine also supports multi-resource transactions that are not XA transactions. These transactions do not have guaranteed reliability. --- product: Getting Started keywords: anypoint platform pricing, metrics definitions, global resource pool limits, cloudhub 2.0, application deployment, access management entitlements, mulesoft pricing --- # Anypoint Platform Pricing > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The Usage Reports page supports pricing packages for [integration](https://www.mulesoft.com/anypoint-pricing). When your organization opts in to a usage-based pricing plan, such as the Anypoint Integration Advanced package, you must redeploy your apps. After redeploying your apps, your usage reports are shown. For CloudHub and CloudHub 2.0, apps are automatically redeployed during the monthly runtime patch update cycle. For more information, see [CloudHub Runtime Continuous Updates](https://docs.mulesoft.com/cloudhub/cloudhub-app-runtime-version-updates) and [CloudHub 2.0 Operating System Patch Updates](https://docs.mulesoft.com/cloudhub-2/ch2-patch-updates). For Runtime Fabric, you must manually redeploy apps to remain in compliance with your Anypoint Platform contract. ## Metrics Definitions Usage-based pricing packages and their usage reports are based on your organization’s use of allotted Mule components. To understand the technical aspects of metering and pricing concepts within Anypoint Platform, see [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) documentation. ## Global Resource Pool Limits Root organizations provisioned with usage-based pricing receive a shared global pool of CPU and memory resources for CloudHub and CloudHub 2.0 deployments across all business groups and environments in the organization. This pool of resources is large enough to consume all the purchased flows and messages without interruption. If an organization runs out of resources, actions that consume more resources, such as deploying new applications or starting stopped applications are blocked until sufficient resources are available. You can free up resources by stopping or deleting unused applications, or reducing the replica size or resources that an existing application consumes. When your organization approaches the resource limit on the Applications List UI, Application Deployment UI, and Manage Application UI, you receive a warning. To avoid reaching limits, allocate only the needed resources by using granular replica sizes in CloudHub and CloudHub 2.0. Contact Support if you require an exception when you reach the resource limit. > [!NOTE] This limit doesn’t impact applications configured with > [Configuring Horizontal Autoscaling (HPA) for CloudHub 2.0 Deployments](https://docs.mulesoft.com/cloudhub-2/ch2-configure-horizontal-autoscaling). > You can continue to deploy applications if Horizontal Pod Autoscaling is enabled even if you reach > the global resource limits. ## CloudHub 2.0 Application Deployment For organizations provisioned with a usage-based pricing package, CloudHub 2.0 uses replica sizing for application deployment. You can choose replica sizes based on the application profile or size and display the equivalent in terms of legacy vCores. Replica sizes with the suffix `.mem` are memory-intensive options with the same compute.
OfferingEquivalent vCore SizeTotal MemoryHeap MemoryStorage

mule.nano

0.05

1 GB

0.5 GB

8 GB

mule.micro

0.1

1 GB

0.5 GB

8 GB

mule.micro.mem

0.1

2 GB

1 GB

8 GB

mule.small

0.2

2 GB

1 GB

8 GB

mule.medium

0.5

3 GB

1.5 GB

10 GB

mule.medium.mem

0.5

5 GB

2.5 GB

10 GB

mule.large

1

4 GB

2 GB

12 GB

mule.large.mem

1

8 GB

4 GB

12 GB

mule.xlarge

2

7 GB

3.5 GB

20 GB

mule.xlarge.mem

2

12 GB

6 GB

20 GB

mule.2xlarge

4

15 GB

7.5 GB

20 GB

During the monthly patching cycle, your applications automatically migrate to an equivalent replica size. ## Access Management Entitlements Accounts provisioned with a usage-based pricing package show flows, messages, and throughput entitlements in Access Management instead of vCores. These entitlements are available only at the root organization level. Because vCores are no longer the purchased entity, they can no longer be tracked or allocated among business groups. To view your monthly usage of flows, messages, and throughput, [access usage reports](https://docs.mulesoft.com/general/usage-reports#access-usage-reports) in the Access Management UI. ## See Also - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) --- product: Getting Started keywords: anypoint platform security, api security, mulesoft security, integration security, data protection, security best practices --- # Anypoint Platform Security > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Anypoint Platform to build security into your application network: - Manage access for users, groups, environments, client providers, identity providers, connected apps, and external access with [the Access Management user interface](https://docs.mulesoft.com/access-management/). You can also manage access programmatically with [Access Management APIs](https://dev-portal.mulesoft.com/apis/access-management.html). - Apply policies to your APIs with [the API Manager user interface](https://docs.mulesoft.com/api-manager/latest/latest-overview-concept). - Monitor Anypoint Platform for denial-of-service attacks and other security issues with [the Anypoint Monitoring user interface](https://docs.mulesoft.com/monitoring/). --- product: Getting Started keywords: policy library, open policies, canonical policies, governance policies, apply policy, policy catalog --- # Apply Open Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 open policy model, the apply and management workflow, activity tracking, and per-provider support, see [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) and [Open Policies](https://docs.mulesoft.com/general/exp-policies-open). ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Any of these permissions: - API Governance: Governance Administrator - API Manager: Manage Policies - The Organization Administrator role, required to load the open policy catalog, open a policy configuration form, and apply an open policy. Without this role, the catalog is empty or those actions fail. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - API instances registered in the portfolio on a supported gateway. > [!NOTE] 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 > [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ## Browse Open Policies 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. Each policy appears with its name, category, and a short description of what it enforces. You can filter policies by category: - **Access and Security** - **Compliance and Observability** - **Data Privacy and Integrity** - **Performance and Cost** 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 an Open Policy The apply steps vary depending on where you start. ### From the Governance Strategies Page 1. On the Governance Strategies page, select **Add Strategy**, then **Apply Policy**. 2. On the **Select Policy** step, select the policy you want to apply. 3. On the **Configure Policy** step, set the policy parameters. Required and optional fields vary by policy type. 4. On the **Scope** step, choose whether to apply the policy globally or to specific API instances. 5. On the **Name & Description** step, name the policy. This step appears only when you apply the policy globally. 6. On the **Review** step, review the summary, then apply the policy. ### From an API Instance 1. On the API instance, select the **Apply Policy** action to open the Policy Library. 2. On the **Select Policy** step, select the policy you want to apply. 3. On the **Configure Policy** step, set the policy parameters. Required and optional fields vary by policy type. 4. On the **Select Instances** step, select the API instances where you want to apply the policy. 5. On the **Review & Apply** step, review the summary, then apply the policy. When you apply a policy, the platform validates it against your governance configuration and then creates the corresponding native policy on each selected instance’s gateway. 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 [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). For how open policies map to each provider’s native policy, and which policies you can then edit, enable, disable, or remove afterward, see [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) and [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ## See Also - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: apply policy, edit policy, remove policy, enable policy, disable policy, external gateways, api manager, anypoint platform --- # Applying and Managing Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Apply, edit, enable, disable, and remove policies on an API instance from the **Policies** tab in **Portfolio**. These actions work on Anypoint gateways (Omni and Mule), and on external providers such as Google Apigee, Azure API Management, and Kong Gateway, subject to per-provider support. See [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference). > [!NOTE] Automate policy application and management using the MuleSoft MCP Platform Server. For > details, see > [apply\_policy\_to\_instance](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#apply-policy-to-instance) > and related Policy Management tools in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - The API Manager: Manage Policies permission. - The Organization Administrator role, required to load the open policy catalog, open a policy configuration form, and apply an open policy, or to apply, edit, enable, disable, or remove native policies on external gateways. Without this role, those actions fail or the catalog is empty. Listing native policy templates on an external gateway still uses the View Policies permission. Viewing policies already applied on Omni or Mule gateways still uses the View Policies or Manage Policies permission. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - For external providers, a connected scanner for that provider. Anypoint reuses the same connection and credentials you configured for scanning to authorize and perform policy changes. There’s no second set of provider credentials to configure. The per-provider setup you must do on your side (for example, Apigee roles and permissions) is described in [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference). > [!NOTE] Button state is a hint, not the final authorization. The **Policies** tab enables or > disables actions based on what it believes you can do, but the real permission check happens when > the background job talks to the provider. If you lack permission there, the operation fails and > the failure appears in the **Activity log**. When Anypoint can’t reliably determine your > permissions, it keeps the actions available rather than blocking them; if you aren’t authorized, > the gateway rejects the request when the background job runs. For providers Anypoint can’t check > at all, actions can appear disabled. ## Apply a Policy 1. In **Portfolio**, open the API and select the instance. 2. Open the **Policies** tab and select **Apply Policy**. 3. Choose the policy and configure it. 4. If the provider requires a policy name, enter one. 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 [Policy Naming and Identity](#policy-naming-and-identity). 5. Apply the policy. Anypoint accepts the request and performs it in the background. Confirm the outcome in the **Activity log** tab. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). To apply an open policy across multiple providers at once, use the **Policy Library** instead. See [Open Policies](https://docs.mulesoft.com/general/exp-policies-open). ## 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 open use cases, plus several additional native Kong policies (see [Open Policies](https://docs.mulesoft.com/general/exp-policies-open)); 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. - The policy is scoped above the instance rather than to it. - The policy has conditional rules. - The policy has no provider reference. - The provider doesn’t support the action. - Another operation is already in progress on the policy. ## Enable, Disable, and Remove You can enable, disable, and remove policies more broadly than you can edit them, because these actions don’t require a recognized configuration shape. It’s normal to see a policy where **Edit Configuration** is unavailable while **Enable Policy**, **Disable Policy**, and **Remove Policy** remain available, as long as the provider supports that action. - **Enable Policy** / **Disable Policy** toggle a policy on or off. Apigee and Azure API Management have no native enable/disable state, so these actions aren’t available there. See [Supported Actions by Provider](https://docs.mulesoft.com/general/exp-policies-provider-reference#supported-actions-by-provider). - **Remove Policy** detaches the policy from the instance. While an operation is in progress, the provider locks further changes until it finishes. The scope of that lock differs by provider: Apigee and Azure API Management lock the entire instance, so no other policy operation on that instance can start until the current one completes; Kong Gateway locks only the policy being changed, so you can work with other policies on the same instance at the same time. You can track progress in the **Activity log**. See [Instance Locking During Operations](https://docs.mulesoft.com/general/exp-policies-provider-reference#instance-locking-during-operations). ## Policy Naming and Identity Policy naming applies to Apigee only. Other providers don’t use policy names, and you aren’t required to enter one. On Apigee, the name is the policy’s unique identity on the gateway, not just a label: - The name is required at creation. - The name can’t be changed afterward. On a later edit, the name field is fixed: editing changes the policy’s configuration, never its name. - To change a name, remove the policy and create a new one. An Apigee edit that tries to change the name is rejected, because the name is the on-gateway identifier. ## See Also - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started --- # Applying Model Proxy Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Model Proxy enforces three policies by default to secure and route LLM traffic without additional configuration. Apply additional supported policies through API Manager to add content safety, PII detection, and token rate limiting controls. Outbound policies and the Rate Limiting SLA policy are not supported. By default, Model Proxy applies these policies: - Client ID Enforcement - Model Proxy Core Policy - Model Based Routing Policy or Semantic Routing Policy (policy name dependent on embedded service provider) You don’t need to modify these policies. > [!NOTE] Automate model proxy policy management using the MuleSoft MCP Platform Server. For > details, see > [apply\_policy\_to\_instance](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#apply-policy-to-instance) > and related Policy Management tools in the MuleSoft MCP Platform Server Tool Reference. Model Proxy supports most [included policies](https://docs.mulesoft.com/gateway/latest/policies-included-directory), but doesn’t support outbound policies. > [!NOTE] Model Proxy doesn’t support > [Rate Limiting: SLA-Based Policy](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla). These policies are specific and useful for Model Proxies: - [Amazon Bedrock Guardrails Policy](https://docs.mulesoft.com/gateway/latest/policies-included-bedrock-guardrails) - [Azure Content Safety Policy](https://docs.mulesoft.com/gateway/latest/policies-included-azure-content-safety) - [LLM PII Detection Policy](https://docs.mulesoft.com/gateway/latest/policies-included-llm-pii-detection) - [Model Proxy Request Compression Policy](https://docs.mulesoft.com/gateway/latest/policies-included-llm-proxy-request-compression) - [LLM Token Based Rate Limit Policy](https://docs.mulesoft.com/gateway/latest/policies-included-llm-token-rate-limit) - [Regex Prompt Guard Policy](https://docs.mulesoft.com/gateway/latest/policies-included-regex-prompt-guard) ## Apply Policies to Model Proxies 1. From API Manager, click **Model Proxies**. 2. Click the name of the Model Proxy you want to apply a policy to. 3. Click **AI Policies**. 4. Click **Add inbound policy**. 5. Select the policy to apply. 6. Configure the required parameters. For policy configuration parameters, see [Inbound Policies Directory](https://docs.mulesoft.com/gateway/latest/policies-included-directory). 7. If necessary, configure **Advanced options**. 8. Click **Apply**. ## Model Proxy Authentication Policy By default, the Model Proxy has the Client ID Enforcement policy applied. This is required because the Client ID Enforcement populates the `Authentication.clientName` variable in the `Authentication` object that is used as a unique identifier for LLM Metrics. To remove the Client ID Enforcement policy, ensure that you either: - Apply a policy that populates `Authentication.clientName`: - [Client ID Enforcement Policy](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement) - [Rate Limiting: SLA-Based Policy](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [OAuth 2.0 Token Introspection Policy](https://docs.mulesoft.com/gateway/latest/policies-included-oauth-token-introspection) (If Client ID enforcement is configured, `skipClientIdValidation=false`) - [OpenID Connect OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/gateway/latest/policies-included-openid-token-enforcement) (If Client ID enforcement is configured, `skipClientIdValidation=false`) - [JWT Validation Policy](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation) (If Client ID enforcement is configured, `skipClientIdValidation=false`) - A custom policy that populates `Authentication.clientName` - Edit the DataWeave variable in Model Proxy Core to extract a different unique identifier, such as `clientid`, `userid`, or `departmentid`. > [!NOTE] You can’t filter by this unique identifier in Usage Reports. ## See Also - [Securing Omni Gateway Instances with Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Inbound Policies Directory](https://docs.mulesoft.com/gateway/latest/policies-included-directory) --- product: Getting Started keywords: automation credits, mulesoft automation, credit usage, billing, account summary, usage rates, monthly email reports --- # Automation Credits Usage and Rates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Your MuleSoft Automation subscription plan includes a quota of Automation Credits that depletes as you create and execute automations. ## Subscription Plan Credit usage rates differ for different subscription plans. See the article that corresponds to your subscription plan in this table:
Subscription PlanConversion Rate Sheet

Automation Starter
Automation Advanced
Automation for vCore/Core
MuleSoft Integration Starter
MuleSoft Integration Advanced
MuleSoft Integration Unlimited
MuleSoft for Flow Integration - Enterprise Edition
MuleSoft for Flow Integration - Performance Edition
MuleSoft for Flow Integration - Unlimited Edition

MuleSoft Automation Credits 3.0

Automation Starter
Automation Advanced
Automation for vCore/Core
Additional Automation Credits

MuleSoft Automation Credits 2.0

MuleSoft - Automation
MuleSoft - Automation - (Gold, Platinum, Titanium Edition)
MuleSoft - Automation for Salesforce
MuleSoft - Automation for Salesforce - (Gold, Platinum, Titanium Edition)
MuleSoft - Automation - Additional Credits (100)
MuleSoft - Automation - Additional Credits (100) - (Gold, Platinum, Titanium)

MuleSoft Automation Credits 1.0

## Usage Types
ProductMetric DescriptionUsage Details

Composer

Composer task: Any discrete action executed on a Composer connector, including but not limited to read, create, update, and delete.

Calculated on a per action basis and aggregated as the total number of tasks completed within a billing cycle.

RPA (Robotic Process Automation)

RPA bot minutes: The total duration (in minutes) spent running process automations across all active bot sessions.

Calculated by tracking active execution time. Parallel bot sessions, multi-bot processes, and test-phase runs each count toward total bot minutes.

RPA API Calls: Programmatic HTTP/REST requests used to trigger, monitor, or manage RPA bot workflows from external applications.

Calculated on a per-request basis by summing all individual API calls made to the RPA Manager or RPA Bot API.

Intelligent Document Processing (IDP)

IDP Document Pages: A single physical or digital document page processed by IDP document actions.

Calculated per page processed (each page of multi-page documents counts separately). IDP actions executed by RPA consume document pages and corresponding RPA Bot Minutes.

MuleSoft for Flow: Integration

Integration Tasks: A discrete execution of integration capabilities within Salesforce Flow.

Calculated in real time per individual task execution, enabling immediate monitoring and aggregation of total consumption.

## MuleSoft Automation Credits A quantity of Automation Credits is included with certain MuleSoft Services, with the specific entitlement indicated on the Usage Details table on the Order Form for such Services. Automation Credits are consumed as you create and execute automations based on the rates in the following table. While MuleSoft Automation Credits 1.0 uses a conversion-based model, MuleSoft Automation Credits 2.0 and 3.0 use multiplier rates. Credit usage rates differ by subscription plan. Refer to the column that corresponds to your credit system. > [!IMPORTANT] As of February 18, 2026, Flow Orchestration is included for customers in Enterprise > and higher editions. For customers on other editions, the > [General Flow Limits](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5) > apply.
Usage TypeMuleSoft Automation Credits 3.0MuleSoft Automation Credits 2.0MuleSoft Automation Credits 1.0

Flow Orchestration Runs

Included for Enterprise and higher editions. For other editions, the General Flow Limits apply.

100 automation credits per run. Included for Enterprise and higher editions. For other editions, the General Flow Limits apply.

Not Available

IDP Document Pages

30 credits per page.

30 credits per page.

5 pages per credit.

Integration Tasks

2 credits per task.

2 credits per successful task.

Not Available

MuleSoft for Flow: IDP

30 credits per page.

Not Available

Not Available

RPA Bot Minutes

Not Available

80 credits per RPA Bot minute.

2 RPA Bot minutes per credit.

RPA API Calls

Not Available

2 credits per successful call to the RPA Manager or RPA Bot API.

100 Bot API calls per credit.

Composer Tasks

Not Available

2 credits per task.

50 tasks per credit.

> [!NOTE] Quoting rules generally prevent you from holding both MuleSoft Automation credits 2.0 and > 3.0 simultaneously. However, if you have both MuleSoft Automation credits 2.0 and 3.0, the system > sends all usage data to the Digital Wallet to provide a single, centralized view of consumption. ## Viewing Usage and Billing The method for viewing usage and handling billing varies based on the type of Automation purchase.
Usage TypeUsage VisibilityFrequency

MuleSoft Automation Credits 3.0

Digital Wallet (and optionally IDP and RPA usage in Anypoint Usage Reports)

See your daily and monthly usage in Digital Wallet.

MuleSoft Automation Credits 2.0

IDP and RPA usage in Anypoint Usage Reports

See your Automation Credits in Monthly Account Summary Emails.

MuleSoft Automation Credits 1.0

IDP and RPA usage in Anypoint Usage Reports

See your Automation Credits in Monthly Account Summary Emails.

## Monthly Account Summary Emails Salesforce sends usage-based billing reports to every MuleSoft Composer, Intelligent Document Processing (IDP), and Robotic Process Automation (RPA) customer on the 10th day of each month. By default, Salesforce sends these emails to the account’s billing contact. For more information about the reports, the list of recipients, and other details, see the [Monthly Account Summary Email FAQ](https://help.salesforce.com/s/articleView?id=000390885&type=1). ## See Also - [MuleSoft Automation Credits 3.0](https://docs.mulesoft.com/general/mulesoft-automation-credits-3-0) - [MuleSoft Automation Credits 2.0](https://docs.mulesoft.com/general/mulesoft-automation-credits-2-0) - [MuleSoft Automation Credits 1.0](https://docs.mulesoft.com/general/mulesoft-automation-credits-1-0) - [Digital Wallet–Enabled Consumption-Based Products](https://help.salesforce.com/s/articleView?id=xcloud.wallet_enabled_products_rate_cards.htm&type=5) (Salesforce Help) --- product: Getting Started keywords: anypoint platform, browser support, supported browsers, browser compatibility, unsupported browsers, browser policy --- # Browser Support for Anypoint Platform > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Anypoint Platform with the latest version of any supported browser: - Microsoft Edge with Chromium - Microsoft Edge without Chromium (supported through December 31, 2020) - Google Chrome - Mozilla Firefox - Safari Browser support for Anypoint Platform follows the Salesforce Lightning Experience policy. ## Exceptions to Browser Support Policy Partner Manager 2.0 modifies the browser support policy: - [Partner Manager 2.0](https://docs.mulesoft.com/release-notes/partner-manager/anypoint-partner-manager-2.0-release-notes#browser-compatibility) ## Unsupported Browsers Internet Explorer versions 11 and earlier are not supported. If you use the browser with Anypoint Platform, you might experience issues. ## See Also [Supported Browsers for Lightning Experience](https://help.salesforce.com/s/articleView?language=en_US&id=getstart_browsers_sfx.htm&type=5) --- product: Getting Started keywords: model wallets, model wallet, budgets, token budget, spend limit, model proxies, jwt claims, cost management, anypoint platform --- # Capping Spend for Callers of Model Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A model wallet identifies a caller of a model proxy and caps that caller’s token or dollar spend against a provider over a set time window. Each wallet has a system-generated client ID and required JSON Web Token (JWT) claims that you define. When a caller sends a request, the proxy matches the client ID and claims to a wallet and counts the request against that wallet’s budgets. After the wallet reaches its budget, the proxy blocks further requests to that provider’s models. That block enforces a spend or token cap. A wallet doesn’t grant or deny access to the proxy. > [!NOTE] Automate model wallet management using the MuleSoft MCP Platform Server. For details, see > [fetch\_model\_wallets](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-model-wallets) > and related tools in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin To manage model wallets, you need: - An Anypoint Platform account. - At least one configured model proxy. See [Creating Model Proxies](https://docs.mulesoft.com/general/model-proxy-create-model-proxy). - A configured identity provider (IdP) that issues JWTs for callers. - Policies configured on each model proxy that callers reach through the wallet. See [Configure Policies on a Model Proxy](#configure-policies-on-a-model-proxy). - API Manager permissions: - API Manager: API Creator - API Manager: View APIs Configuration - API Manager: Edit APIs Configuration - API Manager: Manage Policies, to apply, disable, reorder, and edit policies For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). > [!NOTE] Organizations without an IdP configured can’t use model wallets. Those organizations > continue to use existing access methods. ## Configure Policies on a Model Proxy A model wallet matches the client ID and JWT claims in a request to the wallet’s configuration. Default model proxy policies include DataWeave Headers Transformation and Client ID Enforcement. For wallets, disable those policies and identify callers from the JWT. Apply these policy changes on each model proxy that callers reach through the wallet. Apply them from the model proxy, not from **Model Wallets**. 1. From **Portfolio** > **Model Proxies**, open the model proxy. 2. Select the **Policies** tab. 3. From the actions menu for **DataWeave Headers Transformation** inbound policy, select **Disable Policy**. 4. From the actions menu for the **Client ID Enforcement** inbound policy, select **Disable Policy**. 5. Select **Apply Policy**. 6. Select **JWT Validation**, and then select **Next**. 7. Configure the policy to validate tokens from your IdP, including the JWT origin and the JSON Web Key Set (JWKS) URL or signing key. For configuration parameters, see [JWT Validation policy](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation). 8. Select **Apply Policy**. 9. Select **Reorder Instance Policies**. 10. Move **JWT Validation** to the second position. The [Cross-Origin Resource Sharing](https://docs.mulesoft.com/gateway/latest/policies-included-cors) policy remains first. JWT Validation in the second position validates the token before later policies read the claims. 11. Select **Save Order**. 12. From the actions menu for **LLM Proxy Core Policy**, select **Edit Configuration**. 13. In **Client ID**, enter: #\[authentication.properties.claims.client\_id\] This expression reads the `client_id` claim after JWT Validation publishes the verified claims. 14. Select **Save Changes**. Repeat these policy steps for each model proxy that callers reach through the wallet. ## Create a Model Wallet Create a model wallet to define the client ID, JWT claims, and budgets for a model. To create a model wallet, you need: - A model proxy. - A configured identity provider (IdP) that issues JWTs for callers. - Policies configured on each model proxy that callers reach through the wallet. See [Configure Policies on a Model Proxy](#configure-policies-on-a-model-proxy). - Costs configured for the models that callers use through the wallet. For more information, see [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs). 1. From **Portfolio** > **Model Proxies** > **Model Wallets**, select **New Model Wallet**. 2. In **Name**, enter a name for the wallet, for example, `Finance Analytics Bot`. 3. (Optional) Enter a **Description** of the wallet’s purpose. 4. Under **Authentication**, copy the system-generated **Client ID**. The Client ID is read-only. The service selects a wallet by matching the caller’s JWT claims against each wallet’s required claims. The matching wallet with the highest priority wins. Client ID is only a tie-breaker. When several wallets share the best matching priority, send the optional x-client-id request header to select the tied wallet whose Client ID equals that value. If the header is absent or matches none of the tied wallets, the service uses the tied wallet whose Client ID sorts first alphabetically. 5. In **Required Claims**, enter at least one required claim: - In **Claim key**, enter one or more claim keys, for example, `group`. - In **Claim values**, enter one or more comma-separated values. - To add more claims, select **Add Claim** again. The required claims match claims in the JWT after the JWT Validation policy on the model proxy validates the token. 6. Click **\+ Add Budget** to add one or more budgets for this model wallet to cap spend or token usage. See [Add a Budget to a Wallet](#add-a-budget-to-a-wallet). 7. Select **Create Model Wallet**. ## View Model Wallets From **Portfolio** > **Model Proxies**, select **Model Wallets**. The wallet list shows: - **Name**: The wallet’s display name. - **Description**: The wallet’s purpose. - **Budgets**: The number of budgets on the wallet. - **Last Updated**: When the wallet was last changed. To find a specific wallet, use the search box to filter by name or description. ## Edit a Model Wallet 1. From **Portfolio** > **Model Proxies** > **Model Wallets**, open the wallet and select **Edit**. 2. Change the **Name**, **Description**, or **Required Claims**. The **Client ID** is read-only. 3. Select **Save**. Manage budgets separately from the wallet name, description, and claims. See [Add a Budget to a Wallet](#add-a-budget-to-a-wallet). ## Add a Budget to a Wallet A budget caps usage for a wallet against a provider over a recurring period. Add a budget when you create or edit a model wallet, or add a budget from the budgets view in **Governance** > **Cost Management**. Add multiple budget limits to a wallet. Assign each model to only one budget limit. 1. Open the model wallet from **Portfolio** > **Model Proxies** > **Model Wallets**, or open the budgets view in **Governance** > **Cost Management**. 2. In the **Budgets** section, select **Add Budget**. 3. Enter the budget details: - **Provider**: The provider the budget tracks. - **Period**: **Daily**, **Weekly**, or **Monthly**. - **Resets on Day of Month**: The day of each period when the usage counter returns to zero. - **Metric**: Whether the limit is measured in dollars (**Spend**) or **Tokens**. - **Spend Limit (USD)**: The limit amount for the selected metric. 4. Select **Add Budget**. Spend-based budgets depend on model costs. To track dollar spend accurately, set a cost for each model on the **Models** page. Models without configured costs show zero spend. See [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs). When a wallet reaches its budget, the model proxy blocks requests to that provider’s models. If a fallback route exists, then the model proxy routes the request to the next model in the proxy’s route. Budgets are approximate rather than a real-time hard cutoff. The model proxy tracks total token consumption across routes as a governance and cost-awareness tool. Usage can briefly exceed a limit before the model proxy blocks requests. ## See Also - [Creating Model Proxies](https://docs.mulesoft.com/general/model-proxy-create-model-proxy) - [Applying Model Proxy Policies](https://docs.mulesoft.com/general/model-proxy-policies) - [JWT Validation Policy](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation) - [Client ID Enforcement Policy](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement) - [DataWeave Headers Transformation Policy](https://docs.mulesoft.com/gateway/latest/policies-included-dataweave-headers-transformation) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) --- product: Getting Started keywords: alerts, notifications, configure alerts, alert target, manage alerts, anypoint platform, monitoring --- # Configuring Notifications for Alerts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Send API Manager alerts from Anypoint Platform directly to Slack channels, Microsoft Teams channels, and email. Configure alerts in the enhanced experience so teams can see notifications where they work and jump directly into **Portfolio** or **Observability** to respond. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account - Access to the enhanced experience at omni.mulesoft.com - Any of these permissions to view alerts: - API Manager: View API Alerts - Any of these permissions to manage alerts: - API Manager: Manage API Alerts For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - The MuleSoft Slack app installed in your workspace (see [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) for installation steps), or the MuleSoft for Teams app installed in your Microsoft Teams tenant (see [Integrate the Enhanced Experience with Microsoft Teams](https://docs.mulesoft.com/general/exp-teams-integrate) for installation steps) ## View and Manage Alerts The enhanced experience provides a unified view of all your alerts: 1. Navigate to the **Notifications** tab in the enhanced experience. 2. View all alerts for APIs, MCPs, Agents, and LLMs in one place. 3. Filter alerts by: - Alert type (request count, response time, response codes, and policy violation) - Severity level (critical, warning, informational) - Delivery channel (Slack, Microsoft Teams, email) ## Create an Alert To create an alert: 1. Navigate to the **Notifications** page in the enhanced experience at omni.mulesoft.com. 2. Click **Create Alert**. ### Select Alert Target 1. Select your **Environment** from the dropdown. 2. Choose a **Service Type**: - **API** - **LLM** - **MCP** - **Agent** 3. In the **Target Service** field, search for and select the specific service to monitor. 4. If available for your service type, select an **API instance** from the dropdown. ### Specify Alert Configuration 1. Select an **Alert Metric** from the dropdown (Request Count, Response Time, Response Code, or Policy Violation). 2. Configure the alert condition: - Choose a comparison operator (such as `>` for greater than). - Enter the threshold value. - Select the time window ( 5 min, 10 min, 15 min, 20 min). The alert triggers when the metric satisfies the comparison for the selected duration. ### Set Alert Delivery 1. Select a **Severity** level: - **Critical** - **Warning** - **Info** 2. Enter an **Alert Name** (minimum 4 characters). This name appears in the notification list and email subjects. 3. Configure **Delivery Channels**: - Toggle **Email** on or off to send alerts to email addresses. - Toggle **Slack** on or off to send alerts to Slack if enabled. - Toggle **Microsoft Teams** on or off to send alerts to Teams if enabled. 4. If **Slack** is enabled, select your delivery destination: - Choose a Slack channel from your workspace. - Or select a direct message recipient. 5. If **Microsoft Teams** is enabled, select your delivery destination: - Choose a Teams channel from your tenant. - Or select a direct message recipient. 6. Click **Create Alert** to save. ## Edit an Existing Alert To modify an existing alert: 1. Navigate to the **Notifications** page in the enhanced experience. 2. Locate the alert you want to modify. 3. Click to edit the alert. 4. Update any section as needed: - **Select Alert Target**: Change the environment, service type, target service, or API instance. - **Specify Alert Configuration**: Modify the metric, condition, threshold, or time window. - **Set Alert Delivery**: Change severity, alert name, or delivery channels (Email, Slack, Microsoft Teams). 5. Save your changes. ## How Alerts Appear in Slack and Microsoft Teams When an alert triggers, your team receives a notification directly in the configured Slack or Microsoft Teams channel or DM: - Alerts display key information about the condition that triggered them - Teams can see and respond to alerts where they already collaborate - Alerts include context to help with triage and decision-making - No need to check email inboxes or switch to the platform console ## Alert Severity and Routing Map alerts to appropriate channels based on severity to reduce noise: - **Critical alerts**: Route to high-priority channels monitored by on-call teams - **Warning alerts**: Send to team channels for awareness and investigation - **Informational alerts**: Deliver to lower-traffic channels or aggregated reporting channels This routing strategy ensures teams see the most important signals first without alert fatigue. ## See Also - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [View Detailed Metrics for Your Services](https://docs.mulesoft.com/general/exp-services-view-detailed-metrics) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Integrate the Enhanced Experience with Microsoft Teams](https://docs.mulesoft.com/general/exp-teams-integrate) - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) --- product: Getting Started --- # Configuring Semantic Caching Services > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Semantic caching services store and retrieve LLM responses based on semantic similarity. When an incoming request is semantically similar to a previous request, Model Proxy returns the cached response instead of calling the LLM provider again, which reduces latency and cost. Configure a semantic caching service before creating a model proxy that uses semantic caching. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Configure a Semantic Caching Service 1. In the navigation pane, select **Model Proxies** > **Semantic Services**. 2. Click **Add Semantic Service** > **Semantic Caching Service**. 3. Configure the **Embedding Service Connection** parameters for the embedding service that generates vector representations of queries: - **Embedding Service Provider**: The provider of the embedding model. Semantic caching supports **OpenAI** only. - **Model**: The embedding model to use. - **URL**: The URL of the embedding service. - **Authentication key**: The API authentication key for the embedding service. 4. Click **Next**. 5. Configure the **Vector Database Connection** parameters for the vector database that stores cached embeddings: - **Vector database provider**: The provider of the vector database. Select **Azure AI Search**. - **Host**: The host URL of your vector database. - **API Key**: The API authentication key for the vector database. - **Index name**: The index name in your vector database (for example, `semantic-cache`). 6. Click **Next**. 7. Configure the **Object Store Connection** parameters for the object store that persists cached responses: - **Client ID**: The client ID for the object store. - **Client Secret**: The client secret for the object store. - **Object store URL**: The URL of the object store. - **Object store name**: The name of the object store (for example, `semantic-cache-store`). 8. Click **Next**. 9. Configure the **Advanced Caching Configurations** to set the caching environment, behavior, and similarity settings: - **Environment**: The environment to use for the semantic caching service. - **Service label**: Label to identify the new service. Shown as the label in the Semantic Services catalog. - **TTL** and **Unit of time**: The length of time a cached response remains valid before it expires (for example, `7` `Days`). - **Similarity Threshold**: A value from 0 to 1 that sets how similar an incoming request must be to a cached request for a cache hit. Higher values require more similarity. - **LLM-determined response caching**: Enable this option to let the LLM decide whether a response is cacheable. When enabled, define an **LLM cache decision prompt** that specifies the acceptance criteria for caching incoming responses. This prompt is added to the user request. - Optionally, expand **Advanced Settings** to select which fields to include when comparing queries for similarity under **Similarity Criteria**: - **Include LLM provider** - **Include user or agent ID** - **Include client ID** - **Include Model Proxy ID** 10. Click **Next**. 11. On the **Review Configuration** page, review your configurations. To change a section, click **Edit**. 12. Click **Save Config & Download Script**. Saving automatically downloads your vector database cache warmup scripts. Run them to preload the cache with your data and documents. ## Edit a Semantic Caching Service To edit a semantic caching service: 1. From **Semantic Service Setup**, click the three-dots menu (![3%](/mulesoft/current/en-us/gateway/latest/_images/three-dots-menu.png)) of the semantic caching service you want to edit. 2. Make the necessary edits. 3. Click **Save Config & Download Script**. If you edit the vector database connection, you must download and run the cache warmup scripts again. --- product: Getting Started --- # Configuring Semantic Routing Services > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Semantic routing services compare incoming requests to defined prompt topics to route traffic to the best-matching model path or block requests that match denylist topics. Model Proxy supports Basic Scale semantic routing services for simple routing and Advanced Scale semantic routing services for complex routing backed by an external vector database. Configure a semantic routing service before creating a model proxy that uses semantic routing. Model Proxy supports two types of semantic routing services: - [Advanced Scale](#configure-an-advanced-scale-semantic-service): For complex semantic routing. Advanced scale semantic routing services use a vector database to store and compare prompt topic utterances. Advanced scale semantic routing services support unlimited prompt topics and 2000 utterances per prompt topic. - [Basic Scale](#configure-a-basic-scale-semantic-service): For simple semantic routing and blocking. Basic scale semantic routing services support up to 6 prompt topics and 10 utterances per prompt topic. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Configure an Advanced Scale Semantic Routing Service 1. In the navigation pane, select **Model Proxies** > **Semantic Services**. 2. Click **Add Semantic Service** > **Semantic Routing Service**. 3. Select **Advanced Scale**. Advanced scale supports large utterance sets per topic and requires a dedicated external vector database connection. 4. Configure the embedding connection parameters: - **Environment**: The environment to use for the semantic service. - **Embedding service provider**: The provider of the embedding model. Select from these options: - **OpenAI** - **Hugging Face** - **Azure OpenAI**. - **Service label**: Label to identify the new service. Shown as the label in the Semantic Services catalog. - **URL**: The URL of the embedding service. - **Model**: The embedding model to use. - **Auth key**: The API authentication key for the embedding service. 5. Configure the vector connection parameters: - **Environment**: The environment to use for the vector database. - **Vector Database provider**: The provider of the vector database. Select from these options: - **Qdrant** - **Pinecone** - **Azure AI Search** - **Host**: The host URL of your vector database. - **API Key**: The API authentication key for the vector database. - **Collection**: The collection name in your vector database. 6. Define prompt topics: Supports up to 2000 utterances per topic. 1. Click **Create Prompt Topic**. 2. Define a **Prompt topic name**. 3. Define prompt utterances or click **Upload utterances** to upload a plain text file containing your prompt utterances. 4. Create as many prompt topics as necessary. You can also create new prompt topics later by editing the semantic service. > [!NOTE] To deny users from asking about certain subjects, create prompt topics for the > subjects and apply them as deny list topics when configuring your Model Proxy. 7. Click **Save & Download Script**. 8. Open the downloaded `.sh` script file in your database to populate it with your scaled vectors. ## Configure a Basic Scale Semantic Routing Service 1. In the navigation pane, click the **Model Proxies** dropdown arrow. 2. Select **Semantic Services**. 3. Click **Add Semantic Service** > **Semantic Routing Service**. 4. Select **Basic Scale**. Basic scale supports up to six topics and 10 utterances per topic. Managed via internal Model Proxy configuration. 5. Configure the embedding connection parameters: - **Environment**: The environment to use for the semantic service. - **Embedding service provider**: The provider of the embedding model: **OpenAI**, **Hugging Face**, or **Azure OpenAI**. - **Service label**: Label to identify the new service. Shown as the label in the Semantic Services catalog. - **URL**: The URL of the embedding service. - **Model**: The embedding model to use. - **Auth key**: The API authentication key for the embedding service. 6. Click **Save**. ## Edit a Semantic Routing Service To edit a semantic routing service: 1. From **Semantic Service Setup**, click the three-dots menu (![3%](/mulesoft/current/en-us/gateway/latest/_images/three-dots-menu.png)) of the semantic routing service you want to edit. 2. Make the necessary edits. 3. Click either **Save** or **Save & Download Script** depending on your semantic routing service. If creating new prompt topics for an advanced scale semantic service, you must download and run the vector script in your database again. --- product: Getting Started keywords: claude desktop, mulesoft mcp server, enhanced experience, administrator configuration, mcp integration, ai integration, mulesoft claude --- # Connect the Enhanced Experience to Claude Desktop > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Some organizations connect Claude Desktop (or similar assistants) to the enhanced MuleSoft experience so developers can jump from conversational workflows into governed catalogs and policies without leaving their preferred environment. Your IT team controls whether this integration is available, which OAuth scopes apply, and which actions the assistant can initiate on your behalf. ## Before You Begin - A supported Claude Desktop release and any enterprise controls your company applies to assistant software. - Network access from your workstation to both the assistant vendor endpoints and MuleSoft endpoints your security team approved. - An Anypoint Platform account. - Mule Developer Generative AI User permission to send prompts to agents. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Administrator Configuration - Identity and consent Map your Anypoint Platform identity to the assistant context and document which business groups can use the integration. - Allowed actions Decide whether the workflow is read-only (for example opening catalog links) or triggers guarded operations, then enforce that with roles and internal process. ## Use the Integration Follow the internal instructions your platform team published, for example a starter prompt, a packaged connector, or a bookmark that opens the enhanced experience with the required query parameters. In the browser, complete any additional sign-in or verification your organization requires. If the connection stops working after a client or policy update, check certificates, proxy settings, and token expiry with your administrator before opening a support case. ## Work with the Enhanced Experience via MuleSoft MCP Server Maintain velocity from your own work environment by executing end-to-end lifecycle tasks in the enhanced experience using MuleSoft Platform MCP Server. Manage assets, run scanners, configure gateways, handle governance, and more entirely in natural language from Claude Desktop, VS Code, ChatGPT, Windsurf, and Cursor. To get started, see [Getting Started with MuleSoft Platform MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started-platform). ## See Also - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) --- product: Getting Started keywords: external systems, slack integration, claude desktop, mcp, mulesoft enhanced experience, integrations --- # Connect the Enhanced Experience with External Systems > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Connect the enhanced experience to external tools so teams can act on governed services without leaving their preferred environment. You can integrate with collaboration tools like Slack or AI assistants like Claude Desktop. The enhanced experience integrates with these external tools: - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) Install the MuleSoft for Slack app to receive notifications, run shortcuts, and deep-link into the enhanced experience from your Slack workspace. - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) Connect Claude Desktop to the enhanced experience so developers can move between conversational AI workflows and governed catalogs. ## See Also - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) --- product: Getting Started keywords: contribute, mulesoft documentation, feedback, documentation updates, open source docs, edit documentation, pull request --- # Contribute to MuleSoft Documentation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Many of our documentation repositories are open and we welcome your contributions! To contribute to the English version of this documentation: 1. If this is your first time contributing to MuleSoft documentation, sign the [Salesforce.com Contributor License Agreement (CLA)](https://cla.salesforce.com/sign-cla). You need to sign the CLA only once per GitHub account. 2. Navigate to the page that you want to modify and click **View in Github**. 3. Make your edits. 4. Submit a pull request to the GitHub repository. The Documentation team then either accepts your pull request or contacts you for clarification. If your pull request results in an error, verify that you signed the CLA in Step 1. --- product: Getting Started keywords: agent fabric, llm cost, cost management, model proxy, model wallets, semantic routing, semantic caching, token spend, runaway agent, omni gateway --- # Controlling LLM Costs in Agent Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Agentic systems make large language model (LLM) calls constantly, and every call costs tokens. As you add agents, teams, and providers, token spend grows faster than you can track, and a single agent can run up a large bill before you notice. To manage that cost, you need to see what’s driving it, cut the spend you don’t need, and cap the spend you can’t afford. ## Why LLM Costs Grow Without Agent Fabric Controls Without visibility and enforcement, LLM costs grow as an agentic system scales. Agent Fabric cost management addresses these cost factors: - Unpredictable token use: Token usage varies widely based on agent behavior and queries. - No caller visibility: Costs can’t be attributed to the providers, models, and callers that generated them. - Expensive models on simple queries: Teams use expensive models for simple queries when a cheaper model can do the work. - Budgets that don’t enforce: Without enforcement of a budget, a number in the plan isn’t a real limit. - Runaway agents: A compromised or malfunctioning agent can drive unexpected cost. - Optimization without data: Without data on usage patterns, optimization is guesswork. You need visibility into what drives cost, and you need controls that reduce spend and cap it. ## See, Reduce, Cap, and Contain Spend Every governed LLM call in Agent Fabric flows through Model Proxy. Omni Gateway is the runtime enforcement point for Agent Fabric, and Model Proxy runs on Omni Gateway. Model Proxy is a single access point in front of your LLM providers. You use Model Proxy to see spend, reduce spend, cap spend, and contain an anomalous agent. Usage that never reaches Model Proxy isn’t included in these controls. Model Proxy cost management gives you the visibility and controls you need to manage LLM costs by: - Helping make decisions based on spend data: See token consumption and cost by provider, model, and wallet, so you act on what drives cost. - Knowing the owner for each overrun: Trace tokens and dollars to the wallet that drove them. - Lowering cost without removing capability: Route routine queries to a cheaper model, and reuse responses to similar requests. - Having a cap that blocks requests: A Model Wallet blocks requests when a budget is reached, so spend stops at the cap. - Having a fast stop for a runaway agent: When an agent behaves anomalously, block its model access. Reverse the block if the flag was a false positive. - Having one control plane for every provider: Apply the same controls across every provider. Adding a model or a team doesn’t mean rebuilding those controls. ## How Cost Management Works in Agent Fabric Omni Gateway is the runtime enforcement point for Agent Fabric. Model Proxy runs on Omni Gateway and provides one governed endpoint for many LLM providers. Because all model traffic that you route through the proxy passes through this endpoint, cost management works in stages: see spend, reduce it, cap it, and contain anomalies. Usage that never reaches the proxy isn’t included. ### Review and Attribute Spend First, set a cost for each model so token usage translates into dollars. The Cost Management dashboard shows token consumption and spend across governed model calls, broken down by provider, model, and wallet. You can view usage as tokens or as dollars. Token counts come from model traffic, but dollar figures depend on the per-model costs you set. Since cost tracking starts from the time you set costs, rather than retroactively, set model costs early so spend data reflects your full usage. A model with no configured cost shows zero spend, but Model Proxy still counts its token usage. ### Reduce Spend with Routing and Caching Not every request needs your most powerful, most expensive model. Two optimizations lower the cost curve without capping usage: - Semantic routing compares each request to prompt topics you define and routes it to the best-matching model path. Route routine intents, such as order status or account lookups, to a fast, cost-effective model, and reserve advanced models for complex work. You can also deny-list topics to block requests you don’t want served at all. - Semantic caching stores model responses and reuses one when a new request is semantically similar to an earlier one, returning the cached response instead of calling the provider again. That reduces latency and cost. On chat-style traffic, semantic caching typically cuts token usage substantially. Semantic routing chooses a model path from the request, as in this example: ```text Simple query: "What's the status of order 12345?" → Route to: fast, cost-effective model Complex query: "Analyze this quarter's sales trends, identify anomalies, and recommend strategic adjustments" → Route to: powerful, higher-cost model ``` ### Cap Spend with Model Wallets A Model Wallet identifies a caller of Model Proxy and caps that caller’s token or dollar spend against a provider over a period you set. You can apply these cost control options to a Model Wallet: - Enforced limits: When a wallet reaches its budget, Model Proxy blocks further requests to that provider’s models. - Periodic caps: Set a daily, weekly, or monthly limit that resets on a schedule, so spend stays bounded each period. - Flexible metrics: Set limits in dollars (USD) or tokens, whichever your team tracks. - Identity-scoped controls: A wallet ties usage to a caller’s identity, so each application or agent can have its own budget. Wallets rely on an identity provider that issues signed tokens to identify callers. Enforcement is approximate rather than a real-time hard cutoff. Usage can briefly exceed a limit before Model Proxy blocks further requests. The Cost Management dashboard shows usage against each cap. Budget rows show when usage is approaching the limit and when the wallet has reached it. ### Contain Runaway Agents Budgets stop normal usage at a planned cap. A compromised or malfunctioning agent is a different problem: it can drive unexpected cost through anomalous behavior that no single budget anticipates. To address such concerns, apply these policies: - Rogue Agent Detection policy: Monitor agent traffic and flag risky behavior, such as prompt injection or attempts to escalate privileges. - Agent Kill Switch policy: Block a flagged agent’s model access when you decide to contain it. Detection never acts on its own. You review flagged activity before taking action, and containment is fully reversible, so you can restore an agent’s access if a flag turns out to be a false positive. Apply both policies as described in [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents). ## Who This Is For Agent Fabric cost management capabilities are ideal for: - FinOps teams managing cloud and AI spending - Engineering leaders optimizing infrastructure costs - Product teams building cost-effective agentic features - Enterprises scaling agent deployments beyond proof of concept - Any organization where LLM costs are a significant budget item ## Example Cost Management Scenarios in Agent Fabric A large organization runs agents in several business units and can’t tell which callers and providers drive LLM cost. ### Scenario 1: Cost Visibility Across Providers and Callers **Challenge:** A large organization has agents deployed across multiple business units but no visibility into which callers and providers are driving LLM costs. With Agent Fabric you get cost visibility for traffic that goes through Model Proxy. Here’s how it works: 1. Route LLM traffic through Model Proxy. 2. Set a cost for each model so token usage translates into spend. 3. Use Cost Management to view token consumption and spend by provider, model, and wallet. **Result:** Token usage and spend map to the providers, models, and wallets that generated them. Leaders can see which deployments cost the most and target optimization where it pays off. For more information, see [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs). ### Scenario 2: Semantic Routing and Caching for Customer Support **Challenge:** A customer support agent system uses expensive models for all queries, including simple lookups, and repeats similar calls for common questions. With semantic routing and caching in Agent Fabric you cut cost on routine and repeated work. Here’s how it works: 1. Configure semantic routing rules: - Simple queries (order status, account lookups) route to a cost-effective model. - Complex queries (troubleshooting, technical issues) route to an advanced model. 2. Enable semantic caching so repeated, similar questions return a stored response instead of a new model call. **Result:** Routine lookups move to a cheaper model path, and repeated questions are served from cache without a provider call. Average token use drops on common support traffic. For more information about semantic routing, see [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service). ### Scenario 3: Budget Controls for Development Teams **Challenge:** Development teams experimenting with agents have no spending limits, leading to budget surprises. With the Model Wallets feature in Agent Fabric you get budgets agents can’t quietly overrun. Here’s how it works: 1. Create a wallet for each team, scoped to that team’s callers. 2. Add a budget per provider, choosing a daily, weekly, or monthly period. 3. Set the limit in dollars (USD) or tokens, so requests are blocked when the limit is reached. 4. Watch budget consumption in the Cost Management dashboard. **Result:** A runaway experiment stops near its cap instead of surfacing as a month-end invoice. Finance gets predictable per-team spend, and teams keep the autonomy to experiment within a limit they can see. For more information about Model Wallets, see [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage). ### Scenario 4: Multi-Model Optimization **Challenge:** An organization uses multiple LLM providers but doesn’t know which models are most cost-effective for its use cases. With Agent Fabric you get evidence-based model selection. Here’s how it works: 1. Deploy agents with flexible model configuration. 2. Use Cost Management to compare spend by provider, model, and wallet. 3. Adjust routing so each class of request uses the model that fits its cost and complexity. **Result:** Model selection becomes a decision based on observed spend, not a default. Routing can change as providers change pricing or release new models. For more information, see [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage). ### Scenario 5: Containing a Runaway Agent **Challenge:** An agent is compromised or misconfigured and begins making unusual, high-volume model calls that drive unexpected spend. With runaway-agent containment policies in Agent Fabric you stop the runaway agent without taking down the whole system. Here’s how it works: 1. Apply the Rogue Agent Detection and Agent Kill Switch policies to Model Proxy. 2. Rogue Agent Detection flags the agent’s anomalous behavior for review. 3. Review the flagged activity, then quarantine the agent. The Agent Kill Switch policy blocks its model access. 4. Restore the agent’s access once you’ve corrected the underlying issue. **Result:** A single misbehaving agent is contained instead of running up cost until someone notices the invoice. Other agents keep working, and the block is fully reversible if the flag was a false positive. For more information about rogue agent detection, see [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents). ## Implementation Steps Follow these steps to set up cost management in Agent Fabric. ### Step 1: Deploy Model Proxy 1. Set up Model Proxy as part of your Omni Gateway deployment. 2. Configure integration with your LLM providers. 3. Route agent traffic through Model Proxy. ### Step 2: Set Model Costs Set the input and output token cost for each model your proxies use so token usage translates into spend. Dollar figures accrue only from the time you set costs, not retroactively, so set them early. A model with no configured cost shows zero spend, though its token usage is still counted. For the steps to set model costs, see [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs). ### Step 3: Turn On Cost Visibility 1. Identify each caller at the proxy to allocate traffic costs to the right wallet. 2. Use Cost Management to view token consumption and spend by provider, model, and wallet. ### Step 4: Establish Baseline Costs 1. Monitor usage patterns for one to two weeks without optimization. 2. Identify current cost drivers. 3. Categorize query types by complexity and frequency. 4. Calculate baseline cost metrics. ### Step 5: Optimize with Semantic Routing and Caching 1. Define query complexity categories as prompt topics, and assign an appropriate model to each. 2. Create routing rules so routine requests reach a cost-effective model and complex ones reach an advanced model. 3. Enable semantic caching so similar requests reuse a stored response instead of calling the provider again. 4. Test routing and caching with sample queries. ### Step 6: Set Budget Controls with Model Wallets 1. Create a wallet for each caller (team, application, or agent) you want to cap. Wallets require an identity provider that issues signed tokens to identify callers. 2. Add a budget for each provider the caller routes to, choosing a daily, weekly, or monthly period. 3. Set the limit in dollars (USD) or tokens, so requests are blocked when the limit is reached. 4. Watch budget consumption in the Cost Management dashboard. ### Step 7: Add Runaway-Agent Containment 1. Apply the Rogue Agent Detection policy to the proxies you want to protect, and define the anomalies to flag. 2. Register each agent with a unique identity so flags and actions attribute correctly. 3. Apply the Agent Kill Switch policy so that when you quarantine a flagged agent, the proxy blocks its model access. 4. Review flagged activity before you quarantine, and restore access if a flag is a false positive. ### Step 8: Monitor and Optimize 1. Track cost trends after optimization. 2. Refine routing rules and budgets based on results. 3. Share cost savings and optimization wins. ## Related Documentation - [Agent Fabric Use Cases](https://docs.mulesoft.com/general/agent-fabric-use-cases) - [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy) - [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service) - [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service) - [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage) - [Viewing Token Usage and Model Proxy Metrics](https://docs.mulesoft.com/general/model-proxy-token-reports) - [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents) --- product: Getting Started keywords: akamai api security scanner, akamai integration, security risk, vulnerability findings, incident correlation, portfolio catalogs --- # Correlating Risk Using Akamai API Security > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Akamai for risk correlation to map external security findings to the right services in **Portfolio**. Teams get one view to triage risk, track incidents, and remediate faster. To enable this correlation, configure an Akamai API Security scanner that connects your Akamai account, runs scheduled scans, and surfaces mapped findings on related services in **Portfolio**. The scanner doesn’t import or register third-party services. It correlates risk scores, findings, and incidents for APIs and MCP services in one governance workflow. The integration relies on a bidirectional sync between your MuleSoft and Akamai API Security tenants. You connect the two tenants with credentials in each direction: Akamai reads your API assets and instances from MuleSoft so it can match its security observations to the correct APIs, and the scanner pulls the resulting findings and incidents back into **Portfolio**. ## Akamai Scanner vs. Import Scanners Most provider scanners discover metadata in external platforms and import services into **Portfolio** catalogs. The Akamai API Security scanner works differently: instead of creating new services, it enriches existing ones with Akamai security data. ## Before You Begin Before setting up the Akamai scanner, make sure you have: - Exchange Administrator permission in the target business group. - Akamai Security base URL, client ID, and client secret. - Access to apply the Akamai correlation policy in the environments you want to scan. - Existing APIs and MCP services in **Portfolio** catalogs for correlation targets. For credential and role details, see [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). ## Monitor Traffic Through Omni Gateway Akamai observes traffic at the Akamai edge, which is traffic between external clients and your APIs on domains you own and control. To also have Akamai analyze traffic that passes through Omni Gateway but isn’t inspected at the Akamai edge, apply the **Akamai API Security (Omni Gateway)** policy to your API instances. This traffic includes: - Internal traffic between services (east-west traffic). - External traffic to endpoints you can’t register at the Akamai edge, such as MuleSoft-managed CloudHub endpoints. The policy forwards this traffic to Akamai API Security in asynchronous batches. Forwarding doesn’t block requests. If the Akamai engine is unavailable, forwarding fails open and your API traffic isn’t affected. Akamai owns and maintains this policy, and it’s separate from the Akamai correlation policy that the scanner applies. For findings from forwarded traffic to appear on the related API in **Portfolio**, apply both policies to the API instance. The correlation policy adds the correlation data that Akamai uses to match a finding to its API, and the Akamai API Security (Omni Gateway) policy forwards that data with the traffic it captures. You create the policy in Akamai API Security, publish it to Anypoint Exchange, and apply it to your APIs in Anypoint API Manager. > [!IMPORTANT] To monitor traffic, set `PREVENTION_ENABLED` to `false` when you apply the policy. In > this capture-only configuration, the policy forwards traffic for analysis without blocking > requests. > > The policy can also block requests from attackers that Akamai API Security detects and return a > `403` response. Blocking is an opt-in control that runs synchronously in the request path, so > Akamai engine availability and the policy’s timeout settings can affect your API traffic. Before > you enable prevention, review the policy parameters in the Akamai documentation. ### Before You Apply the Policy Make sure you have: - API instances that run on Omni Gateway. - The Akamai correlation policy applied to those API instances. See [Set Up the Akamai Scanner](#set-up-the-akamai-scanner). - Network access from Omni Gateway to your Akamai API Security engine over HTTPS. - The Admin role in Akamai API Security with the Traffic Source & Prevention permission. - Permission to publish assets to Anypoint Exchange and apply policies in Anypoint API Manager. - Anypoint CLI with the PDK plugin, Node.js, and Rust installed on the machine where you install the policy. See [Prerequisites for Omni Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-prerequisites). ### Apply the Policy 1. In Akamai API Security, create a MuleSoft traffic source integration for Omni Gateway, and then download the policy. For instructions, see [MuleSoft Omni Gateway - Source and Prevention Integration](https://docs.nonamesecurity.com/docs/mulesoft-omni-gateway-source-and-prevention-integration) in the Akamai documentation. 2. In Anypoint Platform, create a connected app that acts on its own behalf (client credentials) with the **Exchange Contributor** scope, and then copy the client ID and client secret. This connected app is separate from the one Akamai uses to read API assets from MuleSoft. For instructions, see [Creating Connected Apps in Anypoint Platform](https://docs.mulesoft.com/access-management/creating-connected-apps-dev). 3. Configure Anypoint CLI with the connected app credentials, your business group ID, and your environment ID, and then run the installation script included in the policy download. The script publishes the policy to Anypoint Exchange. For the commands, see "Step 4: Deploy the Policy" in [MuleSoft Omni Gateway - Source and Prevention Integration](https://docs.nonamesecurity.com/docs/mulesoft-omni-gateway-source-and-prevention-integration) in the Akamai documentation. 4. In Anypoint API Manager, apply the **Akamai API Security (Omni Gateway)** policy in one of these ways: - To apply the policy to all APIs in an environment, add it as an automated policy. In **Advanced Options**, set **Rule of application** to **Omni gateways only**. See [Applying Automated Inbound Policies](https://docs.mulesoft.com/gateway/latest/policies-automated-applying). - To apply the policy to specific APIs, add it as an inbound policy on each API. To capture traffic without blocking requests, set `PREVENTION_ENABLED` to `false`. For instructions, see "Step 5: Apply the Policy" in [MuleSoft Omni Gateway - Source and Prevention Integration](https://docs.nonamesecurity.com/docs/mulesoft-omni-gateway-source-and-prevention-integration) in the Akamai documentation. 5. Move the **Akamai API Security (Omni Gateway)** policy to the top of the policy list, above the Akamai correlation policy. With this order, the correlation policy adds correlation data to the response before the Akamai API Security (Omni Gateway) policy captures it. If the order is reversed, Akamai receives the traffic without correlation data, so findings from that traffic don’t appear on the related API in **Portfolio**. No error is reported. For policy parameters and troubleshooting, see the [Akamai documentation for the MuleSoft Omni Gateway integration](https://docs.nonamesecurity.com/docs/mulesoft-omni-gateway-source-and-prevention-integration). You need an Akamai account to view this documentation. ## Set Up Tenant Connectivity The integration uses a bidirectional sync between your MuleSoft tenant and your Akamai API Security tenant. You provision and configure both tenants. Each MuleSoft customer tenant (root organization) connects to one Akamai API Security tenant (for example, `.nonamesec.com`). Setup involves credentials in both directions: - A service account in Akamai, which you configure on the MuleSoft side so the scanner can read findings and incidents from Akamai. - A connected app in MuleSoft, which you configure on the Akamai side so Akamai can pull API asset and instance information from MuleSoft. Complete these steps as an organization administrator: 1. Create a service account in Akamai API Security. In your Akamai API Security tenant, create a service account and note its client ID and client secret. 2. Configure the scanner in MuleSoft. Add an Akamai scanner and enter the Akamai service account credentials (client ID and client secret) and the Akamai base URL, along with a scan frequency. See [Set Up the Akamai Scanner](#set-up-the-akamai-scanner). 3. Create a connected app in MuleSoft. In Anypoint Platform, go to **Access Management** > **Connected Apps** and create an app that acts on its own behalf (client credentials). Add the **Exchange Viewer** or **Asset Viewer** scope so Akamai can read API instance and asset information, then save. Copy the client ID and client secret. For instructions, see [Creating Connected Apps in Anypoint Platform](https://docs.mulesoft.com/access-management/creating-connected-apps-dev). 4. Configure the sync on the Akamai side. In your Akamai API Security tenant, enter the MuleSoft connected app client ID and client secret so Akamai can pull API asset and instance information from MuleSoft. ## Set Up the Akamai Scanner Before you set up the scanner, review the prerequisites for Akamai scanners in [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). 1. From **Platform** > **Providers**, select **Akamai**. 2. Click **Add Scanner** and enter the connection values. 3. Test the connection. 4. Enter scanner metadata, such as scanner name, description, frequency, and time. 5. Apply the Akamai correlation policy to selected environments. 6. Save the scanner and run a discovery scan. ## How the Sync Works After both tenants are connected, data flows in two directions: MuleSoft to Akamai Akamai periodically pulls API instance and asset information from MuleSoft (typically every few hours) and adds it to its API security inventory. Akamai correlates these API instances with the north-south traffic it observes, so it can attach MuleSoft context — such as organization ID, environment ID, and API instance ID — to the endpoints it monitors. The pull runs at the root organization level. Akamai to MuleSoft The scanner pulls security findings and incidents from Akamai on the schedule you set, then correlates and stores them so they appear on the related services in **Portfolio**. For Akamai to observe and correlate traffic, the Akamai correlation policy must be applied to your API instances. This out-of-the-box policy (for Omni Gateway and Mule gateways) stamps correlation headers on API responses so Akamai can match observed traffic to the correct MuleSoft API. Akamai observes north-south traffic only for domains you own and control. ## Review Scanner Detail Tabs After you select a configured Akamai scanner from the provider list, use the scanner detail tabs to monitor scanner status, related services, and configuration values. For common tab behavior across scanners, see [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details). For Akamai scanners, the **Overview** tab highlights correlation policy status and shows whether existing services are being updated with Akamai risk, findings, and incident data. The **Services** tab lists services associated with the scanner and shows which existing services are receiving correlated Akamai security data. The **Settings** tab shows scanner configuration values, including schedule and provider connection values, and provides options to edit or delete the scanner. ## Apply Missing Correlation Policies If some environments show that the correlation policy isn’t applied, you can apply missing policies from the scanner detail page: 1. Open **Platform** > **Providers** and select the configured Akamai scanner. 2. In **Overview**, check the **Akamai Correlation Policy** status. 3. If the status shows missing environments, click **Check again** to apply the policy only to those environments. 4. Wait for the status to change to **Applied** and confirm all target environments are covered. If policy application fails, verify your Admin API write permissions and environment access, then retry. ## Reviewing Akamai Security Results in the Enhanced Experience After a successful run, Akamai results appear on existing services: - API list views show values in the **Security Risk** column. - API detail pages show Akamai security data in **Conformance**. - Security sections display violation totals, findings, incidents, and endpoint context. - The **Akamai Security Findings** table lists each finding with columns for finding, instance, endpoint, API risk, scan status, and remediation progress. - Finding detail views show fields such as status, type, endpoint path, and mapped frameworks. ## Interpret Risk Status Levels The **Security Risk** column shows the risk level assigned to correlated Akamai findings: Low Lower-urgency risk. Review and remediate in your normal security lifecycle. Medium Moderate risk. Prioritize remediation after high-risk issues. High Elevated risk. Investigate and remediate first. Critical Highest-urgency risk. Remediate immediately. ## Track Remediation and Scan Status In the **Akamai Security Findings** table on the **Conformance** tab, two columns help you track remediation progress for each finding: Remediation Shows how many of the suggested remediation policies are applied on the finding’s instance, as an _applied/suggested_ count (for example, `1/3 remediations`). The suggested count reflects the remediation policies recommended for that finding type, and the applied count reflects how many of those policies are currently applied on the API instance. This count is tracked at the instance level, so two findings on different endpoints of the same instance that share a finding type show the same count. Scan Status Indicates whether remediation is underway for the finding: Open No remediation policy is applied yet for the finding. Rescan Confirmation At least one remediation policy is applied on the instance, but the finding still appears in the latest results. Re-run the scanner to confirm whether the finding is resolved. > [!NOTE] The **Akamai Security Findings** table lists only findings that are currently active. When > a finding is remediated and a rescan confirms the fix, the finding no longer appears in the table. ## Remediate Risks from the API Conformance Tab Use the API **Conformance** tab in **Portfolio** to triage and remediate Akamai findings: 1. Open the API from the **APIs** catalog in **Portfolio**. 2. Select **Conformance** and review the **Akamai** section, including findings and incidents. 3. Select a finding to open details, such as endpoint, severity, and mapped standards. 4. Apply recommended remediation policies directly from the finding detail view when available. 5. Re-run the scanner after remediation to confirm updated findings and risk levels. If no direct remediation policy is available for a finding, use the finding details to update the API configuration in your gateway or upstream system, then scan again to verify the result. ## Troubleshoot Missing Akamai Findings If a scan completes but results don’t appear: - Verify the correlation policy is applied in the same environment as the service instance. - Confirm the target service already exists in **Portfolio** catalogs. - Confirm scanner scope and business group match the service location. - For traffic forwarded by the Akamai API Security (Omni Gateway) policy, confirm the policy is above the Akamai correlation policy in the policy list. - Re-run the scanner after connection or policy changes. ## See Also - [Securing Services in Your Portfolio](https://docs.mulesoft.com/general/exp-securing-services) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) --- product: Getting Started keywords: scanner, provider services, create scanner, entry points, experience services, mulesoft integration, service discovery --- # Create a Scanner for Provider Services > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To create a scanner, connect to a provider. The system runs scanners against supported cloud platforms, discovers services (such as agents, APIs, and MCP servers), and registers them in the matching catalog in **Portfolio**. You supply credentials and scanner metadata so the integration is repeatable and auditable. Start the flow from **Home** or from a specific catalog in **Portfolio**. To see how this flow relates to manual registration, see [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio). To create and tune scanners, see [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers). > [!NOTE] Amazon, Microsoft, and HashiCorp use this same **Connect to a Provider** flow to register > an external vault (AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault). A vault > syncs secret metadata rather than discovering services, so it doesn’t create a scanner or register > anything in a **Portfolio** catalog. For the vault registration flow, see > [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Administrator - Exchange: Exchange Contributor - API Manager: API Creator - API Manager: Manage Policies For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## When to Use a Scanner Use a scanner when your team maintains services in an external platform and wants those services to appear automatically in portfolio catalogs after authentication and discovery, instead of registering each service manually. ## Entry Points for Creating a Scanner - **Home** Use **Add Services**, select **Connect to Provider**, then work through the flow to pick a provider, validate access, and save scanner settings. Use this path when you’re not starting from a single catalog view. - **Portfolio** Open a supported service catalog in **Portfolio**. Use the add control for that service type (for example **Add API** or **Add MCP Server**), select **Connect to Provider**, and complete the same style of flow scoped to that catalog. Labels differ by catalog and release. Match what you see in the UI. ## Create a Scanner Across **Home** and **Portfolio** entry points, scanner creation includes the same decisions: - Which provider or platform to target for discovery and import. - Credentials and authentication so the system can reach the provider securely. - Connection validation so you know discovery can run against live data. - Scanner identity and settings: name, description, and options your administrator expects before you save the scanner. When the scanner runs successfully, the system registers discovered services in the catalog you started from (for example, APIs land in the **APIs** catalog). ## How Catalog Selection Affects Registration Scanner setup decisions stay the same across catalogs. However, after successful runs, discovered results get registered in specific service catalogs. For example, when you start from **APIs**, discovered APIs are registered in the **APIs** catalog. ## See Also - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) --- product: Getting Started keywords: governance strategies, create strategy, strategy workflow, governance scope, strategy type, api governance, mulesoft --- # Create Governance Strategies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Governance strategies define which services the system evaluates or enforces policy against and under what conditions. A Control strategy monitors compliance and can block noncompliant activity. An Automated Policy strategy enforces requirements at the gateway or runtime layer. You can create strategies if your tenant includes **Governance** and you have the required administrator role. > [!NOTE] Automate strategy creation using the MuleSoft MCP Platform Server. For details, see > [create\_guardrail](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#create-guardrail) and > [create\_automated\_policy\_strategy](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#create-automated-policy-strategy) > in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Any of these permissions: - API Governance: Governance Administrator - API Manager: Manage Policies For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). Also decide whether you need validation-only monitoring or active runtime enforcement. This choice determines the strategy type and the rules or policies to apply. ## Open the Strategy Workflow 1. Log in and go to **Governance** > **Governance Strategies**. 2. Select **Create Governance Strategy** to start the setup flow. The setup flow guides you through these steps: **Strategy Type**, **Scope**, **What to Apply**, **Name & Description**, and **Review**. ## Select Strategy Type Select from these types: - **Control** validates targeted services against control rules. Use controls to monitor compliance and, when supported, block noncompliant activity. - **Automated Policy** enforces runtime policy requirements across targeted services. Select the type that matches your governance objective, then proceed. ## Define Governance Scope Configure scope criteria to identify the services that the strategy governs. All criteria are combined to narrow the scope. Set these filters: **Service Type** Select one or more service types to govern. **Tags** Select tags to include only services that match those tags. **Categories** Select categories to further narrow the scope. **Instances** Filter by instance status: - **All APIs**: Include all matching services regardless of instance status. - **Include only APIs with instances**: Include only services that have at least one associated instance. - **Only APIs without instances**: Include only services with no associated instances. Use **Preview Governed Scope** to see which services currently match your criteria before you move forward. ## Configure Controls or Policies In the enhanced experience, your existing Anypoint profiles appear as controls. Controls offer expanded capabilities, such as governing new services and providing rules to control service and AI state behavior. Depending on the strategy type, select the controls or policies the strategy enforces: - For **Controls**, select controls from the catalog available in your tenant. - For **Automated Policy**, define runtime details such as gateway runtime, endpoint type, and environment. Available options depend on your earlier selections and your organization’s enabled products. ## General Information Enter a clear **Strategy Name**, such as "PCI Compliance Rules." Add a **Description** that states what the strategy enforces and why. ## Review and Activate Review your selections: strategy type, scope, rules or policies, and general information. Select **Create and Activate Strategy**. Strategies are active by default. To disable a strategy, go to **Governance Strategies**. ## After Strategy Activation - The system evaluates services that match the scope against the rules or policies in the strategy. - For **Controls**, compliance status appears in conformance reports. - For **Automated Policy**, enforcement runs at the gateway or runtime layer. - Edit the strategy from **Governance Strategies** when scope, rules, or naming change. Work with your governance lead if strategies affect production services or if rollout timing requires coordination. ## Create Governance Strategies with Your IDE You can also author governance strategies from your IDE by using locally installable developer skills. With skills, you define governance rulesets as code, which is useful for version control, reuse, and collaboration. Some rule types are available only through IDE skills. For example, you can’t configure control rules that track third-party provider policy subcategories in the UI. To create these rules, use a prompt such as `create a rule to track that each API has a JWT policy applied to it`. For step-by-step guidance on authoring rulesets from your IDE, see the [Author a Governance Ruleset](https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html) skill in the MuleSoft Developer Hub. ## See Also - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) - [Managing Governance Strategies](https://docs.mulesoft.com/general/exp-governance-manage-strategies) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: mcp server, create mcp server, mcp bridge, model context protocol, mcp tools, saas, api integration --- # Create MCP Servers with MCP Bridge > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use MCP Bridge to create MCP servers from your APIs and SaaS systems so that agents can discover and call their operations as MCP tools. MCP Bridge turns an existing API or SaaS system into an MCP server without custom code and without changing the underlying system. You select the sources to expose, choose which of their operations to publish as tools, and provide the credentials MCP Bridge uses to call the sources. When you create an MCP server in Enhanced Experience, the server is added to **Portfolio** automatically. During creation, you define: - **Sources** The APIs and SaaS systems to expose as MCP tools. - **Tools** The operations from each source that agents can discover and call. - **Credentials** The credentials MCP Bridge uses to call the selected SaaS systems. ## How MCP Bridge Works Each operation you select from a source becomes an MCP tool. When an agent requests the list of available tools (`tools/list`), the MCP server responds with each tool’s name, description, and input schema. When an agent calls a tool (`tools/call`), MCP Bridge maps the tool name and arguments to an HTTP request to the underlying API or SaaS system. This diagram shows the relationship of the upstream and downstream configurations to your upstream service and agent client: ![The MCP Bridge instance is deployed on a gateway between the upstream APIs and the downstream configuration.](/mulesoft/current/en-us/general/_images/mcp-bridge-instance.png) MCP Bridge generates each tool’s name and description from the source definition: - For SaaS systems, tool names use the format `_`, for example `15five_getUsers`. You can’t edit SaaS tools. - For APIs, tool names use a prefix that identifies the API, followed by the HTTP method and path, for example `cmdb-sync_get_admin_dlq`. You can edit API tools before you create the server. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these Exchange permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator - These permissions on the environment where you deploy the MCP server: - API Manager: Manage APIs Configuration - API Manager: Manage Policies - API Manager: Deploy API Proxies - Runtime Manager: Read Servers Your administrator can assign these permissions and the Exchange role directly to your user, or through a team or role group in Access Management. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - Credentials for each SaaS system you plan to expose. ## Create an MCP Server 1. Open **MCP Servers** and select **Add MCP Server** > **Create MCP Server**. 2. In **Select APIs and SaaS systems**, select the sources to expose as MCP tools: 1. To narrow the list, search by name or select **APIs** or **SaaS**. 2. Select one or more sources. You can combine APIs and SaaS systems in the same MCP server. Each source shows the number of tools or operations it provides. 3. For an API, select the API version from the version list. The latest version is selected by default. 3. In **Select Tools**, choose which tools to expose from the selected sources. Tools are grouped by source. For an API, the group shows the URL of the API instance that MCP Bridge calls. Each tool shows its HTTP method, description, path, and tool name. Hover over a description to see its full text. 1. For an API, to use a different API instance or create an unmanaged instance, click **Change Instance**. See [Change the Instance for an API](#change-api-instance). Each API must have an instance before you can continue. If an API doesn’t have an instance, click **Change Instance** and create an unmanaged instance. 2. To narrow the list, click **Filter**, select the methods and paths to show, and click **Apply**. > [!NOTE] Filtering changes only which tools are shown, not which tools are selected. Tools > hidden by the filter remain selected and are exposed by the MCP server. 3. Clear the checkbox for each tool that agents must not call. For example, to expose only read operations, filter to the **POST**, **PUT**, **PATCH**, and **DELETE** methods, clear the checkbox for each tool shown, and then reset the filter to confirm that only **GET** tools remain selected. 4. For an API tool, to edit the tool’s name, description, input schema, or HTTP mapping, click the **Actions** menu (**⋮**) for the tool. See [Edit an API Tool](#edit-api-tool). 5. To remove a source, click **X** in the source’s group. 6. Confirm the number of tools selected, and click **Next**. 4. In **SaaS Credentials**, provide the credentials MCP Bridge uses to call each selected SaaS system. If you selected only APIs, this step doesn’t appear, and you go directly to **Review**. The required credential fields depend on the SaaS system, for example **API Key** or **API Token**. 1. If a warning icon appears next to a SaaS system, its upstream configuration is incomplete. Click **Configure**, enter a value for each variable, and click **Save**. You must complete the upstream configuration for each SaaS system before you can continue. Some SaaS systems use variables in their upstream and token URLs, such as `https://{account}.api-us1.com`. MCP Bridge substitutes the values you enter into the URLs before it calls the SaaS system. 2. For each SaaS system, enter the required credentials. To show or hide a value, click the eye icon. 3. Optionally, click **Test Credentials** to confirm that MCP Bridge can authenticate to the SaaS system. **Test Credentials** is available after you enter the required credentials. If the test fails, an error such as `Authentication failed (403)` appears. Testing isn’t required to continue. 4. Click **Next**. 5. In **Review**, review the MCP server configuration: 1. In **Advanced Server Configuration**, review the server details that MCP Bridge generates: - **Server Name** and **Version** — The name and version of the MCP server. - **Path** — The base path of the MCP server on the gateway. - **Environment** and **Gateway** — Where the MCP server is deployed. - **Inbound TLS** and **Outbound TLS** — The TLS contexts for traffic from agents and to the sources. - **URL** — The endpoint that agents use to connect to the MCP server. 2. To change the server configuration, click **Edit** in **Advanced Server Configuration**, and then update the settings: - In **Server Configuration**, edit the following settings, and then click **Save**: - **Server Name** — Identifies the MCP server and becomes the subdomain of the server’s URL. - **Version** — The semantic version of the MCP server, for example `1.0.0` or `v2.1.3`. - **Path** — The base path on the gateway. By default, the path is derived from the server name. - **Environment** — The environment where the MCP server is deployed. - **Gateway** — The gateway that hosts the MCP server. - In **TLS Configuration**, optionally click **Add TLS Context** to encrypt communication from clients to the gateway (inbound) and from the gateway to your API instances (outbound). 3. Optionally, in **Description**, describe the business purpose of the MCP server. 4. In **Sources, Instances & Tools**, review each source, its API instance ID and URL, and the tools the MCP server exposes. 5. To change the sources, instances, or tools, click **Edit** in **Sources, Instances & Tools**. This returns you to **Select APIs and SaaS systems**, and you complete the remaining steps again. 6. Click **Create & Deploy**. After you click **Create & Deploy**, the MCP server is deployed to the gateway and added to the **MCP Servers** catalog in **Portfolio**. Agents connect to the MCP server at the URL shown in **Review**. ## Change the Instance for an API For an API source, MCP Bridge calls the API through an API instance. You can select a different existing instance or create an unmanaged instance that points to an upstream URL. 1. In **Select Tools**, click **Change Instance** in the API’s group. 2. In **Advanced settings**, select a source: - To use an existing instance, select **Select Instance**, then: 1. Select the instance from the list. Each instance shows its label or ID, type, environment, and upstream URL. 2. Optionally, edit the **Route label**. By default, the route label is the API name. - To create an unmanaged instance, select **Create new unmanaged instance**, then: 1. In **Name**, enter a name for the instance. 2. In **URL**, enter the upstream endpoint the instance points to, including the `http://` or `https://` scheme. For example, `http://example.com/api/v1/`. 3. In **Visibility**, select **Private** or **Public**. The default is **Private**. 3. Click **Save**. ## Edit an API Tool MCP Bridge generates each API tool from the API specification. Before you create the MCP server, you can change how a tool is presented to agents and how its arguments map to the HTTP request. 1. In **Select Tools**, click the **Actions** menu (**⋮**) for the tool. 2. In **Tool definition**, review and edit the tool: - **Enable as tool** — Whether the MCP server exposes the tool to agents. This is the same setting as the tool’s checkbox in **Select Tools**. - **Method** and **Resource** — The HTTP method and API resource the tool calls. - **AI tool name** — The name agents use to call the tool. The prefix that identifies the API, such as `cmdb-sync_`, can’t be changed. - **Description** — The description agents use to decide when to call the tool. Write a description that states what the tool does and what it returns. - **Schema (JSON)** — The tool’s input schema, which defines the arguments the agent supplies when calling the tool. Editing the schema replaces the schema derived from the API specification. 3. Optionally, in **HTTP mapping (optional)**, edit how the tool’s arguments map to the HTTP request. These values are populated from the API specification. - **Query Parameter(s)** — Click **Add query parameter** to map an argument to a query parameter. - **URI Parameter(s)** — The URI parameters in the resource path, if any. - **Headers** — Click **Add header** to map an argument to an HTTP header. - **Body** — A DataWeave expression that builds the request body. The default is `#[vars.params.body]`. To test the expression, click **Try the DataWeave expression in the playground**. 4. Click **Save**. ## Edit an MCP Server After you create an MCP server, you can edit its sources, API versions, tools, credentials, and server configuration. 1. Open **MCP Servers** and select the MCP server you want to edit. 2. Click **Actions** > **Edit**. The same steps you used to create the MCP server open with your current selections. 3. Update the settings as needed. For more information about each step, see [Create an MCP Server](#create-mcp-server). 4. In **Review**, click **Save & Deploy**. ## See Also - [Making Your APIs Agent-Ready](https://docs.mulesoft.com/general/af-use-case-mcp-bridge) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: api instances, apis catalog, create instance, manage instances, anypoint platform, api management, instance configuration --- # Creating and Managing Instances of Services > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Instances represent how a service runs in a specific environment, such as production or sandbox, and how traffic reaches it through gateways or runtimes your organization manages. Services such as APIs, agents, MCP servers, and Model proxies can include instances. In the enhanced experience, you manage instances from the service detail page through the **Instances** tab. Managed paths through Anypoint Omni Gateway can provide additional policy and monitoring integrations if your organization supports them. Unmanaged or external paths remain available when they align with your operating model. Watch this video to see how to create and manage instances: ![](https://play.vidyard.com/yNgFyJtT4MV6fYSvwbaZQ2.jpg) ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - These permissions: - API Manager: API Creator to create instances. - API Manager: View APIs Configuration to view instances. - API Manager: Edit APIs Configuration to edit instances. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Open the Service Catalog 1. In **Portfolio**, open the catalog for the service type, such as **APIs**, **Agents**, **MCP Servers**, or **Model Proxies**. 2. Select a service to open its detail page. 3. Open the **Instances** tab. Field names, required metadata, and available gateway or runtime options depend on the selected service type and your organization’s configuration. ## Create an Instance 1. In the **Instances** tab, click **Add Instance**. 2. Select the instance type: - **Managed Instance** – Creates a new instance on an Omni Gateway with full support for authentication, monitoring, and policy enforcement. - **Unmanaged Target** – Creates a basic record of an API endpoint. You can add management for this endpoint later. 3. Complete the **Instance** fields: - **Environment** – Select the environment where the instance runs, such as Sandbox or Production. - **Omni Gateway** – Select the gateway to route traffic through. Required for managed instances. - **Version** – Select the API version for this instance. - **Label** – Optional label to identify the instance. 4. Under **Target**, enter the **Target URL** where the instance proxies requests. 5. Click **Create Instance**. ## After Creating or Updating an Instance After creating or updating an instance, you can continue managing the service through related areas of the experience. - Use the **Policies** tab to review or apply policies to the instance. For a managed instance on an Omni Gateway, policies are enforced through the Omni Gateway. For an instance discovered on a third-party API gateway (Azure API Management, Google Apigee, or Kong Gateway), the **Policies** tab applies policies directly to the provider through policy write, with no Omni Gateway in the request path. This requires a scanner connection whose credentials carry the provider’s write scope. If the connection has only read access to the provider, the instance appears as **Read-Only** and policy actions are unavailable. For write scopes and requirements, see [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). For the apply and management workflow, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). If the instance uses a Kong gateway, applying a policy targets the gateway level and protects all services in that gateway. - Use the **Monitoring** tab to review metrics and runtime performance when monitoring is available. - Coordinate with platform owners if DNS, certificates, or upstream routing changes must happen outside the product. ## See Also - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) --- product: Getting Started --- # Creating and Managing Model Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Model Proxy provides a unified access layer for multiple Large Language Model (LLM) providers. Model Proxies are deployed to Omni Gateway to enable governance, intelligent routing, and cost management for AI applications. Model Proxy is supported on Managed Omni Gateway and Self-Managed Omni Gateway running in Connected Mode. By creating a proxy, the user defines a singular LLM service that can receive requests for multiple LLM providers. This simplifies the developer experience. You can seamlessly add new models to the service without changing the endpoint. ![A Model Proxy with a single endpoint routing requests to multiple LLM providers](/mulesoft/current/en-us/general/_images/model-proxy.png) ## Supported Endpoint Formats Model Proxy supports these endpoint formats that are selected when creating a Model Proxy and can’t be changed later: - **OpenAI**: The OpenAI API format works with all supported LLM providers and supports multi-routing and fallback mechanisms. - **Gemini**: The native Gemini API format for direct Google Gemini model requests. Supports model-based routing only. - **Anthropic**: The native Anthropic API format for direct Anthropic Claude model requests. Supports model-based routing only. Depending on configuration, the proxy then sends the request to the model defined by the user or dynamically sends the request to the provider that best matches the request: - [Model-Based Routing](#model-based-routing): Static routing. The user specifies what model the Model Proxy should send the request to. - [Semantic Routing](#semantic-routing): Dynamic routing. The Model Proxy chooses which model to send the request to based on the request content. ## Model-Based Routing Model-based routing is static routing. In the request, the user specifies what model the Model Proxy should send the request to. By specifying a target model, Model Proxy can override the model version provided by the user. ## Semantic Routing Semantic routing is dynamic routing where the Model Proxy chooses which model to send the request to. For Sematic Routing, the user creates prompt topics for each route. When a request is sent to the Model Proxy, a semantic service compares the request to the define topic utterances and sends the request to the route that best matches it. ## Semantic Caching Semantic caching stores and reuses LLM responses based on semantic similarity. When an incoming request is semantically similar to a previous request, Model Proxy returns the cached response instead of calling the LLM provider again, which reduces latency and cost. To use semantic caching, configure a semantic caching service and enable it on the Model Proxy. Semantic caching supports Azure AI Search as the vector database only. For more information, see [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service). ## Connections and Model Proxies Model Proxy includes these types: - **Proxy**: A proxy configuration that can route requests to one or multiple LLM providers by using model-based routing and semantic routing strategies. The enhanced experience manages proxy configurations. - **Connection**: A connection configuration that stores credentials and metadata for connecting to a specific LLM provider. The enhanced experience displays connections as a single-route proxy. Connection configurations are managed by external projects, such as an Agent Network project. ## Model Proxy Limits Up to 50 Model Proxies are supported per Large Omni Gateway. ## Supported LLM Providers and Models Model Proxy supports these LLM providers and models: - OpenAI - GPT 5.2 - GPT 5.2 Pro - GPT 5 Mini - GPT 5.2 Codex - GPT 5 Nano - GPT 5 - GPT 4.1 - GPT 4o Mini - Chat Latest - ChatGPT-4o - codex-mini-latest - computer-use-preview - Daybreak Blue - Daybreak Red - GPT-3.5 Turbo - GPT-4 - GPT-4 Turbo - GPT-4 Turbo Preview - GPT-4.1 Mini - GPT-4.1 nano - GPT-4.5 Preview - GPT-4o - GPT-4o Search Preview - GPT-4o Mini Search Preview - GPT-5 Chat - GPT-5 Pro - GPT-5-Codex - GPT-5.1 - GPT-5.1 Chat - GPT-5.1-Codex - GPT-5.1-Codex Mini - GPT-5.1-Codex-Max - GPT-5.2 Chat - GPT-5.3 Chat - GPT-5.3-Codex - GPT-5.4 - GPT-5.4 Mini - GPT-5.4 nano - GPT-5.4 Pro - GPT-5.5 - GPT-5.5 Pro - GPT-5.6 Cyber - GPT-5.6 Luna - GPT-5.6 Sol - GPT-5.6 Terra - GPT-6 Astra - GPT-6 Sol - GPT-6 Luna - gpt-oss-120b - gpt-oss-20b - o1 - o1 Preview - o1-mini - o1-pro - o3 - o3-deep-research - o3-mini - o3-pro - o4-mini - o4-mini-deep-research - Azure OpenAI - GPT-6 Astra - GPT-6 Sol - GPT-6 Luna - GPT-5.6 Sol - GPT-5.6 Terra - GPT-5.6 Luna - GPT-5.5 - GPT-5.4 - GPT-5.4 Mini - GPT-5.4 Nano - GPT-5.4 Pro - GPT-5.3-Codex - GPT 5.2 - GPT 5.2 Pro - GPT 5 Mini - GPT 5.2 Codex - GPT 5 Nano - GPT 5 - GPT 4.1 - GPT 4o Mini - Bedrock OpenAI - GPT-6 Astra (Bedrock) - GPT-6 Sol (Bedrock) - GPT-6 Luna (Bedrock) - GPT-5.6 Sol (Bedrock) - GPT-5.6 Terra (Bedrock) - GPT-5.6 Cyber (Bedrock) - GPT-5.6 Luna (Bedrock) - GPT-5.5 (Bedrock) - GPT-5.4 (Bedrock) - GPT-OSS 120B (Bedrock) - GPT-OSS 20B (Bedrock) - Gemini - Gemini 3 Flash Preview - Gemini 2.5 Flash - Gemini 2.5 Flash Preview 09-2025 - Gemini 2.5 Flash Lite - Gemini 3 Flash - Gemini 3.1 Pro - Gemini 3.5 - Gemini 3.8 Flash - Gemma 4 26B A4B - Gemma 4 31B - Anthropic - Claude Opus 5.5 - Claude Opus 5 - Claude Sonnet 5 - Claude Fable 5.1 - Claude Opus 4.8 - Claude Opus 4.7 - Claude Opus 4.6 - Claude Sonnet 4.6 - Claude Haiku 4.5 - Claude Fable 5 - Bedrock Anthropic - Claude Opus 5.5 (Bedrock) - Claude Opus 5 (Bedrock) - Claude Opus 4.8 (Bedrock) - Claude Opus 4.7 (Bedrock) - Claude Opus 4.6 (Bedrock) - Claude Sonnet 5 (Bedrock) - Claude Sonnet 4.6 (Bedrock) - Claude Haiku 4.5 (Bedrock) - Claude Fable 5.1 (Bedrock) - Claude Fable 5 (Bedrock) - Claude Sonnet 4.5 (Bedrock) - NVIDIA - Nemotron 3 Nano 30B A3B - Nemotron 3 Super 120B A12B - Llama Nemotron Ultra 253B - Nemotron 3 Ultra 550B A55B - Nemotron 3.5 Lightning 30B A3B - Llama Nemotron Super 49B - Llama Nemotron Super 49B v1.5 - Llama Nemotron Nano 8B v1 - Nemotron Nano 9B v2 - Llama Nemotron 70B Instruct - xAI - Grok 4.6 - Grok 4.5 - Grok 4.3 - Grok 4.20 (Reasoning) - Grok 4.20 (Non-Reasoning) - Grok 4.20 Multi-Agent Beta - Grok Build 0.1 - Mistral - Mistral Large 3 - Mistral Medium 3.5 - Mistral Small - Magistral Medium - Magistral Small - Ministral 8B - Ministral 3B - Codestral - Devstral Medium - Devstral Small - Pixtral Large --- product: Getting Started --- # Creating Model Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can configure a model proxy to route LLM traffic across different models and providers using model-based or semantic routing strategies. When you create a model proxy, you define the endpoint format, routing strategy, and at least one route that maps requests to a supported LLM provider and model. After deployment to Omni Gateway, you can edit the proxy configuration at any time. > [!NOTE] A large Omni Gateway supports up to 50 Model Proxies. > [!NOTE] Automate model proxy provisioning using the MuleSoft MCP Platform Server. For details, see > [provision\_mcp\_server](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#provision-mcp-server) > in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account - API Manager: API Creator permission For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - A deployed Omni Gateway version 1.11.4 See [Deploy a Managed Omni Gateway](https://docs.mulesoft.com/gateway/latest/gateway-managed-set-up). - API keys to authenticate with your LLM Providers. - A [configured semantic routing service](https://docs.mulesoft.com/general/model-proxy-semantic-service) if you want to use semantic routing. - A [configured semantic caching service](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service) if you want to enable semantic caching. - A connection to an external vault (AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault) configured under **Platform** > **Providers** if you want to authenticate a route with a secret from your vault. For more information, see [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). ## Create a Model Proxy 1. In the navigation pane, select **Model Proxies**. 2. Click **Add Model Proxy** 3. Configure the proxy parameters: 1. **Proxy Name**: Define a name for the Model Proxy. 2. Enter a **Description** of what this proxy does (up to 256 characters). 3. **Base Path**: Define a base path for the proxy endpoint (for example: `/billing-ai`). 4. **Format**: Select an endpoint format: - **OpenAI**: Select the OpenAI API format to send requests to all supported LLM providers (including Gemini and Anthropic). Supports multi-routing and fallback mechanisms. You can’t change this format later. - **Anthropic**: Select the Anthropic API format for native Anthropic Claude model requests. Supports model-based routing only. You can’t change this format later. - **Gemini**: Select the Gemini API format for native Google Gemini model requests. Supports model-based routing only. You can’t change this format later. 5. **Environment**: Select the environment for the Model Proxy. 6. **Omni Gateway**: Select an Omni Gateway to deploy the Model Proxy to. 7. Enter a **Consumer Endpoint**: the URL where the Model Proxy is accessible (for example, `[https://api.example.com](https://api.example.com)`). 8. **Port**: Enter the port number for the Model Proxy (for example, `8081`). This field is required. 9. Configure **TLS Configuration** to secure the proxy endpoint: - **Secret Group**: Select the secret group that contains your TLS context. If you don’t see your secret group, ensure that it is downloadable. For more information, see [Add a TLS Context](https://docs.mulesoft.com/gateway/latest/conn-tls-config#add-a-tls-context). - **TLS Context**: Select the TLS context to use. If you don’t see your TLS context, click **Configure a new TLS Context** to create one. 4. Click **Continue**. 5. Configure the routing strategy: 1. Select a routing strategy: - **Model-based**: Route requests based on the model specified in the request payload. - **Semantic**: Route requests based on semantic analysis of the prompt content. Requires a configured semantic service. Not supported for the Anthropic or Gemini endpoint formats. 6. Configure at least one route: 1. Provide a route name (for example, `Route A`). 2. Click **Add headers** to add routing headers that filter requests by region, SLA, or custom rules. For example, `Region: US` 3. Configure the target: - **Provider**: Select your LLM provider from these options: - **OpenAI** - **Gemini** - **Azure OpenAI** - **Bedrock OpenAI** - **Bedrock Anthropic** - **NVIDIA** - **Anthropic** - **xAI** - **Mistral** - Any custom provider published to Anypoint Exchange. For more information, see [Publishing Custom LLM Providers to Anypoint Exchange](https://docs.mulesoft.com/general/model-proxy-publish-custom-llm-metadata). - **Request model override**: Select a target model to override the model version specified in the payload. Selecting **Use model from request** sends the request to the model specified in the request. A target model is required for semantic routing. - **Destination URL**: Specify the URL for your provider endpoint. Ensure the URL is correct and edit if necessary. 4. Under **TLS Configuration**, click **Add TLS Context** to secure the connection to the provider endpoint with a TLS context. 5. Configure authentication: - **API Key**: Choose one of the following: - **Static**: Use your provider API key. Enter a static API key for the provider endpoint. - **Dynamic**: Retrieve your key dynamically from the request. Define a DataWeave script to extract the API key from the incoming request. - **From vault**: Use a secret stored in an external vault. Select a secret group, then select a secret from that group. For more information, see [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). 7. Click **Add Route** to add additional routes. Complete the previous steps to configure each new route 8. Expand **Advanced Options** and enable **Enable semantic caching** to cache and reuse LLM responses based on semantic similarity. Select a configured semantic caching service from the list. For more information, see [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service). 9. Click **Add Model Proxy**. ## Edit a Model Proxy To edit a Model Proxy: 1. In the navigation pane, select **Model Proxies**. 2. Click the name of the Model Proxy you want to edit. 3. Click **Edit Configuration**. 4. Make the necessary edits. 5. Click **Save Changes**. --- product: Getting Started keywords: quarantine agent, contain rogue agent, kill switch, agent behavioral drift, tool-call abuse detection, token spend anomaly, flag history, reactivate quarantined agent, unauthorized agent actions, agent security monitoring, model proxy policies, mulesoft --- # Detect and Contain Rogue Agents > For the full documentation index, see: https://docs.mulesoft.com/llms.txt As AI agents take on more autonomous work across your organization, a single compromised, misconfigured, or malfunctioning agent can quickly leak sensitive data, take unauthorized actions, or run up costs before anyone notices. Monitor agent traffic from a single location in the enhanced MuleSoft experience to detect anomalous behavior and contain a rogue agent before it causes damage. > [!NOTE] Detecting and containing rogue agents requires Omni Gateway 1.13.5 or later. Detection and containment rely on two policies that work together. Apply both to each model proxy you want to protect: - **Rogue Agent Detection** policy monitors agent traffic and flags risky behavior for your review. - **Agent Kill Switch** policy blocks a flagged agent’s access to the model proxy when you decide to contain it. Both policies identify an agent from the same JSON Web Token (JWT) claims. The identity that Rogue Agent Detection flags is the identity that Agent Kill Switch blocks. Set the **Agent Identity Selector** to the same value in both policies. Key benefits: - Detect anomalous or unauthorized behavior in real time, using built-in detectors and your own custom rules. - Review flagged activity before you act. Quarantine starts only after you review the flagged activity. - Quarantine a rogue agent instantly to stop data leakage, harmful actions, or runaway costs. Quarantine is fully reversible, so you can undo a false positive in seconds. - Meet compliance requirements. The platform logs every action with full attribution. ## Before You Begin Confirm these prerequisites are in place. - You need these API Manager permissions: - API Creator: Create instances - View APIs Configuration: View instances - Edit APIs Configuration: Edit and manage instances - View API Alerts: View API alerts in a specific environment - Manage API Alerts: Manage API alerts in a specific environment - Register each agent you want to monitor with a unique instance name and ID, and link it to its model proxies. This lets flags, logs, and containment actions target the correct agent. - Set up your agents as service identities in your enterprise identity provider (IdP). Configure the IdP to include each agent’s identifier and the identity of the person the agent is acting for in the tokens it issues. - Apply the [JWT Validation](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation) policy to each model proxy you want to protect. JWT Validation publishes the verified claims that Rogue Agent Detection and Agent Kill Switch use to identify the calling agent. ## Enable Agent Monitoring for a Model Proxy Enable monitoring on each model proxy whose agent traffic you want to track. > [!NOTE] The Rogue Agent Detection policy increases token usage. The policy checks each incoming > prompt against the anomaly detection rules to identify rogue or compromised agent behavior. Each > check uses extra inference calls. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. In **Portfolio**, select **Model Proxies**. 3. Select the model proxy you want to monitor. 4. Select **Policies** and then select **+Apply Policy**. 5. Select the **Rogue Agent Detection** policy and click **Next**. 6. Configure the policy settings: 1. In **Agent Identity Selector**, enter a Common Expression Language (CEL) expression that identifies the calling agent from its validated JWT claims, for example, `claims.act.sub`. Use the same selector you configure on the Agent Kill Switch policy so the flagged identity is the one that gets blocked. This field is required. 2. In **User Identifier**, enter a CEL expression that identifies the person the agent is acting for, for example, `claims.email`. This value is recorded for attribution only and does not affect detection. This field is required. 3. Under **Anomalies to Detect**, add at least one rule. For each rule, select an **Anomaly Type** and, optionally, enter a **Detection Prompt**: - **PII Leak** (personally identifiable information), **Privilege Escalation**, and **Prompt Injection** are built-in types with a built-in definition, so a detection prompt is optional. - **Custom** has no built-in definition, so a Custom rule does nothing until you add a detection prompt. > [!NOTE] If you add no rules, the policy forwards every request and detects nothing. 4. In **Deduplication Window (seconds)**, set how long to wait before re-alerting on the same agent, anomaly type, and verdict. The minimum is 60 seconds and the default is 3,600 seconds. This field is required. 5. (Optional) Expand **Advanced Configuration** to customize the **System Evaluation Prompt**. Most deployments don’t need to change this setting. 6. (Optional) Expand **Policy Details** to set: - In **Policy Label**, enter a descriptive name that helps tell this policy apart from other policies in the list. - In **Policy Version**, select the policy template version to apply. - In **Application Conditions**, select **Apply to all requests** or **Apply only to specific resources**. 7. Select **Apply Policy**. Repeat these steps for each model proxy to protect. ## Apply the Agent Kill Switch Policy The Agent Kill Switch policy enforces containment. When you quarantine a flagged agent, this policy blocks that agent’s identity from accessing Model Proxy. Apply it to every model proxy where you want to contain an agent. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. In **Portfolio**, select **Model Proxies**, then select the model proxy to protect. 3. Select **Policies** and then select **+Apply Policy**. 4. Select the **Agent Kill Switch** policy and click **Next**. 5. Configure the policy settings: 1. In **Agent Identity Selector**, enter the same CEL expression you used on the Rogue Agent Detection policy, for example, `claims.act.sub`. The selectors must match so that the identity Rogue Agent Detection flags is the identity this policy blocks. This field is required. 2. (Optional) In **Killed Agent IDs**, enter a comma-separated list of agent identifiers to block. Matching is an exact, character-for-character comparison against the value the Agent Identity Selector resolves. Leave this field empty in normal operation. 3. (Optional) Expand **Policy Details** to set a **Policy Label**, **Policy Version**, and **Application Conditions**. 6. Select **Apply Policy**. Repeat these steps for each model proxy to protect. ## Review and Quarantine a Flagged Agent When an agent is flagged, review its activity and quarantine it if needed. Quarantine stops the agent from acting. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. Navigate to **Governance** > **Security**. The **Security** page shows flagged and reviewed agents from the last 90 days. 3. Select **Needs Review**, then find the flagged agent. 4. Select **Review** to open the agent’s flag history. 5. Review the timeline of detection events, then select an action: - **Quarantine agent** Stops the agent from acting and blocks its access to any model proxy that uses the Agent Kill Switch policy. Confirm in the window to complete this action. - **Clear flags** Dismisses the flags if the activity was legitimate. Confirm in the window to complete this action. - **Cancel** Closes the view with no changes. The agent stays in the review queue. The audit log records the action with the agent instance ID, the user who performed it, and details such as the timestamp and environment. ## Reactivate a Quarantined Agent After you confirm a quarantined agent is safe to return to service, reactivate it. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. Navigate to **Governance** > **Security**. 3. Select **Reviewed** and then find the quarantined agent. 4. Select **Review** to open the agent’s flag history. 5. Select an action: - **Restore Model Access** Returns the agent to service. In the confirmation window, select **Restore Model Access**. - **Close** Closes the view with no changes. The agent stays quarantined. After reactivation, the audit log records the action. ## See Also - [Securing Services in Your Portfolio](https://docs.mulesoft.com/general/exp-securing-services) - [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Controlling LLM Costs in Agent Fabric](https://docs.mulesoft.com/general/af-use-case-cost-management) - [JWT Validation Policy](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation) --- product: Getting Started keywords: enhanced mulesoft experience, learning map, mulesoft training, getting started, mulesoft resources --- # Enhanced MuleSoft Experience > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The enhanced MuleSoft experience helps you manage, optimize, and govern a multi-agent ecosystem from one place. Work with agents, APIs, MCP servers, Model proxies, and gateways as a single portfolio. View asset relationships, apply governance and cost discipline, and act on observability signals instead of working in separate silos. The experience pairs this portfolio view with an in-product assistant to connect integrations, tune configurations, and get answers in context. - Scan platforms and import discovered APIs and agents, then manage scanners in one place. - Register services manually, view services across providers, and create MCP servers and model proxies. - Test APIs and MCP servers in playgrounds without leaving the portfolio. - Govern services with run-time policies, governance strategies, and Akamai risk correlation. - Observe service health and monitor cost, token usage, and dashboards across services and environments. ![](/mulesoft/current/en-us/general/_images/enhanced-experience-pillars.png) The end-to-end journey for the experience consists of these tasks, each with links to relevant content to assist you in completing them.

Test Services in Playgrounds

Test APIs and MCP servers in playgrounds without leaving the portfolio.

Apply Governance Rules and Policies

Monitor and enforce policies, block noncompliant activity, and connect your existing Akamai account to protect services.

Connect to External Systems

Connect the enhanced experience to Slack and Claude Desktop.

## See Also - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience and Anypoint Platform Comparison](https://docs.mulesoft.com/general/exp-compare) - [Troubleshoot the Enhanced Experience](https://docs.mulesoft.com/general/exp-troubleshoot) - [Troubleshoot the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-troubleshoot) --- product: Getting Started keywords: enhanced mulesoft experience, anypoint platform comparison, task management, platform benefits, mulesoft migration, platform differences --- # Enhanced MuleSoft Experience and Anypoint Platform Comparison > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Both the enhanced MuleSoft experience and Anypoint Platform include robust capabilities, but they emphasize different strengths, especially if you manage AI services such as agents, Model proxies, and MCP servers next to APIs and gateways. Adopting the new experience gives you a fuller way to manage and optimize AI services, with the flexibility and governance modern AI-driven environments need. You configure AI policies and map relationships among services faster and more seamlessly in the new experience because the UI targets that portfolio. The enhanced experience is especially useful when AI is central to your strategy. You still rely on Anypoint Platform for API and integration work, such as designing and evolving specifications, implementing and testing Mule apps in Anypoint Code Builder or Anypoint Studio, running CI/CD, deploying to runtimes such as CloudHub or Runtime Fabric, and using **Exchange** and **API Manager** for publishing, deep lifecycle policy, and runtime management. ## Benefits of Adopting the Experience Unified Relationships Across Entity Types **Overview** and graph-style context show how agents, MCP servers, Model proxies, APIs, and gateways connect. You can reason about dependencies and impact more easily than when each silo lives only in its legacy console. Governance Framed for AI as Well as APIs You apply and review governance across domains such as access and security, performance and cost, data privacy and integrity, and compliance and observability, aligned to the asset you’re viewing. Policy and conformance work stays adjacent to the asset instead of only in a separate API-only mental model. Cost and Usage Signals for AI Operations The experience includes cost management tooling aimed at portfolio spend, including visibility into token usage and optimization strategies for MCP servers and related AI paths. Use it when you need instance-level usage context tied to the same catalog as the rest of the portfolio. Instance-Level Policy Control For instances backed by Omni Gateway where the product supports it, the experience elevates instance-level governance, including options to tune policy order and draw from a named policy catalog. Use the enhanced experience when you need fine-grained control in the portfolio UI, and use the deeper runtime-only workflows in Anypoint Platform when the experience links you there. Provider Breadth for AI Connections **Platform** includes **Providers** and related configuration so the experience can connect AI and integration services across multiple vendors, such as AWS Bedrock and Google Vertex AI, in addition to your existing MuleSoft footprint. The same **Providers** area connects external vaults (AWS Secrets Manager, Microsoft Azure Key Vault, and HashiCorp Vault), so credentials stay in your existing secrets manager instead of in your MuleSoft configuration. The interface supports multi-vendor AI stacks without forcing each vendor’s console to be your only view. Managed and Unmanaged Instances The experience supports creating managed instances on Omni Gateway when you want full support paths including authentication and monitoring, or unmanaged-style instances when you want a lighter footprint. Select the model per asset and gateway strategy. Assistant Across the Portfolio The in-product MuleSoft Agent assistant targets setup, questions, and recommendations across the services the experience tracks. The classic Anypoint Platform control plane doesn’t provide that same assistant-led experience. ## Task Management by Platform The enhanced MuleSoft experience and Anypoint Platform each offer distinct capabilities that can guide where you perform different tasks. Understanding each platform’s strengths helps you pick the right environment and still combine tools when a workflow spans both.
TaskPreferred ExperienceWhyExample for Dual Use

API design and documentation

Anypoint Platform

Anypoint Platform offers powerful tools like Anypoint Code Builder for crafting APIs with RAML or OAS and publishing detailed documentation.

To cross-reference API design with governance policies established in the enhanced experience, add your API to the enhanced experience portfolio, then open the asset to review its compliance details alongside the design. See Adding Services to Your Portfolio.

Policy enforcement and governance

Enhanced MuleSoft experience

The new experience excels in applying and managing governance policies across agents, APIs, and other services with detailed compliance tracking and reporting features.

Use Anypoint Platform for initial policy setup when launching a new API. Use the new experience for ongoing monitoring and adjustment to make sure policies remain effective and compliant.

Integration development

Anypoint Platform

Anypoint Code Builder is specifically designed for developing integrations and flows, offering seamless tools for connecting systems and designing workflows.

If an integration involves workflows managed by multiple AI agents, start in Anypoint Platform and then use the new experience to make sure each agent complies with integration standards.

Multi-agent ecosystem management

Enhanced MuleSoft experience

The new experience monitors and optimizes interactions between AI agents to maintain cohesive operation across the ecosystem.

Conduct initial API integration testing in Anypoint Platform to verify functionality, then switch to the new experience for monitoring agents that interact with those APIs.

Cost and performance optimization

Enhanced MuleSoft experience

The new experience provides cost management, token usage tracking, and performance metrics across agents, APIs, MCP servers, and related services in the portfolio.

Use Anypoint Platform to initially monitor API performance under load during development, and use the new experience for ongoing cost optimization after APIs are in full production.

Runtime application management

Anypoint Platform

Use Anypoint Runtime Manager to deploy, manage, and monitor Mule applications during runtime operations.

Deploy applications via Anypoint Platform to leverage its runtime monitoring, then switch to the new experience for broader operational oversight involving governance and policy application across running services.

## See Also - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) --- product: Getting Started keywords: enhanced mulesoft experience, glossary, terminology, definitions, mulesoft platform, key terms --- # Enhanced MuleSoft Experience Glossary > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The enhanced MuleSoft experience uses a consistent set of terms across governance, portfolio, instance management, and agentic experiences. Clear definitions help you apply the right concepts when registering assets, configuring strategies, and managing instances. A2A bridge An A2A-compliant protocol server that presents an A2A facade in front of a non-A2A _source agent_. Implemented as a chain of policies running on an Omni Gateway instance, it translates between the A2A protocol and the agent’s native protocol and manages the A2A task lifecycle. Create an A2A bridge to make agents built on platforms such as Salesforce Agentforce discoverable, governable, and orchestratable by Agent Fabric. See [Make an Agent A2A-Compliant](https://docs.mulesoft.com/general/exp-services-create-a2a-bridge). A2A Bridge card The A2A agent card that a bridge publishes. It’s derived from the source agent’s card plus any capabilities added by the bridge and any customizations you make. Bridge capabilities are set and locked by the platform so the card can’t advertise a capability the bridge can’t honor. A2A endpoint An endpoint that exposes an agent’s capabilities using the Agent-to-Agent (A2A) protocol. Point to an A2A endpoint during agent registration to fetch the agent card automatically. Agent An AI-powered service registered in the Agents catalog. Agents connect via A2A endpoints or agent cards and support governance, policy application, and instance management in the enhanced experience. Agent card A metadata file that describes an agent’s capabilities, endpoint, and connection details. Upload an agent card during manual registration, or point to an A2A endpoint to fetch one automatically. Akamai security findings Security issues detected by Akamai API Security through live traffic inspection and surfaced in the **Conformance** tab of a governance strategy alongside governance rule results. Critical and High findings map to violations, Medium to warnings, and Low and Info to informational findings. Select a finding to view remediation opportunities and apply a policy directly from the detail panel. API A service defined by a formal specification and managed in the APIs catalog. Supports REST (OAS, RAML), gRPC (Proto), and AsyncAPI formats. Register APIs manually with a spec file or import them via provider scanners. MuleSoft Agent The embedded agentic experience built into the enhanced MuleSoft experience UI. Use MuleSoft Agent for setup guidance, portfolio questions, and recommendations without leaving the product. Conformance Report A view on the detail pages of agents, APIs, and MCP servers that shows compliance scores, rule violations, and warnings that applied governance strategies generate. Cross-gateway conformance A unified view of compliance status across APIs hosted on Anypoint Platform gateways and connected third-party provider gateways. Access cross-gateway conformance from the **Governed Services** tab of an active governance strategy. Use the **Any provider** filter to compare conformance by platform or focus on a specific provider. Enhanced experience The new MuleSoft UI for managing your AI portfolio, including governance, instance management, observability, and agentic experiences. External gateway provider A third-party API gateway connected through a provider scanner whose policies you can manage from Anypoint. Supported providers include Google Apigee, Azure API Management, and Kong Gateway, with partial support for Amazon API Gateway. Policy management reuses the scanner connection’s credentials. External vault A connection to your cloud secrets manager (AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault) configured under **Platform** > **Providers**. MuleSoft stores only secret metadata, such as names and paths, and resolves values from the vault when needed. Secret values are never stored, displayed, or logged. See [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). Gateway A runtime component that proxies traffic to backend services while enforcing policies. Supported types include Anypoint Omni Gateway (managed), external gateways, and unmanaged gateways. Injection point Where a policy runs relative to the request and response (for example request or response on Apigee, or inbound, outbound, and backend on Azure API Management). Each policy template declares which injection points it allows. Governance > Cost Management A section under Governance that surfaces token usage, daily spend signals, and cost optimization recommendations across your portfolio. Apply tool mapping, tool sanitization, and related strategies here where the experience supports them. Governance > Coverage A view that shows which services and instances have active governance strategies and which governance domains they cover. Coverage identifies gaps where services operate without policy or compliance oversight. Governance > Governance Strategies A section under Governance for configuring and managing strategies that monitor, report, enforce, and block noncompliant activity across your services. Governance > Security The domain of policies and controls that protect who can access and call your services. Governance Strategy A bundled set of design-time and runtime rules that enforce a governance posture across targeted services. Governance strategies connect policy intent to conformance reporting, cost management, and runtime behavior. Governance Strategy > Controls Design-time rules that validate services against selected rule sets and generate conformance reports. Apply controls as part of a governance strategy to optionally block noncompliant actions. Governance Strategy > Automated Policies Runtime rules that govern traffic passing through service instances. Policies control access, data handling, rate limits, and other runtime behaviors defined in a governance strategy. Instance A deployed version of a service on a specific gateway or runtime. Instances receive traffic on the Instance URL and proxy requests to the Target URL. Supported service types include APIs, agents, MCP servers, and Model proxies. Model Proxy A gateway-backed service that routes requests to a large language model. Model proxies register in the Model Proxies catalog and support instance management, policy application, and token usage monitoring. Managed instance An instance backed by Anypoint Omni Gateway that enables full policy enforcement, authentication, and monitoring integration. Managed instances provide stronger governance and observability than unmanaged paths. MCP Server A server that implements the Model Context Protocol, exposing tools and resources to MCP clients. Create MCP servers from existing APIs, register them manually with an MCP URL or schema file, or import them via provider scanners. MuleSoft Agent The agentic experience for MuleSoft available in Slack. Use the MuleSoft Agent to receive notifications, run shortcuts, and navigate back into the enhanced experience from your messaging workspace. Observability A section that aggregates org-wide dashboards, reports, and notifications when your administrator enables and connects the observability backend for your business group. Use Observability to compare service-level monitoring signals with broader traffic patterns. Platform MCP Server The MCP server that exposes enhanced MuleSoft experience capabilities to MCP clients such as Claude Desktop. Use Platform MCP Server to access portfolio and governance features from supported development environments. Portfolio The set of services registered or discovered within your org, organized into catalogs for agents, APIs, MCP servers, Model proxies, and gateways. Each catalog provides governance, monitoring, and instance management for the services it contains. Providers The external cloud platforms connected to the enhanced experience to enable automated service discovery and import, or to connect an external vault. Configure providers under **Platform** > **Providers**. Scanner A configured connection between the enhanced experience and a supported cloud provider. When a scanner runs, it discovers services and registers them in the matching Portfolio catalog. Scanners run on a schedule or on demand. A scanner is distinct from an external vault, which syncs secret metadata rather than discovering services. Secret A credential stored in your external vault, such as an API key. The enhanced experience tracks secret metadata (name, path, usage, and last-rotated time) and can reference a secret from a model proxy’s authentication configuration, so keys stay in your secrets manager. See [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). Slackbot The native Slack assistant that connects to the MuleSoft Platform MCP Server to answer questions about the MuleSoft platform from within Slack. After installing the MuleSoft for Slack app, open Slackbot and connect it through **Integrations**. Slackbot is separate from the MuleSoft Agent, which handles management tasks and notifications. Semantic Service A service that applies context-aware matching to route LLM-driven requests to the most relevant tools and pathways. It’s available at Basic scale (managed internal configuration) or Advanced scale (external embedding API and vector database). Source agent An existing agent, built on a platform that isn’t natively A2A-compliant, that you make A2A-compliant by creating an _A2A bridge_ in front of it. The bridge derives its A2A card from the source agent without modifying the source agent. Target The backend implementation that a gateway proxies traffic to after enforcing policies. Each instance defines a Target URL that points to the live service or runtime. Tool mapping A governance control that defines which tools an LLM or agent can invoke. Apply tool mapping to reduce token spend and limit exposure to unintended operations. Tool sanitization A governance control that filters or modifies tool inputs and outputs before they reach a model or service. Apply tool sanitization to reduce risk and cost for LLM-backed services. 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. 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 open-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled. --- product: Getting Started keywords: enhanced mulesoft experience, enhanced experience, capabilities, workflow, mulesoft overview, experience features --- # Enhanced MuleSoft Experience Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To grow and tune your AI portfolio, register and monitor agents, APIs, and gateways in centralized catalogs. Sign in through the entry point your organization provides, such as Anypoint Platform or a direct URL, to access dashboards and governance strategies based on your assigned permissions. Review live performance metrics, manage security policies, and track rule-level compliance through automated conformance reports. Your AI services stay audit-ready with clear visibility into cost and runtime health across your org. ## Enhanced Experience Capabilities The enhanced MuleSoft experience supports the full lifecycle of AI-connected integration services: Entity Management Register and manage agents, REST and GraphQL APIs, MCP servers, Model proxies, and gateways, including Anypoint Omni Gateway, external gateways, and unmanaged gateways. Each type has a dedicated catalog under **Portfolio**. Governance and Compliance Define and apply policies across domains such as access and security, performance and cost, data privacy and integrity, and compliance and observability. For connected third-party API gateways (Azure API Management, Google Apigee, and Kong Gateway), apply, enable, disable, and remove policies directly from Anypoint through policy write, with no Omni Gateway in the request path. Conformance reporting summarizes rule violations and severity so you can close gaps systematically. Cost and Performance Optimization Monitor token usage, per-instance signals, and daily cost where the product exposes them. Apply governance strategies and related controls, such as tool mapping and tool sanitization, to reduce spend and risk where the experience supports them. Instance Management Create and review instances for supported asset types. Choose managed paths through Omni Gateway when you need deeper monitoring and policy enforcement, or choose lighter models when that matches your operating model. Credential and Secrets Management Connect an external vault (AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault) under **Platform** > **Providers** so credentials stay in your existing secrets manager. MuleSoft stores only secret metadata and resolves values from the vault when needed, and a model proxy can reference a vault secret instead of storing a key. See [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). MuleSoft Agent (AI assistant) Get help navigating, searching, and managing your portfolio through natural language conversations. The AI assistant provides context-aware guidance, performs actions with your confirmation, and suggests next steps based on your current task. Available from every page in the enhanced experience. ## Enhanced Experience High-Level Workflow To manage and tune your AI portfolio, register services, apply security policies, and monitor runtime health, access centralized catalogs to track agents and gateways while verifying compliance through conformance reports and cost management tools. These integrated features help you optimize performance and maintain audit readiness across your environment. 1. Complete onboarding and access the enhanced experience. Confirm your credentials and the permissions that your administrator assigned, as described in [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). Finish integration setup for supporting systems, such as connected providers under **Platform** > **Providers**, before you rely on the experience in production. For onboarding details, see [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start). 2. Learn the layout of the enhanced experience. Sign in through your entry path and land on **Home**. Scan **Portfolio** catalogs, **Governance**, **Observability**, and **Platform** so that you know where to register services, apply policies, read health signals, and manage providers. For more information about portfolio views, see [View Your Portfolio Overview](https://docs.mulesoft.com/general/exp-portfolio-overview). For AI assistant usage, see [Using the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-use). 3. Register services in **Portfolio**. Under **Portfolio**, open **Agents**, **MCP Servers**, **Model Proxies**, **APIs**, or **Gateways**. Add services to work with. Register them manually or use connected providers under **Platform** > **Providers** if your organization enables discovery flows. For registration methods, see [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio). 4. Create and manage instances. In **Portfolio**, open a service detail page from **Agents**, **MCP Servers**, **Model Proxies**, or **APIs**, then open the **Instances** tab to create managed or unmanaged deployments that match your needs. Managed instances on Omni Gateway give stronger governance and monitoring when the new experience exposes them. **Gateways** don’t include an **Instances** tab on their detail page. For instance workflows, see [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add). 5. Configure policies. On a service detail page in **Portfolio**, open the **Policies** tab for the service or one of its instances to apply governance policies that match access control, data privacy, performance, and compliance goals. For APIs discovered from third-party gateways, applying policies requires a scanner connection whose credentials carry the provider’s write scope; see [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). Use top-level **Governance** for gateway-wide policy work, organization strategies, and cost tools. For governance policy workflows, see [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies). 6. Review compliance. In **Portfolio**, open a service detail page from **Agents**, **APIs**, or **MCP Servers**, then open the **Conformance Report** tab to review scores, violations, and warnings and address the findings your governance team prioritizes. For gateways, use top-level **Governance** for the same compliance story at the scope the experience supports. For service-level tabs and conformance context, see [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). 7. Monitor runtime health. On a service detail page in **Portfolio** (**Agents**, **APIs**, **MCP Servers**, or **Model Proxies**), open the **Monitoring** tab to review live metrics such as latency, error rates, and request volume when the new experience surfaces Omni Gateway data for managed paths. Compare those service-level metrics with dashboards, reports, or notifications under top-level **Observability** when your administrator enabled those views for your team. For monitoring workflows, see [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring). 8. Manage costs. Under **Governance**, open **Cost Management** to study token usage and related spend signals. Apply the cost reduction strategies your organization adopted, such as tool mapping or tool sanitization, where the new experience supports them. For cost and token usage details, see [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage). 9. Operate and tune the portfolio. Coordinate agents, APIs, gateways, MCP servers, and Model proxies so traffic, policies, and integrations stay aligned. Open **Versions** when you need configuration history before you change instances or policies. Adjust policies, instances, or registrations when monitoring and governance insights show drift or new risk. For service detail workflows, see [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). 10. Improve on each cycle. Feed findings from monitoring and governance back into planning for the next change window. For strategy refinement workflows, see [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies). ## See Also - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience and Anypoint Platform Comparison](https://docs.mulesoft.com/general/exp-compare) - [Enhanced MuleSoft Experience](https://docs.mulesoft.com/general/learning-map-exp) --- product: Getting Started keywords: experience hub release notes, api experience hub, new features, bug fixes, known issues, version history, mulesoft experience hub --- # Enhanced MuleSoft Experience Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The enhanced MuleSoft experience is a unified workspace for managing, governing, and monitoring AI-connected integration assets, including agents, APIs, Model Context Protocol (MCP) servers, model proxies, and gateways. Teams use it to register services, apply governance strategies, monitor runtime health, and optimize costs from one portfolio view instead of working across disconnected tools. ## October 22, 2026 ### What’s New #### Features - You can now monitor traffic through Omni Gateway by applying the Akamai API Security (Omni Gateway) policy to your API instances. This traffic includes: - Internal traffic between services (east-west traffic). - External traffic to endpoints you can’t register at the Akamai edge, such as MuleSoft-managed CloudHub endpoints. For more information, see [Monitor Traffic Through Omni Gateway](https://docs.mulesoft.com/general/exp-akamai-risk-correlation#monitor-traffic-through-omni-gateway). - When you apply an Amazon API Gateway policy from agentic tools through the Platform MCP server, you can now scope it to a path, an HTTP method, or an operation, which combines a path and a method. The agent shows the scopes that the policy supports and asks which scope and target you want. The policy details it returns now include the scope each policy applies to. #### Enhancements - The **Review** step of the governance strategy **Create Policy** wizard now tells you when a policy supports more granular scopes, which you can select in the instance-level policy experience. - MuleSoft Agent now returns catalog and governance assets from child business groups for users in the root business group. - MuleSoft Agent in Slack and Microsoft Teams now takes fewer steps to answer, so responses arrive faster. In Microsoft Teams, answers now appear as they’re generated instead of all at once. - MuleSoft Agent in Slack and Microsoft Teams now supports GraphQL and the additional tools available in the embedded MuleSoft Agent. - Third-party libraries are upgraded to address reported security vulnerabilities. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

Agent detail pages no longer show Unknown in the Updated field.

W-23016618

The advanced options for policies that you apply to agents and MCP servers no longer include the option to apply the policy conditionally by HTTP method.

W-23267358

MuleSoft Agent now returns catalog and governance assets from child business groups for users in the root business group.

W-23926623

The See Benchmark view on the Optimizations tab now shows an indicator for additional models.

W-23953679

Users who don’t have access to Cost Management now see a permission message instead of a "No LLM proxies found for the selected filters" message.

W-23983310

Optimization cards now show the See Benchmark link and the Why this policy section, and show potential savings in dollars per month instead of tokens.

W-23998776

Searching model proxies on the Optimizations tab now matches instance IDs in addition to names.

W-24010016

The submit button on policy forms in the Platform MCP server now reads Apply policy instead of Request policy creation.

W-24027218

MuleSoft Agent in Slack and Microsoft Teams now tells you when it can’t find data instead of showing an empty card.

W-24105572

A2A policies now appear in the policy catalog for A2A v1.0 agent instances, so you can apply policies such as A2A Token Based Rate Limit.

W-24119017

The MuleSoft Agent welcome message in Microsoft Teams no longer appears twice when you add the agent to a channel or direct message.

W-24135116

The error message that appears when a user who isn’t an Anypoint Platform administrator grants access permissions is now clearer.

W-24159946

Assets discovered by scanners no longer appear as managed instances with options to apply policies or as deployed to the Production environment.

W-24276575

The Security tab now shows data from all environments instead of only the default environment.

W-24366135

Third-party libraries are updated to resolve reported security vulnerabilities.

W-24505378

## October 14, 2026 ### What’s New #### Features - You can now create a ServiceNow AI agent scanner to discover agents from ServiceNow. - You can now create a Kong Gateway scanner to discover MCP servers from Kong Gateway. - You can now use OAuth 2.0 Authorization Code for Google Vertex AI scanners to create, authorize, and test the provider connection before you continue scanner setup. For more information, see [Scanner OAuth Authorization](https://docs.mulesoft.com/general/exp-scanners-add-from-providers#scanner-oauth-authorization). - You can now apply open policies at the path, operation, or HTTP method level for providers that require a finer scope than the API instance, such as Amazon API Gateway. When an open policy maps to more than one native policy, the **Review** step tells you, and the policy list shows the path or operation that each policy applies to. - The Platform MCP server now includes tools to apply open policies and to apply and edit native policies from agentic tools, such as Claude and Cursor. A new skill guides agents through applying an open policy. - You can now register remote MCP servers that require browser-based OAuth 2.1 Authorization Code with PKCE authentication. - You can now publish a custom LLM provider to Anypoint Exchange as an `llm-metadata.json` classifier asset and select it as the provider for a model proxy route. For more information, see [Publishing Custom LLM Providers to Anypoint Exchange](https://docs.mulesoft.com/general/model-proxy-publish-custom-llm-metadata). #### Enhancements - Policy configuration forms now support conditional fields and mutually exclusive configuration options, such as the signing key length in JWT Validation and the JWKS source in Apigee Verify JWT. - The **Configure Policy** step of the governance strategy **Create Policy** wizard now shows the providers that support the selected open policy. - Policy validation errors now appear in Spanish when the UI language is Spanish. - Dropdowns now support type-ahead search, so you can quickly find items in long lists, such as AWS regions. - The **Session Token** field is now available for Amazon Bedrock routes in dynamic mode, so callers that use short-lived AWS credentials can route requests through a model proxy. - MuleSoft Agent in Microsoft Teams now shows the same loading, authentication, and error messages as in Slack, and suggests follow-up actions after each answer. - MuleSoft Agent now responds faster in Slack and Microsoft Teams. - The MuleSoft bot is now added to a Microsoft Teams channel automatically when you select the channel, and the bot name now includes the region, such as **MuleSoft (EU)**. - Instance detail, gateway, and policy template pages load faster. #### Changes - Universal policies are renamed to open policies, and the **Omni & MuleSoft** badge for advanced policies is renamed to **Omni & Mule Gateway**. - The **Policies** tab and activity log no longer appear for MCP server and agent instances that are managed by third-party gateways, such as Azure API Management or Amazon API Gateway, because applying policies isn’t supported for these providers. Previously, the tab showed an **Apply Policy** button that returned an error. - Azure OpenAI no longer appears as a provider option when you create a semantic service, because it isn’t supported. - The welcome dialog now reflects the Agent Fabric brand. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

Public MuleSoft catalog assets no longer show a Not Validated conformance badge.

W-22108561

The create_omni_gateway MCP tool now marks runtimeVersion as required, so requests no longer fail with a 400 error.

W-22624722

The Gateways page no longer lists a self-managed gateway that doesn’t exist in Anypoint Platform.

W-22732162

The view_api_instance_policies MCP app now shows the name of the API instance whose policies it displays.

W-22831480

Filters on portfolio pages now narrow results consistently.

W-22848133

Governance strategies created with the prepare_automated_policy_creation MCP tool now appear in your organization’s governance strategies list.

W-22854736

Agent detail pages no longer show an unknown environment.

W-23017333

The list_governance_strategies MCP tool now labels controls as controls instead of guardrails.

W-23059789

MuleSoft Agent in Slack and Microsoft Teams now sends each response as one message instead of several messages.

W-23553477

Creating a Trusted MCP server through MuleSoft Agent in Slack no longer fails at gateway selection.

W-23640564

Installing the Slack app now succeeds for organizations that have an orphaned Slack connection.

W-23756773

Custom asset icons now appear in the portfolio catalog, not only on the asset detail page.

W-23815011

Adding or removing a model proxy route no longer resets the client identifier configuration in the LLM Proxy Core policy, so token tracking continues to work.

W-23824232, W-24138884

The Amount Saved card on the agent dashboard now includes only request compression savings.

W-23943885

The Saved column on the MCP Servers tab of the Optimizations page now shows a trend indicator.

W-23954561

The applied policy count for Payload Optimization now updates after you apply a subpolicy.

W-23955262

The MCP Servers tab on the Optimizations page now paginates results when there are more than 10 MCP servers.

W-23955499

API instance names on Cost Management opportunity cards now appear as links.

W-23974322

Bulk update failure messages for alerts are now shorter.

W-23980698

Selecting the MuleSoft logo in the navigation sidebar now opens the home page.

W-23997715

MCP clients no longer need the full OAuth scope to connect to the MCP server.

W-24006913

You can now use the keyboard to navigate table rows.

W-24015335

A provisioning failure banner no longer appears for a Trusted MCP server that provisioned successfully after a retry.

W-24046223

Editing a disabled open policy on a MuleSoft API instance now shows the saved configuration instead of empty fields.

W-24079553

The consumer endpoint of a model proxy is now always editable, and the port is editable on self-managed gateways and limited to 8081 or 8082 on managed gateways.

W-24087973

The model proxy configuration summary now shows the environment name instead of the environment type, and shows the input format.

W-24104747

Users who aren’t organization administrators can now select a model when configuring a model proxy fallback route.

W-24117065

Saving a model wallet that contains an Amazon Bedrock budget no longer fails with a "model isn’t recognized" error.

W-24119805

The cost and tokens toggle on the Optimizations tab now works without first using it on the Budgets tab.

W-24149250

MCP Bridge now recognizes roles that are assigned through teams when checking permissions.

W-24156034

The Performance page now loads available data when an optional query fails, instead of failing to load entirely.

W-24178872

Users who have the documented API Manager permissions can now create a model proxy without the Organization Administrator role.

W-24194029

Policy configuration fields that accept multiple values no longer split values that contain commas, such as Cedar rules in Attribute-Based Access Control.

W-24198588

Creating an automated policy for A2A v1 agents no longer fails with an "Invalid endpoint types" error.

W-24198627

MuleSoft Agent responses in Microsoft Teams no longer refer to Slack.

W-24215212

Model names now appear when users who have the documented permissions create model wallet budgets or configure model-based routing.

W-24247083

Model detail pages now list model wallets from all environments instead of only the default environment.

W-24254296

Numeric policy fields with fractional steps now show rounded values, such as 0.84, instead of values such as 0.8099999999999999.

W-24255976

Selecting View Optimization in the opportunities carousel now updates the page URL.

W-24269008

Logging in after a session times out no longer fails with an "Invalid OAuth state" error.

W-24276489

You can now edit AWS Signature Injection policies without field errors.

W-24276857

Selecting a model wallet on the Budgets tab now opens the wallet in its own environment.

W-24280601

The Request model override field is now optional for model-based and semantic routing.

W-24313182

An IP address validation error no longer remains after you replace an invalid IP address with a valid one in policy configuration.

W-24359644

Editing a policy on a model proxy route now opens the configuration for that route when more than one route has the same policy.

W-24360920

Model proxies that use the Gemini format now handle streaming responses correctly.

W-24363980

Model proxy descriptions are now limited to 256 characters to match Exchange, so creating a model proxy with a longer description no longer fails.

W-24377785

New model proxy routes no longer show NVIDIA as the provider when you haven’t selected one.

W-24387103

Model proxies with OpenAI and Mistral routes now save without a duplicated routing headers error.

W-24387105

Semantic routing is no longer available for model proxies that use the Anthropic or Gemini input format, because it isn’t supported for these formats.

W-24392230

Creating a model proxy with an Amazon Bedrock OpenAI route no longer fails with a 400 error.

W-24424271

Selecting a self-managed Omni Gateway when editing a model proxy no longer shows an endpoint retrieval error that blocks saving.

W-24440299

## September 28, 2026 ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

MuleSoft Agent responses are no longer truncated mid-sentence.

W-22511562

Third-party libraries are updated to resolve reported security vulnerabilities.

W-23323287

The Updated field on service and instance detail pages now uses the canonical Platform API timestamps instead of deployment or audit fallbacks.

W-23817531

The enhanced experience now loads after you select Go to enhanced experience.

W-23909031

The MuleSoft Agent now returns a response instead of failing to reply.

W-23926482

The agent chat no longer renders a blank turn when the LLM gateway returns a 5xx error mid-answer.

W-23942921

The MuleSoft Agent now calls the correct backend tool.

W-23973420

The Optimizations column now shows the correct number of applied optimizations.

W-24010562

Applying a policy through the Platform MCP server now succeeds instead of failing with a "policy apply failed (unknown)" error.

W-24027214

Payload compression savings now appear in Cost Management even when JWT client ID validation is skipped, so the Amount Saved and ROI dashboards no longer report zero savings.

W-24028032

The Playground now applies manually configured authentication, including API Key, Bearer, Basic, and OAuth 2.0, to outgoing requests when the API spec doesn’t declare a security scheme.

W-24061141

The Agents modal chart now loads data instead of appearing empty.

W-24091631

The Token Usage & Response Time chart now shows estimated usage without optimization separately from tokens used, so savings are visible.

W-24100260

Cost Management entitlement gating is now consistent with the Model Proxy backend fallback, so entitled customers are no longer blocked.

W-24128912

The Total Managed Spend, Total Spend on Agents, and Potential Savings values on the Optimization page now roll up correctly into the millions.

W-24149371

Policy descriptions for the Tool Mapping, MCP Tools Progressive Disclosure, and Request Compression policies no longer contain typos and grammar errors.

W-24160887

The Cost Management tab on an agent’s detail page now shows the correct optimization policy count and format.

W-24161316

The Policy Violation Count graph on the Performance tab now displays data.

W-24216820

Drill-downs on the Performance page now return data even when the environment filter isn’t selected.

W-24250463

## September 7, 2026 ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

Installing the Slack app now succeeds when a previous session wasn’t cleared, instead of failing.

W-23754100

Policy templates no longer return a proxy error.

W-23836725

The Cost Management tab no longer renders blank.

W-24007593

The policy-count column label is now consistent across the agent, model proxy, and MCP server dashboards.

W-24021273

Applying agent optimization policies from the Optimizations tab in Ask MuleSoft no longer fails silently.

W-24026346

Applying the MCP Tools Progressive Disclosure optimization policy in Ask MuleSoft no longer gets stuck in a loop.

W-24027064

Managing model wallets through the MuleSoft Agent no longer requires you to provide an environment ID.

W-24027144

Model wallets now appear in the model proxy route editor for organizations that have more than one environment.

W-24043182

The Tokens Saved column on the model proxy Optimizations tab now shows actual values instead of always showing 0.

W-24054184

Budget Management now includes an environment switcher, so you can view budgets across all your environments instead of only one.

W-24060216

The Organizations filter on the MCP server and agent catalogs now shows the correct count and pagination, applies the expected checkbox behavior, and no longer shows a stale empty state when you open it from a deep link.

W-24063692

## August 31, 2026 ### What’s New #### Features - You can now connect the enhanced experience to AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault so API keys and other credentials stay in your secrets manager. MuleSoft stores only metadata, such as secret names and paths, not the secret values. It reads the secret from your vault when a model proxy or other service needs it. For more information, see [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). - You can now contain a rogue AI agent before it leaks data, takes unauthorized actions, or runs up costs. Stop that agent’s requests from reaching your models, then restore access if the containment was a false positive. For more information, see [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents). - Cost Management now includes budget management. Set spending budgets for your model wallets, track spend against each budget, and manage budgets across providers and models from the **Budgets** tab. For more information, see [Budgets Tab](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage#budgets-tab). - The Cost Management **Optimizations** page now includes an **Agents** tab, so you can review token usage and optimization opportunities for your agents alongside model proxies and MCP servers. For more information, see [Filter and Search](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage#filter-and-search). - You can now create, edit, delete, and list model wallets, which allocate token budgets that are granted only when a request’s claims match the wallet’s required claims. Manage model wallets from the UI or through the MuleSoft Agent. For more information, see [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage). - You can now edit instances for model proxies, APIs, agents, and MCP servers from the service detail page or the instance detail page, without switching to Anypoint Platform. - Model Proxy now supports semantic caching, TLS security for provider connections, external vault–based provider authentication, and the Model Proxy Request Compression policy. For more details about updates to model proxy, see [Model Proxy Release Notes](https://docs.mulesoft.com/release-notes/gateway/model-proxy-release-notes). - MCP Bridge now exposes tool output schemas as part of the MCP specification, so you can connect servers built with MCP Bridge to Agentforce. - These SaaS connectors are now available in the Trusted MCP catalog: Wix, WordPress.com, Hootsuite, Descript, Intercom, Front, and LiveChat. - You can now create an A2A bridge to make a non-A2A agent A2A-compliant so that Agent Fabric can discover, govern, and orchestrate it alongside native A2A agents. For more information, see [Make an Agent A2A-Compliant](https://docs.mulesoft.com/general/exp-services-create-a2a-bridge) - You can now use OAuth 2.0 Authorization Code for Microsoft Copilot Studio scanners to create, authorize, and test the provider connection before you continue scanner setup. For more information, see [Microsoft Copilot Studio OAuth Authorization](https://docs.mulesoft.com/general/exp-scanners-add-from-providers#microsoft-copilot-studio-oauth-authorization). - You can now apply universal policies to your API instances and manage the resulting native policies. A universal policy is defined once and applied as the correct native policy on each supported gateway. For more information, see: - [Apply Open Policies](https://docs.mulesoft.com/general/exp-governance-policy-library-apply) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - API scanners now write policies from these provider platforms: Google Apigee, Azure API Management, and Kong Gateway. For these providers, policy results are visible from each discovered API in Portfolio > APIs > Policies. For more information, see: - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference) - [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - You can now track remediation and scan status in the **Akamai Security Findings** table on the **Conformance** tab. For more information, see [Track Remediation and Scan Status](https://docs.mulesoft.com/general/exp-akamai-risk-correlation#track-remediation-and-scan-status). #### Enhancements - Cost Management optimization for MCP servers now includes policy recommendation cards with an **Apply** action, a sortable potential-savings column, savings framed in dollars per month, applied policies grouped by category, and a benchmark of the top MCP servers across the top models. - The **Optimizations** and **Budgets** dashboards now include a toggle to switch between dollar and token views. - MCP Bridge overview pages now group tools by the source API they were generated from, with a link to each API’s Exchange page. - MCP Bridge tool editing now includes a resource filter and instance-type badges, and you can add a TLS context and customize HTTP request mappings on a deployed MCP server. - You can now configure inbound and outbound TLS contexts when you create or modify an MCP Bridge, and Model Proxy now supports TLS context configuration for upstream connections. - You can now edit a model proxy’s deployment configuration inline, including its base path, gateway target, and consumer endpoint, with a warning when a change requires redeployment. - The Portfolio **Filters** menu now includes an **Organizations** group, so you can narrow the catalog to specific business groups and hide public MuleSoft catalog assets. - MuleSoft for Teams is now available as a limited availability feature. Install the MuleSoft for Teams app to interact with MuleSoft directly from your Microsoft Teams tenant, receive platform alerts in channels, and use MuleSoft Agent to list APIs, view MCP servers, check governance, and perform other management tasks. To request access, contact your account executive. For more information, see [Integrate the Enhanced Experience with Microsoft Teams](https://docs.mulesoft.com/general/exp-teams-integrate). - The MuleSoft app for Microsoft Teams is now available in additional regions. - The MuleSoft Agent in Slack and Microsoft Teams now uses a refreshed set of cards for listing and viewing services, instances, and policies, and for applying a policy. - You can now filter your alerts and bulk-assign a Microsoft Teams channel as the delivery destination, with a confirmation step that lists the affected alerts. - When you ask the MuleSoft Agent to do something it doesn’t have a tool for, it now explains what it can do and offers to report the limitation. - MuleSoft Agent semantic search is recalibrated to return more accurate and relevant results. - Portfolio, service detail, instance detail, and policy pages load faster. #### Changes - In a model proxy route, the **Model** field is renamed to **Request model override**, and **Not applicable** is renamed to **Use model from request**, to clarify that the field overrides the model specified in the incoming request. - The MuleSoft Agent panel is now hidden by default unless the MuleSoft Agent feature is enabled for your organization, and it’s hidden in trial accounts. Previously, the panel could appear for users who couldn’t access the feature. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

The MuleSoft Agent now returns results when you search for assets by type, instead of returning none.

W-23149216

The MuleSoft Agent no longer returns a "No generations found in stream" error in the agent panel, Slack, and Teams.

W-23927589

Switching to a child business group now returns correct results for the MuleSoft Agent in Microsoft Teams.

W-23927098

Your business group selection is now preserved when you refresh the page or open the enhanced experience in a new tab.

W-23444044

Installing and uninstalling the MuleSoft Slack app now works correctly.

W-23632725

A clearer error message now appears when a user who isn’t an organization admin tries to connect Slack to Anypoint Platform.

W-23360453

MuleSoft Agent notifications now deliver to Microsoft Teams instead of failing with an SSL error.

W-23649227

Reinstalling the MuleSoft app in Microsoft Teams now recovers automatically from an installation conflict, matching Slack behavior.

W-23651771

You can now connect Microsoft Teams to a second organization that uses the same Microsoft Entra tenant.

W-23972001

Notifications now display the tenant ID instead of the MuleSoft organization ID.

W-23902550

Toast messages are no longer truncated in the notification list.

W-23902562

Testing the connection to an unreachable or invalid MCP server URL now returns a clear validation message instead of a server error.

W-23480369

MCP server detail pages now show connected APIs, because connection metadata is preserved on MCP server upstreams.

W-23748233

Creating a model proxy from a child business group no longer redirects you to the parent business group.

W-23930690

The topics and model fields are now populated when you edit an existing model proxy that uses semantic caching.

W-23792167

The Omni Gateway dropdown in the model proxy wizard now lists all gateway targets instead of only the first page.

W-23845232

Permissions are now consistent between the model proxy gateway and route-configuration APIs.

W-23845221

The Fallback model dropdown in the model proxy route editor no longer renders empty when a model wallet is enabled.

W-23996495

The provider badge for Amazon Bedrock AgentCore now displays correctly.

W-23995654

The Smart Response Trimming payload optimization policy now saves a complete model proxy URL.

W-23561570, W-23956373

Payload optimization opportunities now appear for instances whose average token usage doesn’t cross the display threshold.

W-23653988

Testing credentials for an OpenAI model proxy in the payload optimization policy now works.

W-23688845

The Discovered tile on the home page no longer over-counts forked MuleSoft public templates.

W-23630949

The agents catalog count no longer includes agent-network rows, so the count matches the assets shown.

W-23631818

## August 28, 2026 ### What’s New #### Features - The Kong Gateway scanner now detects gRPC and GraphQL protocols and assigns the correct service type for these services. Services that use other protocols are registered as service type REST for now. MuleSoft plans to support more protocols in a future release. For more information, see [general::exp-scanners-add-from-providers.adoc#kong-gateway-scanner-protocol-to-asset-type-mapping](https://docs.mulesoft.com/general/exp-scanners-add-from-providers#kong-gateway-scanner-protocol-to-asset-type-mapping). ## August 24, 2026 ### Fixed Issues The release addresses this enhanced MuleSoft experience issue:
Issue ResolutionID

The Expose as MCP Server action now appears for APIs that have a deployable instance, even without a configured consumer endpoint.

W-23922779

## August 6, 2026 ### What’s New #### Features - Playgrounds are now available for APIs and MCP servers. Use the **Playground** tab on a service detail page to explore endpoints and tools, configure and send requests, and inspect responses without leaving the enhanced experience. For more information, see [Testing Services with Playgrounds (Beta)](https://docs.mulesoft.com/general/exp-playground-overview), [Testing APIs in the API Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-api), and [Exploring MCP Server Tools in the MCP Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-mcp). - The Akamai scanner is now available to map external security findings to the right services in **Portfolio**. Add the scanner to scan APIs, surface security findings, and apply governance strategies from the portfolio. The scanner doesn’t import or register third-party services. It correlates risk scores, findings, and incidents in one governance workflow. For more information, see [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) and [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies). - Additional Trusted MCP server SaaS integrations are now available, and ready-to-use MCP client configuration snippets help you connect popular MCP clients faster. - Model Proxy now supports the Anthropic API format and native Anthropic models. See [Supported LLM Providers](https://docs.mulesoft.com/general/model-proxy#supported-llm-providers). - API scanners now read policies from these provider platforms: Amazon API Gateway, Google Apigee, Azure API Management, and Kong Gateway. For these providers, policy results are visible from each discovered API in **Portfolio** > **APIs** > **Policies**. After connecting to a third-party API gateway provider, you can govern discovered APIs through the same governance workflow used for Anypoint Platform APIs. This enables unified governance across multiple gateway platforms. For more information, see: - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Create Governance Strategies with Your IDE](https://docs.mulesoft.com/general/exp-governance-create-strategy#create-with-ide) - [Govern Third-Party Provider APIs](https://docs.mulesoft.com/general/exp-governance-govern-third-party-apis) - [Monitoring Cross-Gateway Conformance](https://docs.mulesoft.com/general/exp-governance-monitor-cross-gateway-conformance) #### Enhancements - The Scanner details page now includes an Activity Log with a real-time timeline of scan progress events. For more information, see [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details). - MCP Bridge now lets you edit tool input schemas, customize tool HTTP request mappings and headers, and expose tool output schemas as part of the MCP specification. - Cost Management now lets you edit optimization policies and is available from the Ask MuleSoft sidebar. - The LLM proxy credential test now distinguishes between credentials that can’t be verified and credentials that are invalid. - LLM Proxy is now renamed to Model Proxy. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

The MCP server creation success screen now displays a persistent runtime authentication warning banner instead of stacked notifications.

W-22323999

Agent detail policy views no longer show a misleading "No instances covered" message for environment types that have no instances.

W-22416846

Portfolio catalog and entity pages now load faster and filter more reliably.

W-22580671

The Anypoint MCP Bridge now returns tool input schemas in valid JSON Schema format in tools/list responses.

W-22602876

Platform MCP server tools now match filter values to stored display labels, returning correct results.

W-22850282

The Apply Policy agent action now displays available policies immediately instead of showing none during an initial delay.

W-23011916

The agent no longer directs you to a nonexistent automated policy creation page.

W-23012045

The agent no longer gets stuck on the Environment field when prefilling a governance strategy form.

W-23091457

The Ping operation now works correctly in MCP Bridge.

W-23128311

Cost Management now displays metrics for Twilio MCP server instances.

W-23141551

API catalog filter options now include values from all assets instead of only the first page of results.

W-23330370

Long LLM responses are no longer dropped mid-stream.

W-23366770

The policy version selector on the policy configuration page now lists versions in order.

W-23385993

Cost Management now surfaces Payload Optimization opportunity cards even when the Payload Optimization policy is not yet applied.

W-23402200

Correlation policies now apply correctly to instances.

W-23470169

Cost Management policy names no longer display underscores.

W-23475812

The MuleSoft Agent prompt now works for users who are granted agent permission only in a child business group.

W-23478614

The MCP server creation wizard now shows an accurate message when the blocker is a missing Exchange permission.

W-23495332

Cost Management Payload Optimization Smart Response Trimming now works regardless of sub-policy order.

W-23515804

Notification labels now match Anypoint Platform.

W-23522019

The agent no longer rejects legitimate platform questions as off-topic.

W-23528364

The agent no longer loops when discovering assets that include nested environment fields.

W-23564370

Cost Management now uses the latest policy version for Trusted MCP servers.

W-23574980

Cost Management now surfaces Payload Optimization opportunities in instance modals even when projected savings are below the display threshold.

W-23632337

## July 15, 2026 ### What’s New #### Features - The new Payload Optimization policy page lets you configure token-reduction strategies, including payload sanitization and TOON encoding, as toggleable sub-policies. - Cost Management now surfaces Payload Optimization sub-policies as opportunity cards, so you can act on top token-savings recommendations directly from the Cost Management page. - The new MCP Tools Progressive Disclosure policy enables you to reduce context window token cost by exposing tools on demand through search. Apply the policy Cost Management. - Instance detail pages now display the consumer endpoint URL, including the base path, so you can copy a callable URL without switching to Anypoint Platform. #### Enhancements - Tool Mapping policy configuration now includes a version selector, so you can update the policy to a new version. - Applied policies now display a "New version available" indicator when a newer version is available. - The model proxy overview now shows the configured fallback route and semantic prompt guard as summary cards, so you can review them without entering edit mode. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

The MCP server Create & Deploy button now displays progress notifications instead of internal provisioning steps.

W-22477443

The monitoring summary page now loads successfully and no longer times out because of backend connectivity failures.

W-22561882

MCP server creation no longer pre-selects a gateway without a public URL, preventing validation errors during review.

W-22569213

MCP server detail pages now open correctly even before the asset is fully indexed, instead of redirecting to the MCP server list.

W-22668860

Name and path validation is improved during MCP server creation.

W-22730633

Policy views for externally managed gateway instances now return an empty policy set instead of a 404 error.

W-22850289

The Run discovery scan quick action in the agent panel now performs the same scan as the Run discovery scan button on scanner pages.

W-22855741

MCP tool input schemas now display complete information.

W-22903101

Long text entered in the agent panel input box now stays within its container.

W-23012031

The Support Credentials toggle in Cross-Origin Resource Sharing policy configuration is now enabled, matching earlier behavior.

W-23050595

Health Check policy configuration now routes you to the alert builder to create an alert after the policy is applied.

W-23050597

Injection Protection policy configuration now provides a multi-select dropdown for built-in protections instead of a free-form text field.

W-23050599

Policy configuration forms with nested fields no longer add an empty row that caused save errors.

W-23050623

Navigation from the agent panel to a specific agent’s detail page now works correctly.

W-23091579

Availability drill-downs now display the availability metric instead of the reliability metric.

W-23111937

Time-series chart drill-downs now display the time bucket you select instead of an adjacent one.

W-23111946

Agent portfolio search now returns agents that also appear in the main UI search.

W-23113003

Tool-mapping descriptions are no longer duplicated when a tool’s summary and description match.

W-23130198

Agent responses now display consistently in chat history.

W-23131703

Cost Management token-savings projections in the instance detail modal now update to match the selected timeframe instead of always using the 30-day period.

W-23140133

The trusted MCP wizard footer now adjusts correctly when the sidebar is collapsed.

W-23176162

Cost Management tool optimization now displays an error message when your organization lacks Agentforce access instead of failing silently.

W-23178835

Acronis test-connection operations now succeed by using the correct tenant filter.

W-23181533

Editing a policy no longer disables or unchecks unrelated fields whose names end in header or headers.

W-23186039

Model Based Routing policy configuration now displays the selected version after you change and save it.

W-23200921

Cost Management tooltips now render with a solid background for better readability.

W-23312200

Cost Management now displays estimated saved tokens correctly when optimization strategies are active.

W-23319697

## July 2, 2026 ### What’s New - Model proxies now supports multiple routes to the same LLM provider and can filter requests to different routes with headers. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

Manual API registration now processes uploaded .zip files without errors.

W-22441824

Manual API registration now processes uploaded JSON and YAML files without server errors.

W-22441846

Portfolio page headers and toolbars now remain fixed at the top when scrolling.

W-22454943

Newly created API instances now appear immediately in the instance list.

W-22461347

Basic Authentication policy password fields now mask input correctly.

W-22476294

Slack Agent now processes Omni Gateway requests without errors.

W-22518488

Pre-selected paths in MCP Server creation no longer display validation errors during review.

W-22599092

Slack Agent responses now focus on available actions instead of describing unavailable creation workflows.

W-22642526

MCP transcoding operations now correctly handle body literals without affecting upstream policies.

W-22642906

Gateway detail page links now redirect to Anypoint Runtime Manager with the correct environment scope.

W-22708401

Outbound OAuth 2.0 Credential Injection policies now allow setting Client ID and Secret.

W-22815084

Policy listing views now clearly distinguish between inbound and outbound policies.

W-22923681

Model proxy asset creation now handles Exchange API responses without HTTP 502 errors.

W-22927281

MCP Server tool lists now return all available tools without truncating results at 512 items.

W-22928504

Portfolio page provider filters now display all configured providers instead of a static list.

W-22928563

Portfolio page filters now handle large result sets without returning empty results.

W-22928667

OAuth 2.0 test connection operations now work correctly when creating an MCP server.

W-22965458

API specification overviews for gRPC APIs now populate correctly in the India region.

W-22966440

A2A PII Detector policy configuration now supports multi-select for PII types.

W-23050572

MCP PII Detector policy configuration now supports multi-select for PII types.

W-23050575

LLM PII Detection policy configuration now supports multi-select for PII types.

W-23050578

Model Based Routing policy configuration now includes Match Headers and isFallback Entry fields.

W-23050585

Client ID Enforcement policy configuration now displays Client ID Expression and Client Secret Expression fields when Custom Expression is selected.

W-23050592

JWT Validation policy configuration now includes JWT Signing Key Length, conditional JWT Key fields, and Client ID Expression.

W-23050601

Credential Injection API Key policy configuration now displays auth-type-dependent fields for custom headers, API keys, and client credentials.

W-23050605

Credential Injection OAuth 2.0 policy configuration now displays grant-type-dependent fields for Client Credentials and Password grant types.

W-23050608

OAuth 2.0 OBO Credential Injection policy configuration now displays all grant-type-dependent fields.

W-23050613

Agent registration workflow now uses correct naming conventions.

W-23064092

MCP Server creation now displays clear, actionable error messages when credential validation fails.

W-23073090

Acronis credential test operations now work correctly with network allowlist configurations.

W-23085376

Public Agent detail pages no longer display delete icons.

W-23090929

POST tools created from MCP bridge connections now correctly include all input parameters.

W-23128385

The MuleSoft Agent now displays correctly for users who have been enabled in child business groups.

W-23182443

## June 22, 2026 ### What’s New #### Enhancements - Notifications are now available, allowing you to configure and receive alerts for service health and governance events. For more information, see [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications). - MuleSoft Agent is now available. Manage your MuleSoft environment with MuleSoft Agent, an agentic experience available in the control plane. Use MuleSoft Agent to create scanners, apply policies, deploy instances, and perform other management tasks. To request access, contact your account executive. For more information, see [Using the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-use). - MuleSoft for Slack is now available. Install the MuleSoft Slack app to interact with the MuleSoft Platform directly from your Slack workspace, send platform notifications to Slack channels or direct messages, take platform actions, and ask questions about your MuleSoft organization. For more information, see [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate). ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

Inactive instances now display correctly across both pipeline and summary views.

W-22456216

Instance detail pages now display environment names correctly instead of showing only environment types.

W-22455820

Instance detail page headers now display correctly with proper styling and element positioning.

W-22455880

Governance strategy deletion now completes successfully without returning errors.

W-22476104

The MCP Server creation flow no longer displays premature "select at least one tool" warnings during loading or when no operations exist.

W-22490327

MCP Server creation now displays helpful error messages when incorrect credentials are provided.

W-22570827, W-22570738

Connected asset graph links on agent pages now navigate directly to entity detail pages instead of list pages.

W-22571289

Cost Management recommendation cards now display in strict descending order by projected savings.

W-22586604

Text overflow issues on MCP Server creation pages are resolved.

W-22598973, W-22622184

Auto-generated MCP tool names now follow snake_case convention and use operation names instead of API asset prefixes.

W-22601645

The Continue button now enables correctly after editing optimized tool names and descriptions in Tool Mapping policy imports.

W-22603960

The MCP Tool Response Sanitization policy now displays values that match Anypoint settings.

W-22692504

Chat input fields in Cost Management now handle long prompts without overflowing the container.

W-22692107

Consumer endpoints now display correctly and no longer intermittently show implementation URLs.

W-22696329

Gateway URLs in MCP Server creation now update correctly instead of remaining stuck at default demo URLs.

W-22696327

Scan summaries now correctly display skipped services in provider scan results.

W-22701129

Cost Management optimization estimations now correctly check input schemas.

W-22709243

Credential input fields in the MCP Server wizard now display correct validation messages.

W-22730686

Azure API Management providers now display correctly in the provider listing.

W-22730614

You can now delete MCP assets from the catalog when they have zero instances.

W-22732824

Model proxy Bedrock routes now correctly clear empty session tokens when switching from STS to long-term IAM credentials.

W-22769399

Scanner deletion operations now complete cleanly without displaying stale scanner data.

W-22779340

Cost Management optimization operations now display loading indicators correctly for individual rows instead of all rows.

W-22781792

Consumer endpoint URLs for trusted MCP servers now include the correct /mcp path.

W-22782195

Read-only operation selection in MCP bridge SaaS actions now correctly deselects PUT operations.

W-22784169

The JWT Validation policy configuration form now includes the JWT Key input parameter.

W-22795041

Service catalog counts now display consistently between the UI and MCP server counts.

W-22795809

Provider pages now reload correctly when switching Business Groups.

W-22795416

Provider filters on the Agents portfolio page now return correct results for all providers including Amazon Bedrock AgentCore and Azure AI Foundry.

W-22910173

HTTP Basic Authentication configuration for Client ID Enforcement policies now works correctly.

W-22923781

You can now edit policy configurations for all policy types.

W-22923643

Rate Limiting policy search now works as expected.

W-22923811

OAuth2 OBO Credential Injection now works correctly for outbound policies.

W-22924163

Cross Origin policy forms now properly disable the Support Credentials option when applicable.

W-22924051

Tool response size limits now prevent oversized responses from exceeding client token limits.

W-22947243

Scanner connection tests for Vertex AI now return descriptive error messages on failures.

W-22947245

API instance upstream URLs now update correctly when editing trusted MCP server configurations.

W-22971120

Monitoring and performance modules now load correctly without modularity errors.

W-22999188

The All Versions filter label now displays correctly on monitoring pages instead of showing MISSING_KEY errors.

W-23003583

MCP bridge instances now display availability status correctly.

W-23003437

Asset search now validates query parameters correctly and no longer accepts empty queries.

W-22962129

Agent and MCP detail pages now display enriched metadata correctly.

W-22992220

## June 18, 2026 ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

The Performance page now displays monitoring data correctly for organizations in the India cloud.

W-22997947

Monitoring data now resolves to the correct environment when organizations contain multiple environments of the same type.

W-23007726

The Instances column header now displays Env Type instead of Environment.

W-22418037

The Edit action now appears in the action menu on MCP Server detail pages in EU, Japan, and Canada clouds.

W-22693560

CloudFront URL access for file downloads now works correctly in Japan and Canada clouds.

W-22686958

## June 11, 2026 ### What’s New This release includes security updates and improvements to the enhanced MuleSoft experience. ### Fixed Issues The release addresses these enhanced MuleSoft experience issues:
Issue ResolutionID

You can now deploy, edit, and delete MCP servers that share the same name.

W-22603005

Auto-generated MCP tool names no longer contain spaces, ensuring compliance with the MCP specification.

W-22816476

You can now open service detail pages from the Services catalog while viewing the root Business Group context.

W-22696491

Governance Insights reports now display policy rulesets and instances correctly.

W-22710201

The Environment filter on the Gateways catalog page now correctly filters the displayed gateways by the selected environment.

W-22778035

The Provider filter on portfolio pages (Agents, APIs, MCPs) now correctly returns services associated with the selected provider.

W-22815822

The Vitest library is upgraded to 4.1.8 to address a reported security vulnerability.

W-22777847

Automated policies configured at both organization and environment levels now display correctly without duplicated policy activity.

W-22735582

Policy direction (inbound or outbound) now displays correctly under application methods instead of showing generic instance policy labels.

W-22801826

A cross-tenant security vulnerability that allowed unauthorized access to Kong gateway plugin configurations across organizations is resolved.

W-22803601

Public MCP Server and Agent assets no longer allow unmanaged instance creation.

W-22733185

MCP server provisioning status now updates more reliably while reducing unnecessary refresh cycles.

W-22725529

Third-party libraries are updated to resolve reported security vulnerabilities.

W-22618670

## May 28, 2026 ### What’s New - You can now manage agents, APIs, MCP servers, model proxies, and gateways from one portfolio experience, so teams can govern and operate AI integrations without switching between separate tools. For more information, see [Enhanced MuleSoft Experience](https://docs.mulesoft.com/general/learning-map-exp) and [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview). - You can now add services through provider-based discovery or manual registration, so teams can onboard both cloud-managed and custom services faster. For more information, see [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio), [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add), and [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually). - You can now create MCP servers by selecting source systems and publishing tools and resources for MCP clients, so you can more easily expose existing APIs and SaaS systems through MCP workflows. For more information, see [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server). - You can now add semantic services with Basic and Advanced scale models, so LLM-driven requests route with improved context awareness as traffic grows. For more information, see [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service). - You can now apply governance strategies across supported service types, so teams can enforce conformance and cost controls more consistently. For more information, see [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) and [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). - Scanner operations now support lifecycle workflows for running, pausing, editing, and deleting scanners, so provider discovery stays current with less manual overhead. For more information, see [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) and [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage). - Service detail pages now centralize instance creation and management workflows for supported catalogs, so teams can align deployment operations with governance and monitoring workflows. For more information, see [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) and [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). - Monitoring guidance now connects service health, detailed metrics, and token and response analysis, so responders can triage regressions faster. For more information, see [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring), [View Detailed Metrics for Your Services](https://docs.mulesoft.com/general/exp-services-view-detailed-metrics), and [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage). - You can now access the experience from Anypoint Platform, direct URLs, and supported coding assistants, so teams can work from existing workflow surfaces. For more information, see [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect). - Service detail pages now clarify tab availability by service type, so operators can more easily find instance, governance, and conformance data by catalog. For more information, see [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). ## See Also - [Enhanced MuleSoft Experience](https://docs.mulesoft.com/general/learning-map-exp) - [Troubleshoot the Enhanced Experience](https://docs.mulesoft.com/general/exp-troubleshoot) - [Troubleshoot the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-troubleshoot) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started keywords: mcp server playground, test mcp server, mcp tools, tool invocation, anypoint platform, enhanced experience --- # Exploring MCP Server Tools in the MCP Playground (Beta) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the MCP server playground to understand what an MCP server does and how it behaves without connecting it to an external tool such as Postman, the MCP Inspector, or Claude Desktop. Instead of reading only the overview and documentation, you explore the server’s tools, invoke them, and see what they return, directly on the service detail page. > [!NOTE] The MCP server playground is a pilot or beta service that is subject to the Beta Services > Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written > Unified Pilot Agreement if executed by Customer, and applicable terms in the > [Product Terms Directory](https://ptd.salesforce.com/?_ga=2.247987783.1372150065.1709219475-629000709.1639001992). > Use of this pilot or beta service is at the Customer’s sole discretion. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Viewer - Exchange: Exchange Contributor - Exchange: Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Open the MCP Server Playground 1. In **Portfolio**, open the **MCP Servers** catalog and select the MCP server you want to test. 2. On the service detail page, select the **Playground** tab. ## Inspect and Invoke Tools The playground lists the tools inside the MCP server so you can explore each tool’s functionality and description. 1. In the tool list, select the tool you want to test. 2. If you aren’t already authenticated to the MCP server, configure authentication. If you’re already authenticated, you don’t need to authenticate again. 3. Configure the tool’s parameters in form or JSON format. 4. (Optional) Copy the request snippet, which reflects your configuration. 5. Select **Execute** to invoke the tool. 6. Review the response, including the status code and the full JSON response body. If required parameters are missing or validation fails, the playground shows an error or an explanation of the failure. ## See Also - [Testing Services with Playgrounds (Beta)](https://docs.mulesoft.com/general/exp-playground-overview) - [Testing APIs in the API Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-api) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) --- product: Getting Started keywords: agent fabric, get started, prerequisites, permissions, access management, anypoint platform, omni gateway, mcp server, model proxy, portfolio --- # Get Started with Agent Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Agent Fabric is the AI control plane for agents, MCP servers, and APIs across platforms. You can’t apply governance, security, or cost controls to agents you don’t know about. Catalog your assets first. Then complete only the jobs you need. ## Before You Begin Complete these checks with your administrator before you rely on Agent Fabric in production. Requirements vary by entry point and by which jobs you do. Access and Credentials Confirm that you have an Anypoint Platform user account and valid credentials for your organization’s entry path. Platform and Product Access Confirm these platform settings with your administrator: - Confirm that your organization has the required product access for Agent Fabric and that an administrator turned it on for your Anypoint Platform business group or organization. If Agent Fabric isn’t available, contact your Anypoint Platform organization administrator or MuleSoft account team. - Confirm that generative AI is turned on for your organization when you use AI-assisted features. See [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - Confirm that any connected Salesforce orgs are linked. See [Connecting a Trusted Salesforce Organization to Anypoint Platform](https://docs.mulesoft.com/access-management/connecting-salesforce-orgs). Permissions Confirm how your administrator maps jobs to roles: - Agent Fabric uses Anypoint Platform access management. Your administrator maps jobs to roles and permissions in Access Management, and exact permission names differ by organization. - Use the permission tables in each job section together with your internal access guide. For the enhanced experience permissions table, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - If you can’t complete an action or a page shows an authorization error, ask your organization administrator for the matching permission or role. > [!TIP] These apply to more than one job: > > - Omni Gateway (managed or self-managed) puts authentication, monitoring, and policy in the > request path. It’s required for managed instances, A2A bridges, model proxies, and rogue-agent > containment. Model Proxy requires an Omni Gateway running in Connected Mode. For more > information, see [Omni Gateway Overview](https://docs.mulesoft.com/gateway/latest/). > > - An identity provider (IdP) that issues JSON Web Tokens (JWTs) is required for model wallets and > rogue-agent detection. > > - A connected provider scanner is required before you apply policies to, or govern, third-party > gateway APIs. ## Catalog Agents, MCP Servers, and APIs The registry is a single inventory of agents, MCP servers, APIs, and related services, regardless of which platform built them. ### Register Services Register assets so other teams can find and reuse them instead of rebuilding the same agents and tools. Before you register services, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Gateways created in Anypoint Platform and opened from Agent Fabric. You also need these permissions:
To do thisYou need

View catalogs and services

One of: Exchange Viewer, Exchange Contributor, or Exchange Administrator

Register agents, APIs, and LLMs

One of: Exchange Contributor, Exchange Administrator, or Exchange Creator

Learn more: - [View Your Portfolio Overview](https://docs.mulesoft.com/general/exp-portfolio-overview) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) ### Discover Services with Scanners Use scanners when agents run on more than one platform and manual registration can’t keep the registry current. Before you create scanners, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Access to, and active context in, the business group where you want to add the scanner. - A connected cloud provider under **Platform** > **Providers** for each source you scan. - Provider-specific credentials, roles, and permission scopes for that scanner. For example, writing policies to a third-party gateway requires connection credentials that carry the provider’s write scope, and the Microsoft Copilot Studio scanner can require a pre-configured OAuth app. See [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). - The Akamai API Security scanner, available only when your administrator turns on that feature for your organization. You also need these permissions:
To do thisYou need

Create scanners

Exchange Administrator

View Providers

Exchange Administrator, or the required scanner entitlements for API, MCP, or agent scanners

Learn more: - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) ## Expose Existing APIs as MCP Servers Agents can’t call APIs as tools until you expose those APIs as MCP servers. ### Use MCP Bridge MCP Bridge turns an existing API or SaaS system into an MCP server without custom code. Before you create an MCP server with MCP Bridge, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - An existing API or SaaS system to expose, including the credentials the MCP server uses to call that source. You also need these permissions:
To do thisYou need

Create an MCP server

One of: Exchange Contributor, Exchange Administrator, or Exchange Creator, plus API Manager: Manage APIs Configuration on at least one environment

Learn more: - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Making Your APIs Agent-Ready](https://docs.mulesoft.com/general/af-use-case-mcp-bridge) ### Build a Custom MCP Server in Mule Use MCP Connector when the tools don’t map to a single existing API and you need custom Mule logic. The resulting MCP server or client runs in Mule. Before you add MCP Connector to a Mule application, confirm you have: - Familiarity with Anypoint Connectors, Mule runtime engine (Mule), and how to create a Mule app and configure global elements in Anypoint Code Builder. - Java 17 and Apache Maven. - An Anypoint Platform account. - The latest version of Anypoint Code Builder. - Credentials to connect with the target resource the MCP server or client calls. You also need these permissions:
To do thisYou need

Download and publish assets

Exchange Viewer and Exchange Creator

Deploy applications

Runtime Manager: Read Applications, Create Applications, and Delete Applications

View and create APIs

Design Center Developer

Learn more: - [MCP Connector](https://docs.mulesoft.com/mcp-connector/latest/) ## Present Non-A2A Agents as A2A-Compliant Many enterprise agents, including Agentforce agents, aren’t A2A-compliant on their own. Register Amazon Bedrock AgentCore and Google Vertex AI directly. ### Create an A2A Bridge An A2A bridge presents a non-A2A agent as A2A-compliant without changing the source agent. Salesforce Agentforce is the supported source platform. Before you create an A2A bridge, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - A source agent that’s registered in Portfolio and that isn’t already A2A-compliant. - A managed or self-managed Omni Gateway in the target environment. - Credentials for the source agent’s platform, such as the Salesforce org URL, OAuth token URL, client ID, and client secret for an Agentforce source agent. You also need these permissions:
To do thisYou need

Create an A2A bridge

One of: Exchange Contributor, Exchange Administrator, or Exchange Creator, plus API Manager: Manage APIs Configuration on the target environment

Learn more: [Make an Agent A2A-Compliant](https://docs.mulesoft.com/general/exp-services-create-a2a-bridge) ### Add A2A Support to a Mule Application Use A2A Connector when an existing Mule application must participate as an A2A-compliant agent. The connector implements the A2A protocol so the app can act as an A2A server, an A2A client, or both. Before you add A2A Connector to a Mule application, confirm you have: - Familiarity with Anypoint Connectors, Mule runtime engine (Mule), and how to create a Mule app and configure global elements in Anypoint Code Builder. - Java 17 and Apache Maven. - An Anypoint Platform account. - The latest version of Anypoint Code Builder. - Credentials to connect with the target resource. - An existing Mule application that must act as an A2A server, an A2A client, or both. You also need these permissions:
To do thisYou need

Download and publish assets

Exchange Viewer and Exchange Creator

Deploy applications

Runtime Manager: Read Applications, Create Applications, and Delete Applications

View and create APIs

Design Center Developer

Learn more: [A2A Connector](https://docs.mulesoft.com/a2a-connector/latest/) ## Coordinate Work Across Specialized Agents A broker is an intelligent router that orchestrates work across specialized A2A-compliant agents. You define the broker and its nodes in Agent Script. Before you create an agent network, confirm you have: - Your Anypoint Platform credentials. - Anypoint Code Builder, with the Anypoint Code Builder URLs allowlisted. See [Allow URLs for Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/urls-to-allow). - At least one Managed Omni Gateway in the target environment. A single gateway can handle both ingress and egress traffic. - A2A-compliant agents in the network. Create an A2A bridge first for agents that aren’t A2A-compliant. - A deployment target such as a CloudHub 2.0 shared or private space, or a Runtime Fabric target. Every Anypoint Platform organization includes a CloudHub 2.0 shared space. A private space requires CloudHub Network Administrator to create and manage it, and you must associate that space with the business groups and environments where you deploy. - Generative AI turned on for your organization if you use MuleSoft Vibes. See [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). For Vibes, also install Node.js 20 LTS or later and the latest version of `jq`, and connect your Anypoint Platform organization to a Salesforce organization that has generative AI enabled. - For the Anypoint CLI (optional): Node 20 (v20.19.4) or later, Java 17 or later with `JAVA_HOME` set, and the Anypoint CLI Agent Fabric Plugin. You also need these permissions:
To do thisYou need

Use Anypoint Code Builder

Anypoint Code Builder Developer

Use AI features in Anypoint Code Builder, including MuleSoft Vibes

Anypoint Code Builder: Mule Developer Generative AI User

Create and read applications and servers

Runtime Manager: Manage Servers, Create Applications, and Read Servers

View and create APIs

Design Center Developer

Deploy API proxies and manage policies

API Manager: Deploy API Proxies and Manage Policies

Publish agent network assets

Exchange Contributor

View usage

Usage Viewer

Deploy to a CloudHub 2.0 private space

CloudHub Network Administrator, plus Runtime Manager: Create Applications and Read Applications

View applications on Runtime Fabric or CloudHub 2.0

Runtime Manager: Read Applications for the environment, and Read Runtime Fabrics for the business group

Learn more: - [Get Started with Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-get-started) - [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) - [MuleSoft Vibes for Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/vibes-get-started) - [Agent Visualizer](https://docs.mulesoft.com/agent-visualizer/) ## Enforce the Same Policies on Live Traffic Omni Gateway sits in front of your agents, APIs, MCP servers, and LLM traffic, regardless of the platform that built them. ### Create Instances of Services and Apply Policies Instances represent how a service runs in a specific environment. APIs, agents, MCP servers, and model proxies can include instances. A managed instance of an API, agent, or MCP server puts Omni Gateway in the request path so authentication, monitoring, and policy apply to live traffic. Before you create instances of services or apply policies, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - An Omni Gateway for each managed instance. - A connected provider scanner whose credentials carry the provider’s write scope, required to apply policies to third-party gateway APIs (Azure API Management, Google Apigee, or Kong Gateway). See [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). You also need these permissions:
To do thisYou need

Create instances

API Manager: API Creator

View instances

API Manager: View APIs Configuration

Edit instances

API Manager: Edit APIs Configuration

View policies

API Manager: View Policies

Apply, edit, enable, disable, or remove policies

API Manager: Manage Policies

Learn more: - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) ### Create Governance Strategies A governance strategy defines access, data privacy, performance, cost, and compliance rules once and applies them across the services in scope. Before you create governance strategies, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Governance available for your tenant. - For third-party API governance: a connected third-party gateway scanner and control rules authored as a governance ruleset. You also need these permissions:
To do thisYou need

Create governance strategies

API Governance: Governance Administrator for Control types, or API Manager: Manage Policies for Automated Policy types

View governance reports

One of: API Governance: Governance Viewer or Governance Administrator (You also need Exchange Viewer for the conformance badge)

Learn more: - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) - [Govern Third-Party Provider APIs](https://docs.mulesoft.com/general/exp-governance-govern-third-party-apis) - [Monitoring Cross-Gateway Conformance](https://docs.mulesoft.com/general/exp-governance-monitor-cross-gateway-conformance) ## See LLM Spend, Cap It, and Reduce Token Use A model proxy, deployed to Omni Gateway, is one governed endpoint for multiple LLM providers. ### Create a Model Proxy Deploy the proxy to Omni Gateway so routing, caching, and policy run in front of every LLM call. Before you create a model proxy, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - A deployed Omni Gateway version 1.11.4 or later, running in Connected Mode. Model Proxy runs only on Omni Gateway. - Up to 50 model proxies on each Large Omni Gateway. - API keys to authenticate with your LLM providers. - A configured semantic routing service if you want to use semantic routing. See [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service). - A configured semantic caching service if you want to enable semantic caching. See [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service). - A connection to an external vault (AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault) under **Platform** > **Providers** if you want to authenticate a route with a secret from your vault. You also need these permissions:
To do thisYou need

Create a model proxy

API Manager: API Creator

Learn more: - [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy) - [Creating Model Proxies](https://docs.mulesoft.com/general/model-proxy-create-model-proxy) ### Set Model Costs and Cap Spend with Wallets Set a cost for each model so token counts read as dollars. A model wallet caps a caller’s token or dollar spend against a provider. Before you set model costs or manage wallets, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - At least one configured model proxy. - A configured IdP that issues JWTs for callers. Organizations without an IdP can’t use model wallets. - JWT Validation applied on each model proxy that callers reach through the wallet, with DataWeave Headers Transformation and Client ID Enforcement turned off. You also need these permissions:
To do thisYou need

Set model costs

One of: API Manager: API Creator, View APIs Configuration, or Edit APIs Configuration

Manage model wallets

API Manager: API Creator, View APIs Configuration, Edit APIs Configuration, and Manage Policies

Use the Cost Management experience

API Manager: Manage Policies, View APIs Configuration, and View Policies; Anypoint Monitoring: Monitoring Viewer; and Exchange: Exchange Viewer. Anypoint Code Builder: Mule Developer Generative AI User is optional and required only to enable AI features.

Learn more: - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage) - [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs) - [Controlling LLM Costs in Agent Fabric](https://docs.mulesoft.com/general/af-use-case-cost-management) ### Route and Cache Model Calls Semantic routing sends each request to the best-matching model. Semantic caching reuses a response when a new request is similar to an earlier one. Before you configure semantic routing or caching, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - A model proxy on Omni Gateway. - For semantic routing: credentials for an embedding service (OpenAI, Hugging Face, or Azure OpenAI). Advanced Scale also requires a dedicated external vector database (Qdrant, Pinecone, or Azure AI Search). - For semantic caching: an OpenAI embedding service, an Azure AI Search vector database, and object store connection values (client ID, client secret, URL, and store name). You also need these permissions:
To do thisYou need

Configure semantic routing

One of: Exchange Contributor, Exchange Administrator, or Exchange Creator

Configure semantic caching

One of: Exchange Contributor, Exchange Administrator, or Exchange Creator

Learn more: - [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service) - [Configuring Semantic Caching Services](https://docs.mulesoft.com/general/model-proxy-semantic-caching-service) ## Detect and Contain Rogue Agents A compromised or misconfigured agent can leak data, take unauthorized actions, or drive unexpected cost. Detection flags risky behavior for your review. The Kill Switch policy blocks that agent’s access to the model proxy when you quarantine it. Before you detect and contain rogue agents, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Omni Gateway 1.13.5 or later. - Each monitored agent registered with a unique instance name and ID, and linked to its model proxies. - Agents set up as service identities in your IdP, with tokens that include the agent’s identifier and the identity of the person the agent is acting for. - JWT Validation policy applied to each protected model proxy. You also need these permissions:
To do thisYou need

Detect and contain rogue agents

API Manager: API Creator, View APIs Configuration, Edit APIs Configuration, View API Alerts, and Manage API Alerts

Learn more: [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents) ## Keep Credentials in an External Vault Register an external vault so credentials stay in AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. Only metadata is stored. Before you register an external vault, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Access to the external secrets manager, including its endpoint URL and credentials. - A supported vault: AWS Secrets Manager, Microsoft Azure Key Vault, or HashiCorp Vault. You can’t change a vault’s name after you create it. You also need these permissions:
To do thisYou need

View vaults

One of: Secrets Manager: View Vault Integrations or Manage Vault Integrations

Manage vaults

Secrets Manager: Manage Vault Integrations, Exchange Administrator, Exchange Contributor, API Manager: API Creator, and API Manager: Manage Policies

Learn more: [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) ## Correlate Akamai Risk to Discovered Services Correlate security findings to APIs and MCP services in the portfolio so you can triage risk before it becomes an incident. Before you set up Akamai risk correlation, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Akamai Security base URL, client ID, and client secret from an Akamai service account. - A MuleSoft connected app that acts on its own behalf, with the Exchange Viewer or Asset Viewer scope, so Akamai can read API asset and instance information. - Access to apply the Akamai correlation policy in the environments you scan. - Existing APIs and MCP services in Portfolio to correlate against. - The Akamai API Security feature turned on for your organization. You also need these permissions:
To do thisYou need

Set up Akamai risk correlation

Exchange Administrator in the target business group, plus write access to apply the correlation policy in the environments you scan

Learn more: [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) ## Monitor Latency, Errors, and Volume Monitoring shows latency, error rates, and request volume. Agent Visualizer maps how agents, brokers, and MCP servers connect. Before you monitor services or open Agent Visualizer, confirm you have: - An Anypoint Platform account with the required product access for Agent Fabric. See [Before You Begin](#before-you-begin). - Managed paths on Omni Gateway for the metrics that the experience surfaces. - A connected and approved observability backend for organization-wide dashboards when your tenant includes Observability. - For alert delivery: the MuleSoft Slack app installed in your workspace, or the MuleSoft for Teams app installed in your Microsoft Teams tenant. You also need these permissions:
To do thisYou need

View monitoring

One of: Anypoint Monitoring: Monitoring Viewer or Monitoring Administrator

View agentic assets in Agent Visualizer

Exchange: Exchange Viewer

View API nodes and relationships in Agent Visualizer

API Manager: View APIs Configuration

View policies for assets in Agent Visualizer

API Manager: View Policies

View alerts

One of: API Manager: View API Alerts or Runtime Manager: Read Alerts

Manage alerts

One of: API Manager: Manage API Alerts or Runtime Manager: Manage Alerts

Learn more: - [Agent Visualizer](https://docs.mulesoft.com/agent-visualizer/) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications) ## See Also - [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) - [Agent Fabric Use Cases](https://docs.mulesoft.com/general/agent-fabric-use-cases) - [Learn About Agent Fabric](https://docs.mulesoft.com/general/learning-map-agent-fabric) - [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) - [Omni Gateway Overview](https://docs.mulesoft.com/gateway/latest/) - [Getting Started with Omni Gateway](https://docs.mulesoft.com/gateway/latest/gateway-getting-started-overview) - [Connecting a Trusted Salesforce Organization to Anypoint Platform](https://docs.mulesoft.com/access-management/connecting-salesforce-orgs) - [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai) --- product: Getting Started keywords: agent networks, ai agents, mulesoft, get started, agent orchestration, setup, configuration --- # Get Started with Agent Networks > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Creating agent networks is a multi-step process. Review these prerequisites and task overviews to make sure you can create agent networks efficiently. ## Before You Begin Before you get started, review these prerequisites. ### Anypoint Platform Requirements and Permissions
Anypoint Platform ComponentRequired Permissions

Runtime Manager

  • Manage Servers

  • Create Applications

  • Read Servers

Anypoint Code Builder

  • Anypoint Code Builder

  • Mule Developer Generative AI User

Anypoint Design Center

Design Center Developer

API Manager

  • Deploy API Proxies

  • Manage Policies

Exchange

Exchange Contributor

Usage

Usage Viewer

CloudHub 2.0 or Runtime Fabric

Runtime Fabric permissions or CloudHub 2.0 permissions

See [Permissions by Product in Anypoint Platform](https://docs.mulesoft.com/access-management/permissions-by-product) for a list of all Anypoint Platform permissions. ### Additional Requirements To complete these tasks, you also need: - Your Anypoint Platform credentials - [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/start-acb) Allowlist Anypoint Code Builder URLs. For more information, see [Allow URLs and Antivirus Exclusions for Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/urls-to-allow). - [Omni Gateway Ingress and Egress gateways](https://docs.mulesoft.com/gateway/latest/gateway-managed-ingress-egress) ### MuleSoft Vibes Requirements (Optional) If you plan to use MuleSoft Vibes to create agent network projects, make sure you meet [the requirements](https://docs.mulesoft.com/anypoint-code-builder/mulesoft-vibes#before-you-begin-vibes). ### CLI Requirements (Optional) If you’re using the Anypoint CLI to create agent network projects, ensure you meet these requirements. - Node 20 (v20.19.4) or later. See [Nodejs.org](https://nodejs.org/en). - Java 17 or later. Set the `JAVA_HOME` environment variable. - [Anypoint CLI Agent Fabric Plugin](https://www.npmjs.com/package/mulesoft-anypoint-cli-agent-fabric-plugin) ## Task Overview ### Step 1: Set Up Your Agent Network 1. Use Anypoint Runtime Manager to set up a space in CloudHub 2.0 or deployment target in Runtime Fabric. See [Set Up the Space or Deployment Target for Your Environment](https://docs.mulesoft.com/agent-network/latest/af-get-started#setup-space). 2. Set up Omni Gateways for the space or deployment target. - If using Anypoint Code Builder, see [Set Up Agent Network Gateways for the Space or Deployment Target](https://docs.mulesoft.com/agent-network/latest/af-get-started#setup-gateways). - If using the Anypoint CLI, see the [setup gateways command reference](https://docs.mulesoft.com/agent-network/latest/af-build-agent-networks-in-a-ci-cd-environment#agent-network-setup-gateways). ### Step 2: Create a Project Now you’re ready to create an agent network project. Choose one of these methods. - [Create a Network Using MuleSoft Vibes](https://docs.mulesoft.com/agent-network/latest/af-create-agent-network#create-dev-agent) - [Create a Network Using Anypoint Code Builder](https://docs.mulesoft.com/agent-network/latest/af-create-agent-network#create-acb) - [Create a Network Using the Anypoint CLI](https://docs.mulesoft.com/agent-network/latest/af-create-agent-network#create-cli) ### Step 3: Define Your Agent Network Specification After you create your agent network project, configure `agent-network.yaml` and `exchange.json` to reflect the structure of your network. - [Define a Network Using MuleSoft Vibes](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification#define-dev-agent) - [Define Your Network in Anypoint Code Builder](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification#define-acb-ide) ### Step 4: Publish Your Agent Network Assets Build and publish your agent network project as Anypoint Exchange assets. When you publish the agent network, an asset is created in Exchange for each broker, agent, and MCP server that’s in your agent network. - [Publish Your Network Using MuleSoft Vibes](https://docs.mulesoft.com/agent-network/latest/af-publish-agent-network-assets#publish-dev-agent) - [Publish Your Network Using Anypoint Code Builder](https://docs.mulesoft.com/agent-network/latest/af-publish-agent-network-assets#publish-acb) - [Publish Your Network Using the Anypoint CLI](https://docs.mulesoft.com/agent-network/latest/af-build-agent-networks-in-a-ci-cd-environment#agent-network-project-publish) ### Step 5: Deploy Your Agent Network Instances Deploy your agent network instance to a deployment target. You can deploy to a CloudHub 2.0 shared space, a CloudHub 2.0 private space, or to a Runtime Fabric target. - [Deploy Your Network Using MuleSoft Vibes](https://docs.mulesoft.com/agent-network/latest/af-deploy-agent-network-targets#deploy-dev-agent) - [Deploy Your Network Using Anypoint Code Builder](https://docs.mulesoft.com/agent-network/latest/af-deploy-agent-network-targets#deploy-acb) - [Deploy Your Network Using the Anypoint CLI](https://docs.mulesoft.com/agent-network/latest/af-build-agent-networks-in-a-ci-cd-environment#agent-network-project-deploy) --- product: Getting Started keywords: enhanced experience, get started, permissions, workflow, access, anypoint platform, setup --- # Get Started with the Enhanced Experience > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Grow and tune your AI portfolio by registering and monitoring agents, APIs, and gateways in centralized catalogs. Sign in through the entry point your organization provides, such as Anypoint Platform, or a direct URL, to access dashboards and governance strategies based on your assigned permissions. You can review live performance metrics, manage security policies, and track rule-level compliance through automated conformance reports. These tools ensure your AI assets remain audit-ready while providing clear visibility into cost and runtime health across your organization. Watch this video to see how to get started with the enhanced MuleSoft experience: ![](https://play.vidyard.com/pQMYGFeqiwcw2EG9rKia2d.jpg) ## Access the Enhanced Experience Your organization determines how you access the new experience. Common options include these environments. - Anypoint Platform In Anypoint Platform, look for the new experience banner or shortcut and choose **Go to the new experience**. Your administrator can also add a direct link in the main navigation or workspace. - Coding assistants If your organization connects the new experience to a supported assistant, such as Claude Code, follow your internal instructions to open the new experience features from that development environment. - Direct URL Your organization can share a standalone URL that signs you in to the new experience outside other apps. Use the address your administrator or internal documentation provides. - Custom integrations Your organization can build access through another tool. Follow the internal access instructions for custom integrations. > [!NOTE] Available access points depend on how your administrators configured the new experience’s > integrations with other platforms. ## Before You Begin Before you rely on the new experience in production, complete these checks with your administrator. Requirements vary by entry point and how your administrator integrates the new experience with other systems. Access and Credentials - Confirm that you have a user account for your organization’s entry path, such as Anypoint Platform, and valid credentials to log in. - Confirm that you can reach the new experience and integrated services, such as Anypoint Platform, or a connected coding assistant, from the networks and locations you use. Platform and Product Access - Confirm that your organization has the required product access for the new experience and that an administrator enabled it for your Anypoint Platform business group or organization. If the experience isn’t available, contact your Anypoint Platform organization administrator or MuleSoft account team. - Confirm that required integrations with Anypoint Platform or your development environment work end to end. - If the new experience connects to other services, work with your administrator to configure authentication, such as API keys or OAuth tokens, to ensure successful connections. - Confirm that your administrator approved and configured required external connections, such as cloud providers under **Providers**. ## Enhanced Experience Permissions The new experience uses Anypoint Platform access management. Your administrator maps jobs to roles and permissions in Access Management. Exact permission names differ by organization. Use this table with your internal access guide.
Required PermissionsGrants the Ability toNotes

Any of these permissions:

  • Exchange: Exchange Viewer

  • Exchange: Exchange Contributor

  • Exchange: Exchange Administrator

View services

View services in the portfolio and open the catalog overview in Anypoint Exchange.

One of these Exchange permissions:

  • Exchange: Exchange Contributor

  • Exchange: Exchange Administrator

  • Exchange: Exchange Creator

Create services

Register MCP servers, agents, LLMs, or APIs. To create an MCP server, you also need the API Manager: Manage APIs Configuration permission on at least one environment.

API Manager: API Creator

Create instances

Create or add instances.

API Manager: View APIs Configuration

View instances

View instances for services and open the Instances tab.

API Manager: Edit APIs Configuration

Edit instances

Edit instances for services.

Exchange: Exchange Administrator

Create scanners

Create scanners from Providers using Add MCP Server, Add Agent, or Add API if your organization enables matching scanner capabilities.

To view the Providers section, you need these permissions or the required scanner entitlements for API, MCP, or agent scanners.

Any of these permissions:

  • Secrets Manager: View Vault Integrations

  • Secrets Manager: Manage Vault Integrations

View vaults

List and view external vaults under Platform > Providers, including sync activity and health checks.

Secrets Manager: Manage Vault Integrations

Manage vaults

Register, edit, delete, test, and sync external vaults under Platform > Providers. This permission includes View Vault Integrations.

Any of these permissions:

  • Anypoint Monitoring: Monitoring Viewer

  • Anypoint Monitoring: Monitoring Administrator

View monitoring

Open the Monitoring tab at the service and instance levels, and view Monitoring in the navigation bar.

API Manager: View Policies

View policies

View and apply policies on instances, and access policies from the Governance tab.

API Manager: Manage Policies

Apply policies

Edit policy configurations and add policies.

These permissions:

  • API Manager: Manage Policies

  • API Manager: View APIs Configuration

  • API Manager: View Policies

  • Anypoint Monitoring: Monitoring Viewer

  • Exchange: Exchange Viewer

  • Anypoint Code Builder: Mule Developer Generative AI User (Optional)

Use the Cost Management experience

Apply optimization strategies using policies, view policies, view Exchange assets, and query metrics. The Mule Developer Generative AI User permission is required to enable AI features.

Anypoint Code Builder: Mule Developer Generative AI User

Use AI features in Anypoint Code Builder

Use AI-powered features in Anypoint Code Builder, including MuleSoft Vibes and Diagnostics Agent.

Any of these permissions:

  • API Governance: Governance Administrator

  • API Manager: Manage Policies

Create governance strategies

Create governance strategies.

To view and create governance strategies, you need the Governance Administrator permission for Control types, or the Manage Policies permission for Automated Policy types.

Any of these permissions:

  • API Governance: Governance Viewer

  • API Governance: Governance Administrator

View governance reports

View governance reports at the service and governance strategy levels.

To see the conformance badge and whether rulesets passed or failed, you need the Exchange Viewer permission. To view or export detailed governance reports, including violations, warnings, and rule breakdowns, you need the Governance Viewer permission.

Any of these permissions:

  • API Manager: View API Alerts

  • Runtime Manager: Read Alerts

View alerts

View API alerts in API Manager and read alerts in Runtime Manager.

Any of these permissions:

  • API Manager: Manage API Alerts

  • Runtime Manager: Manage Alerts

Manage alerts

Manage API alerts in API Manager and alerts in Runtime Manager.

MuleSoft Agent AI User

Use MuleSoft Agent functionality

Access MuleSoft Agent functionality in the enhanced experience.

To apply open policies, or to apply, edit, enable, disable, or remove native policies on external gateways, you also need the Organization Administrator role. Without it, you can’t load an open policy catalog, open a policy configuration form, apply an open policy, or apply, edit, enable, disable, or remove native policies on an external gateway. Listing native policy templates on an external gateway still uses the View Policies permission. Viewing policies already applied on Omni or Mule gateways still uses the View Policies or Manage Policies permission. If you can’t complete an action or a page shows an authorization error, ask your Anypoint Platform organization administrator for the matching permission or role. ## See Also - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Enhanced MuleSoft Experience and Anypoint Platform Comparison](https://docs.mulesoft.com/general/exp-compare) --- product: Getting Started keywords: api management, anypoint platform, getting started, api lifecycle, mulesoft, learning map --- # Getting Started with API Management on Anypoint Platform > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API management on Anypoint Platform is a collection of new and existing products that accelerate application delivery and combat API sprawl by managing and securing any API, built and deployed anywhere. You can start anywhere in this end-to-end API lifecycle journey: design and build, discover, manage and secure, govern, and create engaging digital experiences. The end-to-end API lifecycle journey for API management consists of various tasks, each with links to relevant content to assist you in completing them.
lm start

What Is API Management?

API management is the process of creating, publishing, and overseeing application programming interfaces (APIs) in a secure and scalable environment.

API management helps ensure that APIs are reliable, secure, and easy to use, which can lead to better developer experiences and more successful applications.

lm analyze 1

Discover

Enable your developer community to discover your APIs anywhere automatically along with relevant metadata and documentation.

lm audience end 1

Engage

Create custom API portals to engage with your ecosystem of API consumers and producers.

## See Also - [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/) - [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) - [Anypoint Studio](https://docs.mulesoft.com/studio/) - [API Catalog CLI](https://docs.mulesoft.com/exchange/apicat-about-api-catalog-cli) - [API Designer](https://docs.mulesoft.com/design-center/) - [API Experience Hub](https://docs.mulesoft.com/api-experience-hub/) - [API Functional Monitoring](https://docs.mulesoft.com/api-functional-monitoring/) - [API Governance](https://docs.mulesoft.com/api-governance/) - [API Manager](https://docs.mulesoft.com/api-manager/latest/) - [Exchange](https://docs.mulesoft.com/exchange/) - [Omni Gateway](https://docs.mulesoft.com/gateway/latest/) - [Mule Gateway](https://docs.mulesoft.com/mule-gateway/mule-gateway-capabilities-mule4) --- product: Getting Started keywords: third-party apis, cross-gateway governance, provider governance, api compliance, policy enforcement --- # Govern Third-Party Provider APIs > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After connecting to a third-party API gateway provider, you can govern discovered APIs through the same governance workflow used for Anypoint Platform APIs. This enables unified governance across multiple gateway platforms. Follow these steps to govern APIs from third-party providers: 1. Connect and create a scanner. When the scanner runs, it discovers and catalogs APIs and their read-only policies. See [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) 2. Go to **Portfolio** > **APIs** and verify that discovered APIs appear, each labeled with its provider (for example, **AWS**). APIs are automatically added to the portfolio as they are discovered. 3. Create control rules to track the policies that you want to enforce across providers. You create these rules using developer skills rather than the UI. For guidance on creating policy subcategory rules, review the [Author a Governance Ruleset](https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html) skill in the MuleSoft Developer Hub. For example, use a prompt such as `create a rule to track that each API has a JWT policy applied to it`. 4. Create a [governance strategy](https://docs.mulesoft.com/general/exp-governance-create-strategy#create-with-ide) and select the control rules or automated policies to apply. The strategy evaluates conformance for all in-scope APIs, including those discovered from third-party providers. 5. Track conformance status for provider-hosted APIs through the governance strategy dashboard. Use the **Any provider** filter in the **Governed Services** tab of your governance strategy to focus on a subset of your cross-gateway environment. ## See Also - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Author a Governance Ruleset](https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html) - [Monitoring Cross-Gateway Conformance](https://docs.mulesoft.com/general/exp-governance-monitor-cross-gateway-conformance) --- product: Getting Started --- # Headless MuleSoft > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can work with the MuleSoft platform programmatically using natural language from your AI-powered IDEs, AI assistants, and Slack, skipping the web UI altogether. Developers and AI agents can discover, build on, operate, and govern the platform from their preferred tools. Your access travels over APIs and MCP servers, and the same identity and permissions apply wherever you start a request. You programmatically access the platform through several capabilities: - Build and author integrations from your IDE with the MuleSoft DX MCP Server. - Operate, govern, and monitor the platform from any MCP-capable client with the MuleSoft Platform MCP Server. - Build in Anypoint Code Builder with an AI assistant using MuleSoft Vibes. - Manage your portfolio in plain language using the MuleSoft Agent, the UI, or Slack. - Register and monitor your services (agents, APIs, MCP servers, model proxies, and gateways) in centralized Portfolio catalogs, with governance, cost, and monitoring applied across the services. - Use Developer Hub, a catalog open to both humans and agents, to discover what you can build on. Because access is governed by Anypoint Platform Access Management, the permissions that apply on Anypoint Platform apply on every surface. ## Roles and Surfaces
RoleTasksSurfaces

Developers

Build, deploy, and operate services. Manage assets, configure gateways, and apply policies.

Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, other supported IDEs, and Anypoint Code Builder with MuleSoft Vibes.

Platform and governance teams

Register services, apply governance strategies, and monitor health and costs.

The platform UI and Slack

Business and operations users

Get answers, receive alerts, and run common actions in plain language.

Slack

AI agents

Discover and operate platform capabilities within their user’s permissions.

Any MCP-capable surface

## The Surfaces ### MuleSoft MCP Servers Use the DX MCP Server to build and author in your IDE. Use the Platform MCP Server to operate, govern, and monitor the platform. Some IDEs can connect to both. #### MuleSoft DX MCP Server The MuleSoft DX MCP Server lets AI-powered development assistants in your IDE interact with Anypoint Platform, so you build and manage applications without leaving your coding environment. From natural-language prompts, generate Mule flows and API specs. Generate and modify MUnit tests, create MCP servers, manage API instances and policies, deploy and update Mule applications, and search assets. For setup and prerequisites, see [Getting Started with MuleSoft DX MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started). #### MuleSoft Platform MCP Server The MuleSoft Platform MCP Server gives AI tools governed access to your agentic landscape, including APIs, agents, MCP servers, and LLMs. Use it to scan, discover, govern, and monitor services in natural language. Tool categories include Exchange, API Manager, Anypoint Monitoring, Governance, Runtime Manager, and Cost Management. For setup and prerequisites, see [Getting Started with MuleSoft Platform MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started-platform). ### MuleSoft Vibes MuleSoft Vibes is an AI assistant for the development lifecycle, built into Anypoint Code Builder. Using natural language and generative AI, build, deploy, and manage projects. Develop API specifications, create and configure applications, search for assets, deploy and manage instances, and secure applications. Vibes connects to your MuleSoft environment through the MuleSoft MCP Server and supports reusable skills. For prerequisites, see [MuleSoft Vibes Before You Begin](https://docs.mulesoft.com/anypoint-code-builder/mulesoft-vibes#before-you-begin-vibes). ### MuleSoft Agent The MuleSoft Agent is an AI assistant available throughout the platform UI and in Slack. Use the MuleSoft Agent to navigate, search, and manage your portfolio through conversation. Capabilities include portfolio management, governance, monitoring and observability, cost management, navigation, and platform configuration. The agent respects your Access Management permissions, confirms actions before making changes, and logs every action. The MuleSoft Agent is available on request. To get access, contact your account executive or MuleSoft representative to request enablement. For prerequisites, see [MuleSoft Agent Before You Begin](https://docs.mulesoft.com/general/exp-ai-assistant-use#before-you-begin). > [!NOTE] MuleSoft Vibes and the MuleSoft Agent are different assistants. Use MuleSoft Vibes to > build integrations, APIs, and applications in Anypoint Code Builder. Use the MuleSoft Agent to > operate and manage your portfolio, including governance, monitoring, and cost, from the platform > UI or Slack. ### Developer Hub The [MuleSoft Developer Hub](https://dev-portal.mulesoft.com) is a portal for developers and AI agents to discover, interact, and build together. It catalogs platform APIs, skills (agent workflows), MCP servers, and Terraform resources. Browse, search, and filter the catalog in a web UI, and your agents consume machine-readable entry points (`AGENTS.md`, `registry.json`, and `llms.txt`) to discover and invoke capabilities. Skills cover tasks such as building a Mule integration, securing an API, agent, or MCP server, applying a policy to an API instance, and building or translating an agent network (agent broker) project. ### Slack The MuleSoft for Slack app connects a Slack workspace to a MuleSoft organization for notifications, shortcuts, and deep links. Slackbot can connect to the Platform MCP Server for Q&A, and the MuleSoft Agent can take governance and management actions from the channel. The MuleSoft Agent is available on request. To get access, contact your account executive or MuleSoft representative. For setup, see [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate). ## User Journeys These journeys show how developers, platform teams, and agents use the surfaces to build, operate, and govern on the platform. ### Journey 1: Build in Your IDE Role: Developer 1. In a supported IDE such as Cursor, VS Code, or Claude Desktop, register the **MuleSoft DX MCP Server**. 2. Use natural-language prompts to generate a Mule flow or API spec, then generate MUnit tests to validate it. 3. Deploy the Mule application and manage its API instance and policies, all from your editor. Never switch to a separate console to finish the build. ### Journey 2: Build with MuleSoft Vibes in Anypoint Code Builder Role: Developer 1. In Anypoint Code Builder, chat in natural language with MuleSoft Vibes to develop an API specification and create and configure an application. 2. Vibes connects to the MuleSoft environment through the MuleSoft MCP Server, so you search for assets, deploy, and manage instances without leaving Code Builder. 3. Apply reusable skills to standardize repeated tasks across your workspace. ### Journey 3: Operate and Govern from Your IDE or Assistant Role: Developer or platform team 1. From an MCP client such as Claude Desktop, Cursor, or MuleSoft Vibes, connect to the MuleSoft Platform MCP Server and authenticate into your organization. 2. Use natural language to interact with the platform, for example: - `Show me all payment-related APIs across my organization.` - `Help me set up a rate-limiting policy on my Stripe API.` - `Which LLMs consumed the most requests last week?` 3. For a policy request, the agent fetches the applicable policies, presents configuration options, and applies the policy to the instance, all within your permissions. ### Journey 4: Operate the Platform in Plain Language Role: Platform or governance team 1. Working in the platform UI or in Slack, ask the MuleSoft Agent for what you need, for example: - `Create a governance strategy that applies a PII detection policy to all customer-facing agents.` - `Show me the health of my customer-facing APIs.` 2. The agent uses page and portfolio context, shows a confirmation before any change, and guides multi-step tasks. 3. Actions run within your Access Management permissions and are logged and auditable. ### Journey 5: Make Your Existing APIs Agent-Ready (API Owner and Platform Team) Role: API owner or platform team 1. An AI team needs managed APIs available to their agents, but those APIs include write and delete operations that are too risky to expose. 2. In API Manager, expose a target API as an MCP server and map only the safe operations (for example, GET-only) to MCP tools, with no changes to the underlying API. 3. The MCP server runs on MuleSoft Omni Gateway, where existing authentication, policies, and monitoring apply to every agent request. 4. Agents connect to the MCP server endpoint and can call only the operations that were explicitly exposed. Usage is monitored alongside the team’s other services. ### Journey 6: Discover What You Can Build On (Developer or Agent) Role: Developer or agent 1. Open the Developer Hub, where you browse and filter APIs, skills, MCP servers, and Terraform resources, and agents read `AGENTS.md`, `registry.json`, and `llms.txt` to know which platform capabilities exist and how to call them. 2. Find the capability you need and build on it, from one catalog, instead of rebuilding what already exists. ## Where to Start Pick the surface that matches your role, then follow the setup topic for that surface. 1. Developers: Connect the DX MCP Server in your IDE, or open MuleSoft Vibes in Anypoint Code Builder. 2. Platform and governance teams: Connect the Platform MCP Server, or ask the MuleSoft Agent in the UI or Slack. 3. Anyone discovering capabilities: Browse Developer Hub to get started. ## Related Resources - [Getting Started with MuleSoft DX MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started) - [MuleSoft Vibes Overview](https://docs.mulesoft.com/anypoint-code-builder/mulesoft-vibes) - [Getting Started with MuleSoft Platform MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started-platform) - [Using the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-use) - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) - [MuleSoft Developer Hub](https://dev-portal.mulesoft.com) --- product: Getting Started keywords: microsoft teams integration, mulesoft agent, teams bot, mcp server, anypoint platform, enhanced experience --- # Integrate the Enhanced Experience with Microsoft Teams > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the MuleSoft for Teams app in your Microsoft Teams tenant to interact with MuleSoft directly from Teams using natural language. The Teams app enables you to: - [Connect Your Microsoft Teams Tenant to the MuleSoft Organization](#connect-teams-tenant): Bind your Microsoft Teams tenant to your Anypoint organization so the app can send alerts and notifications directly to channels and DMs. - [Begin Using the MuleSoft Agent](#begin-using-agent): Manage your MuleSoft environment with the MuleSoft Agent integrated with Teams. Use MuleSoft Agent, to list APIs, view MCP servers, check governance, and perform other management tasks. - Configure alerts to deliver notifications to Teams channels. For instructions, see [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications). > [!NOTE] This tool uses generative AI, which can produce inaccurate or harmful responses. Review > for accuracy and safety before using. ## Before You Begin Before setting up the Teams integration, verify that the following requirements are met: - **Generative AI enabled**: Generative AI must be enabled in your Anypoint Platform and Salesforce organizations. For more information, see [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - **Salesforce-Anypoint Connection**: Your Anypoint Platform organization must be fully connected to your Salesforce organization. - **Early Access Program**: The MuleSoft Agent feature must be enabled for your organization by the MuleSoft team as part of the Early Access Program. Contact your Customer Success Manager (CSM) or Account Executive (AE) to join the program. ## Connect Your Microsoft Teams Tenant to the MuleSoft Organization You must be a MuleSoft organization administrator and a Microsoft Teams administrator to connect the Teams integration. If you are not a Teams administrator, you can send a request to your Teams administrator to approve the app. Each MuleSoft organization can connect to only one Microsoft Teams tenant, and each tenant can connect to only one MuleSoft organization. 1. Log in and go to **Notifications** > **Settings**. 2. In **Microsoft Teams Setup**, click **Install Microsoft Teams app**. This publishes the Teams app to your AAD tenant’s app catalog through Microsoft Graph. If the tenant hasn’t yet consented to this app, you’re redirected to Microsoft to grant admin consent. 3. Select your Microsoft Teams admin account. 4. Review the permissions requested and click **Accept**. The app requests the following permissions: - Read and write to all app catalogs - Maintain access to data you have given it access to - View your basic profile 5. After the installation completes, the confirmation page displays **Microsoft Teams integration installed**. Click **Back to Settings**. In **Notifications** > **Settings**, the **Microsoft Teams Setup** section now shows **Installed** and displays the bound tenant ID. 6. Click **Grant Access** to allow the app to browse your Teams directory for channel and team member access. 7. In Microsoft Teams, review the permissions requested and click **Accept**. After access is granted, configure notification channels in the **Notification Channels** section. After installation, the MuleSoft Agent app appears in Microsoft Teams Admin Center under **Manage apps** as available to everyone and unblocked. To disconnect the integration: 1. Click **Disconnect** in the **Microsoft Teams Setup** section. 2. Confirm the disconnection. This immediately revokes MuleSoft’s access to your Teams tenant and stops all notifications. The MuleSoft app remains in the Microsoft Teams Admin Center. To fully remove it, a Teams administrator must uninstall it from the Admin Center, or right-click the app in Teams and select **Uninstall**. ## Begin Using the MuleSoft Agent > [!IMPORTANT] MuleSoft Agent is available on request. To get access, contact your account > executive. Before getting started, make sure you have: - An Anypoint Platform account with access to the enhanced experience. - Generative AI enabled in your Anypoint Platform and Salesforce organizations by your administrator. For more information, see [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - The **MuleSoft Agent AI User** permission assigned to your user. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). To assign the **MuleSoft Agent AI User** permission across business groups: 1. Log in to Anypoint Platform and open **Access Management**. 2. Select the business group where you want to assign the permission. 3. Find the user and assign the **MuleSoft Agent AI User** permission. 4. Repeat for each business group that requires access. To start using the agent in Teams: 1. Open Microsoft Teams and go to **Apps**. 2. Under **Built for your organisation**, find **MuleSoft Agent** and click **Add**. 3. Click **Open** or select a channel where you want to use the app. 4. The agent sends a welcome message. Select a prompt suggestion or type a message to start. 5. If prompted, click **Connect to MuleSoft** and sign in with your Anypoint Platform credentials. 6. After authenticating, close the browser tab to complete account linking. Return to Teams to continue the conversation. After you authenticate, you can use the agent to list APIs, agents, MCP servers, view governance reports, and more. > [!NOTE] After the first 24 hours, you must @mention the MuleSoft Agent in channels to send it a > message. In direct messages, you can send messages to the agent at any time without @mentioning > it. ## Available Prompt Suggestions When you open the MuleSoft Agent, the following prompt suggestions are available: - **signin**: Connect your MuleSoft account. - **signout**: Disconnect your MuleSoft account. - **What business group am I in?**: Shows your current business group. - **List APIs in my business group**: Lists APIs in your current business group. - **Risks across my portfolio?**: Shows risks across your portfolio. - **Top MCP token spend this week**: Shows which MCP servers had the highest token spend this week. - **Which agents have instances?**: Lists agents that have instances. - **Top API error rates (7 days)**: Shows APIs with the highest error rates over the past 7 days. - **feedback**: Send feedback to the MuleSoft Agent team. - **help**: Show available commands. ## Common Use Cases for the MuleSoft Agent You can use the MuleSoft Agent to perform these platform tasks in Teams: - **Receive alerts**: Receive alerts to channels. For more information, see [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications). - **Find services by capability**: Use natural-language search to discover APIs, agents, LLMs, and MCP servers. - **Run governance, monitoring, and cost drill-ins**: Generate governance, monitoring, and cost reports on request. - **Take governance actions**: Apply policies and apply cost management recommendations. ## Microsoft Graph Permissions The MuleSoft for Microsoft Teams app requires the following Microsoft Graph permissions. Use this information when your security or IT team asks for justification before approving the app installation.
PermissionTypePurpose

AppCatalog.Read.All

Application

Verifies that the MuleSoft app is properly published in your Teams app catalog. Without this, the app cannot confirm its own availability, and users see silent failures instead of actionable setup errors.

AppCatalog.ReadWrite.All

Delegated

Required when a Teams admin publishes or updates the MuleSoft app package in your catalog. Only exercised during install or upgrade — not at runtime — and scoped to the consenting admin’s session.

AppCatalog.ReadWrite.All

Application

Allows the MuleSoft app to receive updates, such as new Adaptive Card formats or capability additions, without requiring an admin to manually republish each time.

Channel.ReadBasic.All

Application

Delivers API alerts and deployment notifications to specific channels you configure. The app reads channel names and IDs to resolve routing rules. It reads channel metadata only — not message content.

Team.ReadBasic.All

Application

During setup, lets you map MuleSoft environments and business groups to specific teams without manually looking up team IDs. Read-only access to team names and descriptions — no access to members or content.

TeamsAppInstallation.ReadWriteAndConsentForTeam.All

Application

Lets a Teams admin roll the app out to all relevant teams in a single action with automatic RSC consent, rather than requiring each individual team owner to install it separately.

TeamsAppInstallation.ReadWriteForTeam.All

Application

Manages the app lifecycle across teams, including handling version upgrades and removing the app from teams where it is no longer needed.

TeamSettings.Read.All

Application

Checks team policies before the app attempts to post. If a team has restricted messaging or moderation enabled, the app surfaces a clear configuration error rather than silently dropping critical API alerts. Read-only — it does not change settings through this permission.

TeamSettings.ReadWrite.All

Application

During initial provisioning only, the app may adjust channel settings to enable bot posting in moderated channels where incident alerts must be delivered. This is a one-time setup action, not ongoing runtime behavior.

User.Read

Delegated

Standard sign-in permission for the admin performing the initial consent. The app reads basic profile information (name, email) to log who authorized the connection between the Anypoint Platform organization and the Teams tenant.

## Security, Data Retention, and Residency - **Hyperforce and data boundaries**: The MuleSoft Agent respects your designated Hyperforce region. Install the regional app for Teams that corresponds to your region. Customer data never leaves your designated Hyperforce boundary. - **LLM architecture and web access**: The MuleSoft Agent uses the Salesforce LLM-Gateway, powered by OpenAI GPT-5-mini. The agent does not perform public web searches. - **Data retention and compliance**: Data retention policies, data removal, LLM data tenancy, and infrastructure details are covered in the applicable Salesforce Security, Privacy, and Architecture (SPARC) documentation. Customer data is securely deleted upon expiration of the applicable retention periods in accordance with SPARC guidelines. For more information, see the [Salesforce Trust and Compliance Documentation](https://www.salesforce.com/company/legal/trust-and-compliance-documentation/). ## See Also - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Integrate the Enhanced Experience with Slack](https://docs.mulesoft.com/general/exp-slack-integrate) - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) --- product: Getting Started keywords: slack integration, mulesoft agent, slackbot, mcp server, slash commands, slack workspace, enhanced experience --- # Integrate the Enhanced Experience with Slack > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install the MuleSoft for Slack app in your Slack workspace to receive notifications, run shortcuts, and provide deep links for responders to jump directly into the enhanced experience. The Slack app enables you to: - [Connect Slackbot to the MuleSoft Platform MCP Server](#connect-slackbot-mcp): Connect Slackbot to the Mulesoft Platform MCP Server to answer questions about the MuleSoft platform. - [Begin Using the MuleSoft Agent](#begin-using-agent): Manage your MuleSoft environment with the MuleSoft Agent integrated with Slack. Use the MuleSoft Agent to create scanners, apply policies, deploy instances, and perform other management tasks. - Configure alerts to deliver notifications to Slack channels and DMs. For instructions, see [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications). Available commands, message templates, and workspaces depend on how your organization configured the Slack app. Internal runbooks list the slash commands or shortcuts approved for your workspace. > [!NOTE] This tool uses generative AI, which can produce inaccurate or harmful responses. Review > for accuracy and safety before using. ## Connect Your Slack Workspace to the MuleSoft Organization You must be a MuleSoft organization administrator to connect or disconnect the Slack integration. Each MuleSoft organization can connect to only one Slack workspace, and each Slack workspace can connect to only one MuleSoft organization. 1. Log in and go to **Notifications** > **Settings**. 2. In **Slack Setup**, click **Install**. 3. Select the Slack workspace you want to connect to your MuleSoft organization. 4. Click **Allow**. You may need Slack admin permissions to install this app in your organization’s Slack workspace. Submit a request to install the app to your Slack administrator if you don’t have the permissions. 5. After the app is installed, select Slack as a notification delivery channel when you configure alerts and run shortcuts by using `@MuleSoft` in your Slack workspace. ## Connect Slackbot to the MuleSoft Platform MCP Server After installing the Slack app app, connect Slackbot to the [Getting Started with MuleSoft Platform MCP Server](https://docs.mulesoft.com/mulesoft-mcp-server/getting-started-platform) to answer questions about the MuleSoft platform. 1. Open Slackbot. 2. Click the Slackbot logo again. 3. Click **Integrations**. 4. Click **Connect** for **MuleSoft Platform - MCP** and sign in to Anypoint Platform. Slackbot can now access information from the MCP Platform Server. ## Begin Using the MuleSoft Agent > [!IMPORTANT] MuleSoft Agent is available on request. To get access, contact your account > executive. Before getting started, make sure you have: - An Anypoint Platform account with access to the enhanced experience. - Generative AI enabled in your Anypoint Platform and Salesforce organizations by your administrator. For more information, see [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - The **MuleSoft Agent AI User** permission assigned to your user. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). To assign the **MuleSoft Agent AI User** permission across business groups: 1. Log in to Anypoint Platform and open **Access Management**. 2. Select the business group where you want to assign the permission. 3. Find the user and assign the **MuleSoft Agent AI User** permission. 4. Repeat for each business group that requires access. To start using the agent in Slack: 1. Open Slack in the workspace your company uses for MuleSoft or platform notifications. 2. Open the MuleSoft app your administrator added. 3. To message the agent in channels, add the agent to the channel and tag (`@MuleSoft`) with your question. You can only use slash commands in channels. To message the agent in DM, open the MuleSoft app in Slack and start a conversation with the agent. You can forward the agent’s responses to other team members or channels. 4. If it is your first time using the agent, follow the authentication flow when prompted to connect your Anypoint account to Slack. ## MuleSoft Agent Slash Commands - `/mule help` Shows available commands and short usage notes in Slack. - `/mule feedback` Opens a feedback form to report bugs, request features, or send product feedback. - `/mule signin` Opens the authentication flow to connect your Anypoint account to Slack. If you’re already signed in it may show your connection status or prompt to re-authenticate. ## Common Use Cases for the MuleSoft Agent You can use the MuleSoft Agent to perform these platform tasks in Slack: - Receive alerts: Receive alerts to channels or direct messages (DMs). You can configure notifications to be sent to Slack. For more information, see [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications). - Find services by capability: Use natural-language search to discover APIs, agents, LLMs, and MCP servers. - Run governance, monitoring, and cost drill-ins: Generate governance, monitoring, and cost reports on request. - Take governance actions: Apply policies and apply cost management recommendations. ## See Also - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Connect the Enhanced Experience to Claude Desktop](https://docs.mulesoft.com/general/exp-claude-desktop-connect) --- product: Getting Started keywords: java support, mule runtime, java upgrade, mule apps, java version, mulesoft java compatibility --- # Java Support > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Extended support for Java 8 and 11 ends in February 2027 for 4.6 LTS. Upgrade your apps that run on Java 8 or 11. MuleSoft is adopting Java’s long-term-support (LTS) release cadence, beginning with Mule runtime 4.6, which adds support for Java 17 LTS. Upgrading to Java 17 provides many benefits, including improved performance, language-level enhancement, increased security, and extended APIs and libraries. Many third-party vendors are discontinuing support for Java 8, which impacts the MuleSoft product stack. Adopting the new LTS release cadence provides greater security, compliance, and performance. Even though this change has no immediate impact to Mule applications that are running on currently supported Mule versions, or on applications that are upgraded to Mule runtime 4.6, it’s best to start your upgrade planning now. Java 17 upgrade planning includes evaluating integration apps, connectors (Anypoint connectors and custom connectors), Mule Gateway policies, and API proxies, as all of these components rely on Java. Existing Java 8 apps will continue to run on Java 8 until the end of extended support for the Mule version they’re running on is reached. ## Mule Runtime Java Support The following table shows the timeline for Java 8, Java 11, and Java 17 support:
Mule VersionJava Version

4.13 Edge

17

4.12 Edge

17

4.11 Edge

17

4.10 Edge

17

4.9 LTS

17

4.9 Edge

17

4.8 Edge

8, 11, and 17

4.7 Edge

8, 11, and 17

4.6 LTS

8, 11, and 17

4.6 Edge

8, 11, and 17

4.5 Edge

8 and 11

In Mule 4.6.0 and later, the maximum supported version for running your applications is Java 17. In Mule 4.9.0 and later, you can compile any Mule project and additional dependencies for Java 17 or lower. In versions earlier than Mule 4.9.0, you must compile any Mule project and additional dependencies for Java 8. When selecting a dependency (for example, `mssql-jdbc`), configure the version compatible with Java 8 or Java 17 in the `pom.xml`. For information about compatibility details, refer to the documentation of the dependency. For more information about Mule release cadences, see [Edge and LTS Releases for Mule](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence). ## Steps for Upgrade Follow these steps to upgrade to Java 17: - **Pre-Upgrade** 1. Review your current setup to identify what needs upgrading or removal (such as any Java features that are no longer supported or are marked as deprecated in Java 17). 2. Create a comprehensive upgrade plan, including testing, rollback strategies, and post-upgrade checks. 3. Learn about [application performance](#application-performance) when upgrading to Java 17. 4. For on-prem (as with any upgrade), schedule downtime and inform stakeholders to minimize business disruption. - **Upgrade** 1. Upgrade to [Mule runtime 4.6](#mule-runtime). 2. Upgrade all [Anypoint Connectors and modules](#anypoint-connectors-and-modules), and [custom connectors](#custom-connectors) used within Mule apps and policies to Java 17. Connectors containing [custom Java code](#custom-code-in-connectors) need additional modifications to ensure compatibility with Java 17. 3. Upgrade your [policies](#policies). Policies containing custom Java code need additional modifications to ensure compatibility with Java 17. 4. Upgrade your [API proxies](#api-proxies) and [Mule apps](#mule-apps). Proxies containing custom Java code need additional modifications to ensure compatibility with Java 17. 5. Upgrade [Anypoint Studio](#anypoint-studio) to 7.17 and change the target JVM at the Studio project level to upgrade or downgrade the JVM. 6. Learn about [DataWeave](#dataweave) updates for Java 17 and verify your apps continue to work as expected. 7. Test your apps in a controlled environment before going live. 8. If you are using Mule Maven plugin 4.1.1 and later to deploy your apps, [configure the deployment](#mule-maven-plugin) to use Java 17. - **Post-Upgrade** 1. Monitor your apps for any unexpected behavior. 2. Update any relevant documentation to reflect changes made during the upgrade. ## Mule Runtime To take advantage of the improved performance and security of Java 17, [upgrade to Mule runtime 4.6 or later](https://docs.mulesoft.com/release-notes/mule-runtime/updating-mule-4-versions). Follow these best practices: - Upgrade your standalone Mule instances. - Upgrade on-premises Mule instances that are managed through Runtime Manager. - Update the Mule version used to build your Mule applications. - [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) to a target running on Mule 4.6 or later. ## Mule Apps You can update, test, and redeploy most of your currently running Mule apps to use Java 17. However, any apps and connectors that are running custom Java code require additional work to certify those components. Before you upgrade your integration apps or Mule Gateway policies and proxies to Java 17, you must update all extensions, modules, and connectors used within those apps and policies to Java 17. > [!NOTE] In Mule 4.6.0 and later, the maximum supported version for running your applications is > Java 17. In Mule 4.9.0 and later, you can compile any Mule project and additional dependencies for > Java 17 or lower. In versions earlier than Mule 4.9.0, you must compile any Mule project and > additional dependencies for Java 8. > > When selecting a dependency (for example, `mssql-jdbc`), configure the version compatible with > Java 8 or Java 17 in the `pom.xml`. For information about compatibility details, refer to the > documentation of the dependency. > [!IMPORTANT] To ensure your API proxies or Mule apps are protected when upgrading, upgrade your > policies _before_ upgrading your API proxies or Mule apps. ## Java 17 Performance Considerations Java 17 provides important performance changes to MuleSoft products. Java 17 includes a new JIT compiler, which improves code execution speed. To enhance application performance, see: - [Memory Management](#memory-management) - [Default TLS Cipher Selection](#default-tls-cipher-selection) ### Memory Management Java 17 manages memory differently than it did in earlier versions like Java 8. Java 17 reduces request latency and executes work more predictably. To achieve this, it adopts a different memory management approach. Although highly dependent on each application, in some cases, Java 17 preferentially commits to heap memory. When running Mule applications on Java 17, you might observe heap memory patterns that differ from Java 8. For example, heap usage can remain at a higher baseline or not decrease immediately after load. This behavior is expected and reflects how Java manages memory. For more information, see [Mule heap memory pattern differences between Java 17 and Java 8](https://help.salesforce.com/s/articleView?id=005132434&type=1). > [!NOTE] To ensure optimal operation of your apps and effectively leverage the Java 17 > improvements, you must conduct > [performance testing](https://docs.mulesoft.com/mule-runtime/latest/tuning-test-validations) and > [monitoring](https://docs.mulesoft.com/mule-runtime/latest/tuning-monitoring) for: > > - Large batch apps > > - Apps that are at the limit of their CPU and memory offering If your apps are deployed on-premises: - If your workloads run on Runtime Fabric, you must allocate at least 1400 MB of memory for 0.50 vCPU replica sizes. Because memory requirements vary for individual apps, this minimum provides the best memory allocation configuration for most applications. - If your workloads run on-premises, such as in a hybrid or standalone environment, you must tune your operating system’s garbage collection algorithm. ### Default TLS Cipher Selection When using TLS in a server with Java 11 and later, the server determines the cipher preference. The client supported ciphers list is used to filter, not to determine priority. See [Use server cipher suites preference by default (JDK-8168261)](https://bugs.openjdk.org/browse/JDK-8168261). Upgrading your server from Java 8 to Java 11 and later can cause cipher renegotiation (depending on the supported ciphers list of the client), which can affect the trade-off between security and performance. If you want to change the cipher’s default values, see [Specify Protocols and Cipher Suites](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#optional-specify-protocols-and-cipher-suites). ## Anypoint Connectors and Modules Anypoint Connectors and modules are certified by MuleSoft to run on Java 17. For information about Java 17 support for each connector and module, see the [Release Notes](https://docs.mulesoft.com/release-notes/connector/anypoint-connector-release-notes#mule_4) for that Mule 4 connector or module. ### Where to Find Java Compatibility Information for Connectors and Modules All Anypoint Connectors and modules are Java 17-compatible now. Check the release notes for your connector to see which connector versions are compatible with Java 17. Java compatibility information is also provided on the [Exchange](https://docs.mulesoft.com/exchange/asset-versions) details page for connectors and modules in the **Asset versions** table. This is the most current compatibility information, as connectors are tagged as Java 17-compatible when they are released. ![Expanded menu to show asset version detail option](/mulesoft/current/en-us/general/_images/exchange-version-detail.png) For a list of Java 17-compatible connectors and their respective versions, see [Java 17-Compatible Anypoint Connectors](https://help.salesforce.com/s/articleView?id=000782248&type=1). ### Upgrading Anypoint Connectors To upgrade Anypoint Connectors that are provided by MuleSoft and being used out-of-the-box (no custom code): 1. In Runtime Manager, update the Mule app that has your connectors to run on Mule runtime 4.6 or later. 2. In Anypoint Studio, [change the target JDK](https://docs.mulesoft.com/studio/change-jdk-config-in-projects) at the project property level. 3. When you select JDK 17, Studio automatically prompts you to update the connectors in your project. 4. During packaging, Studio provides guidance and alerts if there are any connectors in your project that are incompatible with the selected JDK version. 5. [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) to a target running on Mule 4.6 or later. Runtime Manager shows alerts if there are any mismatches between the project’s Java version and the deployment environment. If your connector includes custom code, go to [Custom Connectors](#custom-connectors). ## Custom Connectors Custom connectors (including custom configuration properties providers) are any connectors that are not developed and maintained by MuleSoft, including connectors that are built by MuleSoft partners or customers. If you are using a custom connector in your app, you must update your connector to run on Java 17 and Mule runtime 4.6 and later. If you are a MuleSoft partner: 1. In your Mule app, update your connector that is generated from: - [Mule SDK](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST SDK (beta)](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-rest-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-rest-connect-connectors) - [Configuration Properties Providers](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. Test your connector using [Module Testing Framework (beta)](https://docs.mulesoft.com/general/partner-connector-upgrade#test-your-custom-connector-with-mtf). 3. [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) to a target running on Mule 4.6 or later. If you are a MuleSoft customer: 1. In your Mule app, update your connector that is generated from: - [Mule SDK](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-rest-connect-connectors) - [Configuration Properties Providers](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. Test your connector using [MUnit](https://docs.mulesoft.com/general/customer-connector-upgrade#test-your-custom-connector-with-munit). 3. [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) to a target running on Mule 4.6 or later. ## Custom Code in Connectors If you have custom code in your connectors, or if you are using third-party libraries, you must update that custom code to be compatible with Java 17. - Reflection on Java classes To ensure compatibility with Java 17, review and update any code that uses reflection to access Java classes or set parameter values. Java 17 imposes stricter access controls, so avoid introspecting JDK internals. Have a robust test suite that runs with Java 17. Pay special attention to the `setAccessible(true)` method because these access changes are not allowed in Java 17. - Java Platform Module System (JPMS) JPMS was introduced in Java 9. This feature introduces stricter encapsulation, impacting how Mule modules interact with JDK classes. As Mule upgrades to Java 17 and JPMS, these changes are necessary: - Refactor Split Packages: Resolve issues with internal and API package splits by reorganizing and refactoring packages to conform with JPMS modularization standards. - Address `ResourceBundle` Loading: Implement solutions for issues related to resource bundle loading, such as using `ResourceBundleProvider` or alternative methods. - Analyze the third-party libraries' changelogs to understand Java 17 compatibility and changes related to JPMS. - Unsupported directives Don’t set `--add-opens`, `--add-exports`, or `--add-modules` directives. These directives are not allowed in CloudHub, Runtime Fabric, or on-premises. These directives also require managing them for each connector across all environments, and introduce a backward compatibility burden, complicating future Java upgrades and potentially enabling security vulnerabilities. If these directives are used, they are not covered under Support. - JDK Migration Guide See the [Oracle JDK Migration Guide](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A) for a full list of the changes made from Java 8 to Java 17. Use the guide to assess the impact to your code. ## Anypoint Studio Starting with Anypoint Studio (Studio) 7.17, if your Mule app is running on Mule runtime 4.6 or later, you can change the target JVM at the Studio project level to upgrade or downgrade the JVM. Studio 17 provides compatibility guidance: - When you package your app, Studio 7.17 offers real-time guidance and alerts you if there are any incompatible connector versions or project mismatches to prevent deployment failures. - When you add a new connector or module to your project, Studio shows the supported JVM version for each version of the connector or module. - When you upgrade an existing Studio project to Java 17, Studio automatically searches Exchange and suggests which extensions (modules and connectors) in your app to upgrade. - When you deploy an app to CloudHub from Studio, Runtime Manager proactively detects mismatches between the project’s Java version and the deployment environment. For example, if your project is built for Java 8 and your target environment is Java 17, Runtime Manager and Studio provide guidance to prevent deployment failures. For more information, see [Select a Different Java Version to Run the Embedded Mule Runtime](https://docs.mulesoft.com/studio/change-jdk-config-in-projects) and [Update Mule Modules in Anypoint Studio](https://docs.mulesoft.com/studio/update-modules). ## Policies The MuleSoft-included Mule Gateway policies are compatible with Java 17 beginning with the Mule runtime 4.6 release. These policies continue to have standard support for Java 8 until February 2025, so it’s best to start updating your policies as soon as possible. > [!IMPORTANT] To ensure your API proxies or Mule apps are protected when upgrading, upgrade your > policies _before_ upgrading your API proxies or Mule apps. For details about how to upgrade your policies, see [Upgrading Automated Policies](https://docs.mulesoft.com/general/upgrade-policies-proxies#upgrading-automated-policies) and [Upgrading API-Level Policies](https://docs.mulesoft.com/general/upgrade-policies-proxies#upgrading-api-level-policies). ## API Proxies The MuleSoft-included API proxies are compatible with Java 17 beginning with the Mule runtime 4.6 release. These API proxies continue to have standard support for Java 8 until February 2025, so it’s best to start updating your API proxies as soon as possible. > [!IMPORTANT] To ensure your API proxies or Mule apps are protected when upgrading, upgrade your > API policies _before_ upgrading your API proxies or Mule apps. The steps to upgrade are a little different, depending on your **Proxy type**: - Basic endpoint: - If you use Basic endpoint, deploy the adapted application to the Mule runtime instance and connect it to API Manager using autodiscovery. For more information, see [Configuring Mule Gateway API Autodiscovery in a Mule 4 Application](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4). - If you use a Basic endpoint API instance to update your instance, update the Mule application connecting to your API instance. - Proxy application For details about how to upgrade your proxy applications, see [Upgrading API Proxies](https://docs.mulesoft.com/general/upgrade-policies-proxies#upgrading-api-proxies). ## Mule Maven Plugin If you are using Mule Maven plugin 4.1.1 and later to deploy your apps, you can configure the deployment to use Java 17. When deploying to CloudHub, Mule Maven plugin deploys the latest build version of a release train when the build version has a major and minor version. Mule Maven plugin has a new Java version property to explicitly deploy to a specified Java version. When deploying to Runtime Fabric and CloudHub 2.0, Mule Maven plugin accepts the entire tag of the build so you can use the correct semantic version (SemVer) in your deployment. For more information, see the following documentation: - [Deploy Applications to CloudHub Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub) - [Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub-2) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) ## DataWeave DataWeave uses Java’s reflection API to read and write Java objects. Java 17 adds some restrictions in encapsulation and reflective access that affect the Java Data Format and Mule objects. To ensure that your applications continue to work as expected, follow these guidelines: - Verify that the objects used by your application are Plain Old Java Objects (POJOs). POJOs are required for DataWeave 2.6.0 and later. Because reflection is more restricted in Java 17, POJOs now require setters as well. Previously, POJOs had default constructors and getters for all properties. Now, POJOs must also have setters so DataWeave can build outside the connector in the Mule app. Constructors and setters are required if your class is instantiated by DataWeave, and getters are required if your class is read. If your class is returned and not instantiated, only getters are required. However, using both getters and setters simplifies the validation and certification process. You must ensure that the POJOs have: - A default constructor - Getters for all properties - Setters for all properties - Verify that predefined variables are accessed through their proper API. Variables like `attributes`, `message`, and `error` have specific access APIs. Using the proper fields is required when using Java 17 because internal fields are no longer accessible. For example: - `error.muleMessage` needs to be replaced by the proper Mule error field `error.errorMessage`. - `error.errors` needs to be replaced by the proper Mule error field `error.childErrors`. For more information, see the following documentation: - [Java Format](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#java-support) - [Predefined Variables](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) ## See Also - [Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/anypoint-connector-release-notes) - [Upgrading MuleSoft to Java 17: A Comprehensive Guide](https://help.salesforce.com/s/articleView?id=002139151&type=1) --- product: Getting Started keywords: agent fabric, mulesoft, getting started, ai agents, learning map, anypoint platform --- # Learn About Agent Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt AI agents, MCP servers, and APIs are built across multiple platforms. That makes reuse, consistent security, and end-to-end LLM spend tracking difficult. Agent Fabric is the control plane for that landscape. - Find every agent, MCP server, and API in the registry so you reuse what exists instead of rebuilding it. - Make the APIs, applications, and agents you already run available as tools, so agents can take action without a rebuild. - Put the same authentication, access, and security rules on live traffic, regardless of which platform built the agent. - See where token spend goes, cap it, and stop paying a frontier model for work a smaller model can do. The end-to-end journey for Agent Fabric consists of these tasks, each with links to relevant content to assist you in completing them.

Learn About Agent Fabric

Start with how the registry, agent actions, governance, and cost control fit together. Then pick a job.

Enable Agent Actions

Make the APIs, applications, and agents you already run available as tools. Start by exposing existing APIs as MCP servers, and use an A2A bridge for agents that aren’t A2A-compliant. Add a broker only when work spans specialized agents.

## See Also - [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) - [Connecting a Trusted Salesforce Organization to Anypoint Platform](https://docs.mulesoft.com/access-management/connecting-salesforce-orgs) - [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai) - [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/) - [Anypoint Exchange](https://docs.mulesoft.com/exchange/) - [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) - [Agent Visualizer](https://docs.mulesoft.com/agent-visualizer/) --- product: Getting Started keywords: a2a bridge, agent2agent, agentforce bridge, a2a compliant, agent fabric, non-a2a agent, omni gateway, source agent --- # Make an Agent A2A-Compliant > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Create an A2A bridge to make a non-A2A agent A2A-compliant so that Agent Fabric can discover, govern, and orchestrate it alongside native A2A agents. Agent Fabric orchestrates agents using the Agent2Agent (A2A) protocol, but many enterprise agents—such as Salesforce Agentforce agents—aren’t A2A-compliant on their own. An A2A bridge closes this gap. A bridge is a chain of policies—inbound authentication plus the bridge policies—that runs on an Omni Gateway instance and presents an A2A-compliant facade in front of a **source agent**. More than a protocol translator, the bridge is an A2A-compliant protocol server: it translates between A2A and the source agent’s native protocol, manages the task lifecycle, and serves A2A task management methods so downstream consumers see a fully A2A-compliant agent. No changes to the source agent are required. When you create an A2A bridge, Agent Fabric derives an A2A agent card from the source agent, publishes it to your **Portfolio**, and deploys the first bridge instance—in a single wizard. During creation, you define: - **A2A card** The advertised name, description, and skills the bridge exposes to other agents for discovery and routing. Capabilities are set and validated by the platform. - **Deployment** The environment, Omni Gateway, base path, and consumer endpoint where the bridge instance runs. - **Inbound authentication** How A2A clients authenticate to the bridge. - **Upstream authentication** How the bridge authenticates to the source agent. ## How an A2A Bridge Works A source agent is an existing agent, built on a platform that isn’t natively A2A-compliant, that you want to bring into your agent network. The bridge sits between A2A clients and the source agent as an A2A-compliant protocol server and handles: - **Protocol translation** — Converts A2A requests into the source platform’s native API calls and maps native responses back to A2A task states. - **Identity and task mapping** — Maps the source platform’s session or conversation identifiers to A2A `contextId` and `taskId` values. - **Task lifecycle and state** — Tracks task state so A2A operations such as `GetTask`, `ListTasks`, and `CancelTask` return correct results. - **A2A card derivation** — Generates an A2A v1 agent card that accurately reflects the capabilities the bridge can honor. The bridge card is derived from the source agent’s card, plus any capabilities added by the bridge and any customizations you make. The card advertises the bridge’s A2A endpoint as a JSON-RPC interface in its `supportedInterfaces` and locks platform-set capabilities such as streaming and the human-in-the-loop extension. Because the bridge is always A2A-compliant, A2A clients consume a bridged agent with no custom logic. If the source platform later adds native A2A support, you can disable the bridge and clients continue to work without changes. ## Supported Source Platforms
Source platformBridge availabilityNotes

Salesforce Agentforce

Available

Bridge translates A2A to the Agentforce Agent API. Supports streaming and human-in-the-loop.

Microsoft Copilot Studio

Planned

Roadmap. Copilot’s activity-based Direct Line API requires heuristic task-lifecycle handling.

Amazon Bedrock AgentCore, Google Vertex AI

Not required

These platforms are natively A2A-compliant. Register them directly rather than bridging. See Register Services Manually.

Other platforms

Extensible

Build a custom bridge policy with the Policy Development Kit (PDK), or use A2A Connector.

## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - A source agent registered in your **Portfolio** that isn’t already A2A-compliant. - One of these Exchange permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator - This API Manager permission on the target environment: - API Manager: Manage APIs Configuration For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - A managed or self-managed Omni Gateway in the target environment. - Credentials for the source agent’s platform, such as the Salesforce org URL, OAuth token URL, client ID, and client secret for an Agentforce source agent. ## Create an A2A Bridge You create a bridge from the source agent’s detail page. 1. In **Portfolio**, open the **Agents** catalog and select the source agent you want to bridge. 2. On the **Overview** tab, select **Configure A2A Bridge & Deploy First Instance**. 3. In **Customize Card**, review and edit the **Skills** on the A2A card the bridge will publish. Skills describe what the agent can do so other agents can discover and route to it. 4. Add custom skills or hide skills as needed. Each skill must have a unique ID. 5. Click **Continue: Deploy Instance**. 6. In **Deploy Instance**, configure where and how the first bridge instance runs: - **Environment** — Select the target environment. - **Omni Gateway** — Select the managed or self-managed gateway that hosts the bridge. - **Instance URL** — Enter the path segment for the bridge’s A2A endpoint. Agent Fabric checks for route conflicts against existing instances on the gateway. - **Consumer Endpoint** — Optionally override the gateway ingress URL used to build the instance URL. 7. Configure **Inbound Authentication** to control how A2A clients authenticate to the bridge. Select a method such as **JWT Validation**, **Basic Authentication**, or **Client ID Enforcement**, then provide the required values. 8. Configure **Upstream Authentication** to control how the bridge authenticates to the source agent. For an Agentforce source agent, provide the **Salesforce Org URL**, **Token URL**, **Grant Type**, **Client ID**, and **Client Secret**. Source-derived values such as the tenant endpoint are read-only. 9. Expand **Advanced** to review or adjust the generated policy configuration. 10. Complete the wizard. Finishing publishes the A2A card and deploys the bridge instance together. After the bridge is created, the derived A2A agent card is published to the **Agents** catalog in your **Portfolio**, where it can be discovered, governed, monitored, and orchestrated like any other A2A agent. On the bridged agent’s **Overview** tab, Agent Fabric shows two cards side by side: - **A2A Bridge card** — The advertised name, description, version, protocol, capabilities, and skills the bridge publishes to other agents. Capabilities such as streaming, push notifications, state transition history, and extensions are set by the platform and locked to prevent the bridge from advertising a capability it can’t honor. Skills are flagged as **Custom** when you added them or **Hidden** when you excluded them from discovery. - **Source card** — The name, description, and metadata of the underlying non-A2A source agent that the bridge card is derived from. To scale a bridge across environments or gateways, deploy additional instances from the **Instances** tab using **Create A2A Bridge Instance**. To change the advertised card content—skills, advertised name, and description—open the agent’s **Overview** tab and click **Customize Card**. Editing the card creates a new bridge version that instances can adopt. ## Update an A2A Bridge Instance Each bridge instance is pinned to a specific bridge version. The instance’s **Overview** tab shows a **Deployment** section with: - **Serving A2A Bridge Version** — The bridge version this instance runs. The version fixes the instance’s advertised card (skills, name, and description) along with its authentication and advanced settings. If a newer version exists, Agent Fabric shows that a newer A2A bridge version is available. - **Consumer Endpoint** — The URL where the instance receives A2A requests. - **Discovery URL** — The well-known A2A agent card endpoint (`.well-known/agent-card.json`) that callers fetch to discover the agent. To change an instance’s configuration, click **Update Instance** to open the **Update A2A Instance** dialog, then adjust any of these: - **Inbound Authentication** — How other agents authenticate when they call this instance. - **Upstream Authentication** — How the instance’s bridge authenticates to the source agent. Leave a masked secret unchanged to keep the stored value, or enter a new value to rotate it. - **Advanced** — The generated policy configuration, such as the request timeout. - **Version** — If a newer bridge version is available, adopt it to update the instance’s advertised card and settings to that version. Click **Save Changes** to redeploy the instance with the updated configuration. Updating an instance doesn’t republish the bridge card; edit card content from the agent’s **Overview** tab with **Customize Card**. ## Known Limitations A2A bridge behavior is constrained by what the source platform’s API supports. Review the limitations for your source platform before you rely on a bridge in production. - **Transport** — Bridges expose a single A2A JSON-RPC interface. The derived card advertises this interface in its `supportedInterfaces`; other A2A transports aren’t advertised. - **Task state durability** — Task lifecycle state is held in gateway memory and doesn’t survive an Omni Gateway restart. After a restart, A2A operations such as `GetTask` and `ListTasks` can’t return state for tasks created before the restart. Agentforce source agents have these additional limitations, which the derived agent card reflects: - **No asynchronous tasks** — Agentforce responds synchronously. Long-running tasks that exceed the gateway timeout fail. Use Agentforce agents for real-time, low-latency tasks, and orchestrate long-running work through a broker. - **No task subscription** — A2A resubscription isn’t available. Streaming must be consumed on a single in-band connection. - **No push notifications** — The Agentforce API doesn’t support push notifications. - **Limited input-required support** — Not all Agentforce agent types support the A2A `input-required` state, so some bridged agents can’t pause a task to request additional input for human-in-the-loop interactions. - **Session lifecycle** — The bridge creates and manages Agentforce sessions automatically. Sessions time out on the Agentforce side; you don’t manage them directly. ## Migrate to Native A2A The A2A bridge is designed to be superseded. When a source platform adds native A2A support, disable the bridge and point consumers at the platform’s native A2A endpoint. Because clients already consume the agent through the A2A protocol, no client changes are required. ## See Also - [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [A2A Connector 2.0](https://docs.mulesoft.com/a2a-connector/latest/) --- product: Getting Started --- # Making Your APIs Agent-Ready > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You’ve invested heavily in API infrastructure, but you didn’t design your APIs for agents to consume. For agents to act on the systems behind those APIs, you need to make each operation callable. You must decide which operations are safe to expose and figure out how to keep access consistent across every agent platform, all of which usually leads to a bunch of custom integrations. Agent Fabric removes all this work. In Agent Fabric, you expose an existing API as a Model Context Protocol (MCP) server through configuration alone. You choose which operations become agent-ready tools, and you apply your governance pattern, without touching the underlying API. ## The Problem Adapting existing APIs for agentic workflows presents several challenges. - API complexity: Existing APIs aren’t designed for agent consumption. - Security concerns: APIs often include write and delete operations that are too risky for agents. - Integration overhead: Building custom integrations for each agent platform is time-consuming. - Inconsistent access: Different agents access the same APIs in different ways. - Governance gaps: It’s hard to track and control how agents use existing APIs. You need a way to make this API infrastructure available to agents safely and efficiently, without rebuilding it. ## The Solution Agent Fabric exposes your existing APIs as MCP servers. Agents then get safe, efficient API access: - Rapid integration: Connects existing API instances to agents through configuration alone, without rewriting the API or building a custom integration for each agent platform. - Selective exposure: Exposes only the operations you explicitly map as discrete MCP tools that agents can discover and call. Write and delete operations stay off-limits unless you choose to expose them, without modifying the underlying API. - Centralized management: Provides a single point of control so that all agents reach your APIs the same way. Access, policy, and monitoring stay unified as you add agents, with governance policies applied from the same portfolio. - Agent-facing abstraction: Presents existing REST API operations as MCP tools so that agents can call them without needing API-specific details. - Asset reuse: Works with your MuleSoft API infrastructure without rebuilding assets for agentic use. ## How It Works Omni Gateway is the runtime enforcement point for Agent Fabric. This single gateway sits in front of your agents, APIs, and MCP servers so that authentication, monitoring, and policy enforcement apply to every request. When you expose an API as an MCP server, you create the server from the API and choose which operations to publish as tools. You then deploy the MCP server on Omni Gateway. A required MCP support policy makes the server callable, and you apply additional policies to govern every request. The server runs on the same gateway infrastructure you use to manage your API traffic. Each agent request follows this path: 1. The AI agent makes an MCP request. 2. The request flows through Omni Gateway, where the MCP server’s policies execute. 3. The MCP server maps the request to the underlying API operation that you’ve exposed as an MCP tool. 4. The call reaches the backend API. 5. Responses flow back through the gateway to the agent. ## Who This Is For Exposing APIs as MCP servers is ideal for: - Companies with existing API infrastructure - Security teams concerned about agent access to sensitive operations - Integration teams who enable agents quickly without custom development - Architects who design safe agent access to enterprise systems - Teams who want to build on investments in API management and governance ## Example Scenarios Different companies expose APIs as MCP servers to solve specific agent access challenges. ### Scenario 1: Customer Service Agent with Read-Only Access **Challenge:** Customer service agents answer questions about customer accounts and orders but can’t modify data. Without an MCP server in front of the API, you must build custom integrations for each agent platform. This approach risks exposing write operations and creates inconsistent behavior across platforms. By exposing the API as an MCP server, you deploy rapidly with built-in safety. Here’s how you do it: 1. Create an MCP server from your customer API, publishing only its read (GET) operations as tools. 2. Deploy the server on Omni Gateway and apply the required MCP support policy. 3. Connect all agent platforms to the MCP server endpoint. **Result:** Agents answer account and order questions with no write access exposed, from a single configuration. You don’t build or maintain a per-platform integration, and no path exists for an agent to modify customer data. ### Scenario 2: Inventory Check Agent **Challenge:** Your inventory API includes operations to check stock levels, reserve items, adjust quantities, and process transfers. Sales agents, warehouse agents, and customer service agents all check current stock, but only warehouse systems adjust it. Without an MCP server in front of the API, you either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. By exposing the API as an MCP server, you give all agents read-only inventory access from a single configuration. Here’s how you do it: 1. Create an MCP server from the inventory API, publishing only the read (GET) operations for stock queries as tools. 2. Deploy the server on Omni Gateway. 3. Connect all agent types to the MCP server endpoint. 4. Monitor agent usage alongside your existing services. **Result:** Sales, warehouse, and customer service agents all read live stock levels from one read-only tool surface. Stock adjustments stay restricted to warehouse systems, without a filtered endpoint for each agent type. ### Scenario 3: Financial Data Agent with Layered Tool Selection **Challenge:** Different agents need different levels of access to financial APIs. Without a controlled tool surface, you build separate custom integrations for each agent access level. This duplication increases the risk that a high-privilege operation reaches the wrong agent. By exposing the API as multiple MCP servers with layered tool selection, you get fine-grained access control with safety guarantees. Here’s how you do it: 1. Create multiple MCP servers from your financial API, each publishing a different set of tools: the Basic server with GET operations for account balances, the Analytics server with GET operations for transaction history and reports, and the Approval server with GET operations plus the POST operation for creating approval requests. 2. Deploy each server on Omni Gateway, and connect each agent to the appropriate endpoint based on access requirements. 3. Apply policies to each MCP server to govern runtime access. **Result:** Each agent gets exactly the access its role requires. Agents access balances, analytics, or approval requests from one financial API, with no duplicated integrations and no path for a high-privilege operation to reach the wrong agent. ### Scenario 4: Mule Integration Platform **Challenge:** Your company has extensive Mule infrastructure and wants agentic access without rebuilding integrations. Without a configuration-based approach, you need to build agent-specific adapters on top of each Mule API. Those adapters duplicate logic and bypass the governance that protects those APIs. By exposing your Mule APIs as MCP servers, you extend your existing Mule investment to agentic use cases. Here’s how you do it: 1. Create MCP servers from key Mule APIs, publishing the operations you want to expose as tools. 2. Deploy the servers on your existing Omni Gateway infrastructure. 3. Monitor usage and apply policies the same way you do for your existing APIs. **Result:** Existing Mule APIs become agent-callable without new adapters or duplicated logic, and agent traffic inherits the same governance already protecting those APIs. ## Implementation Steps ### Step 1: Identify APIs for Agent Access 1. List APIs that agents access. 2. Document the current API operations (GET, POST, PUT, DELETE). 3. Identify which operations are safe for agents. 4. Prioritize APIs by business value and risk. ### Step 2: Select Tools for Each API Instance For each API instance: - Identify which operations agents can access. - Decide whether read-only operations are sufficient. - If agents require write access, identify which write operations they use. - Identify which Omni Gateway policies apply to the resulting MCP server. ### Step 3: Create and Deploy an MCP Server 1. Create an MCP server from your target API, and select which operations to publish as tools. Apply read-only filtering to expose only the operations that are safe for agents. 2. Deploy the server on Omni Gateway, configuring the server label, base path, protocol, and port, and the upstream connection. 3. Apply the required MCP support policy so the server is callable. 4. Test the MCP server endpoint with sample requests. For the steps to create an MCP server from an existing API, see [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server). For the steps to deploy it on Omni Gateway, see [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add). ### Step 4: Apply Omni Gateway Policies The MCP server controls which API operations are available as tools. Omni Gateway policies control how agents can use those tools at runtime. After deploying the MCP server, apply policies to the MCP server to enforce authentication, rate limiting, logging, and alerting. For the steps to apply policies, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ### Step 5: Connect Agents 1. Update agents to use the MCP server. 2. Test with realistic scenarios. 3. Verify that agents can call only the operations you expose. 4. Monitor initial usage. ### Step 6: Monitor and Refine 1. Review latency, error rates, and request volume for your MCP server. 2. Analyze which tools agents call and identify missing operations. 3. Check gateway logs for attempts to call unexposed operations. 4. To change which operations agents can call, update the MCP server’s tool selection and redeploy. To monitor MCP servers alongside other services in your portfolio, see [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring). ## Tool Selection Strategies Choose which API operations to expose as discrete MCP tools that agents can discover and call. When you create the MCP server, you select which operations to publish as tools. Expose all operations, only read operations, or any subset you choose, without modifying the underlying API. Consider a Customer API with both read and write operations: ```text Customer API: - GET /customers/{id} (read) - POST /customers (create) - PUT /customers/{id} (update) - DELETE /customers/{id} (delete) - GET /customers/{id}/orders (read) - POST /customers/{id}/orders (create) ``` After you configure the MCP server to expose only read operations, agents see a reduced tool surface: ```text Customer API (Agent Tool Surface): - GET /customers/{id} (read - exposed as an MCP tool) - GET /customers/{id}/orders (read - exposed as an MCP tool) ``` The agent can read customer and order data but can’t create, modify, or delete anything. The write operations exist in the underlying API but aren’t exposed as MCP tools. ### Read-Only Operation Mapping Map only GET operations to tools first. Explicitly map write operations only when a use case requires them. ### Operation Allowlisting Select specific operations to expose rather than trying to identify operations to block. Allowlisting is safer and easier to maintain. ## Common Tool Selection Patterns Choose an approach based on your security requirements and use cases. ### Read-Only Tool Surface Use this pattern when agents only retrieve data. Expose all GET operations as tools and exclude all write (POST, PUT, DELETE) operations. ```text (exposed) GET /resource/{id} (exposed) GET /resource (not exposed) POST /resource (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Read and Create Tool Surface Use this pattern when agents look up records and create new ones but don’t modify or delete existing data. ```text (exposed) GET /resource/{id} (exposed) POST /resource (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Read and Request-Only Tool Surface Use this pattern when agents initiate a workflow (for example, submitting an approval request) without directly modifying records. ```text (exposed) GET /resource/{id} (exposed) POST /resource/request (not exposed) PUT /resource/{id} (not exposed) DELETE /resource/{id} ``` ### Granular Tool Surface Use this pattern for fine-grained control. Expose specific safe operations and block others based on assessments of business risk. For example, expose `GET /orders/{id}` so agents can view order details, but block `PUT /orders/{id}/status` to prevent agents from changing order status. This pattern gives agents access to the information they need while protecting sensitive operations. ```text (exposed) GET /orders/{id} (exposed) POST /orders/{id}/notes (add note - safe) (not exposed) PUT /orders/{id}/status (change status - risky) (not exposed) DELETE /orders/{id} (delete order - risky) ``` ## Security Considerations When you expose APIs as MCP servers, follow these security practices to minimize risk and maintain control over agent access to your APIs. ### Default Deny Start with no access and grant only the operations that agents use. Apply Omni Gateway policies to turn on logging and monitor MCP server usage. ### Regular Reviews Periodically review: - Which operations are in use - Whether your tool selection is still appropriate - Whether to remove additional operations from the agent tool list ## Integration with Existing Tools MCP servers integrate with your MuleSoft infrastructure, identity systems, and gateway deployment to build on investments you’ve made. ### Mule Integration Expose Mule API instances you manage as MCP servers without rebuilding them. - Expose existing Mule APIs as MCP servers. - Reuse your existing governance. - Extend Mule monitoring to agent access. - Reuse existing API policies. ### Omni Gateway Integration MCP servers run on Omni Gateway infrastructure. They’re managed through API Manager and protected by Omni Gateway policies, like API instances. - Create and deploy MCP servers on the same Omni Gateway that manages your APIs. - Apply policies to MCP servers the same way you apply them to APIs. - Use unified monitoring and alerting across APIs and MCP servers. ### Identity Systems MCP servers work with existing identity infrastructure so that agent access to APIs respects the same authentication and authorization rules you already have in place. - Integrate with existing authentication. - Use existing authorization rules where applicable. - Extend identity-based access control to agents. ## Related Documentation - [Agent Fabric Use Cases](https://docs.mulesoft.com/general/agent-fabric-use-cases) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) --- product: Getting Started keywords: cost management, token usage, ai governance, usage metrics, anypoint platform, cost tracking, ai services --- # Managing Costs and Token Usage > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use cost and token metrics to understand usage, control spend, and identify optimization opportunities. Available metrics depend on your tenant configuration and role. > [!NOTE] Automate cost and token usage reporting using the MuleSoft MCP Platform Server. For > details, see > [fetch\_cost\_overview](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-cost-overview) > and related Cost Management tools in the MuleSoft MCP Platform Server Tool Reference. Watch this video to see how to track cost and token usage: ![](https://play.vidyard.com/gmgGwda3MpnowKnYUaCQom.jpg) ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - These permissions: - API Manager: Manage Policies - API Manager: View APIs Configuration - API Manager: View Policies - Anypoint Code Builder: Mule Developer Generative AI User (Optional) - Anypoint Monitoring: Monitoring Viewer - Exchange: Exchange Viewer For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Cost and Token Data Locations The system displays token usage and performance data in several places: - **Governance** > **Cost Management**: Primary dashboard for organization-wide token usage and spend indicators - Service detail pages: Usage and performance summaries for supported services - **Observability**: Aggregated token and latency trends, when configured Navigation labels can vary by catalog, enabled features, and release. ## Open Cost Management 1. Log in and go to **Governance** > **Cost Management**. 2. Select a tab: - The **Budgets** tab (default): View total managed spend and budget breakdowns. - The **Optimizations** tab: Analyze MCP server token usage and optimization opportunities. 3. Set the time range for the data you want to analyze. The time range selector (**1H**, **24H**, **7D**, or **30D**; default **30D**) sits next to the tabs and applies to both the **Budgets** and **Optimizations** tabs. 4. Use the **Tokens**/**Cost** toggle to choose how metrics display. See [View Metrics in Tokens or Cost](#view-metrics-in-tokens-or-cost). ## View Metrics in Tokens or Cost The **Tokens**/**Cost** toggle next to the tabs controls whether **Cost Management** metrics display as token counts or as dollar amounts. The toggle defaults to **Tokens**. To view spend in dollars, set the toggle to **Cost**. Before dollar amounts appear, you must configure a cost rate for each model. Until you set model rates, the **Cost** view shows a prompt to configure your models, and metrics that depend on cost show zero. To set rates, select **Configure Costs**, or set a cost per token for each model on the **Models** page. See [Setting Model Costs for Spend Tracking](https://docs.mulesoft.com/general/exp-models-manage-costs). ### When Cost Tracking Begins Cost metrics accrue only from the time you configure model rates. LLM usage before that time isn’t priced and doesn’t appear as cost, even for earlier periods within the selected time range. Token counts are unaffected. The **Tokens** view continues to reflect the complete spend from the time you enabled **Cost Management**, regardless of when you set model rates. ## Cost Data Use Cases Cost and performance data inform multiple workflows: - Cost optimization: Identify services with high usage and apply optimization controls. - Performance triage: Correlate latency or error spikes with deployments or policy changes. - Planning and alignment: Share trends with finance and platform teams for forecasting. To automatically cap usage, configure budgets in the **Budgets** tab or through model wallets. Budgets block requests once the limit is reached. To limit consumption in other ways, apply governance strategies or rate-limiting policies. ## Cost Data and Governance Use **Cost Management** data to create or refine governance strategies. For runtime enforcement, attach cost-related controls or policies to a governance strategy and apply it to the relevant services. ## Budgets Tab The **Budgets** tab shows financial summaries across your configured budgets: - **Total Managed Spend**: Total spend across all configured budgets. - **By Provider**: Spend breakdown by LLM provider. - **By Model Wallet**: Spend breakdown by model wallet. These summaries display as token counts or dollar amounts based on the **Tokens**/**Cost** toggle. Dollar amounts appear only after you configure model rates. See [View Metrics in Tokens or Cost](#view-metrics-in-tokens-or-cost). Each budget row displays a status badge that reflects current usage against the budget limit: - **At Risk**: Usage has reached 75% or more of the budget limit. - **At Limit**: Usage has reached the budget limit. The system blocks further requests. Use the search on the **Budgets** table to find specific budgets. ### Add a Budget 1. In the **Budgets** tab, select **New Budget**. 2. In the **New Budget** dialog, configure the budget: - **Model Wallet** (required): Select the model wallet to scope the budget. - **Provider** (required): Select an LLM provider. - **Model** (required): Select a model. This field appears after you select a provider. - **Period**: Select **Daily**, **Weekly**, or **Monthly**. - **Metric**: Select **Spend** to set a dollar limit, or **Tokens** to set a token count limit. - **Spend Limit (USD)** or **Token Limit** (required): Enter the maximum allowed value. 3. Select **Create Budget**. When usage reaches the budget limit, the system blocks requests. Each model wallet, provider, and model combination supports only one budget. For information about model wallets and how they combine authentication credentials with budget limits, see [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage). ## Optimizations Tab The **Optimizations** tab shows cost and token savings data across model proxies, agents, and MCP servers. The summary cards show: - **Total Managed Spend**: The total cost of all LLM traffic routed through managed proxies. This excludes any usage that bypasses the proxy network. - **Agents Potential Savings**: Estimated cost savings available by applying optimization policies to agents. It shows **Amount Saved** as the amount already saved. - **LLM Proxies Potential Savings**: Estimated cost savings available by applying optimization policies to LLM proxies. It shows **Amount Saved** as the amount already saved. - **MCP Servers Potential Savings**: Estimated token savings available by applying optimization policies to MCP servers. It shows **Tokens Saved** as tokens already saved. Treat these metrics as directional, not exact. The **Top optimization opportunities** section highlights the instances with the highest potential savings and the specific optimization policy to apply. ### Filter and Search Use the controls at the top of the **Optimizations** tab to narrow the view: - Select a sub-tab to filter by instance type: - **Model Proxies**: Monitor cost data and savings for traffic explicitly routed through your managed proxy network. - **Agents**: Track proxy-attributed spend and policy savings for active agents governed by Omni Gateway. - **MCP Servers**: Observe token volumes processed through tool responses during active server calls. - Search for instance names. - Use **Filters** to refine the view by **Environment** or **Provider**. The counter updates to show the number of matching instances. ## Apply Optimization Policies Optimization policies reduce token consumption and cost for a given instance without changing what the instance does. The available policies depend on the instance type. To apply an optimization policy: 1. In the **Optimizations** tab, select the sub-tab for the instance type: **Model Proxies**, **Agents**, or **MCP Servers**. 2. Locate the instance you want to optimize, and select **View optimizations**. 3. In the instance’s optimizations view, locate the policy you want to apply. 4. Review the policy’s **Potential savings**, and expand **Why this policy?** for details. 5. Select **Apply** to enable the policy. Treat the savings estimates as directional, and note that some policies may affect instance latency. ### MCP Optimizations For MCP servers, you can apply these optimization policies. Each policy shows its **Potential savings** and a **Why this policy?** explanation, and you apply it by selecting **Apply**. - **MCP Tool Mapping**: Redefines tool names and descriptions to reduce prompt complexity and improve LLM comprehension. - **MCP Tools Progressive Disclosure**: Wraps the MCP server and surfaces two tools, `search_tools` and `invoke_tool`, to increase both accuracy and cost optimization. - **Clean Payloads**: Strips structural noise from tool responses, such as whitespace, nulls, and base64 blobs. - **Smart Response Trimming**: Trims oversized responses to match agent intent, dropping fields the agent never reads. - **Compress Repeated Structures**: Compresses repeated tabular structures into Token-Oriented Object Notation (TOON). ### Agent Optimizations For agents, you can apply these optimization policies to the agent’s Model Proxy to reduce token costs. Each policy shows its **Potential savings** and a **Why this policy?** explanation, and you apply it by selecting **Apply**. - **Clean Responses**: Strips redundant fields and boilerplate from tool responses before they reach the model. - **Compress Repeated Structures**: Re-encodes repeated array or object structures in tool responses into a more compact form. ### Model Proxy Optimizations For model proxies, you can apply these optimization policies to reduce token costs. Each policy shows its **Potential savings**, and you apply it by selecting **Apply**. Applying policies may affect instance latency. - **Semantic Caching**: Caches LLM responses by semantic similarity so repeat or near-repeat prompts short-circuit an upstream call. This typically results in about 40% fewer tokens on chat-style traffic. ## See Also - [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage) - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Managing Governance Strategies](https://docs.mulesoft.com/general/exp-governance-manage-strategies) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [View Detailed Metrics for Your Services](https://docs.mulesoft.com/general/exp-services-view-detailed-metrics) --- product: Getting Started keywords: governance strategies, api governance, strategy metrics, filter strategies, anypoint platform, strategy actions, api management --- # Managing Governance Strategies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Keep governance strategies aligned with your portfolio by adjusting scope, rules, or status as your services and compliance requirements evolve. Summary cards show active strategy counts, type breakdowns, and governance coverage at a glance. > [!NOTE] Automate strategy management using the MuleSoft MCP Platform Server. For details, see > [list\_governance\_strategies](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#list-governance-strategies) > and related tools in the MuleSoft MCP Platform Server Tool Reference. ## Display Governance Strategies Go to **Governance** > **Governance Strategies** to view all strategies. Check the strategy name, type, environment, target, status, governed services count, and last modified time. ## Available Strategy Actions - View details: Open a strategy to review scope, rules or policies, and metadata. - Enable or disable: Pause a strategy without deleting it. - Edit configuration: Update scope, rules, name, or description, then save. - Reorder strategies: To change the order of Automated Policy strategies, set the type filter to **Automated Policies** and select **Reorder**. - Delete a strategy: Permanently remove a strategy that you no longer need. - Change to draft: For Control strategies, select **Change to Draft** to move the strategy back to a draft state without deleting it. ## Filter and Search Strategies Use the controls above the table to narrow the list: - Use the strategy type tabs to show **All**, **Controls**, or **Automated Policies**. - Use the status filter to select **Any Status**, **Active**, or **Disabled**. - Enter text in the search field to match strategy names. The page updates to show only matching strategies. ## Strategy Metrics Review the summary cards: - **Active Strategies**: The number of enabled strategies - **Strategy Types**: The breakdown of **Controls** and **Automated Policies** - **Governance Coverage**: When available, the portion of the portfolio governed by at least one strategy Use these cards to spot governance gaps quickly. ## Akamai-Generated Strategy When you connect Akamai API Security as a provider, the system automatically creates a pre-configured Akamai security strategy in the strategy list. This strategy attributes Akamai security findings to your MuleSoft APIs and MCP servers. Don’t delete it unless you also remove the Akamai scanner. Deleting the strategy stops security findings from appearing in conformance reports. ## Identify When to Edit or Disable a Strategy Edit or disable a strategy when: - Scope drift causes the strategy to include the wrong services or miss intended services. - New compliance requirements call for adding or replacing rules. - False positives or unexpected blocking require control changes. - Environment or tag changes make existing filters inaccurate. Check the **Governed Services** count before and after changes to confirm the scope adjusted as expected. ## Impact on Governed Services When you disable a strategy, the system stops evaluating or enforcing that strategy for matching services. When you delete a strategy, active governance for that strategy stops. Historical data retention depends on your reporting backend. Coordinate with service owners and your governance team if changes affect production services or compliance reporting that your organization relies on. ## See Also - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: policies, gateway policies, external gateways, apigee, azure api management, kong, api manager, anypoint platform --- # Managing Policies on Gateway Providers > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Manage policies not only on Omni and Mule gateways but on external gateway providers, such as Google Apigee, Azure API Management, and Kong Gateway. You work with these policies entirely through the enhanced MuleSoft experience, from the **Policies** tab of an API instance in **Portfolio**. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - The API Manager: Manage Policies permission to apply, edit, enable, disable, or remove policies. - The Organization Administrator role to apply open policies, or to apply, edit, enable, disable, or remove native policies on external gateways. Without this role, you can’t load an open policy catalog, open a policy configuration form, apply an open policy, or apply, edit, enable, disable, or remove native policies on an external gateway. Listing native policy templates on an external gateway still uses the View Policies permission. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - A provider scanner already connected for each external provider whose policies you want to manage. Policy management reuses the same connection you set up for scanning. See [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers). ## Reading Policies vs. Writing Policies There are two distinct ways you interact with provider policies: - Read (discover and display): Provider scanners import the full catalog of policies attached on the provider so you can see them on the **Policies** tab. This is view-only. See [View Read Policies Discovered by Scanners](https://docs.mulesoft.com/general/exp-services-view-details#view-read-policies-discovered-by-scanners). - Write (create, edit, enable, disable, remove): From the same **Policies** tab, you can manage a curated subset of policies directly on the provider. This is the feature described in this section. ## The Editability Rule The enhanced MuleSoft experience 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 [Open Policies](https://docs.mulesoft.com/general/exp-policies-open). 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 [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) and [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference). ## How Policy Operations Work Every policy change on an external provider, such as apply, edit, enable, disable, or remove, runs asynchronously: the enhanced MuleSoft experience accepts the request and performs the work on the provider in the background. Because an accepted request isn’t the same as an applied policy, confirm the outcome in the Activity log tab for the API instance. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). ## See Also - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) --- product: Getting Started keywords: cross-gateway conformance, provider conformance, governance monitoring, compliance tracking, multi-gateway governance --- # Monitoring Cross-Gateway Conformance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After creating governance strategies that target multiple gateway platforms or third-party providers, monitor conformance across your entire API ecosystem through a unified dashboard. The conformance summary shows conformance status for APIs hosted on Anypoint Platform gateways and connected third-party providers. ## Before You Begin Before monitoring cross-gateway conformance: - [Connect to one or more third-party providers](https://docs.mulesoft.com/general/exp-services-view-details) to enable cross-gateway governance. - [Create a governance strategy](https://docs.mulesoft.com/general/exp-governance-create-strategy) that evaluates the APIs you want to monitor. - Verify that the strategy is active and has evaluated the targeted APIs. ## View Cross-Gateway Conformance 1. Log in and go to **Governance** > **Governance Strategies**. 2. Select an active strategy. The strategy opens on the **Configuration** tab, which shows the scope and rules. 3. Select the **Governed Services** tab to view conformance results. The **Governed Services** tab displays: - A **Conformance** summary: the total number of governed services, broken down into **Conformant**, **Nonconformant**, and **Pending**. - An **Identified Issues** summary: counts of violations, warnings, and info-level findings. - A table of governed services with **Service**, **Type**, **Provider**, and **Conformance** columns. The **Provider** column shows which platform hosts each API. ## Filter by Specific Provider To focus on conformance for a specific provider: 1. On the **Governed Services** tab, locate the **Any provider** filter. 2. Select a provider from the list. The list updates to show only APIs hosted on the selected provider. Use this filter to: - Compare conformance across providers. - Identify provider-specific conformance gaps. - Focus on a subset of your multi-gateway environment during reviews or audits. ## See Also - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Govern Third-Party Provider APIs](https://docs.mulesoft.com/general/exp-governance-govern-third-party-apis) --- product: Getting Started keywords: service monitoring, monitoring signals, access monitoring, mulesoft services, monitoring use cases, api monitoring --- # Monitoring Services in Your Portfolio > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Monitoring helps you see whether the services in your portfolio—and the paths that carry their traffic—are healthy, performant, and stable over time. You work from service context (what a single API, agent, MCP server, Model proxy, or gateway is doing) and, when your administrator enables it, from broader observability surfaces that sit alongside **Portfolio** and **Governance**. > [!NOTE] Automate service monitoring using the MuleSoft MCP Platform Server. For details, see > [fetch\_monitoring\_overview](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-monitoring-overview) > and related Monitoring and Observability tools in the MuleSoft MCP Platform Server Tool Reference. Watch this video to see how to monitor service health: ![](https://play.vidyard.com/T3gwcM44w5qpN5ze6WUwoK.jpg) ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Any of these permissions: - Anypoint Monitoring: Monitoring Viewer - Anypoint Monitoring: Monitoring Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Monitoring Use Cases - Spot regressions early. Compare latency, errors, and throughput (or equivalent signals the system exposes for your integration type) against what you expect after a release or policy change. - Triage incidents. Correlate spikes or failures on a service with recent deployments, instances, or gateway paths your team manages. - Support capacity and cost conversations. Use sustained load or usage patterns as inputs when you tune scaling, routing, or token-related spend with your platform owners. Exact metrics depend on how the service is hosted, which gateway or runtime path applies, and which observability backend your organization has connected. ## Access Monitoring Monitoring appears in these areas of the experience: - **Home** — Your entry path sometimes highlights alerts or shortcuts back into **Portfolio** or **Observability**; use whatever your organization configured after sign-in. - **Portfolio** and service detail — Open a catalog entry and use the **Monitoring** tab on the service (and, where the product exposes it, on instances) to read metrics scoped to that service. This is where you typically go when checking whether a specific API or agent is degrading. - **Observability** — When your tenant includes it, **Observability** aggregates dashboards, reports, or notifications to compare service-level signals with organization-wide views your administrator configured. Use filters to narrow to the service, environment, or route you’re investigating. Navigation labels can vary by catalog, enabled features, and release. ## Monitoring Signals The system emphasizes runtime health for managed integration paths—for example latency, error rates, and request volume when the new experience surfaces Omni Gateway data for routes your team operates under policy. Not every catalog type exposes the same charts; some services show richer series only after you complete instance setup or connect the observability backend your administrator approved. If a tab is missing, confirm with your administrator that monitoring data is flowing for that environment and that your account has the right permissions. ## See Also - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) --- product: Getting Started keywords: mulesoft ai, ai integration, artificial intelligence, mulesoft, learning resources, ai capabilities --- # MuleSoft AI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft AI empowers agent action with flexible intelligent tooling that integrates systems and automates processes with AI to help accelerate your ability to deliver an actionable, connected enterprise by helping you build, orchestrate, and manage AI-driven experiences. The end-to-end journey for MuleSoft AI consists of various tasks, each with links to relevant content to assist you in completing them.
lm start

Learn About MuleSoft AI

MuleSoft AI is a set of capabilities for building, orchestrating, governing, deploying, and observing AI agents and agent networks across your enterprise.

lm analyze 1

Observe and Gain Actionable Insights

Visualize and monitor your agent network and agentic assets.

lm audience end 1

Govern and Secure Your Agents

Apply policies and secure agent network traffic.

## See Also - [Agent Fabric](https://docs.mulesoft.com/general/learning-map-agent-fabric) - [Agent Visualizer Overview](https://docs.mulesoft.com/agent-visualizer/) - [Anypoint Code Builder Overview](https://docs.mulesoft.com/anypoint-code-builder/) - [Anypoint Monitoring Overview](https://docs.mulesoft.com/monitoring/) - [Anypoint Exchange Overview](https://docs.mulesoft.com/exchange/) - [Omni Gateway Overview](https://docs.mulesoft.com/gateway/latest/) - [Use MuleSoft Documentation with AI](https://docs.mulesoft.com/general/use-mulesoft-docs-with-ai) --- product: Getting Started keywords: mulesoft automation credits, automation credits 1.0, mulesoft licensing, automation pricing, credits usage --- # MuleSoft Automation Credits 1.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use MuleSoft Automation Credits 1.0 with Composer, IDP, RPA, or a combination of these products. Consumption aggregates over the term of your subscription (not per session) and is then converted to credits as shown below. The credits are deducted from your assigned quota for the subscription period. If you have MuleSoft Automation Credits 1.0, view usage visibility through Anypoint Usage Reports. Sequoia handles monthly statements and overage billing.
Usage typeConversion rate (Units per Credit)

RPA Bot Minutes

2

RPA API Calls

100

Composer Tasks

50

IDP Document Pages

5

MuleSoft adds all the RPA execution times in seconds for the period and converts the total into minutes with two decimal precision. MuleSoft reports Automation Credits with two-decimal precision. For example, if you run 5 processes that take 30 seconds each to execute: MuleSoft converts the total execution time (150 seconds) to minutes, rounds up the last two digits: 150/60 = 2.5 minutes, and then converts the minutes to Automation Credits and rounds up the last two digits: 2.5/2 = 1.25 credits. For detailed definitions and more information, see the [https://www.mulesoft.com/prod-subscription-plans](https://www.mulesoft.com/prod-subscription-plans). ## See Also - [Automation Credits Usage and Rates](https://docs.mulesoft.com/general/automation-credits-usage-and-rates) - [MuleSoft Product Subscription Plans](https://www.mulesoft.com/prod-subscription-plans) - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) --- product: Getting Started keywords: mulesoft automation credits 2.0, automation credits, consumption-based licensing, mulesoft licensing, workflow automation, integration credits --- # MuleSoft Automation Credits 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use MuleSoft Automation Credits 2.0 with Composer, IDP, RPA, Salesforce Flow Orchestration, MuleSoft for Flow: Integration, or a combination of these products, as more fully described in the applicable [Subscription Plan](https://www.salesforce.com/company/legal/mulesoft-subscription-plan/) or Features and Entitlement Document. If you have MuleSoft Automation Credits 2.0, view usage visibility through Anypoint Usage Reports. Sequoia handles monthly statements and overage billing.
Usage typeConversion rate (Credits per unit)

RPA Bot Minutes

80

RPA API Calls

2

Composer Tasks

2

Flow Orchestration Runs

100

IDP Document Pages

30

Integration Tasks

2

To learn more about how Omni Credits are consumed, and when other types of credits are consumed with generative AI features, see [Agentforce and Generative AI Usage and Billing](https://help.salesforce.com/s/articleView?id=ai.generative_ai_usage.htm&type=5) in Salesforce Help. ## See Also - [Automation Credits Usage and Rates](https://docs.mulesoft.com/general/automation-credits-usage-and-rates) - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) --- product: Getting Started keywords: mulesoft automation credits, automation credits 3.0, mulesoft licensing, credits management, mulesoft pricing --- # MuleSoft Automation Credits 3.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft Automation Credits 3.0 is available in Digital Wallet. Use Automation Credits 3.0 with MuleSoft for Flow: Integration, Anypoint IDP, MuleSoft for Flow: IDP, or a combination of these products, as more fully described in the applicable [Subscription Plan](https://www.salesforce.com/company/legal/mulesoft-subscription-plan/) or Features and Entitlement Document. If you have MuleSoft Automation Credits 3.0, usage visibility, monthly statements, and overage billing are all centralized within the Salesforce Digital Wallet. If you have an Anypoint Platform organization, view your usage and entitlement details within Anypoint Usage Reports for cross-platform transparency. > [!NOTE] Composer and RPA are moving to the end of sale. As of February 18, 2026, Flow > Orchestration is included and does not consume Automation Credits in 3.0.
Usage TypeDescriptionConversion rate (Credits per unit)

MuleSoft for Flow: Integration

Integration capabilities within Salesforce Flow; consumes Automation Credits for integration tasks.

2 credits per successful task

IDP Document Pages (Anypoint Platform)

IDP on Anypoint Platform; consumes credits for IDP document pages.

30 credits per page

MuleSoft for Flow: IDP

IDP capabilities within Salesforce Flow; consumes Automation Credits for document processing in Flow.

30 credits per page

Rates and usage types for Automation Credits 3.0 vary by subscription. Refer to the Usage Details table on your Order Form and the applicable Subscription Plan or Features and Entitlement Document. To learn more about how Omni Credits are consumed, and when other types of credits are consumed with generative AI features, see [Agentforce and Generative AI Usage and Billing](https://help.salesforce.com/s/articleView?id=ai.generative_ai_usage.htm&type=5) in Salesforce Help. ## See Also - [Automation Credits Usage and Rates](https://docs.mulesoft.com/general/automation-credits-usage-and-rates) - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) - [Digital Wallet–Enabled Consumption-Based Products](https://help.salesforce.com/s/articleView?id=xcloud.wallet_enabled_products_rate_cards.htm&type=5) (Salesforce Help) --- product: Getting Started keywords: mulesoft documentation, digital transformation, getting started, api design, integration, mulesoft platform, discover mulesoft --- # MuleSoft Documentation > For the full documentation index, see: https://docs.mulesoft.com/llms.txt [New to MuleSoft? Start here.](https://docs.mulesoft.com/general/api-led-overview.html) ## Latest Releases

Oct 23

Microsoft Dynamics NAV Connector 4.0.0

Oct 23

Omni Gateway 1.14.4

Oct 22

Enhanced MuleSoft Experience

Oct 22

OpenAPI Specification Support

Oct 22

Spring Module 2.2.0

Oct 21

Agent Fabric

Oct 21

Microsoft Dynamics GP Connector 3.0.0

[View all release notes](https://docs.mulesoft.com/release-notes/index.html) ## Featured Topics - [Use MuleSoft Documentation with AI](https://docs.mulesoft.com/general/use-mulesoft-docs-with-ai) - [Enhanced MuleSoft Experience](https://docs.mulesoft.com/general/learning-map-exp) - [Getting Long-Term Analytics with Integration Intelligence](https://docs.mulesoft.com/monitoring/integration-intelligence) - [MuleSoft AI](https://docs.mulesoft.com/general/learning-map-mulesoft-ai) - [Learn About Agent Fabric](https://docs.mulesoft.com/general/learning-map-agent-fabric) - [Getting Started with Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-get-started) - [Importing Agentforce Agents](https://docs.mulesoft.com/exchange/importing-agentforce-agents) - [Adding an Omni Gateway Agent or Tool Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-agent-tool) - [Agent Visualizer Overview](https://docs.mulesoft.com/agent-visualizer/) - [Monitoring Agentic Assets](https://docs.mulesoft.com/monitoring/anypoint-insights-agentic) ## The Road to Digital Transformation ![](/mulesoft/current/en-us/general/_images/getting-started.png) ### Getting Started Build the digital transformation your business needs. - [Tutorial: Build an API from start to finish.](https://docs.mulesoft.com/general/api-led-overview) ![](/mulesoft/current/en-us/general/_images/discover.png) ### Discover Browse Exchange to find existing API specifications, templates, examples, and other assets that you can reuse for your projects. - [Discover reusable assets.](https://www.anypoint.mulesoft.com/exchange/) ![](/mulesoft/current/en-us/general/_images/design.png) ### Design Create and publish new API specifications from scratch. - [Create a reusable API specification.](https://docs.mulesoft.com/design-center/design-create-publish-api-specs) - [Manage access to your Anypoint Platform account.](https://docs.mulesoft.com/access-management/) - [Build security into your application network.](https://docs.mulesoft.com/general/security) ![](/mulesoft/current/en-us/general/_images/develop.png) ### Develop & Test Build and test APIs and integration apps. - [Develop your API.](https://docs.mulesoft.com/studio/) - [Connect your data, systems, and apps.](https://docs.mulesoft.com/connectors/) - [Develop the Mule app that integrates systems, services, APIs, and devices.](https://docs.mulesoft.com/mule-runtime/latest/mule-app-dev) - [Access and transform data within the Mule app.](https://docs.mulesoft.com/dataweave/latest/) - [Build automated tests for your APIs and integrations.](https://docs.mulesoft.com/munit/latest/) ![](/mulesoft/current/en-us/general/_images/deploy.png) ### Deploy Choose a deployment option, deploy APIs and apps, and secure them with policies. - [Choose a deployment option.](https://docs.mulesoft.com/runtime-manager/deployment-strategies) - [Configure a proxy for your API.](https://docs.mulesoft.com/api-manager/latest/api-proxy-landing-page) - [Protect your APIs with policies.](https://docs.mulesoft.com/api-manager/latest/manage-policies-overview) ![](/mulesoft/current/en-us/general/_images/monitor.png) ### Monitor Monitor your APIs and integrations using dashboards, metrics, and visualization. - [View metrics for integration apps and APIs.](https://docs.mulesoft.com/monitoring/) - [Test the functional behavior and performance of your API.](https://docs.mulesoft.com/api-functional-monitoring/) - [Monitor your deployed apps.](https://docs.mulesoft.com/runtime-manager/monitoring) --- product: Getting Started keywords: open policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform --- # Open Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt An open policy is a provider-agnostic authoring experience. You configure one policy once, and MuleSoft 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 Omni 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**. > [!NOTE] Automate open policy application using the MuleSoft MCP Platform Server. For details, see > [apply\_universal\_policy](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#apply-universal-policy) > in the MuleSoft MCP Platform Server Tool Reference. ## Open Use Cases At launch, there are five open use cases. Each maps to a specific native policy per provider. See [Supported Policies and Native Equivalents](https://docs.mulesoft.com/general/exp-policies-provider-reference#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. Open policies also support several additional native Kong policies. See [Supported Policies and Native Equivalents](https://docs.mulesoft.com/general/exp-policies-provider-reference#supported-policies-and-native-equivalents). Other recognized policies are view-only. See [Policy Edit Restrictions](https://docs.mulesoft.com/general/exp-policies-apply-manage#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 [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). > [!NOTE] When an open policy targets Omni instances, there is currently no Activity log record for > those targets, so there’s no in-product way to confirm the outcome on Omni 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 Policies vs. Automated Policies vs. Controls These three are easy to confuse. Use this comparison to choose the right tool:
Open PoliciesAutomated PoliciesControls

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.

Native to Omni and Mule, applied automatically by matching rules.

Across APIs and instances.

For automated policies and governance strategies, see [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies). ## See Also - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) --- product: Getting Started keywords: policy provider support, apigee, azure api management, kong, aws, injection points, policy permissions, anypoint platform --- # Provider Support and Limitations for Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt External gateways differ substantially in what they support and how they behave. This reference summarizes per-provider policy support, the setup each provider requires on your side, injection points, and locking behavior during operations. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - A connected scanner for each external provider whose policies you want to manage. Policy management reuses the scanner connection’s credentials. See [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers). ## Supported Actions by Provider
ProviderApplyEditRemoveEnable/DisableViewTrack/Govern

Omni Gateway

Yes

Yes

Yes

Yes

Yes

Yes

Kong Gateway

Yes

Yes

Yes

Yes

Yes

Yes

Google Apigee

Yes

Yes

Yes

No (no native concept)

Yes

Yes

Azure API Management

Yes

Yes

Yes

No (no native concept)

Yes

Yes

Amazon API Gateway

No

No

No

No (not supported yet)

Yes

Yes

> [!NOTE] > > - 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 > [Policy Edit Restrictions](https://docs.mulesoft.com/general/exp-policies-apply-manage#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. > > - View and Track/Govern reflect read-only visibility and governance reporting, which every > provider supports regardless of write access. See > [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy). ## Per-Provider Permissions Because policy management reuses the scanner connection, the permissions you see reflect what that connection’s identity is allowed to do on the provider, not a separate login. - Google Apigee: The enhanced MuleSoft experience checks the connected Google service account’s actual permissions on Google Cloud. See [Apigee Required Permissions and Roles](#apigee-required-permissions-and-roles). - Azure API Management: The enhanced MuleSoft experience checks the connected Azure principal’s role-based permissions on the API resource, including permissions inherited from higher scopes. - Kong Gateway: access is based on your Kong Konnect roles and team memberships for the instance’s control plane. Admin and power teams get full access; otherwise a matching role is required. - Omni Gateway: uses the same Anypoint Platform permissions as elsewhere in the product, with no separate provider-side check. ## Injection Points An injection point is where a policy runs relative to the request and response. Each policy template declares the injection points that it allows. If you choose an unsupported injection point, the system rejects the choice. - Google Apigee: you can choose request or response. On the Apigee side, both map to the proxy-level `PreFlow` (request and response map to the corresponding `PreFlow` section). - Azure API Management: supports `inbound`, `outbound`, and `backend`. Azure’s error-handling section is not editable through the enhanced MuleSoft experience. - Kong Gateway: the injection point is informational only; Kong’s plugin phase is fixed, so it doesn’t change placement. ## Instance Locking During Operations To prevent conflicting concurrent changes, an in-progress operation takes a lock. The scope of that lock differs by provider: - Azure API Management and Google Apigee lock the entire API instance. While one policy operation is running, no other policy operation on that instance can start. Wait for the running one to finish. On Azure, an instance’s policies live in a single document, so any change touches the whole thing. On Apigee, a change re-deploys the whole proxy, so it’s inherently instance-wide. - Kong Gateway locks only the specific policy that you modify. You can work with other policies on the same instance simultaneously. - Omni Gateway takes no such lock. If an operation is already in progress, another operation is mid-flight on that instance (Azure or Apigee) or on that same policy (Kong). Wait for the operation to complete. You can track it in the **Activity log**. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). ## Apigee Required Permissions and Roles For Apigee, the connected Google service account requires these permissions for policy create, edit, and remove operations to work. They cover the read-import-deploy cycle every Apigee change performs: - `apigee.proxies.get` - `apigee.proxyrevisions.get` - `apigee.proxies.create` - `apigee.deployments.list` - `apigee.deployments.create` To get these permissions, you can use one of these predefined Apigee roles: - Apigee API Admin - Apigee Environment Admin Any custom role or higher-scope grant that includes the five permissions also works. The enhanced MuleSoft experience checks the account’s effective permissions, not the role name. ## Supported Policies and Native Equivalents At launch, open policies support 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.
Open Use CaseOmni GatewayGoogle ApigeeAzure API ManagementKong Gateway

API Key Enforcement

Client ID Enforcement

Verify API Key

— (not available)

Key Auth

CORS

CORS

CORS

CORS

CORS

Header Manipulation

Header Injection + Header Removal

Assign Message (request & response)

Set Header (inbound & outbound)

Request Transformer + Response Transformer

IP Allowlist

IP Allowlist

Access Control

IP Filter

IP Restriction

JWT Validation

JWT Validation (Mule 4 & Flex Gateway)

Verify JWT

— (not available)

JWT Signer

> [!NOTE] > > - A dash (—) means that the provider doesn’t offer the use case because it lacks a native > equivalent. > > - Some use cases map to more than one native policy. For example, Header Manipulation applies > separate request/response (or inbound/outbound) policies, and Omni Gateway’s Header Manipulation > is two policies (injection and removal). Open policies also support 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 - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) --- product: Getting Started --- # Publishing Custom LLM Providers to Anypoint Exchange > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If your LLM provider or gateway is not one of the built-in [Model Proxy providers](https://docs.mulesoft.com/general/model-proxy#supported-llm-providers), publish it to Anypoint Exchange as an llm-metadata.json classifier. Model Proxy can then route traffic to that provider. You create the classifier, confirm the asset version is free, and publish it with the Exchange API. ## Before You Begin Before getting started, make sure you have: - `curl` installed To install, see [Install curl](https://curl.se/download.html). - `jq` installed To install, see [Install jq](https://jqlang.org/download/). - An Anypoint [connected app](https://docs.mulesoft.com/access-management/creating-connected-apps-dev) that: - Acts on its own behalf with the `client_credentials` grant type. - Has the **Exchange Contributor** or **Exchange Administrator** scope assigned to the target business group. ## Create the Classifier The `llm-metadata.json` classifier is a JSON object. Only `platform` is required. Unknown properties aren’t accepted, so use only the documented fields.
FieldTypeRequiredDescription

platform

String

Yes

Provider or platform identifier, such as Gemini, OpenAI, or a custom name.

name

String

No

Human-readable platform name.

inputFormat

String

No

Wire format: openai, anthropic, or gemini.

kind

String

No

Platform type, for example llm-gw.

authentication

Array

No

Supported provider authentication methods.

models

Array

No

Model ID strings or detailed model objects.

defaultUrl

Array

No

Named provider URL entries. Each entry requires both name and url.

capabilities

Object

No

Platform-wide supported features.

policyRef

Object

No

Adapter policy coordinates. Requires groupId and assetId. version is optional.

provenance

Object

No

Origin information. Supports id, createdAt, updatedAt, version, status, and url. Use RFC 3339 date-time strings for timestamps.

### Authentication Each `authentication` entry requires `kind`. Supported values are: - `none` - `apiKey` - `amazonSigv4` Authentication entries can include non-secret defaults such as header names, token URLs, scopes, or timeouts. Never include actual API keys, passwords, client secrets, or tokens. If `kind` is `none`, it must be the only authentication entry.
Authentication KindOptional Configuration

apiKey

headerName (required when a configuration is present), apiKeyPrefix, headersToRemove, and additionalHeaders

### Models The `models` field is an array. Each item can be either of these forms: - A string containing only the provider’s model identifier, such as `"gemini-2.5-flash"`. - A detailed object. The `id` field is required. All other fields are optional.
Model FieldTypeDescription

id

String

Provider-specific model identifier.

label

String

Human-readable model name.

description

String

Summary of the model and its intended use.

limits

Object

Context, output, and prompt-caching limits.

capabilities

Object

Features supported by this specific model.

pricing

Object

Prices per million tokens.

lifecycle

Object

Release and retirement information.

The nested objects support these fields:
ObjectFieldTypeDescription

limits

maxInputTokens

Integer

Maximum number of input tokens.

limits

maxOutputTokens

Integer

Maximum number of generated tokens.

limits

supportsPromptCaching

Boolean

Whether prompt caching is supported.

limits

maxCachedTokens

Integer

Maximum number of tokens that can be cached.

pricing

inputPerMillion

Number

Price per million input tokens.

pricing

outputPerMillion

Number

Price per million output tokens.

pricing

cachedInputPerMillion

Number

Price per million cached input tokens.

pricing

reasoningPerMillion

Number

Price per million reasoning tokens.

lifecycle

status

String

Provider-defined state, such as active, deprecated, or sunset.

lifecycle

releasedAt

String

Release date or timestamp.

lifecycle

sunsetAt

String or null

Known retirement date, or null.

This example shows both model forms. ```json { "models": [ "gemini-2.5-flash", { "id": "gemini-2.5-pro", "label": "Gemini 2.5 Pro", "description": "A multimodal model for complex reasoning tasks.", "limits": { "maxInputTokens": 1000000, "maxOutputTokens": 8192, "supportsPromptCaching": true, "maxCachedTokens": 500000 }, "capabilities": { "toolCalling": true, "structuredOutput": true, "imageInput": true, "reasoning": { "supported": true, "type": "adaptive", "effortLevels": ["low", "medium", "high"] } }, "pricing": { "inputPerMillion": 1.25, "outputPerMillion": 5.0, "cachedInputPerMillion": 0.3125, "reasoningPerMillion": 5.0 }, "lifecycle": { "status": "active", "releasedAt": "2025-03-25T00:00:00Z", "sunsetAt": null } } ] } ``` ### Capabilities Declare capabilities at the platform level or within a detailed model. The boolean flags are: - `embeddings` - `toolCalling` - `structuredOutput` - `codeExecution` - `citations` - `batchProcessing` - `imageInput` - `pdfInput` Reasoning support isn’t a boolean flag. Declare it with a nested `reasoning` object that describes whether the platform or model supports reasoning and how it’s controlled:
FieldTypeRequiredDescription

supported

Boolean

Yes

Whether the platform or model supports reasoning.

type

String

No

The reasoning mode the provider uses, for example adaptive.

effortLevels

Array of strings

No

The reasoning effort levels that the provider accepts, for example low, medium, and high.

In this example, the model supports reasoning and accepts three effort levels: ```json "capabilities": { "reasoning": { "supported": true, "type": "adaptive", "effortLevels": ["low", "medium", "high"] } } ``` If the platform or model doesn’t support reasoning, omit the `reasoning` object or set `supported` to `false`. With the exception of a custom authentication method’s provider-specific configuration, nested objects don’t accept undocumented fields. ### Example LLM Provider Asset Create a file named `llm-metadata.json`: ```json { "platform": "Geminiano", "name": "Geminiano", "inputFormat": "gemini", "kind": "llm-gw", "authentication": [ { "kind": "apiKey", "defaultConfiguration": { "headerName": "X-goog-api-key", "headersToRemove": ["Authorization"] } } ], "models": ["gemini-2.5-flash"], "defaultUrl": [ { "name": "default", "url": "https://generativelanguage.googleapis.com/v1beta/" } ], "capabilities": { "toolCalling": true, "structuredOutput": true, "imageInput": true, "pdfInput": true, "reasoning": { "supported": true } } } ``` ## Publish the LLM Asset with the Exchange API 1. Set the coordinates for the asset you want to publish: ```bash export ORGANIZATION_ID="YOUR_ORGANIZATION_ID" export GROUP_ID="YOUR_GROUP_ID" export ASSET_ID="my-custom-llm" export ASSET_VERSION="1.0.0" export VERSION_GROUP="v1" export ASSET_NAME="My Custom LLM" ``` The organization ID identifies the business group that receives the asset. The group ID is the asset’s Maven group ID and is commonly the same value. Use a lowercase, URL-safe asset ID. > [!NOTE] Exchange versions are immutable. If a version already exists, publish a new semantic > version. 2. Export your credentials in the current shell or retrieve them from a secret manager. Don’t commit them to source control or paste them into documents. ```bash read -r -p 'Anypoint client ID: ' ANYPOINT_CLIENT_ID read -r -s -p 'Anypoint client secret: ' ANYPOINT_CLIENT_SECRET echo export ANYPOINT_CLIENT_ID ANYPOINT_CLIENT_SECRET ``` > [!WARNING] Shell history can expose values. Avoid commands such as > `export ANYPOINT_CLIENT_SECRET=literal-secret`. 3. Obtain a bearer token. The steps use OAuth 2.0 client credentials and the production Anypoint host, `[https://anypoint.mulesoft.com](https://anypoint.mulesoft.com)`. ```bash TOKEN_RESPONSE=$(curl --fail-with-body --silent --show-error --location \ --request POST \ 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "client_id=$ANYPOINT_CLIENT_ID" \ --data-urlencode "client_secret=$ANYPOINT_CLIENT_SECRET" \ --data-urlencode 'grant_type=client_credentials') ANYPOINT_TOKEN=$(printf '%s' "$TOKEN_RESPONSE" | jq -er '.access_token') export ANYPOINT_TOKEN ``` Don’t print or log `TOKEN_RESPONSE` or `ANYPOINT_TOKEN`. 4. Confirm your new provider version is available: ```bash curl --silent --show-error \ --output /dev/null \ --write-out 'HTTP %{http_code}\n' \ --header "Authorization: Bearer $ANYPOINT_TOKEN" \ "https://anypoint.mulesoft.com/exchange/api/v2/assets/$GROUP_ID/$ASSET_ID/$ASSET_VERSION" ``` Make sure you receive a `404` error code. - `HTTP 404`: The version is available. - `HTTP 200`: The version already exists. Change `ASSET_VERSION` before publishing. - `HTTP 401` or `HTTP 403`: The request wasn’t authorized. See [Troubleshooting Error Codes](#troubleshooting). 5. From the directory that contains `llm-metadata.json`, publish the asset to Exchange: ```bash curl --fail-with-body --silent --show-error --location \ --request POST \ "https://anypoint.mulesoft.com/exchange/api/v2/organizations/$ORGANIZATION_ID/assets/$GROUP_ID/$ASSET_ID/$ASSET_VERSION" \ --header 'Accept: application/json' \ --header 'x-sync-publication: true' \ --header "Authorization: Bearer $ANYPOINT_TOKEN" \ --form 'files.llm-metadata.json=@llm-metadata.json;type=application/json' \ --form "properties.versionGroup=$VERSION_GROUP" \ --form 'type=llm' \ --form "name=$ASSET_NAME" ``` Don’t set the multipart `Content-Type` header manually. `curl --form` generates the required boundary and header. > [!NOTE] If your file has a different name, replace `@llm-metadata.json` with > `@`. 6. Verify the published asset: ```bash curl --fail-with-body --silent --show-error \ --header 'Accept: application/json' \ --header "Authorization: Bearer $ANYPOINT_TOKEN" \ "https://anypoint.mulesoft.com/exchange/api/v2/assets/$GROUP_ID/$ASSET_ID/$ASSET_VERSION" \ | jq '{groupId, assetId, version, name, type, status}' ``` 7. Open the asset in Exchange and confirm that the published version is visible and that its `llm-metadata.json` classifier is downloadable. 8. After testing, unset the sensitive shell variables: ```bash unset ANYPOINT_CLIENT_ID ANYPOINT_CLIENT_SECRET ANYPOINT_TOKEN TOKEN_RESPONSE unset ORGANIZATION_ID GROUP_ID ASSET_ID ASSET_VERSION VERSION_GROUP ASSET_NAME ``` Rotate any client secret you pasted into chat, logs, tickets, or shell history before using this process in automation. ## Troubleshooting Error Codes `401 Unauthorized` Obtain a new token and verify the client ID and secret. `403 Forbidden` In **Access Management** > **Connected Apps**, add **Exchange Contributor** or **Exchange Administrator** for the target business group. Save the app, obtain a new token, and retry. `409 Conflict` The version already exists. Publish a new semantic version. `400 Bad Request` Check the JSON field names and types, `type=llm`, and `properties.versionGroup`. ## See Also - [Creating Model Proxies](https://docs.mulesoft.com/general/model-proxy-create-model-proxy) - [Connected Apps in Anypoint Platform](https://docs.mulesoft.com/access-management/connected-apps-overview) - [Publishing Assets](https://docs.mulesoft.com/exchange/about-sharing-assets) --- product: Getting Started keywords: register services manually, mcp servers, agents, service registration, mulesoft, anypoint platform, manual configuration --- # Register Services Manually > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Register a service to add it to your portfolio when you already have the metadata, specification, endpoint, or card required in Enhanced Experience, without running a provider scan. Start from **Home** or from the catalog for that service type in **Portfolio**. Completed registrations appear in the matching catalog. To learn how manual registration relates to provider connections, see [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio). ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Get Started - **Home** Open **Add Services**, select the service type, then, if it is available, select manual registration . - **Portfolio** Open the **Agents**, **MCP Servers**, **Model Proxies**, or **APIs** catalog, use the add control for that type (for example **Add API**), and select **Register Manually**. To set up a gateway, select **Add Gateway** to open gateway setup in Anypoint Platform. Navigation labels can vary by catalog, enabled features, and release. ## Agents Register an agent by uploading an agent card file for an A2A or non-A2A agent. Manual registration does not support A2A or non-A2A connection routes, and the system does not validate a connection before creating the agent. ## MCP Servers For MCP servers, define how the system reaches the server and validates runtime access: - **By MCP URL** — Connect over a URL and test the live server so tools and metadata can be discovered. - **Upload Schema** — Upload a schema and supply the details needed to register and test the server. Successful registration stores the MCP server in the **MCP Servers** catalog. ## Model Proxies Model proxy registration has two parts: associate the proxy with a gateway and deployment context, then define routing (and any provider connections your flow requires). After setup is complete, the Model proxy appears in the **Model Proxies** catalog. ## APIs Add an API to the **APIs** catalog by registering it manually or by connecting to a provider. - **Register manually**–Upload a specification file to define a new API. - **Connect to provider**–Discover and import APIs from external platforms. See [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add). ### Register an API Manually When you register an API manually, you provide a specification file that defines the API structure, including endpoints, operations, and data types. 1. In the navigation pane, select **APIs**. 2. Click **Add API**. 3. Select **Register manually**. 4. Enter a name for the API. 5. Select the API type. 6. Upload the specification file. 7. Click **Create**. The experience supports multiple API types and specification formats: - REST APIs (OAS, RAML) - gRPC APIs (Proto files) - Async APIs (AsyncAPI specification) ## Gateways Manual gateway registration isn’t supported in the enhanced experience. To set up a gateway, select **Add Gateway** to open gateway setup in Anypoint Platform. ## See Also - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) --- product: Getting Started keywords: scanners, managing scanners, scanner actions, security scanning, mulesoft, vulnerability detection --- # Running and Managing Scanners > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Scanners typically run on a schedule you or an administrator configured, or manually when you start a scan. After you configure scanners, you run them day to day. Most of that work happens under **Providers**, where you manage provider connections, scanners, and scan activity in one place. > [!NOTE] Automate scanner management using the MuleSoft MCP Platform Server. For details, see > [list\_scanner\_providers](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#list-scanner-providers) > and > [test\_scanner\_connection](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#test-scanner-connection) > in the MuleSoft MCP Platform Server Tool Reference. ## Scanner Actions - **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. - **View Scanner** Inspect connection health, the last completed run, and scan history to verify whether discovery is healthy, slow, or failing authentication. - **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. - **Resume Scheduled Runs** 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. For API gateway providers that support policy write, granting the scanner connection’s identity the provider’s write scope enables policy write (apply, enable, disable, and remove) on the scanner’s discovered APIs. Policy write reuses the same connection you use for scanning. For provider-specific write scopes, see [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). - **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. > [!NOTE] When you delete an Akamai API Security scanner, the system attempts to remove the Akamai > correlation policy from the scanner’s environments. If the removal fails, the correlation policy > may remain applied; check **Automated Policies** to verify. Discovered services remain in your > portfolio regardless. > [!NOTE] Deleting an API gateway scanner used for policy write doesn’t remove policies that were > previously applied to the provider’s APIs through policy write. Those policies remain active on > the gateway. Anypoint stops tracking them, and you lose the ability to manage them from Anypoint > until you reconnect a scanner with the provider’s write scope. ## See Also - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [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) --- product: Getting Started keywords: scanner prerequisites, exchange scanners, provider scanners, required roles, required credentials, scanner setup, vaults --- # Scanner Prerequisites by Provider > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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
ProviderTypeRequired 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

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 alm_ai_* tables

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: 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

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:

  • 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

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:

  • In the Kong control plane, add a gateway service and attach an MCP-related plugin to it.

  • In Kong Catalog, open MCP Servers and create a new MCP server, then link a gateway service to it.

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: 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 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.
ProviderRead ScopeWrite Scope

Amazon API Gateway

apigateway:GET

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](https://docs.mulesoft.com/general/exp-policies-activity-log). > [!NOTE] Anypoint doesn’t manage vendor policy lifecycle, versioning, or CI/CD. ## See Also - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) - [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) --- product: Getting Started keywords: securing services, external vaults, secrets manager, credentials, Akamai API Security, risk correlation, rogue agents, Azure Key Vault, HashiCorp Vault, portfolio, anypoint platform --- # Securing Services in Your Portfolio > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Secure the services you already run so leaked keys, open vulnerabilities, and compromised agents are harder to start and faster to stop. Those failures can expose data, take unauthorized actions, or generate unexpected cost. As you add APIs, MCP servers, and agents, security has to travel with each service, not live only in a disconnected tool. - [Correlate Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) See risk scores, findings, and incidents on the APIs and MCP services you already govern, so teams can triage and remediate from one place. - [Use Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) Authenticate model proxies without storing API keys in MuleSoft. Credentials stay in your external vault. - [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents) Stop a compromised, misconfigured, or malfunctioning agent before it leaks data, takes unauthorized actions, or runs up costs. ## See Also - [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) - [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) - [Detect and Contain Rogue Agents](https://docs.mulesoft.com/general/exp-detect-and-contain-rogue-agents) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy) --- product: Getting Started --- # Sending Requests to Model Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Model Proxy supports these endpoint formats: OpenAI, Gemini, and Anthropic. The format is selected when creating a Model Proxy and can’t be changed later. - **[OpenAI format](#openai-format)**: Supports all LLM providers with multi-routing and fallback mechanisms. Supports both Chat Completions (`/chat/completions`) and Responses (`/responses`) endpoints. - **[Gemini format](#gemini-format-request-example)**: Native Gemini API format. Doesn’t support multi-routing or fallback mechanisms. - **[Anthropic format](#anthropic-format-request-example)**: Native Anthropic API format. Doesn’t support multi-routing or fallback mechanisms. ## Retrieve the Endpoint Configuration Parameters for Your Model Proxy To find your Model Proxy endpoint configuration and client application credentials required to use the requests in this guide: 1. Find your public endpoint: 1. From Anypoint Platform, navigate to **Runtime Manager** > **Omni Gateways**. 2. Click the name of the Omni Gateway where your Model Proxy is deployed. 3. Copy the **Public Endpoint**. 2. Find your base path: 1. From the enhanced experience, select **Model Proxies**. 2. Click the name of the Model Proxy whose base path you want to find. 3. From **Configuration**, copy the **Base path**. 3. Retrieve your client ID and client secret: 1. From the **Overview** page of your Model Proxy, click **Actions** > **View Model Proxy in Exchange**. 2. Click **Request access**. 3. Select the **API Instance** you want to request access to. 4. Select the **Application** you want to request access to. 5. Select the **SLA tier**. 6. Click **Request access**. 7. Copy the **Client ID** and **Client Secret**. ## OpenAI Format Learn more about the OpenAI request types: - [Chat Completions](https://developers.openai.com/api/reference/resources/chat) API is designed for conversational multi-turn interactions rather than simple text continuation. - [Responses](https://developers.openai.com/api/reference/resources/responses) API is recommended unified interface for building powerful agent-like applications. All requests are designed to work for both strategies. When sending a request to a Model Proxy with either routing strategy, you can specify a model in the request. You don’t have to modify the request for different routing strategies. Each routing strategy handles the model selection differently: - **Model-Based Routing**: The user specifies a model in the request (`"model": "openai/gpt-5.2"`). The Model Proxy acts as a direct proxy. If no model is specified, the Model Proxy sends the request to the fallback route or returns an error if no fallback route is configured. - **Semantic Routing**: No model is specified in the request. The Model Proxy chooses which model to use based on the request content by matching it to prompt topics you define for each route. If a model is specified in the request, like in model routing examples, it is ignored. > [!NOTE] Adding a model to a request ensures deterministic routing to a preferred backend if the > routing strategy of a Model Proxy changes. ### Chat Completions API Validation Request Examples [Chat Completions](https://developers.openai.com/api/reference/resources/chat) (/chat/completions) is the standard API for interacting with models. It is designed for conversational multi-turn interactions rather than simple text continuation. The endpoint requires a model and a messages list with roles (such as system, user, or assistant) to generate context-aware responses. These examples validate the basic functionality of the Chat Completions API. #### Basic Chat Completion Example This request example ensures the gateway correctly routes traffic to the specified LLM provider. In the example, the model-based routing request ensures the gateway routes traffic to a Gemini 2.0 model. For semantic routing, the gateway routes traffic to the most suitable provider based on the request content: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "developer", "content": "You are a helpful assistant" }, { "role": "user", "content": "Hello, please introduce yourself" } ] }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "developer", "content": "You are a helpful assistant" }, { "role": "user", "content": "Hello, please introduce yourself" } ] }' ``` #### Creative Content Generation Temperature Control Example This request example performs can preform brainstorming tasks, such as generating multiple unique marketing slogans. The example writes creative content using the temperature parameter (0 to 2 value, higher values are more creative) to control the randomness and creativity of the response: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "user", "content": "Write a creative story about AI" } ], "temperature": 1.5 }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "user", "content": "Write a creative story about AI" } ], "temperature": 1.5 }' ``` #### Multi-Turn Context Management Example This request example maintains conversation context across developer persona, user query, and assistant history. The example passes the "memory" of a conversation to ensure the model knows that "it" refers to "MuleSoft" based on the previous message in the thread: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "developer", "content": "You are a MuleSoft technical expert." }, { "role": "user", "content": "What is MuleSoft?" }, { "role": "assistant", "content": "MuleSoft is an integration platform that helps organizations connect applications, data, and devices." }, { "role": "user", "content": "How does it help with API management?" } ] }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "developer", "content": "You are a MuleSoft technical expert." }, { "role": "user", "content": "What is MuleSoft?" }, { "role": "assistant", "content": "MuleSoft is an integration platform that helps organizations connect applications, data, and devices." }, { "role": "user", "content": "How does it help with API management?" } ] }' ``` #### Structured Data Validation JSON Format Example This request example extracts patterns into structured JSON to transform a messy transcript into a clean JSON object for insertion into a database by using the `top_p` and `max_completion_tokens` parameters: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "user", "content": "Explain MuleSoft Integration patterns in JSON format" } ], "max_completion_tokens": 50000, "top_p": 0.9 }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "user", "content": "Explain MuleSoft Integration patterns in JSON format" } ], "max_completion_tokens": 50000, "top_p": 0.9 }' ``` #### Enterprise Strategy Testing Example This request example validates the gateway’s ability to handle large-payload "Expert" prompts. The example asks an AI Solution Architect to design a migration strategy from legacy SAP systems to Salesforce using MuleSoft Anypoint Platform with an API-led connectivity approach. - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "developer", "content": "You are a MuleSoft solution architect helping with enterprise integrations." }, { "role": "user", "content": "Design a data integration strategy for a Fortune 500 company migrating from legacy systems to Salesforce using MuleSoft Anypoint Platform. Include API-led connectivity approach." } ], "temperature": 0.7, "max_completion_tokens": 10000 }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "developer", "content": "You are a MuleSoft solution architect helping with enterprise integrations." }, { "role": "user", "content": "Design a data integration strategy for a Fortune 500 company migrating from legacy systems to Salesforce using MuleSoft Anypoint Platform. Include API-led connectivity approach." } ], "temperature": 0.7, "max_completion_tokens": 10000 }' ``` #### Streaming API Call Example This example supports user-facing chatbot UIs where the text must appear word-by-word as it is generated, rather than waiting for the entire response to finish. This request example validates the gateway’s ability to stream real-time non-buffered token delivery using the `--no-buffer` flag: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "user", "content": "Explain step-by-step MuleSoft integration process" } ], "stream": true }' \ --no-buffer ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "user", "content": "Explain step-by-step MuleSoft integration process" } ], "stream": true }' \ --no-buffer ``` #### Tool Calling: Initial Request with Tool Definition Example This request example allows the model to request real-time information from the application by invoking a function. The example asks the model to invoke a `get_current_time` function to get the current time in San Francisco, The model recognizes it can’t answer from memory and instead requests to invoke a `get_current_time` function from your local API. - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "tool_choice": "auto", "messages": [ { "role": "user", "content": "What is the time in San Francisco?" } ], "tools": [ { "type": "function", "function": { "name": "get_current_time", "description": "When user asks for time tell me to invoke this Tool", "parameters": { "type": "object", "properties": { "timezone": { "type": "string", "description": "Timezone of the user asked location" } }, "required": ["timezone"] } } } ] }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "openai/gpt-5.2", "tool_choice": "auto", "messages": [ { "role": "user", "content": "What is the time in San Francisco?" } ], "tools": [ { "type": "function", "function": { "name": "get_current_time", "description": "When user asks for time tell me to invoke this Tool", "parameters": { "type": "object", "properties": { "timezone": { "type": "string", "description": "Timezone of the user asked location" } }, "required": ["timezone"] } } } ] }' ``` #### Tool Calling: Request with Tool Execution Response Example This request example sends the executed tool output back to the Model Proxy to generate a final answer. The example provides the executed tool output (current time) back to the Model Proxy so the model can generate a natural-language response for the user: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "tool_choice": "auto", "messages": [ { "role": "user", "content": "What is the time in San Francisco?" }, { "role": "assistant", "content": null, "tool_calls": [ { "id": "call_KDrTKkRTGfylhkAO4A8s0pAO", "type": "function", "function": { "name": "get_current_time", "arguments": "{\"timezone\":\"America/Los_Angeles\"}" } } ] }, { "role": "tool", "tool_call_id": "call_KDrTKkRTGfylhkAO4A8s0pAO", "content": "2026-02-20T05:02:05.873534-08:00" } ], "tools": [ { "type": "function", "function": { "name": "get_current_time", "parameters": { "type": "object", "properties": { "timezone": { "type": "string" } }, "required": ["timezone"] } } } ] }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "openai/gpt-5.2", "tool_choice": "auto", "messages": [ { "role": "user", "content": "What is the time in San Francisco?" }, { "role": "assistant", "content": null, "tool_calls": [ { "id": "call_KDrTKkRTGfylhkAO4A8s0pAO", "type": "function", "function": { "name": "get_current_time", "arguments": "{\"timezone\":\"America/Los_Angeles\"}" } } ] }, { "role": "tool", "tool_call_id": "call_KDrTKkRTGfylhkAO4A8s0pAO", "content": "2026-02-20T05:02:05.873534-08:00" } ], "tools": [ { "type": "function", "function": { "name": "get_current_time", "parameters": { "type": "object", "properties": { "timezone": { "type": "string" } }, "required": ["timezone"] } } } ] }' ``` #### Structured Output Validation JSON Schema Example This request example validates entity extraction into a strictly defined JSON Schema (CalendarEvent). The example asks the model to extract the event information from a plain text user query and return a formatted JSON object that adheres to the required schema. This prevents integration or parsing errors in downstream applications: - Semantic Routing - Model-Based Routing ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "messages": [ { "role": "system", "content": "Extract the event information." }, { "role": "user", "content": "Madhu Dileep and Santosh A are going to a AI Summit on 19th Feb 2026." } ], "response_format": { "type": "json_schema", "json_schema": { "name": "CalendarEvent", "schema": { "type": "object", "properties": { "name": { "type": "string", "description": "Name of the event" }, "date": { "type": "string", "description": "Date of the event, in MM-DD-YYYY format" }, "participants": { "type": "array", "items": { "type": "string" } } }, "required": ["name", "date", "participants"] } } } }' ``` ```cli curl --location '//chat/completions' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "gemini/gemini-3-flash-preview", "messages": [ { "role": "system", "content": "Extract the event information." }, { "role": "user", "content": "Madhu Dileep and Santosh A are going to a AI Summit on 19th Feb 2026." } ], "response_format": { "type": "json_schema", "json_schema": { "name": "CalendarEvent", "schema": { "type": "object", "properties": { "name": { "type": "string", "description": "Name of the event" }, "date": { "type": "string", "description": "Date of the event, in MM-DD-YYYY format" }, "participants": { "type": "array", "items": { "type": "string" } } }, "required": ["name", "date", "participants"] } } } }' ``` ### Responses API Validation [OpenAI Responses API](https://developers.openai.com/api/reference/resources/responses) (/responses)is recommended unified interface for building powerful, agent-like applications, combining capabilities from previous APIs (like Chat Completions and Assistants) into a single, more efficient endpoint. It is designed to be stateful by default and offers built-in access to advanced tools. #### Responses Endpoint for Model Context Protocol (MCP) This request example integrates the gateway with an external MCP server for automated action execution. The example asks an AI agent to search a specific internal Knowledge Base or update a Jira ticket using standardized tools defined on a remote MCP server: - Semantic Routing - Model-Based Routing ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "input": [ { "role": "system", "content": "You are helpful Service Agent" }, { "role": "user", "content": "My Laptop screen is broken" } ], "tools": [ { "type": "mcp", "server_label": "service_mcp", "require_approval": "never", "server_description": "Server enabled to do Service related actions", "server_url": "https://ask-service-mcp-dvaz3u.c87dy0.usa-e2.cloudhub.io/mcp" } ] }' ``` ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "openai/gpt-5.2", "input": [ { "role": "system", "content": "You are helpful Service Agent" }, { "role": "user", "content": "My Laptop screen is broken" } ], "tools": [ { "type": "mcp", "server_label": "service_mcp", "require_approval": "never", "server_description": "Server enabled to do Service related actions", "server_url": "https://ask-service-mcp-dvaz3u.c87dy0.usa-e2.cloudhub.io/mcp" } ] }' ``` #### Stateful Response Persistence This request example validates persistent memory by creating a dependency between two requests using `previous_response_id`. The example removes the need for the client to send the entire previous chat history on every turn, reducing bandwidth and improving security by keeping the context on client side: Request 1: Initial stored call - Semantic Routing - Model-Based Routing ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "instructions": "You are helpful Service Knowledge Agent", "input": [ { "role": "user", "content": "My Laptop screen is broken" } ], "store": true }' ``` ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "openai/gpt-5.2", "instructions": "You are helpful Service Knowledge Agent", "input": [ { "role": "user", "content": "My Laptop screen is broken" } ], "store": true }' ``` Request 2: Follow-up using `previous_response_id` from the response to request 1 - Semantic Routing - Model-Based Routing ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "instructions": "You are helpful Service Agent", "previous_response_id": "", "input": [ { "role": "user", "content": "Thank you!" } ], "store": true }' ``` ```cli curl --location '//responses' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "openai/gpt-5.2", "instructions": "You are helpful Service Agent", "previous_response_id": "", "input": [ { "role": "user", "content": "Thank you!" } ], "store": true }' ``` ## Gemini Format The Gemini format uses the native Gemini API format. Note that this format doesn’t support multi-routing or fallback mechanisms. ### Basic Chat Completion Example This request example ensures the gateway correctly routes traffic to the Gemini provider. ```cli curl --location '//models/gemini-2.5-flash:generateContent' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "contents": [ { "role": "user", "parts": [{ "text": "Hello, please introduce yourself" }] } ] }' ``` ### Streaming API Call Example This example supports user-facing chatbot UIs where the text must appear word-by-word as it is generated rather than waiting for the entire response to finish. This request example validates the gateway’s ability to stream real-time, non-buffered token delivery: ```cli curl --location '//models/gemini-2.5-flash:streamGenerateContent?alt=sse' \ --header 'Content-Type: application/json' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "contents": [ { "role": "user", "parts": [{ "text": "Explain step-by-step MuleSoft integration process" }] } ] }' \ --no-buffer ``` ## Anthropic Format The Anthropic format uses the native Anthropic API format. Note that this format doesn’t support multi-routing or fallback mechanisms. ### Basic Chat Completion Example This request example ensures the gateway correctly routes traffic to the Anthropic provider. ```cli curl --location '//v1/messages' \ --header 'Content-Type: application/json' \ --header 'anthropic-version: 2023-06-01' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "claude-opus-4-1-20250805", "max_tokens": 1024, "system": "You are a helpful assistant", "messages": [ { "role": "user", "content": "Hello, please introduce yourself" } ] }' ``` ### Streaming API Call Example This example supports user-facing chatbot UIs where the text must appear word-by-word as it is generated, rather than waiting for the entire response to finish. This request example validates the gateway’s ability to stream real-time non-buffered token delivery using the `--no-buffer` flag: ```cli curl --location '//v1/messages' \ --header 'Content-Type: application/json' \ --header 'anthropic-version: 2023-06-01' \ --header 'client_id: ' \ --header 'client_secret: ' \ --data '{ "model": "claude-opus-4-1-20250805", "max_tokens": 2048, "stream": true, "messages": [ { "role": "user", "content": "Explain step-by-step MuleSoft integration process" } ] }' \ --no-buffer ``` ## Specify Amazon Bedrock Model Names in Requests Amazon Bedrock Claude models must be specified in Amazon Resource Name (ARN) format, for example: bedrockanthropic/us.anthropic.claude-sonnet-4-5-20250929-v1:0 Formatted as: bedrockanthropic/.anthropic. To find your region and model name for your Claude model, see [Supported Regions and models for inference profiles](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html). --- product: Getting Started keywords: models, model costs, cost per token, input tokens, output tokens, spend tracking, budgets, model proxies, cost management, anypoint platform --- # Setting Model Costs for Spend Tracking > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Set a cost for each model so usage translates into spend tracking. The **Models** page lists the AI models available in your organization. Wallet budgets can cap spend or token count. Spend caps use the model costs that you set here. ## Before You Begin To set model costs, you need: - An Anypoint Platform account. - One of the API Manager permissions: - API Manager: API Creator - API Manager: View APIs Configuration - API Manager: Edit APIs Configuration For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## View Models The **Models** page lists available models, the proxies that use them, and any costs you have set. 1. From **Portfolio** > **Model Proxies**, select **Models**. 2. Review the list of available models. 3. To see details for a model, select its name. The model detail page shows the model proxies that use the model and the model’s configured costs if applicable. ## Edit Model Costs Model costs drive spend and budget calculations. Set a cost per token for each model that you use. 1. From **Portfolio** > **Model Proxies**, select **Models**. 2. Select a model, for example, `Claude 3.5 Haiku`. 3. Select **Edit** from the **Actions** menu. 4. Enter the **Cost per 1M Input Tokens**, for example, `0.01`. 5. Enter the **Cost per 1M Output Tokens**, for example, `0.05`. 6. Select **Save changes**. If a model has no configured cost, then spend tracking and spend-based wallet budgets treat that model’s usage as zero. Token-based wallet budgets still count tokens. See [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage). ## See Also - [Capping Spend for Callers of Model Proxies](https://docs.mulesoft.com/general/exp-model-wallets-manage) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) --- product: Getting Started keywords: api-led connectivity, anypoint code builder, cloudhub 2.0, prerequisites, mulesoft setup, api-led solution, installation --- # Step 1. Prerequisites for Building an API-Led Solution > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Set up your environment before starting the tutorial. You need an Anypoint Platform account, Anypoint Code Builder, and a REST client such as Postman. Specific permissions are also required for deployment and, optionally, for AI-assisted API design with MuleSoft Vibes. - Username and password for your Anypoint Platform organization. If you don’t have Anypoint Platform yet, create a Trial organization on Anypoint Platform. [Create a Trial organization](https://anypoint.mulesoft.com/login/#/signup) - [Download and install Visual Studio Code](https://code.visualstudio.com/download) - To test REST requests, obtain a client such as Postman or Advanced REST Client if you don’t already have one. This tutorial uses Postman. [Install Postman](https://www.postman.com/downloads/) Depending on your platform, you might need to install a different client. - [Install Anypoint Code Builder](#install-acb) - Required permissions: - **Anypoint Code Builder Developer** Allows API spec creation - **Exchange Contributor** Enables publishing assets to Exchange - **Create Applications** Allows deployment of applications to CloudHub 2.0 - Optional permissions (for MuleSoft Vibes AI features): **MuleSoft Vibes** requires generative AI to be enabled in Access Management. See [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - **Mule Developer Generative AI User** Enables MuleSoft Vibes features for AI-generated API specs. If you don’t have this permission, you can still complete the tutorial by manually creating your API spec. ## Install Anypoint Code Builder Install the Anypoint Extension Pack in Visual Studio Code to set up Anypoint Code Builder for desktop development. 1. Open Visual Studio Code. 2. Select **View > Extensions** and search for the **Anypoint Extension Pack**. To avoid installation errors, don’t install the individual Anypoint Code Builder extensions that are also available separately from Anypoint Extension Pack in Visual Studio Marketplace. 3. Select **Install**. > [!NOTE] Make sure that the Anypoint extensions update automatically by right-clicking each > extension to see if **Auto Update All (From Publisher)** is selected. If it’s not, select > **Auto Update** for each extension. 4. If you have an Anypoint Platform account running in the EU cloud, change the **Mule: Control Plane** setting to **EU cloud**: 1. Press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows/Linux) to open the Command Palette. 2. Type **Preferences: Open Settings** and select it. 3. Search for **Mule: Control Plane**. 4. Change the value to **EU cloud**. > [!NOTE] If an Anypoint Platform session is active in any of your browsers when you install > the Anypoint Extension Pack, the extension pack uses that session to sign in to Anypoint > Platform from the IDE. You can log out or sign in from the status bar in the IDE. ## CloudHub 2.0 Setup For CloudHub 2.0 deployments, you need: - A CloudHub 2.0 Shared Space in your organization. Anypoint Platform trial accounts include a default Shared Space. See [About Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about). - At least one environment (such as Sandbox or Development) configured for CloudHub 2.0 deployments. See [Anypoint Platform Environments](https://docs.mulesoft.com/access-management/environments). ## Helpful Hints - Use two browser windows: one to read instructions and one to perform the tasks. - In Anypoint Code Builder, enable auto-save to avoid losing work (**File > Auto Save**). - Bookmark the [Anypoint Platform](https://anypoint.mulesoft.com) login page. ## What’s Next With your environment ready, the next step is designing your API spec. [Step 2. Design an API Specification](https://docs.mulesoft.com/general/api-led-design) --- product: Getting Started keywords: api spec design, anypoint code builder, api-led connectivity, raml, rest api, api specification, mulesoft --- # Step 2. Design an API Spec > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API-led development means designing the contract before writing any code. By defining your API spec upfront, you give your team, consumers, and tools a shared contract to build against, which reduces rework and increases reuse. Design your API spec before building the implementation. An API spec defines the endpoints, parameters, and responses your API supports, giving you and your team a contract to work from. To design an API, assess the purpose and requirements: - Identify the type of API: Is it a simple API, part of an integration, or part of a backend system? - Understand the data flows: one-way, two-way, or more. - Explore the security requirements. After you define the scope and flow of your integration project, define an API spec in OAS. You can use MuleSoft Vibes to generate the spec from a plain-language description, or create it manually in Anypoint Code Builder. ## API Specs and APIs An API is a published interface to a resource that anyone with the correct permissions and a properly structured request can access. An API spec details the functional and expected behavior of an API, as well as the fundamental design philosophy and supported data types. It contains both documentation and API definitions to create a contract that people and software can read. MuleSoft provides tools that make it easy to create an API spec that you can then share with your team, your customers, or the general public. Using an API spec increases adoption and shortens project completion time. ## Step 2.1: Explore Existing API Specs If you look at existing API specs before writing your own, you can learn how other people have approached situations similar to yours. You can also check whether an API spec with the same objectives isn’t already in development, and reuse it if appropriate. Looking for an API spec that already does what you need is easy: 1. Look at the public Anypoint Exchange, which is a portal hosted by MuleSoft that contains API specs, connectors, and other assets that you can download and use. You’ll see some of the most popular API specs, connectors, and other assets displayed on the landing page. [Take me to Exchange](https://www.mulesoft.com/exchange) 1. Select **Any Type > REST APIs** to display only REST API specs. 2. Click any spec to see the data types and the HTTP requests defined for the API. 2. Look at Exchange for your organization (account). Logging in changes the view to your organization’s private Exchange. [Take me to Anypoint Platform](https://anypoint.mulesoft.com/login) 1. Log in to Anypoint Platform if needed. 2. In the Anypoint Platform landing page, go to the **Exchange** section and click **Discover & Share**. 3. Click any spec to see the data types and the HTTP requests defined for the API. If this is a trial org, you might not see anything yet. After exploring Exchange to see the range of assets available, use Anypoint Code Builder to create a new API spec. ## Step 2.2: Access Anypoint Code Builder 1. Open the desktop IDE (VS Code) with Anypoint Code Builder installed. 2. In the activity bar of the IDE, click ![](/mulesoft/current/en-us/general/_images/icon-ms-logo.png) (**Anypoint Code Builder**). ## Step 2.3: Create Your API Spec You have two options for creating your API spec. Choose the method that works best for your environment: - **Option A: Use MuleSoft Vibes (AI-Powered)**: Requires the Mule Developer Generative AI User permission and generative AI enabled in Access Management - **Option B: Create Manually**: Use this option if you don’t have access to MuleSoft Vibes - Option A: Use MuleSoft Vibes - Option B: Create Manually 1. Open MuleSoft Vibes from the toolbar or from the **Build Your Ecosystem with AI** card in the canvas. 2. Type this prompt in the chat: ```text Create an OAS 3.0 API spec called "hello-world-api" with a GET endpoint at /greeting that accepts a required query parameter called "name" and returns a JSON response with a message field containing a personalized greeting. ``` 3. Press Enter to send. MuleSoft Vibes generates your API spec in about 10 seconds. You’ll see the generated spec in the chat response. 4. Click **Create Project** in the MuleSoft Vibes response. 5. Select your home directory as the project location. Anypoint Code Builder creates the project and opens `hello-world-api.yaml` in the editor. 6. Click **Design an API**. 7. Complete the **API Specification** form: - **Project Name**, enter `hello-world-api`. - **Project Location**, select your home directory. - **API Type**, select **REST API**. - **API Specification Language**, select **OAS 3.0 (YAML)**. - Optionally, select a business group. ![The form to create a new API spec with values filled in](/mulesoft/current/en-us/general/_images/api-tutorial-create-project-acb.png) 8. Click **Create Project**. Anypoint Code Builder creates the project and opens `hello-world-api.yaml` in the editor with a basic template. 9. Replace the template content with this API spec: ```yaml openapi: 3.0.0 info: title: hello-world-api version: 1.0.0 paths: /greeting: get: parameters: - name: name in: query required: true schema: type: string description: The name to greet responses: "200": description: Success content: application/json: schema: type: object properties: message: type: string example: "Hello, World!" ``` 10. Save the file (**File > Save** or Cmd+S/Ctrl+S). ## Step 2.4: Review Your API Spec You now have a complete API spec open in the editor. Review the structure: ```yaml openapi: 3.0.0 info: title: hello-world-api version: 1.0.0 paths: /greeting: (1) get: parameters: (2) - name: name in: query required: true schema: type: string description: The name to greet responses: (3) '200': description: Success content: application/json: schema: type: object properties: message: (4) type: string example: "Hello, World!" ```
1The endpoint path for the API. Clients send GET requests to /greeting.
2Defines the required query parameter that clients must provide.
3Defines the possible HTTP responses this endpoint returns.
4The JSON response property that contains the greeting message.
## Step 2.5: Test with the Mocking Service Use the Mocking Service in the API Console to test your spec before implementing it. 1. With `hello-world-api.yaml` still open, click ![](/mulesoft/current/en-us/general/_images/icon-api-console.png) (**API Console**) in the editor toolbar. ![Yaml file is open and API Console icon is selected in the toolbar](/mulesoft/current/en-us/general/_images/api-tutorial-open-api-console-acb.png) The API Console displays your spec. 2. In the API Console, expand the **GET** method for the `/greeting` resource. 3. Click **Try It**. 4. In the **name** query parameter field, enter `World`. 5. Click **Send**. 6. Verify that API Console returns the response: ```json { "message": "Hello, World!" } ``` Congratulations, you’ve designed an API! ## What You Learned You created an OAS 3.0 API spec in Anypoint Code Builder, either by describing your API in plain language using MuleSoft Vibes or by writing the YAML manually. You then used the API Console’s Mocking Service to test the spec and verify it returns the expected response before writing any implementation code. ## Developer Deep Dive Explore advanced API design capabilities: - [MuleSoft Vibes Features](https://docs.mulesoft.com/anypoint-code-builder/vibes-api-ai-create-spec) - [API Governance and Validation](https://docs.mulesoft.com/anypoint-code-builder/des-govern-api) - [Creating Reusable API Fragments](https://docs.mulesoft.com/anypoint-code-builder/des-create-api-fragments) - [Advanced API Design Patterns](https://docs.mulesoft.com/design-center/design-create-publish-api-specs) ## What’s Next Now that your API is designed, you’ll scaffold an implementation project and add the business logic to make it functional. [Step 1. Prerequisites](https://docs.mulesoft.com/general/api-led-prerequisites) [Step 3. Develop the API](https://docs.mulesoft.com/general/api-led-develop) --- product: Getting Started keywords: api-led connectivity, implementation project, scaffolded structure, hello world, mulesoft development, anypoint studio, api implementation --- # Step 3. Develop the API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Now that you’ve created an API spec, you’ll turn it into a working Mule application. Anypoint Code Builder includes an embedded Mule runtime for local testing. Later, you’ll deploy your application to [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy), where it runs on Mule runtime in the cloud. ## Step 3.1: Create the Implementation Project 1. Open your API spec file in the editor, then click ![](/mulesoft/current/en-us/general/_images/icon-implement-api.png) (**Implement this local API**) in the activity bar. > [!NOTE] The icon and command are only available when your API spec file is open and active in > the editor. Alternatively, open the Command Palette and select `MuleSoft: Implement this Local API`. Show me how - Use the keyboard shortcuts: - Mac: Cmd+Shift+p - Windows: Ctrl+Shift+p - In the desktop IDE, select **View** > **Command Palette**. > [!IMPORTANT] Don’t select `MuleSoft: Implement an API Specification`. That command is for > specs published to Anypoint Exchange, not local specs. 2. At the prompt, click **OK**. ![Implement API specification dialog prompting to create a workspace to keep API spec and Mule project in sync](/mulesoft/current/en-us/general/_images/api-tutorial-implement-prompt.png) 3. When prompted to save a `.code-workspace` file, navigate to your home directory and click **Save**. > [!IMPORTANT] Don’t accept the default location. The default saves the `.code-workspace` file > inside your `hello-world-api` spec folder, which causes errors. You must save it one level up > — in your home directory — so it sits alongside (not inside) your projects. For example, if you created your API spec in `~/hello-world-api/`, navigate up to `~` (your home directory) and save the file there. Your folder structure should look like this: ~/ (home directory) ├── hello-world-api/ <- your API spec project │ └── hello-world-api.yaml └── hello-world.code-workspace <- save the file HERE 4. When prompted, provide project configuration details: 1. Provide a name for your Mule project, for example, `hello-world-impl`. ![The prompt to provide a project name for the API implementation project](/mulesoft/current/en-us/general/_images/api-tutorial-api-impl-provide-project-name-prompt.png) 2. When prompted to select a target folder, navigate to your home directory (`~`) and click **Select target folder**. This is where Anypoint Code Builder creates the `hello-world-impl` project folder. Selecting your home directory places both projects side by side: ~/ (home directory) ├── hello-world-api/ <- API spec project │ └── hello-world-api.yaml ├── hello-world-impl/ <- implementation project (created here) └── hello-world.code-workspace 3. Select a Mule runtime version for the project. 4. Select a Java version for the project. Anypoint Code Builder scaffolds your local API spec into a new Mule project. Both the API spec and the implementation project open together in your IDE in a multi-root workspace. 5. Confirm the implementation file opened correctly: 1. In the Explorer view on the left, you’ll see two projects listed: `hello-world-api` and `hello-world-impl`. 2. Expand `hello-world-impl > src > main > mule` and open `hello-world-api.xml`. This is the Mule configuration XML, scaffolded from your API spec. It contains your flows, HTTP Listener, and APIkit Router. The canvas opens automatically. ## Step 3.2: Understand the Scaffolded Structure The canvas shows your scaffolded flows, including: - **hello-world-api-main** HTTP Listener that receives requests on port 8081 - **get:\\greeting:hello-world-api-config** Your GET endpoint implementation - Error handling flows Click the **Listener** component, then select **Edit Connection** (![](/mulesoft/current/en-us/general/_images/icon-gear.png)) to review the connection configuration, including: - **Path**: `/api/*` (receives all API requests) - **Host**: `0.0.0.0` (listens to all interfaces) - **Port**: `8081` (local development port) ![Anypoint Code Builder canvas with Listener component highlighted and an arrow pointing to the Edit Connection icon](/mulesoft/current/en-us/general/_images/api-tutorial-listener-component.png) ## Step 3.3: Implement the Hello World Logic Now add the logic to return your greeting. 1. Navigate to the **get:\\greeting:hello-world-api-config** flow in the canvas. ![The get:\\greeting:hello-world-api-config flow highlighted in the flow list](/mulesoft/current/en-us/general/_images/api-tutorial-api-config-flow-acb.png) The flow contains a **Logger** component by default. You’ll add a **Transform** component after it to return your greeting. 2. Click ![](/mulesoft/current/en-us/general/_images/icon-plus.png) (**Add component**) after the Logger component in the flow. 3. In the **Add Component** panel, search for `Transform` and select **Transform** from the results. 4. Click the **Transform** component to open the DataWeave editor. 5. In the DataWeave editor that opens, replace the default script with: ```dataweave %dw 2.0 output application/json --- { message: "Hello, " ++ attributes.queryParams.name ++ "!" } ``` ![The Transform component with the DataWeave script inserted](/mulesoft/current/en-us/general/_images/api-tutorial-transform-component-acb.png) This DataWeave script reads the `name` query parameter and returns a personalized greeting. 6. Save your changes (Cmd+S on Mac, Ctrl+S on Windows/Linux). That’s it! Your API is implemented and ready to test. ## What You Learned You scaffolded a Mule project from your API spec using Anypoint Code Builder, which generated the HTTP Listener, APIkit Router, and flow structure automatically. You then implemented the greeting logic by adding a **Transform** component and writing a DataWeave script to read the `name` query parameter and return a JSON response. ## Developer Deep Dive Explore advanced implementation techniques: - [DataWeave Language Reference](https://docs.mulesoft.com/mule-runtime/latest/dataweave) - [Error Handling in Mule 4](https://docs.mulesoft.com/mule-runtime/latest/error-handling) - [Understanding Flows and Subflows](https://docs.mulesoft.com/mule-runtime/latest/about-flows) ## What’s Next Your API is implemented. Next, you’ll test it locally using debugging tools, add validation, and inspect the data flow. [Step 2. Design an API Specification](https://docs.mulesoft.com/general/api-led-design) [Step 4. Test the API](https://docs.mulesoft.com/general/api-led-test) --- product: Getting Started keywords: api testing, apikit validation, mulesoft api, logging, api-led connectivity, run api, test api --- # Step 4. Test the API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Test your API locally before deploying it to the cloud. You run the API in Anypoint Code Builder, send requests using Postman, add logging to track requests, and use the built-in debugger to inspect the Mule message at each step. ## Step 4.1: Run and Test Your API 1. Open the Run and Debug panel. Show me how - Click ![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) (**Run and Debug**) in the activity bar. - Use the keyboard shortcuts: - Mac: Cmd+Shift+d - Windows: Ctrl+Shift+d - In the desktop IDE, select **View** > **Run**. 2. Run the Mule app. ![The Run and Debug panel and the button to run the Mule app](/mulesoft/current/en-us/general/_images/api-tutorial-run-mule-app-acb.png)
1Click to open the Run and Debug panel.
2Click the button to run the Mule app.
The Output panel shows startup progress. Wait for `Application started successfully`. 1. Open Postman and send a GET request: ```text http://localhost:8081/api/greeting?name=World ``` 2. Verify you receive: ```json { "message": "Hello, World!" } ``` Your API works! Now let’s add logging and explore debugging. 3. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) in the debug toolbar. ## Step 4.2: Add Logging Logging helps you see what’s happening inside your flows. 1. Click the **Logger** component and configure it: - **Message**: Click **fx** to switch to expression mode, then enter: ```dataweave #["Received greeting request for name: " ++ (attributes.queryParams.name default "not provided")] ``` This message logs the `name` query parameter value or "not provided" if it’s missing. - **Level**: INFO ![Logger component configuration panel showing Message field set to payload and Level field set to INFO](/mulesoft/current/en-us/general/_images/api-tutorial-logger-component-configured-acb.png) 2. Save your changes. ## Step 4.3: Test with Logging 1. Start your application by clicking ![](/mulesoft/current/en-us/general/_images/icon-start-debug.png) (**Run**) in the debug toolbar. 2. Open the Terminal panel to see your application logs: - Mac: `Cmd+\` or select **View** > **Terminal** - Windows: `Ctrl+\` or select **View** > **Terminal** > [!NOTE] Logger output appears in the Terminal panel, not the Output panel. The Terminal > shows the live Mule runtime log as requests are processed. 3. Send a request with Postman: ```text http://localhost:8081/api/greeting?name=World ``` ![Postman UI with the request URL entered](/mulesoft/current/en-us/general/_images/api-tutorial-send-postman-request.png) 4. In the Terminal panel, you’ll see a log entry similar to: ```text INFO [hello-world-impl].get:\greeting Received greeting request for name: World ``` 5. Send a few more requests and watch the logs update. 6. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) when done. ## Step 4.4: Understanding APIKit Validation APIKit automatically validates incoming requests against your API specification. Since your API spec defines the `name` query parameter as required, APIKit: - Validates that the `name` parameter is present before routing to your implementation flow - Returns a `400 Bad Request` error automatically if the parameter is missing - Ensures your flow only executes with valid requests that match the API contract Try it: 1. Start the application. 2. In Postman, send a request without the name parameter: ```text http://localhost:8081/api/greeting ``` 3. Observe that APIKit returns an error response before your flow executes. 4. Check the Terminal — you won’t see your Logger message because APIKit blocked the invalid request. This automatic validation is one of the key benefits of using APIKit — you don’t need to write manual validation code for contract requirements defined in your API specification. ## Step 4.5: Use Breakpoints for Debugging Breakpoints pause execution so you can inspect the Mule message at a specific point in your flow. 1. In the canvas, select the context menu for the **Logger** component, and then select **Add Breakpoint**. ![The context menu for the Logger component with an arrow pointing to the Add Breakpoint option](/mulesoft/current/en-us/general/_images/api-tutorial-logger-context-menu-acb.png) A red dot appears, which represents a breakpoint. ![The Logger component with a red dot representing a breakpoint](/mulesoft/current/en-us/general/_images/api-tutorial-logger-breakpoint-acb.png) 2. Click ![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) (**Run and Debug**) in the activity bar to open the Run and Debug panel. 3. Select **Debug Mule Application** to start your application in debug mode. ![The Debug Mule Application option selected in the Run and Debug panel](/mulesoft/current/en-us/general/_images/api-tutorial-debug-option-acb.png) 4. Send a request from Postman: ```text http://localhost:8081/api/greeting?name=World ``` 5. Return to Anypoint Code Builder. Execution pauses at the breakpoint. The debug toolbar appears at the top of the editor, and the **Variables** panel appears in the Run and Debug panel. > [!NOTE] The Variables panel is in the **Run and Debug sidebar**, not at the bottom of the IDE. > If you don’t see it, make sure the Run and Debug panel is open > (![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) icon in the activity bar). 6. In the **Variables** panel, expand **Mule Message** to inspect: - **payload**: The current message content - **attributes**: HTTP request details, including headers, query parameters, and URI - **vars**: Any flow variables set during execution ![The Variables panel in the Run and Debug panel](/mulesoft/current/en-us/general/_images/api-tutorial-debug-panel-variables-acb.png) 7. Click **Continue** in the debug toolbar to resume execution and complete the request. 8. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) when done. ## What You Learned You ran the API locally and tested it with Postman, then configured a **Logger** to record each request. You learned how APIKit automatically validates requests against your API specification, and used Anypoint Code Builder’s debugger, including breakpoints and the Variables panel, to pause execution and inspect the Mule message at each step. ## Developer Deep Dive Explore advanced testing capabilities: - [Automated Testing with MUnit](https://docs.mulesoft.com/anypoint-code-builder/int-test-munit) - [Advanced Error Handling](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept) - [Troubleshooting AI Features in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/troubleshoot-generative-ai) - [DataWeave Testing Framework](https://docs.mulesoft.com/dataweave/latest/dataweave-testing-framework) ## What’s Next With your APIs fully tested locally, you’ll deploy them to CloudHub 2.0 to make them accessible to other applications and users. [Step 3. Develop the API](https://docs.mulesoft.com/general/api-led-develop) [Step 5. Deploy the API to CloudHub 2.0](https://docs.mulesoft.com/general/api-led-deploy) --- product: Getting Started keywords: cloudhub 2.0, api deployment, runtime manager, api-led connectivity, mulesoft deploy, cloudhub deployment, api verification --- # Step 5. Deploy the API to CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Deploy your tested API to CloudHub 2.0 to make it accessible from anywhere. You update the project version, configure deployment settings, and deploy directly from Anypoint Code Builder. After deployment, verify the API is running by sending a request to its public CloudHub URL. ## Step 5.1: Prepare for Deployment CloudHub 2.0 requires a release version (not a snapshot). When you scaffolded the project, Anypoint Code Builder created a `pom.xml` with `-SNAPSHOT` in the version (Maven’s convention for work-in-progress code). Remove it before deploying. 1. In Anypoint Code Builder, open `pom.xml` in your project. 2. Find the `` element and remove `-SNAPSHOT`: ```xml com.mycompany hello-world-impl 1.0.0 mule-application ``` 3. Save the file. ## Step 5.2: Deploy to CloudHub 2.0 1. Open `hello-world-api.xml` in the editor. 2. Click ![](/mulesoft/current/en-us/general/_images/icon-deploy.png) (**Deploy to CloudHub**). Alternatively, open the Command Palette and select `MuleSoft: Deploy to CloudHub`. 3. If prompted, click **Allow** to sign in to Anypoint Platform, then select a business group. 4. When prompted via the VS Code command palette, select **CloudHub 2.0** as the deployment target, then select the region to deploy the application to. 5. At the prompt, select the environment to deploy to. 6. If the project doesn’t already have a `deploy_ch2.json` file, Anypoint Code Builder indicates that a deployment configuration file has been created and opens it for you to review: ```json { "runtime": "4.x.x", (1) "applicationName": "hello-world-impl-vh", (2) "replicas": 1, (3) "replicaSize": "0.1", (4) "deploymentModel": "rolling", (5) "autoStart": true, (6) "ObjectStoreV2": true (7) } ```
1The Mule runtime version to use for the deployment.
2Defines part of the URL for accessing your application on CloudHub. This must be unique across all applications deployed to CloudHub 2.0. Update this to include your initials or another unique identifier.
3Number of application instances to run. Use 1 for this tutorial; increase for production workloads.
4The vCore allocation per replica. 0.1 vCores provides 0.5 GB of memory.
5The deployment strategy. Use rolling for zero-downtime updates, or recreate for a full restart.
6Starts the application automatically after deployment.
7Enables Anypoint Object Store v2 for storing application state.

Anypoint Code Builder packages the application and deploys it to CloudHub 2.0.

The VS Code status bar shows the progress of the deployment.

The Output panel opens with Mule Maven Output selected.

After a couple of minutes, you’ll see Deployment successful.

7. Click **Open in Runtime Manager**. Your browser opens to Runtime Manager in Anypoint Platform, showing your application. ## Step 5.3: Verify in Runtime Manager 1. Wait for the status to change from **Deploying** to **Running**. ![The application status is Running in Runtime Manager](/mulesoft/current/en-us/general/_images/api-tutorial-app-running-runtime-manager.png) > [!NOTE] The first deployment typically takes 5–10 minutes. You can monitor progress in the > Output panel (**Mule Maven Output**) in Anypoint Code Builder. As long as the status shows > **Deploying** and not an error, the deployment is working. 2. After the app is running, copy the application URL from Runtime Manager. > [!IMPORTANT] The application URL is the base hostname only. Your API endpoint is at the > `/api/greeting` path. Don’t send requests to the root URL (`/`) as it returns a 404. 3. Open Postman and send a request to the full API path: ```text https://hello-world-impl-jsmith..cloudhub.io/api/greeting?name=World ``` Replace `hello-world-impl-jsmith.` with the hostname from Runtime Manager. 4. Verify you receive your greeting: ```json { "message": "Hello, World!" } ``` Congratulations! Your API is live in the cloud! ## What You Learned You prepared your project for release and deployed it to CloudHub 2.0 using the built-in deploy command in Anypoint Code Builder. After deployment, you confirmed the application was running in Runtime Manager and verified the live endpoint with Postman. ## Troubleshoot Deployment Issues If your deployment fails with an error message similar to: Failed to deploy to CloudHub 2.0: PUBLISH 409: ASSET\_PRE\_CONDITIONS\_FAILED. Cannot create a new asset with the provided groupId, assetId, version, state. An asset already exists with this version and published lifecycle state. This means that the version specified in your `pom.xml` is already published to Exchange. Exchange doesn’t allow you to overwrite published versions. To resolve this issue: 1. Open your `pom.xml` file in the project. 2. Increment the `` element: ```xml 1.0.1 ``` > [!TIP] Each time you deploy, you must use a unique version number. 3. Save the file. 4. Retry the deployment. ## Developer Deep Dive Explore advanced CloudHub 2.0 capabilities: - [CloudHub 2.0 Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-architecture) - [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) - [Updating Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps) - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Securing Omni Gateway Instances with Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) ## What’s Next Now that your API is deployed, learn how to monitor it and view logs in Runtime Manager. [Step 4. Test the API](https://docs.mulesoft.com/general/api-led-test) [Step 6. Monitor and Manage](https://docs.mulesoft.com/general/api-led-operate) --- product: Getting Started keywords: runtime manager, api-led connectivity, application monitoring, application health, application logs, anypoint platform --- # Step 6. Monitor and Manage > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In this final step, you’ll learn how to monitor your deployed API using Runtime Manager, your operations dashboard for CloudHub applications. ## Step 6.1: Access Runtime Manager 1. From Anypoint Platform, navigate to [Runtime Manager](https://anypoint.mulesoft.com/cloudhub/#/console/home/applications). 2. Make sure you’re viewing the **Sandbox** environment. 3. Select your **hello-world-impl** application. The dashboard opens. ## Step 6.2: View Application Health The dashboard shows real-time metrics: **Status** Running (green) means your API is healthy. **Replicas** Shows **1/1** (1 running replica out of 1 expected). **Last Updated** The last time the application was updated. **Mule Messages** The number of Mule messages the application has processed. Send a few test requests from Postman and watch the **Mule Messages** graph update. **Average Response Time** The average response time of the application. **Errors** The number of errors the application has encountered. ## Step 6.3: View Application Logs Logs help you troubleshoot and understand what your application is doing. 1. In Runtime Manager, click **Logs** in the left menu. 2. You’ll see recent log entries. 3. Send a request to your API from Postman. 4. Refresh the logs to see your Logger message: ```text INFO [hello-world-impl].get:\greeting Received greeting request for name: World ``` 5. Use log filters: **Log Level** Filter by INFO, WARN, or ERROR. **Search** Find specific text. **Time Range** View logs from the last 30 days. Logs show every request, error, and Logger message from your application. ## Step 6.4: Understand Your Application URL Your application URL has this structure: ```text https://hello-world-impl-jsmith..cloudhub.io/api/greeting ``` - `hello-world-impl-jsmith`: Your unique application name - ``: Your Shared Space’s domain - `/api/greeting`: Your API endpoint path This URL is publicly accessible and automatically includes: - HTTPS/TLS encryption - Load balancing across replicas - Distributed Denial-of-Service (DDoS) protection - Automatic scaling ## Step 6.5: Test from Anywhere Your API is now accessible from any device: - Test the API from your phone’s browser. - Share the URL with teammates. - Call the API from other applications. - Use the API in front-end web apps. Try it! Open a browser on any device and visit: ```text https://your-app-url.cloudhub.io/api/greeting?name=World ``` You’ll see your greeting in the browser. ## What You Learned Congratulations! You’ve completed the full API development lifecycle: 1. Designed an API spec with Anypoint Code Builder 2. Developed the API implementation in Anypoint Code Builder 3. Tested the API locally with debugging tools 4. Deployed the API to CloudHub 2.0 5. Verified and monitored the API in Runtime Manager ## Clean Up (Optional) To remove your tutorial application and free up resources: 1. In Runtime Manager, click your application. 2. Click **Settings** > **Delete Application**. 3. Confirm deletion. Your application is stopped and removed from CloudHub 2.0. ## Learn More Ready to build more complex APIs? Explore: - [More Anypoint Code Builder Tutorials](https://docs.mulesoft.com/anypoint-code-builder/tutorials) - [Connectors for Databases, Salesforce, SAP, and more](https://docs.mulesoft.com/connectors/) - [DataWeave for Data Transformation](https://docs.mulesoft.com/mule-runtime/latest/dataweave) - [API-Led Connectivity Patterns](https://www.salesforce.com/blog/api-led-connectivity/?bc=OTH) [Step 5. Deploy the API to CloudHub 2.0](https://docs.mulesoft.com/general/api-led-deploy) --- product: Getting Started --- # Test a Model Proxy > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The try out feature lets you validate your model proxy configuration by testing mock LLM prompts without making external API requests. You can verify response messages, response headers, the routing path, and which model services each request. The feature is available only for model proxies configured with OpenAI input format. With this feature, you can verify: - What response message your model proxy returns. - What response headers are returned. - What model services the response is routed to. - Why a request is sent to a specific route. > [!NOTE] The Try Out feature only supports Model Proxies configured with OpenAI input format. For > Model Proxies configured with Gemini or Anthropic native formats, use the request examples in > [Sending Requests to Model Proxies](https://docs.mulesoft.com/general/model-proxy-request) to test your proxy. To test your model proxy: 1. From API Manager in Anypoint Platform, click **Model Proxies**. 2. Click the name of the model proxy you want to test. 3. Click **Try out**. 4. Configure any authentication or other headers your request requires. 5. Enter your test prompt. 6. Click **Run test**. 7. View the **LLM response**, **Response headers**, and **Test result** for details about your test request. --- product: Getting Started keywords: api playground, test api, api endpoints, api authentication, request snippet, api response, anypoint platform, enhanced experience --- # Testing APIs in the API Playground (Beta) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the API playground to explore an API’s endpoints, configure and send requests, and inspect responses from the service detail page. Instead of copying paths into an external tool such as Postman, you exercise the API in the enhanced experience and see the results next to its documentation. > [!NOTE] The API playground is a pilot or beta service that is subject to the Beta Services Terms > at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written Unified > Pilot Agreement if executed by Customer, and applicable terms in the > [Product Terms Directory](https://ptd.salesforce.com/?_ga=2.247987783.1372150065.1709219475-629000709.1639001992). > Use of this pilot or beta service is at the Customer’s sole discretion. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Viewer - Exchange: Exchange Contributor - Exchange: Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Open the API Playground The API playground is available only for REST APIs that have at least one instance deployed. To find a compatible API, filter the catalog by REST API or select a REST API you know. 1. In **Portfolio**, open the **APIs** catalog and select the REST API you want to test. 2. On the service detail page, select the **Playground** tab. The playground shows the endpoint list on the left. Each endpoint has its own required parameters and configuration. ## Select an Endpoint and Environment 1. In the endpoint list, select the endpoint you want to test (for example, a **POST** endpoint that creates a new record). 2. Select the version and instance to choose the environment you want to test against. ## Configure Authentication Before sending a request, authenticate to the API. The available methods depend on what the API owner enabled. 1. In the authentication section, select an authentication method. If the API owner enabled only one method (for example, API key), use that method. 2. Enter the required values, such as the API key. ## Configure the Request After authenticating, configure the details of the request: Body Configure the request body in the format the endpoint expects, such as JSON, XML, form, or multipart. Multipart supports file upload. Parameters Add and configure request parameters. Headers Add and configure request headers. ### Copy the Request Snippet The playground generates a request snippet that reflects your current configuration. As you change the authentication, body, parameters, or headers, the snippet updates to match. 1. Select the format you want for the snippet. 2. Copy the snippet to use it outside the playground. ## Send the Request and Review the Response 1. After configuring the request, select **Send**. 2. Review the response: - **Status code**, along with the response size and speed. - **Response body**. - **Response headers**, which you can copy. ## Review Request History After you test several requests or endpoints within an API, the playground keeps a history of your configurations. Open the history to review a previous request or return to an earlier configuration. ## See Also - [Testing Services with Playgrounds (Beta)](https://docs.mulesoft.com/general/exp-playground-overview) - [Exploring MCP Server Tools in the MCP Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-mcp) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) --- product: Getting Started keywords: playground, api playground, mcp server playground, test api, test mcp server, anypoint platform, enhanced experience --- # Testing Services with Playgrounds (Beta) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the playground to try services in your portfolio directly in the enhanced experience—no external tools required. Explore endpoints and tools, configure and send requests, and inspect responses without leaving the service detail page. Before the playground, understanding a service meant reading its overview and documentation, then copying paths into an external tool such as Postman or the MCP Inspector to see how it behaved. The playground brings that testing loop into the enhanced experience so you can go from reading about a service to exercising it in the same view. > [!NOTE] The playground is a pilot or beta service that is subject to the Beta Services Terms at > [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written Unified > Pilot Agreement if executed by Customer, and applicable terms in the > [Product Terms Directory](https://ptd.salesforce.com/?_ga=2.247987783.1372150065.1709219475-629000709.1639001992). > Use of this pilot or beta service is at the Customer’s sole discretion. ## Playground Types The playground adapts to the type of service you open: API playground Test an API by exploring its endpoints, configuring authentication and requests, sending calls, and inspecting responses. Serves a similar purpose to the API Console in Anypoint Platform, embedded in the enhanced experience UI. See [Testing APIs in the API Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-api). MCP server playground Test an MCP server by exploring and invoking individual tools and inspecting their responses. See [Exploring MCP Server Tools in the MCP Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-mcp). ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Viewer - Exchange: Exchange Contributor - Exchange: Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Open the Playground 1. In **Portfolio**, open the catalog for the service type (for example **APIs** or **MCP Servers**). 2. Use the search box to find the service by name or description, or scan the list or grid. 3. Select the service to open its detail page. 4. Select the **Playground** tab. The playground opens with the endpoints or tools available for the service you’re viewing. ## See Also - [Testing APIs in the API Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-api) - [Exploring MCP Server Tools in the MCP Playground (Beta)](https://docs.mulesoft.com/general/exp-playground-mcp) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) --- product: Getting Started keywords: activity log, policy operations, asynchronous operations, policy status, api manager, anypoint platform --- # Tracking Policy Operations in the Activity Log > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Every policy change on an external provider runs asynchronously, so a request that Anypoint accepts isn’t the same as a policy that’s applied on the gateway. Use the **Activity log** tab on an API instance to confirm what actually happened. > [!NOTE] Automate policy operation status checks using the MuleSoft MCP Platform Server. For > details, see > [get\_policy\_operation\_status](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#get-policy-operation-status) > in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Access to the API instance whose **Policies** and **Activity log** tabs you want to view. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Asynchronous Operations and Eventual Consistency When you trigger a policy action, Anypoint accepts the request immediately and does the real work in the background: it talks to the provider, refreshes its view of the provider’s state, and records the outcome. As a result, the policy list is eventually consistent, it sometimes doesn’t reflect the change right after an action. The UI shows an optimistic view until the background job finishes and the state is reconciled. ## Reading the Activity Log The **Activity log** tab lists recent policy operations for the API instance. By default, it shows the last 10 activities from the last 30 days. Select **Refresh** to reload. If no operations have run in that window, the tab indicates that there are no recorded policy changes. Each entry has these columns: - **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** - **Completed** - **Failed** Open an entry to see when it started and finished. ## Interpreting a Failure For a failed operation, open it to see why. The failure detail explains the error and, when applicable, whether the operation is safe to retry: - Transient failures come from a temporary problem, such as an unreachable gateway or a scan error. Try the operation again. - Other failures come from your configuration or the instance’s state. For example, an invalid configuration, a conflict with the instance’s current state, or a policy that can’t be translated for the target gateway. Fix the underlying issue before retrying. ## See Also - [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview) - [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) - [Open Policies](https://docs.mulesoft.com/general/exp-policies-open) - [Provider Support and Limitations for Policies](https://docs.mulesoft.com/general/exp-policies-provider-reference) --- product: Getting Started keywords: enhanced experience, troubleshooting, authentication errors, 403 forbidden, 401 unauthorized, permission errors, mulesoft --- # Troubleshoot the Enhanced Experience > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When authentication, connection, or data issues occur in the enhanced experience, use this information to identify the cause and find solutions. Common issues include permission errors, provider connection failures, rate limiting, missing data, and SSL certificate problems. ## Authentication and Permission Errors Authentication and permission errors prevent you from accessing features or performing actions. ### 403 Forbidden Errors If you receive a 403 Forbidden error: 1. Check your permissions: 1. Review your Access Management permissions in [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). 2. Verify that you have the required permission for the action: See [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) for more information. 3. Ask your administrator to review your role assignments if needed. 2. Check business group access: 1. Verify that you’re working in the correct business group. 2. Confirm that you have permissions in the selected business group, not just at the organization level. 3. Ask your administrator to grant access to the specific business group if needed. ### 401 Unauthorized Errors If you receive a 401 Unauthorized error: 1. Check session status: 1. Verify that you’re still signed in to the enhanced experience. If your session expired, sign in again. 2. Check the browser console for authentication errors (if you have developer tools access). 2. Clear cached credentials: 1. Sign out of the enhanced experience. 2. Clear your browser cache and cookies. 3. Sign in again. 3. Try a different browser: 1. Test with a different browser or incognito/private mode. 2. Disable browser extensions that might interfere with authentication. ### Permission Errors for Specific Actions If you can’t perform a specific action: 1. Verify prerequisites: Some actions require specific service states (such as active or registered). 1. Check that required configurations are in place (for example, a gateway must be configured before creating instances). 2. Verify that the service exists and hasn’t been deleted. 2. Check feature availability: 1. Confirm that the feature is available in your environment. Some features might be in preview or require specific product access. 2. Ask your administrator about feature availability if needed. ## Connection Failures Connection failures prevent you from connecting providers, running scanners, or accessing external systems. ### Provider Connection Issues If you can’t connect a provider: 1. Verify credentials: 1. Check that you entered valid credentials for the provider. 2. Confirm that the credentials haven’t expired. 3. Test the credentials directly with the provider’s console or API. 2. Check network connectivity: 1. Verify that your network allows outbound connections to the provider. 2. Check for firewall rules that might block connections. 3. Confirm that proxy settings are correct if your organization uses a proxy. 3. Review provider permissions: 1. Verify that the credentials have the required permissions on the provider side. 2. Check that the account has access to the resources you want to discover. 3. Review the provider’s documentation for required IAM roles or permissions. 4. Check provider status: 1. Verify that the provider’s API is available and not experiencing outages. 2. Check the provider’s status page for known issues. 3. Try connecting to the provider again after a few minutes. ### Scanner Connection Failures If a scanner fails to connect or discover services: 1. Check scanner authentication: 1. Verify that the scanner’s authentication credentials are valid. 2. Refresh credentials if they’ve expired. 3. Reauthenticate with the provider if needed. 2. Review scanner permissions: 1. Confirm that the scanner has permissions to access the target resources. 2. Check that the account has list or describe permissions for the resource types you want to discover. 3. Verify that the scanner can access all regions or zones if applicable. 3. Check scanner configuration: 1. Review the scanner’s settings in **Platform** > **Providers** > scanner name > **Settings**. 2. Verify that the scanner is targeting the correct resources or namespaces. 3. Check that filters are not excluding the resources you expect to discover. 4. Review scan history: 1. From **Platform** > **Providers**, select the scanner to view its scan history. 2. Look for error messages in recent scan attempts. 3. Check whether previous scans succeeded or when the problem started. ### Gateway Connection Issues If you can’t connect to a gateway or gateway connections fail: 1. Verify gateway endpoint: 1. Check that the gateway URL is correct and accessible. 2. Test the gateway endpoint from your network (for example, using curl or a browser). 3. Confirm that the gateway is running and accepting connections. 2. Check SSL/TLS certificates: 1. Verify that the gateway’s SSL certificate is valid and not expired. 2. Check that the certificate chain is complete. 3. If using a self-signed certificate, verify that it’s trusted by your organization’s certificate authority. 3. Review gateway credentials: 1. Confirm that you’re using valid credentials for the gateway. 2. Check that the credentials have the required permissions. 3. Verify that authentication is configured correctly on the gateway side. 4. Check network path: 1. Verify that your network allows connections to the gateway’s port (typically 443 for HTTPS). 2. Check for firewall rules that might block connections. 3. Confirm that proxy settings are correct if your organization uses a proxy. ## Rate Limiting and Throttling Rate limiting occurs if you exceed the allowed number of requests in a certain period. ### 429 Too Many Requests Errors If you receive a 429 Too Many Requests error: 1. Wait before retrying: Rate limits typically reset after a short period (usually 1–5 minutes). 1. Check the error message for retry-after information. 2. Wait at least 60 seconds before retrying the operation. 2. Reduce request frequency: 1. Avoid running multiple scanners simultaneously if they target the same provider. 2. Space out manual scan runs rather than triggering them in quick succession. 3. Reduce the frequency of scheduled scans if you’re hitting limits regularly. 3. Review operation patterns: 1. Check whether automated processes or scripts are making excessive requests. 2. Review scanner schedules to avoid overlapping runs. 3. Contact your administrator if rate limits don’t align with your usage needs. 4. Provider rate limits: Provider rate limits (AWS, Azure, GCP) are separate from enhanced experience rate limits. 1. Check the provider’s rate limit documentation for their specific limits. 2. Consider requesting a rate limit increase from the provider if needed. ## Data Not Appearing If you expect to see data, but it’s not appearing in the enhanced experience: ### Services Not Showing After Scanner Run If a scanner ran successfully, but services aren’t appearing: 1. Check scanner results: 1. From **Platform** > **Providers**, select the scanner to view its scan history. 2. Verify that the scan reported discovering new services. 3. Check for any error messages in the scan history. 2. Review catalog filters: 1. From **Portfolio**, check that you’re viewing the correct catalog (APIs, Agents, MCP Servers, Model Proxies, or Gateways). 2. Clear any filters that might be hiding the services. 3. Try using the search function to find specific services by name. 3. Verify service type mapping: 1. Confirm that the discovered services are of the expected type. 2. Check that the provider’s resources map to the catalog you’re checking. Some resources might not be imported if they don’t meet the criteria for the catalog. 4. Check business group context: 1. Verify that you’re viewing the correct business group or organization. Services might be registered in a different business group than you’re currently viewing. 2. Switch business groups if needed to find the services. ### Metrics Not Displaying If you expect to see metrics but they’re not appearing: 1. Verify monitoring is enabled: 1. Check that monitoring is configured for the service or instance. 2. From the service detail page, select **Monitoring** to verify that monitoring is active. 3. Contact your administrator if monitoring needs to be enabled. 2. Check time range: 1. Verify that you’re viewing an appropriate time range for the data. 2. Expand the time range to see if data exists outside the current window. New services might not have historical data. 3. Allow time for data collection: Metrics might take several minutes to appear after an event occurs. 1. Wait at least 5–10 minutes after creating or updating a service before expecting metrics. 2. Check again after the next monitoring collection cycle. 4. Verify service activity: 1. Confirm that the service is receiving traffic or requests. 2. Check that the service is deployed and running. 3. Review service logs to verify that requests are being processed. ### Cost or Token Usage Data Missing If cost or token usage data isn’t appearing: 1. Check governance strategy scope: 1. From **Governance** > **Strategies**, verify that a governance strategy targets the service. 2. Confirm that the strategy is active and not in draft state. 3. Check that the strategy includes cost or token tracking. 2. Allow time for data aggregation: 1. Cost and token usage data can take several hours to appear after usage occurs. 2. Check again after 24 hours for the most complete data. Historical data might not be available for newly registered services. 3. Verify service type: 1. Cost and token usage tracking applies primarily to Model proxies and agents. APIs and other service types might not generate cost data. 2. Check the service type in **Portfolio** to confirm it supports cost tracking. ## Async Operations and Delays Some operations run in the background and can take time to complete. ### Operations Appearing Stuck If an operation appears stuck or takes longer than expected: 1. Check operation type: Governance insights and conformance scoring run asynchronously and can take several minutes. 1. Large scanner runs discovering many services can take 10–30 minutes or longer. Policy application to multiple instances might process in the background. 2. Review status indicators: 1. Look for progress indicators or status messages in the UI. 2. Check the service or scanner detail page for updated status. 3. Refresh the page to see if the operation has completed. 3. Wait for background processing: 1. Allow at least 15–30 minutes for governance insights to complete after creating a strategy. Scanner runs can take varying amounts of time depending on the number of resources discovered. Cost data aggregation can take several hours. 4. Check for errors: 1. Review the browser console for error messages (if you have developer tools access). 2. Check notification areas for error alerts. 3. If no error appears, but the operation doesn’t complete after 30 minutes, contact support. ### Checking Background Job Status To check the status of background operations: 1. Scanner runs: 1. From **Platform** > **Providers**, select the scanner. 2. View the scan history on the **Overview** tab. The most recent entry shows the current or last completed scan. 2. Governance operations: 1. From **Governance** > **Strategies**, select the strategy. 2. Check the status indicator next to the strategy name. 3. Review conformance reports for completion status. 3. Service operations: 1. From **Portfolio**, select the service. 2. Check for status messages or progress indicators on the detail page. 3. Look for notifications in the notification area. ## Browser and Client Issues Browser or client problems can affect your experience using the enhanced experience. ### Page Not Loading or Displaying Correctly If pages don’t load or appear correctly: 1. Clear browser cache: 1. Clear your browser cache and cookies. 2. Hard refresh the page (Ctrl+Shift+R on Windows/Linux, Cmd+Shift+R on Mac). 3. Try accessing the enhanced experience in incognito/private mode. 2. Check browser compatibility: 1. Verify that you’re using a supported browser (Chrome, Firefox, Safari, or Edge). 2. Update your browser to the latest version. 3. Check [Browser Support for Anypoint Platform](https://docs.mulesoft.com/general/browser-support) for specific version requirements. 3. Disable browser extensions: 1. Temporarily disable browser extensions that might interfere with the enhanced experience. Ad blockers, privacy extensions, or script blockers can prevent features from working. 2. Test with extensions disabled to identify conflicts. 4. Check browser console: 1. Open browser developer tools (F12 or Cmd+Option+I). 2. Review the console for error messages. 3. Share error messages with your administrator or support team if needed. ### Session Timeout Issues If your session expires frequently or unexpectedly: 1. Adjust session settings: 1. Check your organization’s session timeout policy. 2. Ask your administrator about extending session duration if needed. Security policies can limit maximum session duration. 2. Stay active: 1. Keep a tab or window with the enhanced experience open and active. Periodic interaction prevents session timeouts. 2. Refresh the page if you’ve been idle for an extended period. 3. Re-authenticate: 1. Sign out and sign in again to start a fresh session. 2. Clear browser cache if re-authentication fails. 3. Check with your administrator if authentication fails repeatedly. ## SSL and Certificate Issues SSL and certificate problems prevent secure connections to providers or gateways. ### Certificate Validation Failures If you encounter certificate validation errors: 1. Check certificate validity: 1. Verify that the certificate hasn’t expired. 2. Confirm that the certificate is issued by a trusted certificate authority. 3. Check that the certificate’s common name or subject alternative name matches the hostname. 2. Review certificate chain: 1. Verify that the complete certificate chain is present. 2. Check that intermediate certificates are installed correctly. 3. Confirm that the root certificate is trusted by your system. 3. Self-signed certificates: 1. If using self-signed certificates, verify that they’re trusted by your organization. 2. Ask your administrator about adding the certificate to your system’s trusted store. 3. Consider using certificates from a trusted certificate authority for production systems. 4. Contact your administrator: 1. Share certificate error details with your administrator or security team. Your organization might need to update certificate trust settings. 2. Work with your administrator to resolve certificate trust issues. ## Get Additional Help If these troubleshooting steps don’t resolve your issue: 1. Contact your administrator: 1. Share specific error messages and steps to reproduce the problem. 2. Provide details about what you were trying to accomplish. 3. Include screenshots if they help illustrate the issue. 2. Check documentation: 1. Review feature-specific documentation for additional guidance. 2. Check [Release Notes](https://docs.mulesoft.com/general/exp-release-notes) for known issues. 3. Review [Troubleshoot the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-troubleshoot) for AI assistant-specific issues. 3. Gather diagnostic information: 1. Note exact error message and error code if provided. 2. Record the steps to reproduce the issue. 3. Check browser console for technical error details (F12 or Cmd+Option+I). 4. Note the time the error occurred and any patterns (happens consistently or intermittently). ## See Also - [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) - [Troubleshoot the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-troubleshoot) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) - [Browser Support for Anypoint Platform](https://docs.mulesoft.com/general/browser-support) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started keywords: ai assistant troubleshooting, ai assistant errors, incorrect answers, search results, mulesoft ai assistant, anypoint platform --- # Troubleshoot the MuleSoft Agent > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you experience issues using the MuleSoft Agent AI assistant, use this guide to identify and resolve common problems. ## MuleSoft Agent Doesn’t Respond If the AI assistant doesn’t respond to your messages: Check your connection: 1. Verify that you have an active internet connection. 2. Refresh the browser page. 3. Try sending a simple message like "Hello" to test if the assistant responds. Check session status: 1. Verify that you’re still signed in to the enhanced experience. 2. If your session expired, sign in again. 3. Check for any error messages in the browser console (if you have developer tools access). Try a different browser or clear cache: 1. Clear your browser cache and cookies. 2. Try using a different browser or incognito/private mode. 3. Disable browser extensions that might interfere with the assistant. If the problem persists, contact your administrator or support team. ## MuleSoft Agent Gives Incorrect or Incomplete Answers If the assistant provides answers that don’t match your expectations: Provide more context: 1. Include specific names, IDs, or identifiers in your questions. 2. Mention the environment, business group, or scope if relevant. 3. Add details about what you’re trying to accomplish. Example:
Instead ofTry

"Show me APIs"

"Show me production APIs in the Customer Services business group"

"Why isn’t this working?"

"Why is the rate limit policy on my Payment API instance not being enforced?"

"Check errors"

"Show me error details for the User Authentication Agent over the last 24 hours"

Rephrase your question: 1. Try asking the same question using different words. 2. Break complex questions into smaller, focused questions. 3. Use follow-up questions to narrow down the information you need. Verify the assistant has access to the data: 1. Check that the service is registered in your portfolio. 2. Verify that monitoring or governance data has been collected for the service. 3. Confirm that you have permissions to view the data you’re asking about. ## MuleSoft Agent Suggests Actions I Can’t Perform If the assistant suggests actions but you can’t perform them: Check your permissions: 1. Verify your Access Management permissions in [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). 2. Ask your administrator to review your role assignments. 3. The assistant may suggest actions available in the product, but your specific permissions determine what you can do. Check your subscription tier: 1. Verify whether you have API Portfolio Access or Agent + API Portfolio Access. 2. Some features (like agents, MCP servers, Model proxies) require Agent + API Portfolio Access. 3. Contact your administrator or account team about upgrading your subscription if needed. Check service state: 1. The service may need to be in a specific state (active, registered, etc.) before certain actions are available. 2. Verify that required prerequisites are met (for example, a gateway must be configured before creating instances). ## Search Results Aren’t Relevant If search results don’t match what you’re looking for: Use more specific terms: 1. Include the service type: "Find agents that handle payments" instead of "Find payment services." 2. Specify attributes: "Show me REST APIs with OAuth policies" instead of "Show me APIs." Check the scope: 1. Verify you’re searching in the right business group or environment. 2. Ask the assistant to filter: "Show me only production services." Verify service metadata: 1. Search results depend on how services are described in their metadata. 2. If a service doesn’t appear, check whether its description includes the terms you’re searching for. 3. Update service descriptions to improve future search results. ## MuleSoft Agent Is Slow to Respond If the assistant takes a long time to respond: Check current load: 1. During peak usage times, responses may be slower. 2. If using monitoring or cost queries, large datasets may take longer to process. Simplify your question: 1. Break complex questions into smaller parts. 2. Ask for summaries first, then drill into details. Check your connection: 1. Slow network connections can delay streaming responses. 2. Try refreshing the page or reconnecting to your network. ## MuleSoft Agent Conversation History Is Lost If your conversation history disappears: Session expiration: 1. Conversation history is tied to your session. If your session expires, history may be cleared. 2. Sign in again and start a new conversation. Browser storage: 1. Clearing browser cache or cookies may remove conversation history. 2. Conversation history is stored locally in your browser for the current session. Intentional behavior: 1. For privacy and security, conversation history may not persist across sessions. 2. Sensitive information isn’t stored long-term. ## Actions Performed by MuleSoft Agent Fail If the assistant confirms an action but the action fails: Review error messages: 1. The assistant should display any error messages from the system. 2. Look for specific error details (validation errors, permission issues, etc.). Check prerequisites: 1. Verify that all required fields and configurations are complete. 2. For instance creation, ensure the target gateway is available. 3. For policy application, ensure the service instance is active. Verify data: 1. Double-check that URLs, names, and identifiers are correct. 2. Ensure referenced services, gateways, or environments exist. Try manually: 1. Perform the action manually through the UI to see if the same error occurs. 2. This helps determine whether the issue is with the AI assistant or the underlying system. ## MuleSoft Agent Can’t Access Recent Changes If the assistant doesn’t recognize recently registered services or configuration changes: Wait for indexing: 1. Newly registered services may take a few minutes to appear in search results. 2. Refresh the page and try again after a few minutes. Verify registration completed: 1. Check that the service registration or configuration change was saved successfully. 2. Look for confirmation messages or check the relevant catalog. Be specific: 1. Use exact service names or IDs rather than relying on search. 2. For example: "Show me details for service ID 12345." ## Get Additional Help If these troubleshooting steps don’t resolve your issue: 1. Check with your administrator. Your administrator can verify your permissions, subscription tier, and feature availability. 2. Review documentation. See [Using the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-use) for complete AI assistant usage guidance. 3. Review system status. Ask your administrator to check whether there are any known issues or maintenance windows. 4. Collect diagnostic information. Before contacting support, collect: \* The exact question or request you sent to the assistant \* The assistant’s response \* Any error messages displayed \* The page you were on when the issue occurred \* Your browser type and version 5. Contact support. Reach out to your internal IT support or MuleSoft support with the diagnostic information. ## See Also - [Using the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-use) - [Troubleshoot the Enhanced Experience](https://docs.mulesoft.com/general/exp-troubleshoot) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started keywords: usage reports, troubleshooting, anypoint platform, runtime fabric, access issues, date picker, missing data --- # Troubleshooting Usage Reports > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Because platform data availability depends on activity in your organization, in some cases, usage reports are unavailable. ## Unable to Access Usage Reports in Anypoint Platform Verify that you have the Usage Viewer permission assigned at the root organization level. If you don’t have the Usage Viewer permission assigned to you, contact the Anypoint Platform organization administrator. ## A Supported Product Isn’t listed If a supported product isn’t listed when you open the product list, click **Switch View**. For more information about product availability by view, see [available products](https://docs.mulesoft.com/general/usage-reports#products-usage-reports). ## Usage Reports Don’t Display Data for Runtime Fabric Apps If you don’t see any data for Runtime Fabric apps, ensure that: - You’re using Runtime Fabric agent version 1.13.112, 2.1.30, or later. - After updating the Runtime Fabric agent, you manually redeployed each Runtime Fabric app with a supported date-patch version. If you’re still missing Runtime Fabric apps in your usage reports, contact your account executive to request a report of apps that are not upgraded and what actions you need to take to update them. ## A Month or a Day is Unavailable in the Date Picker If the date picker doesn’t show a month or day, data is unavailable for the selected period. ## Report Says No Data If you select a product and daily or monthly report in new usage reports, and the report returns a `No Data` message, no data is available for the selected period. This means that there is no data available for the selected day or month. ## No Report Available for This Time Period Message If, after selecting a month in legacy usage reports, the report returns `No report available for this time period`, no data is available for the selected month. This means there is no data available for the selected month. ## Deployed Mule App Isn’t Listed in the Mule Runtime Usage Report If a deployed Mule app isn’t listed in the Mule Runtime usage report, make sure you’re using a supported version of Mule runtime. For more information, see [supported runtime versions](https://docs.mulesoft.com/general/usage-reports#supported-mule-runtime-versions). Redeploy your Mule apps with a supported Mule runtime version, either manually or during a monthly patching cycle. ## See Also - [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) - [Usage Viewer permission](https://docs.mulesoft.com/access-management/permissions-by-product#usage) - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started description: Overview of a multipart tutorial for MuleSoft's API development workflow, covering how to build your first API from design to deployment using Anypoint Code Builder. keywords: api-led tutorial, anypoint code builder, api development, api design, mulesoft tutorial, api deployment, build api --- # Tutorial: Build an API from Start to Finish > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Build your first API from design to deployment using Anypoint Code Builder. Design an API spec, implement the logic, test locally, and deploy to CloudHub 2.0 to learn the complete MuleSoft API development workflow. ## What You’ll Build A simple "Hello World" API that: - Returns a greeting message when you call it - Demonstrates the complete API development lifecycle - Runs in the cloud and is accessible from anywhere ## What You’ll Use - Anypoint Code Builder Your development environment for designing and building APIs. - MuleSoft Vibes (Optional) An AI assistant built into Anypoint Code Builder that generates API specs from simple descriptions. Instead of writing code, you describe what you want. If you don’t have access to MuleSoft Vibes, you can create API specs manually in Anypoint Code Builder. - CloudHub 2.0 MuleSoft’s cloud platform where your APIs run. Deploy once and your API is accessible worldwide with automatic scaling and reliability. - Runtime Manager Your operations dashboard for monitoring deployed APIs, viewing logs, and managing applications running on CloudHub 2.0. ## Tutorial Steps Complete the steps in order to create your first API: 1. [Complete the prerequisites](https://docs.mulesoft.com/general/api-led-prerequisites). 2. [Design an API spec with AI](https://docs.mulesoft.com/general/api-led-design). 3. [Scaffold and implement the API](https://docs.mulesoft.com/general/api-led-develop). 4. [Test your API locally](https://docs.mulesoft.com/general/api-led-test). 5. [Deploy your API to CloudHub 2.0](https://docs.mulesoft.com/general/api-led-deploy). 6. [Verify and monitor your API](https://docs.mulesoft.com/general/api-led-operate). After completing this tutorial, you’ll understand the MuleSoft development workflow and be ready to build more complex APIs. ## What’s Next Ready to get started? Begin by setting up your development environment. ## See Also - [What is API-led Connectivity](https://www.salesforce.com/blog/api-led-connectivity/?bc=OTH) - [Anypoint Code Builder Overview](https://docs.mulesoft.com/anypoint-code-builder/) - [MuleSoft Vibes Overview](https://docs.mulesoft.com/anypoint-code-builder/mulesoft-vibes) - [CloudHub 2.0 Overview](https://docs.mulesoft.com/cloudhub-2/) [Step 1. Prerequisites](https://docs.mulesoft.com/general/api-led-prerequisites) --- product: Getting Started keywords: mule credits, subscription plan, usage types, rate cards, billing, usage tracking, mulesoft pricing --- # Understand Mule Credits Usage and Rates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A Mule Credit is a fungible currency that allows you to draw down from a single capacity pool as you consume services across MuleSoft. Instead of managing different usage types for all products, you purchase a package of credits to use flexibly across the entire MuleSoft platform. As you use these capabilities, Anypoint Platform deducts the corresponding credit amounts from your available balance. Mule Credits apply to your entire Anypoint Platform organization and you can’t manage them per business group. Use Mule Credits before the `Order End Date` set in the **Usage Details** table on your **Order Form** because rollovers are not permitted. To see which usage types your subscription includes, refer to your **Order Form**, **Subscription Plan**, or **Features and Entitlement Document**. ## Subscription Plan The usage types available to you depend on your subscription plan.
Subscription PlanAvailable Usage Types

MuleSoft Integration

MuleSoft Flows, MuleSoft Messages, Private Spaces, Network Connections, Load Balancers

MuleSoft Automation

IDP Pages, Flow Integration Tasks

MuleSoft AI & API Management

Managed Assets, Gateway Requests, Private Spaces, Network Connections

Agent Fabric

MuleSoft Flows, MuleSoft Messages, Managed Assets, Gateway Requests, Private Spaces, Network Connections

MuleSoft All-Access

All usage types: MuleSoft Flows, MuleSoft Messages, Managed Assets, Gateway Requests, IDP Pages, Flow Integration Tasks, Private Spaces, Network Connections, Load Balancers

MuleSoft All-Access License

All usage types: MuleSoft Flows, MuleSoft Messages, Managed Assets, Gateway Requests, IDP Pages, Flow Integration Tasks, Private Spaces, Network Connections, Load Balancers

> [!NOTE] MuleSoft All-Access License supports pre-commit and unlimited usage models. ## Usage Types Each usage type (also called a meter) tracks a specific dimension of platform consumption. Credit rates vary by monthly consumption volume and reset on the first day of each calendar month. You consume credits at the same rate across all environments, including production, pre-production, sandbox, and design. For the full tiered rate table, see [Rate Cards](#rate-cards).
Usage TypeDescription

MuleSoft Flows

A flow is a sequence of logical operations configured within the XML <flow/> element of a Mule application. The runtime report tracks flows in deployed and running Mule applications that contain a Mule event source or APIkit route requests.

Mule apps in production environments typically use multiple flows and subflows to divide the app into functional modules or for error-handling purposes. For example, one flow can receive a record and transform data into a given format that another flow processes.

To calculate usage, MuleSoft tracks the number of flows across all business groups, environments, and applications on an hourly basis. For every 24-hour period starting at 00:00 UTC, MuleSoft identifies the hour with the highest flow count as the daily max flow. Based on your contract term, MuleSoft then aggregates these daily maximums over the month or year to determine final usage.

MuleSoft Messages

The total volume of data containers processed by the runtime. To track message usage, the runtime report counts the number of times a Mule event source triggers a message. To calculate usage, MuleSoft aggregates the number of messages daily (UTC time) and monthly. After a Mule event source triggers a message, the report doesn’t track changes to the message because the application’s flows process it internally.

Managed Assets

An asset (API, Agent, MCP Server, or LLM) counts as managed if it has at least one active instance in API Manager deployed to a Mule Gateway or Omni Gateway. Anypoint Platform counts usage per business group per day; if an asset has active instances across multiple business groups, it counts as one asset per group.

Multiple instances within the same business group don’t incur extra charges. Anypoint Platform deducts credits as long as the asset status is Active in API Manager, even if there are no calls to the asset.

Gateway Requests

Any request that Omni Gateway receives. MuleSoft measures usage as the sum of all processed requests, regardless of response status.

IDP Pages

The number of individual document pages that Intelligent Document Processing (IDP) processes in MuleSoft IDP or MuleSoft for Flow: IDP. MuleSoft counts each page within a document as a separate unit, and charges only for successful LLM responses.

Flow Integration Tasks

Individual units of work or actions (reading, creating, or updating a record) executed within MuleSoft for Flow: Integration.

Private Spaces

A Private Space is a dedicated, isolated environment in CloudHub 2.0 for running your apps. You consume credits based on the total number of provisioned Private Spaces per day. After you deprovision a Private Space, it stops consuming credits from the next calendar date onwards.

Network Connections

Network connections allow you to securely connect corporate data centers and on-premises applications to CloudHub 1.0 and CloudHub 2.0 using a VPN or AWS Transit Gateway. You consume credits based on the total number of active network connections per day. After you deprovision a network connection, it stops consuming credits from the next calendar date onwards.

Load Balancers

Dedicated Load Balancers used to distribute incoming traffic across multiple workers or instances. You consume credits based on the total number of provisioned load balancers per day. After you deprovision a load balancer, it stops consuming credits from the next calendar date onwards.

## Rate Cards You consume Mule Credits at the applicable multiplier rate based on the usage type identified in the [Mule Credit Rate Card](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/mulesoft/Mule_Credit_Rate_Card.pdf). If your usage exceeds your contracted amount, MuleSoft sends a monthly overage invoice to your primary billing contact at your standard contracted rate. Contact your account team with any questions about your contract or billing. ## Viewing Usage and Billing Mule Credits usage is available in both Anypoint Usage Reports and Salesforce Digital Wallet. Salesforce Digital Wallet remains the billing source of truth for finalized Mule Credits totals, statements, and overage outcomes. Use both views together for a complete view of Mule Credits consumption. Digital Wallet shows finalized totals and trends, while Anypoint Usage Reports show consumption details by usage type, business group, and application. Values can differ between these views. ### When to Use Each View - Use **Anypoint Usage Reports** to analyze what is driving consumption across usage types, business groups, and applications. - Use **Salesforce Digital Wallet** to review finalized daily and monthly consumption and billing outcomes. ### Digital Wallet Features at a Glance
FeatureFor More Information

Monitor and analyze near-real-time usage for your consumption-based products.

Monitor Usage for Consumption-Based Products in Digital Wallet

View the Consumption Analytics dashboard, which includes Tableau Next visualizations that leverage standard consumption tags. Visualizations are interactive, allowing you to instantly transform your view, drill down into details, and optimize business planning with consumption forecasting.

Consumption Analytics Dashboard (Tableau Next)

Set customized threshold alerts to receive usage notifications when your org’s usage exceeds specified thresholds. Also includes automated Monthly Account Summary emails that summarize usage from the previous month.

Get Notifications about Your Usage

For more information about Digital Wallet access, see [Access Digital Wallet](https://help.salesforce.com/s/articleView?id=xcloud.wallet_access.htm&type=5). ## See Also - [Digital Wallet–Enabled Consumption-Based Products](https://help.salesforce.com/s/articleView?id=xcloud.wallet_enabled_products_rate_cards.htm&type=5) (Salesforce Help) - [Mule Credit Rate Card](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/mulesoft/Mule_Credit_Rate_Card.pdf) - [MuleSoft Rates Landing Page](https://www.salesforce.com/mulesoft/rates) - [Automation Credits Usage and Rates](https://docs.mulesoft.com/general/automation-credits-usage-and-rates) - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) --- product: Getting Started keywords: java upgrade, custom connectors, mulesoft connectors, connector migration, java compatibility, mule 4, customer upgrade --- # Upgrading Java for Custom Connectors (Customers) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Extended support for Java 8 and 11 ends in February 2027 for 4.6 LTS. Upgrade your apps that run on Java 8 or 11. > [!NOTE] This guide applies to MuleSoft customers only. If you are a MuleSoft partner, see > [Upgrading Java for Custom Connectors (Partners)](https://docs.mulesoft.com/general/partner-connector-upgrade). Upgrade, test, and release your custom connectors for Java 17 to ensure compatibility within the MuleSoft ecosystem. Ensuring this compatibility is crucial because running an incompatible connector can lead to runtime failures, decreased performance, and security vulnerabilities that could impact your app’s stability. ## Before You Begin Before upgrading and testing your custom connector for Java 17, you must be familiar with the following considerations: - Target compilation level In Mule 4.9.0 and later, you can compile any Mule project for Java 17 or lower. Additional dependencies must be compiled for Java 17 or lower. - Declaring the minimum Mule version Two parent POMs are available for building extensions. Each one handles the minimum Mule version declaration differently. - `mule-java-extension-parent` (recommended) This is the recommended parent POM for all new extensions and for existing extensions that can migrate. It supports forward compatibility and requires you to explicitly declare the minimum Mule version in your project, giving you full control over which Mule runtime versions your connector supports. The `mule-extensions-archetype-maven-plugin` uses this parent when generating new extension projects. For migration instructions, see [Upgrading Existing Modules](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility-setup#upgrading-existing-modules). > [!NOTE] Switching parent POMs for existing connectors may not be straightforward depending on > the connector’s complexity. If you must upgrade with minimal changes, you can continue to use > `mule-modules-parent` as described below. - `mule-modules-parent` (deprecated) This parent POM is deprecated and remains available for existing connectors where switching to `mule-java-extension-parent` is not practical. If you compile for Java 17, upgrade `mule-modules-parent` to version 1.9.0 or later. The connector’s minimum Mule version is automatically set based on the parent version. For example, version 1.9.0 sets `minMuleVersion` to 4.9.0, ensuring compatibility only with Mule 4.9.0 or later. If the `mule-modules-parent` version is earlier than 1.9.0, the bytecode level for the connector and its additional dependencies must be for Java 8. You can’t use language features from Java 11 or Java 17. Verify that `minMuleVersion` in `META-INF/mule-artifact/mule-artifact.json` reflects the correct version. See [Specify Java Compatibility](https://docs.mulesoft.com/mule-sdk/latest/java-version-support#specify-java-compatibility). - Unsupported directives Don’t set `--add-opens`, `--add-exports`, or `--add-modules` directives. These directives are not allowed in CloudHub, Runtime Fabric, or on-premises. These directives also require managing them for each connector across all environments, and introduce a backward compatibility burden, complicating future Java upgrades and potentially enabling security vulnerabilities. If these directives are used, they are not covered under Support. - Minimum Mule version If your custom connector is running on Mule 4.5.x or earlier, you can’t run Java 17 tests that extend the `MuleArtifactFunctionalTestCase`, but you can still run Java 8 tests. To decouple the minimum Mule version when running tests, add the `-Dmunit.jvm` parameter to use Java 17 as described in [Test Your Custom Connector with MUnit](#test-your-custom-connector-with-munit). ## Upgrade Your Custom Mule SDK Connectors Upgrade your custom Mule SDK (Java SDK and XML SDK) connectors to Java 17. ### Upgrade Third-Party Libraries Your custom connector likely relies on third-party libraries, so it’s important to ensure they are compatible with Java 17 as well. Even if your custom connector passes tests, it is still important to deliver secure and reliable software. If a critical bug or vulnerability is found, you must upgrade to a fixed version. Using up-to-date libraries that explicitly support Java 17 makes this process easier and more reliable, as the vendor has already tested them on Java 17. Upgrade the third-party libraries of your custom connector to be compatible with Java 17: - Java EE libraries Mule 4.6.x exposes Java EE libraries differently than earlier Mule versions. You must add the BOM dependency to your custom connector and, if applicable, exclude the provided conflicting library. You can also add the libraries in the BOM dependency separately. ```java 4.6.0 org.mule mule-javaee-runtime-bom ${muleJavaEeBomVersion} pom import ``` For more information, see [Java EE Libraries](https://docs.mulesoft.com/mule-sdk/latest/java-ee-libraries). - External libraries Upgrade external libraries, which are third-party libraries that are not bundled with your custom connector. Some examples include a JDBC driver, JMS broker client, or Groovy runtime. The following example shows a JDBC driver external library configuration: ```java @ExternalLib(name = "MySQL JDBC Driver", description = "A JDBC driver that supports connection to the MySQL Database", nameRegexpMatcher = "(.*)\\.jar", requiredClassName = "com.mysql.jdbc.Driver", coordinates = "mysql:mysql-connector-java:5.1.44") public class MySqlConnectionProvider implements ConnectionProvider { // } ``` You must update your external libraries to a version that is compatible with Java 17. ### Review Your Code After you compile your custom connector, ensure you can run your custom connector with Java 17. Reviewing your code is important because some restrictions are flagged as warnings in Java 11 but are flagged as failures and can’t be disabled in Java 17. For example, reflection is more restricted in Java 17, so you must review your code to ensure there are no illegal actions. To help you review your code, learn more about the different changes in Java 17: - JDK Migration Guide See the [Oracle JDK Migration Guide](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A) for a full list of the changes made from Java 8 to Java 17. Use the guide to assess the impact to your code. - Mule runtime engine See [Mule runtime](https://docs.mulesoft.com/general/java-support#mule-runtime) to learn more about the Java 17 changes made in Mule runtime engine. - Reflection on Java classes To ensure compatibility with Java 17, review and update any code that uses reflection to access Java classes or set parameter values. Java 17 imposes stricter access controls, so avoid introspecting JDK internals. Have a robust test suite that runs with Java 17. Pay special attention to the `setAccessible(true)` method because these access changes are not allowed in Java 17. - Serialization Update your serialization code to accommodate the restrictions of Java 17. If your code uses libraries like Gson for serializing classes, switch to using Data Transfer Objects (DTOs) where reflective access to JDK classes is involved. Ensure that serialization libraries are updated and adjust your code to minimize reliance on reflection. For more information, refer to [Configure Custom Serializers](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers). - Library upgrades Upgrade your libraries to versions compatible with Java 17. This includes updating ByteBuddy to version 1.14.0, Jacoco to 0.8.10, and SLF4J to version 2.x. Replace CGLib with ByteBuddy and check for updates to other libraries like Groovy and JRuby. Verify that all dependencies are compatible with Java 17 to avoid runtime issues. - Changes with running the test suite Adapt your testing approach for Java 17. If you use Mockito, be aware that Mockito can’t mock JVM classes. Consider custom implementations for mocking and switch from PowerMock to newer Mockito versions. Update your tests to handle the changes in Java 17 and avoid deprecated methods. - Java Platform Module System (JPMS) JPMS was introduced in Java 9. This feature introduces stricter encapsulation, impacting how Mule modules interact with JDK classes. As Mule upgrades to Java 17 and JPMS, these changes are necessary: - Refactor Split Packages: Resolve issues with internal and API package splits by reorganizing and refactoring packages to conform with JPMS modularization standards. - Address `ResourceBundle` Loading: Implement solutions for issues related to resource bundle loading, such as using `ResourceBundleProvider` or alternative methods. - Analyze the third-party libraries' changelogs to understand Java 17 compatibility and changes related to JPMS. ### Add Missing Code Because reflection is more restricted in Java 17, API objects now require setters. Previously with Java 8, it was enough for API objects to only have default constructors and getters for all DataWeave accessible properties. Now, API objects must also have setters so DataWeave can write those properties without using reflection. Constructors and setters are required if your class is instantiated by DataWeave, and getters are required if your class is read. If your class is returned and not instantiated, only getters are required. However, using both getters and setters simplifies the validation and certification process. ## Upgrade Your Custom REST Connect Connectors Upgrade your custom REST Connect connectors to Java 17. REST Connect now supports Java 17. REST Connect connectors are generated from an API specification using REST Connect. To make the connector Java 17-compatible, republish the API specification to Exchange. See [REST Connect Connector Generator](https://docs.mulesoft.com/exchange/to-deploy-using-rest-connect). > [!IMPORTANT] REST Connect now adds support for TLS. To save time, enable TLS at the same time you > update your generated connector for Java 17 so that you need to generate the connector and test > your apps only once. ## Upgrade Your Custom Configuration Properties Providers To upgrade your custom configuration properties provider to be compatible with Java 17, switch to use [Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started) and use the `@JavaVersionSupport` annotation as explained in [Release Your Custom Connector](#release-your-custom-connector). You must also perform all the steps described in [Upgrading Java for Custom Connectors (Customers)](https://docs.mulesoft.com/general/customer-connector-upgrade), just like with any custom connector. The example custom configuration properties provider mentioned in [Example: Mule SDK Module](https://docs.mulesoft.com/mule-runtime/latest/custom-configuration-properties-provider#example-mule-sdk-module) is updated to support Java 17. Refer to that example to update your custom configuration properties provider. For more details about what the changed code looks like (including migrating tests to MUnit), refer to this [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/410ee26d8b3c44adacb077e099f32886f99eb6be). Alternatively, if switching to using [Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started) involves too many changes for you, add a declaration using `ExtensionDeclarer` inside `ExtensionLoadingDelegate` in your custom configuration properties provider. For more details about what the changed code looks like, refer to this [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/19d9d45cd52b0695f7b9c2b9019bae88f45fb228). ## Test Your Custom Connector with MUnit Run your MUnit tests to test compatibility of your connector against Java 17. Ensure your local JDK version is 17. 1. Open the pom.xml file of your Mule app. 2. Replace the `mule-maven-plugin` version with the `${mule.maven.plugin.version}` parameter. 3. If you haven’t already, add the `munit-maven-plugin`. Replace the version with the `${munit.version}` parameter and replace `runtimeVersion` with the `${app.runtime}` parameter. ```xml com.mulesoft.munit.tools munit-maven-plugin ${munit.version} test test test coverage-report true html ${app.runtime} http.port ``` > [!NOTE] MUnit 3.1 is compatible only with Mule runtime 4.3.0 and later. If your connector is > compatible with Mule runtime 4.2.0 and earlier, you must create a legacy profile that > overrides the MUnit version. 4. If you have MUnit dependencies, such as `munit-runner` and `munit-tools`, replace the version for each dependency with the `${munit-version}` parameter. 5. Replace the version for each connector dependency with the Java 17 compatible version of the connector. 6. Open a terminal window in the root of your Mule project and run the following command. This command displays the earliest versions of Mule runtime, MUnit, and the Mule Maven plugin that are compatible with Java 17. ```bash mvn -f pom.xml -s ~/.m2/settings.xml -Dapp.runtime=4.6.0 -Dmunit.version=3.1.0 -Dmule.maven.plugin.version=4.1.0 -fae test ``` You can now see if your connector is compatible with Java 17. For more information about running MUnit tests, refer to [MUnit](https://docs.mulesoft.com/munit/latest/). If you use `mule-java-extension-parent` (recommended), the minimum Mule version is independent of the parent version and you control it directly in your project. For more information, see [Upgrading Existing Modules](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility-setup#upgrading-existing-modules). If you use the legacy `mule-modules-parent`, the Mule runtime version determines the parent version. For example, Mule runtime 4.6.0 corresponds to `mule-modules-parent` 1.6.0. Minor versions maintain a correspondence, such as Mule runtime 4.1.0 with `mule-modules-parent` 1.1.0, Mule runtime 4.2.0 with `mule-modules-parent` 1.2.0, and so forth. Mule runtime 4.6.0 and later supports Java 17. However, a connector can be compatible with both Mule 4.3.0 and Java 17 simultaneously. If your connector must be compatible with Mule 4.3.0, its `mule-modules-parent` version cannot exceed 1.3.0. You don’t need to use `mule-modules-parent` 1.6.0 for your connector to be compatible with Java 17. Using `mule-modules-parent` 1.6.0 is specifically required to leverage other features from the Mule runtime 4.6.0 in the connector. ## Release Your Custom Connector After you update your code and your tests are green, you are ready to release a new Java 17-compatible version of your custom connector. 1. To communicate Java 17 compatibility, generate metadata for Java compatibility of your custom connector by adding or upgrading the custom connector `mule-sdk-api` dependency to the latest version: ```xml org.mule.sdk mule-sdk-api 0.10.1 ``` 2. For Java SDK, add the `@JavaVersionSupport` annotation in the same class as the `@Extension` annotation and include the `JAVA_17` value, for example: > [!NOTE] You don’t need to add any annotations for XML SDK because XML SDK modules are Java 17 > compatible and inherit the property automatically. ```java @Extension(name = "Database") @Operations(...) @JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17}) public class DatabaseConnector { .. } ``` In Mule 4.5.0 and later, custom connectors that don’t specify the `@JavaVersionSupport` annotation are assumed to be compatible with Java 8 and Java 11. You can mark your custom connector as compatible with Java 17 only; however, you must ensure that no adoption or backward compatibility issues exist. When you deploy a Mule app, Mule verifies that all modules in the Mule app are compatible with the Java version. If Mule finds an incompatibility, Mule throws an error and the application does not deploy. > [!NOTE] If you receive an error message specific to an XML SDK based connector, such as > `Extension 'module-error-handler-plugin' does not support Java 17. Supported versions are: [1.8, 11]`, > this means that your Mule app still contains some connectors that are not compatible with Java 17. > To resolve this error, upgrade all connectors in your Mule app to be compatible with Java 17. If your code is compatible with Java 17 but you don’t declare Java 17 compatibility, you can still get a successful test run. To run a quick check on your custom connector or if all dependencies are not ready, pass the following argument to skip hard checks on the Java support declaration: ```bash -M-Dmule.jvm.version.extension.enforcement=LOOSE ``` For more information, see [Java Version Support](https://docs.mulesoft.com/mule-sdk/latest/java-version-support). ## See Also - [Java Support](https://docs.mulesoft.com/general/java-support) --- product: Getting Started keywords: java upgrade, custom connectors, rest sdk connectors, partner connectors, connector upgrade, mulesoft partners, sdk upgrade --- # Upgrading Java for Custom Connectors (Partners) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Extended support for Java 8 and 11 ends in February 2027 for 4.6 LTS. Upgrade your apps that run on Java 8 or 11. > [!NOTE] This guide applies to MuleSoft partners only. If you are a MuleSoft customer, see > [Upgrading Java for Custom Connectors (Customers)](https://docs.mulesoft.com/general/customer-connector-upgrade). Upgrade, test, and release your custom connectors for Java 17 to ensure compatibility within the MuleSoft ecosystem. Ensuring this compatibility is crucial because running an incompatible connector can lead to runtime failures, decreased performance, and security vulnerabilities that could impact your app’s stability. ## Before You Begin Before upgrading and testing your custom connector for Java 17, you must be familiar with the following considerations: - Target compilation level In Mule 4.9.0 and later, you can compile any Mule project for Java 17 or lower. Additional dependencies must be compiled for Java 17 or lower. - Declaring the minimum Mule version Two parent POMs are available for building extensions. Each one handles the minimum Mule version declaration differently. - `mule-java-extension-parent` (recommended) This is the recommended parent POM for all new extensions and for existing extensions that can migrate. It supports forward compatibility and requires you to explicitly declare the minimum Mule version in your project, giving you full control over which Mule runtime versions your connector supports. The `mule-extensions-archetype-maven-plugin` uses this parent when generating new extension projects. For migration instructions, see [Upgrading Existing Modules](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility-setup#upgrading-existing-modules). > [!NOTE] Switching parent POMs for existing connectors may not be straightforward depending on > the connector’s complexity. If you must upgrade with minimal changes, you can continue to use > `mule-modules-parent` as described below. - `mule-modules-parent` (deprecated) This parent POM is deprecated and remains available for existing connectors where switching to `mule-java-extension-parent` is not practical. If you compile for Java 17, upgrade `mule-modules-parent` to version 1.9.0 or later. The connector’s minimum Mule version is automatically set based on the parent version. For example, version 1.9.0 sets `minMuleVersion` to 4.9.0, ensuring compatibility only with Mule 4.9.0 or later. If the `mule-modules-parent` version is earlier than 1.9.0, the bytecode level for the connector and its additional dependencies must be for Java 8. You can’t use language features from Java 11 or Java 17. Verify that `minMuleVersion` in `META-INF/mule-artifact/mule-artifact.json` reflects the correct version. See [Specify Java Compatibility](https://docs.mulesoft.com/mule-sdk/latest/java-version-support#specify-java-compatibility). - Unsupported directives Don’t set `--add-opens`, `--add-exports`, or `--add-modules` directives. These directives are not allowed in CloudHub, Runtime Fabric, or on-premises. These directives also require managing them for each connector across all environments, and introduce a backward compatibility burden, complicating future Java upgrades and potentially enabling security vulnerabilities. If these directives are used, they are not covered under Support. - Minimum Mule version If your custom connector is running on Mule 4.5.x or earlier, you can’t run Java 17 tests that extend the `MuleArtifactFunctionalTestCase`, but you can still run Java 8 tests. To decouple the minimum Mule version when running tests, add the `-Dmunit.jvm` parameter to use Java 17 as described in [Test for Java 17 Compatibility Directly](#test-for-java-17-compatibility-directly). ## Upgrade Your Custom Mule SDK Connectors Upgrade your custom Mule SDK (Java SDK and XML SDK) connectors to Java 17. ### Upgrade Third-Party Libraries Your custom connector likely relies on third-party libraries, so it’s important to ensure they are compatible with Java 17 as well. Even if your custom connector passes tests, it is still important to deliver secure and reliable software. If a critical bug or vulnerability is found, you must upgrade to a fixed version. Using up-to-date libraries that explicitly support Java 17 makes this process easier and more reliable, as the vendor has already tested them on Java 17. Upgrade the third-party libraries of your custom connector to be compatible with Java 17: - Java EE libraries Mule 4.6.x exposes Java EE libraries differently than earlier Mule versions. You must add the BOM dependency to your custom connector and, if applicable, exclude the provided conflicting library. You can also add the libraries in the BOM dependency separately. ```java 4.6.0 org.mule mule-javaee-runtime-bom ${muleJavaEeBomVersion} pom import ``` For more information, see [Java EE Libraries](https://docs.mulesoft.com/mule-sdk/latest/java-ee-libraries). - External libraries Upgrade external libraries, which are third-party libraries that are not bundled with your custom connector. Some examples include a JDBC driver, JMS broker client, or Groovy runtime. The following example shows a JDBC driver external library configuration: ```java @ExternalLib(name = "MySQL JDBC Driver", description = "A JDBC driver that supports connection to the MySQL Database", nameRegexpMatcher = "(.*)\\.jar", requiredClassName = "com.mysql.jdbc.Driver", coordinates = "mysql:mysql-connector-java:5.1.44") public class MySqlConnectionProvider implements ConnectionProvider { // } ``` You must update your external libraries to a version that is compatible with Java 17. ### Review Your Code After you compile your custom connector, ensure you can run your custom connector with Java 17. Reviewing your code is important because some restrictions are flagged as warnings in Java 11 but are flagged as failures and can’t be disabled in Java 17. For example, reflection is more restricted in Java 17, so you must review your code to ensure there are no illegal actions. To help you review your code, learn more about the different changes in Java 17: - JDK Migration Guide See the [Oracle JDK Migration Guide](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A) for a full list of the changes made from Java 8 to Java 17. Use the guide to assess the impact to your code. - Mule runtime engine See [Mule runtime](https://docs.mulesoft.com/general/java-support#mule-runtime) to learn more about the Java 17 changes made in Mule runtime engine. - Reflection on Java classes To ensure compatibility with Java 17, review and update any code that uses reflection to access Java classes or set parameter values. Java 17 imposes stricter access controls, so avoid introspecting JDK internals. Have a robust test suite that runs with Java 17. Pay special attention to the `setAccessible(true)` method because these access changes are not allowed in Java 17. - Serialization Update your serialization code to accommodate the restrictions of Java 17. If your code uses libraries like Gson for serializing classes, switch to using Data Transfer Objects (DTOs) where reflective access to JDK classes is involved. Ensure that serialization libraries are updated and adjust your code to minimize reliance on reflection. For more information, refer to [Configure Custom Serializers](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers). - Library upgrades Upgrade your libraries to versions compatible with Java 17. This includes updating ByteBuddy to version 1.14.0, Jacoco to 0.8.10, and SLF4J to version 2.x. Replace CGLib with ByteBuddy and check for updates to other libraries like Groovy and JRuby. Verify that all dependencies are compatible with Java 17 to avoid runtime issues. - Changes with running the test suite Adapt your testing approach for Java 17. If you use Mockito, be aware that Mockito can’t mock JVM classes. Consider custom implementations for mocking and switch from PowerMock to newer Mockito versions. Update your tests to handle the changes in Java 17 and avoid deprecated methods. - Java Platform Module System (JPMS) JPMS was introduced in Java 9. This feature introduces stricter encapsulation, impacting how Mule modules interact with JDK classes. As Mule upgrades to Java 17 and JPMS, these changes are necessary: - Refactor Split Packages: Resolve issues with internal and API package splits by reorganizing and refactoring packages to conform with JPMS modularization standards. - Address `ResourceBundle` Loading: Implement solutions for issues related to resource bundle loading, such as using `ResourceBundleProvider` or alternative methods. - Analyze the third-party libraries' changelogs to understand Java 17 compatibility and changes related to JPMS. ### Add Missing Code Because reflection is more restricted in Java 17, API objects now require setters. Previously with Java 8, it was enough for API objects to only have default constructors and getters for all DataWeave accessible properties. Now, API objects must also have setters so DataWeave can write those properties without using reflection. Constructors and setters are required if your class is instantiated by DataWeave, and getters are required if your class is read. If your class is returned and not instantiated, only getters are required. However, using both getters and setters simplifies the validation and certification process. ## Upgrade Your Custom REST SDK Connectors Use REST SDK version 0.8.0-RC4 to upgrade your custom REST SDK connectors to Java 17. REST SDK 0.8.0-RC4 generates Java 17-compatible connectors and maintains backward compatibility only with REST SDK 0.8.0-RC3 connectors built without Java customizations. Version 0.8.0-RC4 is not backward-compatible with REST SDK versions earlier than 0.8.0-RC3. When upgrading REST SDK connectors to Java 17: - For REST SDK version 0.8.0-RC3 and earlier connectors with Java customizations, regenerate the connector with REST SDK 0.8.0-RC4 and port over any Java customizations. The resulting connector likely breaks compatibility with the previous version of the connector. - For REST SDK 0.8.0-RC3 and earlier connectors without Java customizations, regenerate the connector with REST SDK 0.8.0-RC4. The resulting connector is backward-compatible with the previous version. For more information about REST SDK, see [REST SDK](https://beta.docs.mulesoft.com/beta-mule-sdk/mule-sdk/1.1/rest-sdk/rest-sdk-connectivity). ### Upgrade an Existing Custom REST SDK Connector If you previously generated a connector using REST SDK and you want to make that connector compatible with Java 17: 1. Upgrade the REST SDK components and dependencies to version 0.8.0-RC4: ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. If you manually create the configuration class (`ConnectorNameConfiguration.java`) using the REST SDK override feature, you must add an extra annotation: ```java import org.mule.sdk.api.annotation.JavaVersionSupport; import org.mule.sdk.api.meta.JavaVersion; @JavaVersionSupport({JavaVersion.JAVA_8, JavaVersion.JAVA_11, JavaVersion.JAVA_17}) public class YourConnectorConfiguration ``` 3. Regenerate the connector. ### Upgrade a New Custom REST SDK Connector If you generate a new connector using REST SDK and want to make that connector compatible with Java 17: 1. Upgrade the REST SDK components and dependencies to version 0.8.0-RC4: ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. Upgrade the Mule runtime version to 4.6.x. ## Upgrade Your Custom REST Connect Connectors Upgrade your custom REST Connect connectors to Java 17. REST Connect now supports Java 17. REST Connect connectors are generated from an API specification using REST Connect. To make the connector Java 17-compatible, republish the API specification to Exchange. See [REST Connect Connector Generator](https://docs.mulesoft.com/exchange/to-deploy-using-rest-connect). > [!IMPORTANT] REST Connect now adds support for TLS. To save time, enable TLS at the same time you > update your generated connector for Java 17 so that you need to generate the connector and test > your apps only once. ## Upgrade Your Custom Configuration Properties Providers To upgrade your custom configuration properties provider to be compatible with Java 17, switch to use [Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started) and use the `@JavaVersionSupport` annotation as explained in [Release Your Custom Connector](#release-your-custom-connector). You must also perform all the steps described in [Upgrading Java for Custom Connectors (Partners)](https://docs.mulesoft.com/general/partner-connector-upgrade), just like with any custom connector. The example custom configuration properties provider mentioned in [Example: Mule SDK Module](https://docs.mulesoft.com/mule-runtime/latest/custom-configuration-properties-provider#example-mule-sdk-module) is updated to support Java 17. Refer to that example to update your custom configuration properties provider. For more details about what the changed code looks like (including migrating tests to MUnit), refer to this [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/410ee26d8b3c44adacb077e099f32886f99eb6be). Alternatively, if switching to using [Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started) involves too many changes for you, add a declaration using `ExtensionDeclarer` inside `ExtensionLoadingDelegate` in your custom configuration properties provider. For more details about what the changed code looks like, refer to this [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/19d9d45cd52b0695f7b9c2b9019bae88f45fb228). ## Test Your Custom Connector with MTF Test your custom connector with Module Testing Framework (MTF) to ensure Java 17 compatibility. For more information about MTF, see [MTF](https://beta.docs.mulesoft.com/beta-mtf/mule-sdk/1.1/mtf). ### Set Up Your Build Ensure your pipeline runs against all supported Java versions (Java 8, Java 11, and Java 17). The following example shows a single build pipeline that is configured to run tests against all supported Java versions, in which `default` corresponds to Java 17: ![Example of single build pipeline](/mulesoft/current/en-us/general/_images/single-build-pipeline.png) The pipeline runs all tests even if the previous tests fail. For example, the pipeline runs Java 17 tests even if the Java 11 tests fail. Although the pipeline contains multiple tests, the pipeline has one compilation phase and one release phase, which targets Java 8. ### Run an Initial Test Run an initial test to test your custom connector for Java 17 compatibility. You can continue to run tests as you change the custom connector code: 1. In the `pom.xml` file of your custom connector, update the munit-extensions-maven-plugin configuration to include the following configuration (the `jacoco.version` property must be 0.8.10 or later): ```xml -javaagent:${settings.localRepository}/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar=destfile=${session.executionRootDirectory}/target/jacoco-munit.exec ``` 2. Run your MTF test to generate the coverage report. Use the `-Dtest=none` and `-DfailIfNoTests=false` flags when running the test to avoid including the JUnit tests in the coverage report. The coverage report is available in `target/jacoco-munit.exec`. ### View your Coverage Report View your coverage report to see your custom connector coverage. You must have at least 80% coverage for a high certainty of Java 17 compatibility. 1. Open IntelliJ IDEA. 2. Go to **Run** > **Show Coverage Data**. 3. In **Choose Coverage Suite to Display**, add `jacoco-munit.exec` to the list if it’s not there already. 4. Look at the coverage percentages to analyze your results. The coverage percentage reflects how much of your connector is tested. A key issue to avoid is illegal reflective access in your code. The only ways to detect this are to [Review Your Code](#review-your-code) or through testing. Aiming for at least 80% coverage allows flexibility on simpler code, such as getters and setters, while ensuring thorough testing of all critical business logic. ### Add the JDeps Maven Plugin JDeps is a tool for static code analysis that detects the usage of JDK internal APIs that are no longer available or accessible. For more information, refer to the [OpenJDK wiki](https://wiki.openjdk.org/spaces/JDK8/pages/17957128/Java+Dependency+Analysis+Tool). Add the JDeps Maven plugin to your custom connector’s `pom.xml` file: ```xml org.apache.maven.plugins maven-jdeps-plugin 3.1.2 jdkinternals test-jdkinternals true ``` If your custom connector is using a JDK internal API that is no longer available or accessible, the build fails. Run the build with both Java 8 and 11 by changing the `JAVA_HOME` value, as the JDeps Maven plugin relies on the JDeps tool bundled with the JDK. Running the build with each Java version ensures extra confidence. To run the JDeps Maven plugin without tests, use the following command: ```bash mvn clean install -Dtest=none -DfailIfNoTests=false -DskipTests=true ``` This helps focus on checking the offending libraries and internal access issues without dealing with potential test failures or long test runtimes. ### Test for Java 17 Compatibility You can test for Java 17 compatibility running on either Java 11 or Java 17. If you are running on Java 11, you can perform early validations by adding a parameter for illegal reflective access. See [Add a Parameter for Illegal Reflective Access](#add-a-parameter-for-illegal-reflective-access). If you are running on Java 17, you can test for Java 17 directly. See [Test for Java 17 Compatibility Directly](#test-for-java-17-compatibility-directly). #### Add a Parameter for Illegal Reflective Access Reflective access is one of the breaking changes of Java 17. If you run your MTF tests with the default Java 11 behavior, the MTF tests log only a warning for reflective access. To resemble Java 17 behavior, run your MTF tests with the `--illegal-access=deny` JVM parameter so the MTF tests fail instead of logging only a warning. Use this parameter in Mule runtime versions 4.2.0 and later. To set up your custom connector’s `pom.xml` file to include the configuration: 1. Add an empty property: ```xml ``` 2. Update the munit-extensions-maven-plugin configuration to include the following configuration: ```xml <_JAVA_OPTIONS>-XX:+PrintCommandLineFlags ${mtf.javaopts} ``` You can now run your MTF tests with the `--illegal-access=deny` parameter. Here is an example bash script (replace with the latest Mule runtime version available): ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmtf.javaopts="--illegal-access=deny" > ./target/test.log ``` After running your MTF tests, go to the `target/illegal-access.log` file and check for classes or dependencies that misbehave. You can also use the following command to exclude the known warnings outside of your custom connector: ```bash cat target/illegal-access.log | sort | uniq | grep -Ev "org.mule.module.artifact|org.mule.metadata|org.mule.runtime|org.mule.service" ``` #### Test for Java 17 Compatibility Directly Run your MTF tests to test compatibility of your custom connector against Java 17. As mentioned previously, you can use a single build pipeline that runs against all supported Java versions. You can also set up another temporary build pipeline for Java 17 so your main build pipeline doesn’t become unstable. After you upgrade to Java 17, discard the temporary build pipeline and converge on your main build pipeline. 1. Set the path to your JVM installation in the `MUNIT_JVM` variable (you must install it yourself). You must also set `JAVA_HOME` to Java 8. 2. Ensure the following MTF dependencies are set in your custom connector `pom.xml` file: - munit 3.1.0 - munit-extensions-maven-plugin 1.2.0 - mtf-tools 1.2.0 - mule-maven-plugin 4.1.0 - mule-extensions-maven-plugin 1.6.0-rc1 These MTF dependencies require a minimum Mule version of 4.3.0. To ensure your MTF tests don’t validate against Mule runtime versions earlier than 4.3.0, add the following to the `munit-plugin` configuration in your custom connector `pom.xml` file: ```xml [...] ${minVersion} false EE ``` You can run MTF tests against Java 17 only with Mule runtime 4.6.0 and later. For Mule runtime 4.5.x and earlier, you can run MTF tests only against Java 8 and Java 11. MUnit 3.1 is compatible only with Mule runtime 4.3.0 and later. If your connector is compatible with Mule runtime 4.2.0 and earlier, you must create a legacy profile that overrides the MUnit version. Use the following bash script to test your custom connector against Java 17: ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmule.module.tweaking.validation.skip=true \ -Dmule.jvm.version.extension.enforcement=LOOSE > ./target/test.log ``` If you use `mule-java-extension-parent` (recommended), the minimum Mule version is independent of the parent version and you control it directly in your project. For more information, see [Upgrading Existing Modules](https://docs.mulesoft.com/mule-sdk/latest/forward-compatibility-setup#upgrading-existing-modules). If you use the legacy `mule-modules-parent`, the Mule runtime version determines the parent version. For example, Mule runtime 4.6.0 corresponds to `mule-modules-parent` 1.6.0. Minor versions maintain a correspondence, such as Mule runtime 4.1.0 with `mule-modules-parent` 1.1.0, Mule runtime 4.2.0 with `mule-modules-parent` 1.2.0, and so forth. Mule runtime 4.6.0 and later supports Java 17. However, a connector can be compatible with both Mule 4.3.0 and Java 17 simultaneously. If your connector must be compatible with Mule 4.3.0, its `mule-modules-parent` version cannot exceed 1.3.0. You don’t need to use `mule-modules-parent` 1.6.0 for your connector to be compatible with Java 17. Using `mule-modules-parent` 1.6.0 is specifically required to leverage other features from the Mule runtime 4.6.0 in the connector. ### Read Your Tests After you run your MTF tests, your build has either of the following outcomes: - Test failures You probably need to change your custom connector code to ensure Java 17 compatibility. - All tests pass Either your custom connector does not require any major changes or your test suite is not comprehensive enough. Review your test suite and double-check that your code coverage is good and that your test scenarios and assertions are not too simple. ## Release Your Custom Connector After you update your code and your tests are green, you are ready to release a new Java 17-compatible version of your custom connector. 1. To communicate Java 17 compatibility, generate metadata for Java compatibility of your custom connector by adding or upgrading the custom connector `mule-sdk-api` dependency to the latest version: ```xml org.mule.sdk mule-sdk-api 0.10.1 ``` 2. For Java SDK, add the `@JavaVersionSupport` annotation in the same class as the `@Extension` annotation and include the `JAVA_17` value, for example: > [!NOTE] You don’t need to add any annotations for XML SDK because XML SDK modules are Java 17 > compatible and inherit the property automatically. ```java @Extension(name = "Database") @Operations(...) @JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17}) public class DatabaseConnector { .. } ``` In Mule 4.5.0 and later, custom connectors that don’t specify the `@JavaVersionSupport` annotation are assumed to be compatible with Java 8 and Java 11. You can mark your custom connector as compatible with Java 17 only; however, you must ensure that no adoption or backward compatibility issues exist. When you deploy a Mule app, Mule verifies that all modules in the Mule app are compatible with the Java version. If Mule finds an incompatibility, Mule throws an error and the application does not deploy. > [!NOTE] If you receive an error message specific to an XML SDK based connector, such as > `Extension 'module-error-handler-plugin' does not support Java 17. Supported versions are: [1.8, 11]`, > this means that your Mule app still contains some connectors that are not compatible with Java 17. > To resolve this error, upgrade all connectors in your Mule app to be compatible with Java 17. If your code is compatible with Java 17 but you don’t declare Java 17 compatibility, you can still get a successful test run. To run a quick check on your custom connector or if all dependencies are not ready, pass the following argument to skip hard checks on the Java support declaration: ```bash -M-Dmule.jvm.version.extension.enforcement=LOOSE ``` For more information, see [Java Version Support](https://docs.mulesoft.com/mule-sdk/latest/java-version-support). ## See Also - [Java Support](https://docs.mulesoft.com/general/java-support) --- product: Getting Started keywords: java upgrade, api policies, api proxies, automated policies, custom policies, api-level policies, mulesoft upgrade --- # Upgrading Java for Policies and API Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Extended support for Java 8 and 11 ends in February 2027 for 4.6 LTS. Upgrade your apps that run on Java 8 or 11. Upgrade your policies and API proxies to be compatible with Java 17. ## Upgrading Automated Policies Upgrade your automated policies (included and custom) to Java 17. ### Upgrading Included Automated Policies To upgrade automated [MuleSoft included policies](https://docs.mulesoft.com/mule-gateway/policies-included-directory) to Java 17: 1. In API Manager, go to **Automated Policies**. 2. In **Policy version**, select the latest version of the included policy. 3. In **Rule of application**: - If your policy is on the latest version: - To apply included policies to all Mule runtimes, select **All runtimes** and click **Apply**. - To apply the included policies to Omni Gateways only, select **Omni gateways only** and click **Apply**. - To apply the included policies to Mule Gateways only: 1. Select **Mule gateways only**. 2. In **From version** and **To**, enter the Mule version range. 3. In **Java Versions**, select **All Java versions** or **Choose specific Java versions**. 4. Click **Apply**. - If your policy is not on the latest version: - To apply included policies to all Mule runtimes, select **All runtimes** and click **Apply**. - To apply the included policies to Omni Gateways only, select **Omni gateways only** and click **Apply**. Note that the **Rule of application** section must be the same as the **Rule of application** section in the latest version or else you might have unprotected APIs. - To apply the included policies to Mule Gateways only: 1. Select **Mule gateways only**. 2. In **From version** and **To**, enter the Mule version range. 3. In **Java versions**, select **Choose specific Java versions** and select Java 8 and Java 11. 4. Click **Apply**. 5. Click **Add automated policy** and add the same automated policy. 6. Click **Advanced options**. 7. Select **Mule gateways only**. 8. In **From version** and **To**, enter the Mule version range. 9. In **Java versions**, select **Choose specific Java versions** and select Java 17. 10. Click **Apply**. ### Upgrading Custom Automated Policies To upgrade custom automated policies to Java 17: 1. In API Manager, go to **Automated Policies**. 2. Upgrade the required extensions and connectors to Java 17. - If your custom policy has Anypoint Connectors, see [Upgrading Anypoint Connectors and Modules](https://docs.mulesoft.com/general/java-support#anypoint-connectors-and-modules). - If your custom policy has custom connectors, see [Upgrading Custom Connectors](https://docs.mulesoft.com/general/java-support#custom-connectors). 3. [Upgrade the custom policy](https://docs.mulesoft.com/mule-gateway/policies-custom-java-version). 4. [Package the custom policy](https://docs.mulesoft.com/mule-gateway/policies-custom-package). Configure Java 17 locally to make custom policies compatible with Java 17. 5. [Republish the custom policy to Exchange](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange). 6. Apply the new version of the custom policy that is compatible with Java 17 to the API instance: 1. Go to **Policies**. 2. In **Applied policy status**, verify that the latest definition is applied. - If the latest definition is applied, click on the More (…​) menu and select **Check for implementation updates**. - If the latest definition is not applied, update to the latest definition. ## Upgrading API-Level Policies Upgrade your API-level policies (included and custom) to Java 17. ### Upgrading Included API-Level Policies To upgrade API-level [MuleSoft included policies](https://docs.mulesoft.com/mule-gateway/policies-included-directory) to Java 17: 1. In API Manager, go to **API Administration** > **{API Name}** > **Policies** > **Add a policy** to [apply policies](https://docs.mulesoft.com/mule-gateway/policies-included-apply) at the individual API level. 2. Upgrade each of your API-level policies: 1. In **Policy version**, select the latest version of the included policy. 2. In **Method & resource conditions**, select either **Apply configuration to all API method & resources** or **Apply configuration to specific API method & resources**. 3. Click **Apply**. ### Upgrading Custom API-level Policies To upgrade custom API-level policies to Java 17: 1. In API Manager, go to **API Administration** > **{API Name}** > **Policies** > **Add a policy** to [apply policies](https://docs.mulesoft.com/mule-gateway/policies-included-apply) at the individual API level. 2. Upgrade the required extensions and connectors to Java 17. - If your custom policy has Anypoint Connectors, see [Upgrading Anypoint Connectors and Modules](https://docs.mulesoft.com/general/java-support#anypoint-connectors-and-modules). - If your custom policy has custom connectors, see [Upgrading Custom Connectors](https://docs.mulesoft.com/general/java-support#custom-connectors). 3. [Upgrade the custom policy](https://docs.mulesoft.com/mule-gateway/policies-custom-java-version). 4. [Package the custom policy](https://docs.mulesoft.com/mule-gateway/policies-custom-package). Configure Java 17 locally to make custom policies compatible with Java 17. 5. [Republish the custom policy to Exchange](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange). 6. Apply the new version of the custom policy that is compatible with Java 17 to the API instance: 1. Go to **Policies**. 2. In **Applied policy status**, verify that the latest definition is applied. - If the latest definition is applied, click on the More (…​) menu and select **Check for implementation updates**. - If the latest definition is not applied, update to the latest definition. ## Upgrading API Proxies > [!IMPORTANT] To ensure your API proxies or Mule apps are protected when upgrading, upgrade your > API policies **before** upgrading your API proxies or Mule apps. The steps to upgrade are a little different, depending on your **Proxy type**: - Basic endpoint: - If you use Basic endpoint, deploy the adapted application to the server from Mule runtime and connect it to API Manager using autodiscovery. For more information, see [Configuring Mule Gateway API Autodiscovery in a Mule 4 Application](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4). - If you use a Basic endpoint API instance to update your instance, update the Mule application connecting to your API instance. - If you use a proxy application, see the following sections for deployment type: - [CloudHub and CloudHub 2.0 Deployments](#cloudhub-and-cloudhub2-deployments) - [Hybrid Deployments](#hybrid-deployments) - [Runtime Fabric Deployments](#runtime-fabric-deployments) ### CloudHub and CloudHub 2.0 Deployments Before following these steps, ensure your policies are updated. For more information, see [Upgrading Automated Policies](#upgrading-automated-policies) and [Upgrading API-Level Policies](#upgrading-api-level-policies). 1. In API Manager, go to **API Administration > Settings**. 2. [Edit the API instance’s configuration settings](https://docs.mulesoft.com/api-manager/latest/edit-api-endpoint-task): 1. In **Runtime Channel**, select the runtime channel to use. 2. In **Version**, select **4.6.0** or later. 3. In **Java version**, select **Java 17**. 3. Click **Save & Apply**. ### Hybrid Deployments Before following these steps, ensure your policies are updated. For more information, see [Upgrading Automated Policies](#upgrading-automated-policies) and [Upgrading API-Level Policies](#upgrading-api-level-policies). 1. Deploy Mule runtime engine 4.6.x in a new server running on Java 17 and start the server. For more information, see [Add Servers to Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create). 2. Select the new target you created running on Java 17 and, in API Manager, go to **API Administration > Settings**. 3. [Edit the API instance’s configuration settings](https://docs.mulesoft.com/api-manager/latest/edit-api-endpoint-task): 1. In **Select target**, select the server running on Java 17 as the target. 4. Click **Save & Apply**. 5. After the server successfully runs on Java 17, shift your traffic gradually to the new server using a load balancer and turn off the old server after all of its apps are migrated. ### Runtime Fabric Deployments Before following these steps, ensure your policies are updated. For more information, see [Upgrading Automated Policies](#upgrading-automated-policies) and [Upgrading API-Level Policies](#upgrading-api-level-policies). 1. Deploy Mule runtime engine 4.6.x in a new server running on Java 17 and start the server. For more information, see [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric). 2. Select the new target you created running on Java 17 and, in API Manager, go to **API Administration > Settings**. 3. [Edit the API instance’s configuration settings](https://docs.mulesoft.com/api-manager/latest/edit-api-endpoint-task): 1. In **Runtime Channel**, select the runtime channel to use. 2. In **Version**, select **4.6.0** or later. 3. In **Java version**, select **Java 17**. 4. Click **Save & Apply**. 5. After the server successfully runs on Java 17, shift your traffic gradually to the new server using a load balancer and turn off the old server after all of its apps are migrated. ## See Also - [Java Support](https://docs.mulesoft.com/general/java-support) --- product: Getting Started keywords: usage reports, mule runtime, product consumption, anypoint platform, runtime versions, monitoring, access reports --- # Usage Reports > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Usage reports provide comprehensive monthly and daily summaries that give you valuable insights into your resource use across Anypoint Platform products. By correlating your usage with billing cycles, you can gain insights into the factors influencing your costs. This enables you to proactively manage your budget and make informed decisions to optimize your resource allocation. When you use an Anypoint Platform product that is metered, MuleSoft measures your usage and aggregates the records on a daily and monthly basis. Usage report data is refreshed twice a day. The most recent three days of data is subject to change. For example, on January 10, data from January 7 to January 10 might still be updated. Data from January 6 and earlier is final and won’t change. All reports are calculated using the UTC time standard. For example, a daily usage is aggregated from 00:00 to 00:00 UTC. Daily usage retention is three months and monthly usage retention is up to five years. Organizations that have a usage-based pricing model can compare actual usage from the report against the existing contract. However, usage reports are not for billing purposes. For more information about usage metrics and pricing, read [Anypoint Platform Pricing](https://docs.mulesoft.com/general/pricing) and [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) Some usage data, such as monthly statements and vCore allocation, appears in different areas of Anypoint Platform or Salesforce products. - Monthly statements for Mule runtime, including Mule flows, Mule messages, and data throughput are sent to the primary billing contact. [Automation credits](https://docs.mulesoft.com/general/automation-credits-usage-and-rates) for RPA, Composer, Intelligent Document Processing (IDP), Salesforce Flow Orchestration, and MuleSoft for Flow are sent to the primary billing contact. For more information, see [Monthly Account Summaries](https://help.salesforce.com/s/articleView?id=000390885&type=1) documentation in Salesforce. - Usage of certain Salesforce generative AI features (Agentforce and Einstein generative AI) or direct calls to the large language model (LLM) gateway consumes credits. All Salesforce AI usage from Anypoint Platform features is routed through your connected Salesforce org, which tracks consumption and handles billing. Anypoint Platform features that use Einstein generative AI or Agentforce features include: - Anypoint Code Builder Use MuleSoft Dev Agent to develop integrations and API specs. For more information about this feature, see [Developing Integrations Using MuleSoft Vibes](https://docs.mulesoft.com/anypoint-code-builder/int-ai-developing-integrations) and [MuleSoft Vibes Overview](https://docs.mulesoft.com/anypoint-code-builder/mulesoft-vibes). - Intelligent Document Processing (IDP) Use Einstein generative AI to read and interpret documents. For more information about this feature, see [Enhancing Data Extraction with Einstein](https://docs.mulesoft.com/idp/enhancing-data-extraction-with-einstein).. - Anypoint Exchange Use Einstein generative AI to generate API documentation for REST APIs. For more information about this feature, see [Generating API Documentation with Generative AI](https://docs.mulesoft.com/exchange/generating-documentation-with-ai). For more information about how the usage for these features is tracked and billed, see [Agentforce and Generative AI Usage and Billing](https://help.salesforce.com/s/articleView?id=ai.generative_ai_usage.htm&type=5). - Alerts for usage reaching 80% and 90% of the contractual entitlement are sent automatically to the primary billing contact email address. The primary billing contact gets alerts monthly once thresholds are reached. For more information, see the [Salesforce Usage Alerts FAQ](https://help.salesforce.com/s/articleView?id=004811177&type=1) knowledge article. - CloudHub vCore consumption data, including peak usage across CloudHub (CH1) and CloudHub 2.0 (CH2), is available in Usage Reports. For more information, see [CloudHub vCore Usage](https://docs.mulesoft.com/general/usage-metrics#cloudhub-vcore-usage). Government Cloud and Anypoint Private Cloud Edition usages aren’t available in usage reports. ## Products Available in Usage Reports The following products are available in usage reports: - Anypoint MQ - API Experience Hub - API Governance - API Manager - [CloudHub vCore](https://docs.mulesoft.com/general/usage-metrics#cloudhub-vcore-usage) - Omni Gateway - Omni Gateway Model Proxy - Intelligent Document Processing (IDP) - Mule Runtime - Object Store v2 ## Supported Mule Runtime Versions To view usage reports for Mule runtime, all applications (in production and sandbox) must use these Mule versions:
Deployment TypeVersion Requirements

CloudHub 2.0

The latest date-patch versions for 4.3.0 and later

CloudHub

The latest date-patch versions for 3.9 and 4.2.0 and later

Runtime Fabric

One of these versions or any later date-patch:

Mule 4 image versions:

  • 4.5.0 and later

  • 4.4.0-20230111-1

  • 4.3.0-20221212-2

  • 4.2.2-20221027-7

  • 4.2.1-20221027-7

  • 4.2.0-20221027-6

Hybrid Standalone

One of these versions or any later date-patch:

  • 4.6.0 and later

  • 4.4.0-20221111

  • 4.3.0-20221024

Runtime Manager Agent 2.7.0 and later

You must redeploy your apps with a supported version, either manually or during the monthly patching cycle. The monthly patching cycle is applicable only for CloudHub and CloudHub 2.0 applications. You can [roll back](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#roll-back-to-a-previous-successful-configuration) to a previous successful application configuration. However, if an app is using a Mule version not supported by usage reports, you must choose a compliant Mule version before deploying changes. After deployment, a new configuration with the previously chosen settings and a supported runtime is created. ## Before You Begin Usage reports are available only when you’re signed in to the root organization and don’t appear at the business group level. To access usage reports, you need the [Usage Viewer permission](https://docs.mulesoft.com/access-management/permissions-by-product#usage). If you don’t have this permission, contact your organization administrator to request access. The Usage Viewer permission must be [applied at the root organization level](https://docs.mulesoft.com/access-management/managing-permissions) rather than the business group level. ## Access Usage Reports 1. Sign in to Anypoint Platform using an account that has the Usage Viewer permission for your root organization. 2. In the Anypoint Platform navigation bar, click the business group selector, and ensure you are at the root organization level. 3. In the Anypoint Platform navigation bar, click your username icon and select **Usage Reports**. 4. Select the product for which to view a usage report. 5. Click **Monthly Usage Report** or **Daily Usage Report**. 6. Select the month or day of the usage report to view. For the selected product, only dates that Anypoint Platform collected data for are available. The usage report appears, displaying an assortment of usage metrics that are [dependent on the product you selected](https://docs.mulesoft.com/general/usage-metrics). ## Export Usage Reports to a CSV File You can export both daily and monthly usage reports to CSV files. These metrics match the data available in usage reports. 1. Navigate to the usage report to download. 2. Click **Export as CSV**. ## Usage API Use the Anypoint Usage API to programmatically access usage data. The API provides both daily and monthly details. Usage metrics are organized by business group and application. This provides detailed insight into product consumption. To use the API, see the API documentation for the [Anypoint Usage API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a/usage-api/) for access and implementation details. Users must have Usage Viewer permission to access the Usage API. For a summary of pricing models and where to review usage and billing context for each model, see [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics). ## Granular Mule Credits Visibility Anypoint Usage Reports provide operational drill-down visibility for Mule Credits-related consumption. > [!NOTE] Use Salesforce Digital Wallet for finalized, billing-relevant Mule Credits totals and > statements. For detailed Mule Credits usage guidance and billing context, see [Understand Mule Credits Usage and Rates](https://docs.mulesoft.com/general/mule-credits-usage-and-rates). ## Usage Reports on Control Planes All features of Usage Reports are supported on Japan and Canada control planes. ## See Also - [Anypoint API Governance Overview](https://docs.mulesoft.com/api-governance/) - [API Manager 2.x](https://docs.mulesoft.com/api-manager/latest/) --- product: Getting Started keywords: usage reports, release notes, mulesoft usage reports, anypoint platform, usage tracking, changelog --- # Usage Reports Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Each Anypoint Platform organization subscribes to a specific pricing, usage, and packaging model. Some functionality within Anypoint Platform depends on your organization’s setup and provisioning. The following release notes are provided for pricing, usage, and packaging: - [Usage Reports Release Notes](https://docs.mulesoft.com/release-notes/usage-reports/usage-reports-release-notes) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: Getting Started keywords: usage metrics, pricing metrics, anypoint mq usage, api experience hub, api governance, api manager --- # Usage-Based Pricing: Usage and Rates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Platform captures usage metrics across products, but not all metrics are billable or reflected in usage reports. ## Usage Type Description This table defines usage metrics by product and explains how each metric is calculated for reporting.
ProductMetric DescriptionUsage Details

Mule Runtime

Mule flow: Flow within a deployed and running Mule app that contains a Mule event source or route APIKit request

Flows are aggregated using a Max Concurrent model. The usage for a month is the highest number of flows that exist in a single given hour during a month.

Mule message: Container of the core information processed by the runtime

A Mule message counts as a single unit when an event source triggers it. Messages are aggregated using a total of all messages sent during a month.

Data throughput: Total amount of data transferred in and out of the infrastructure that runs Mule where the Mule app is deployed

Data throughput counts when the deployed application transfers data to execute its business logic, including but not limited to internal operational network traffic for monitoring, logs, and health checks. Data throughput is aggregated as a sum of all bytes during a month.

API Manager

API instances: API instances in production, preproduction, and unclassified APIs (not associated with an environment) that are managed by API Manager after they are created using add, promote, or import options.

API instances remain under management until they are deleted. Instances of API Manager are aggregated using a Max Concurrent model with three separate metrics for production, preproduction, and unclassified (APIs that aren’t associated with an environment).

Data for API Manager is available starting in October 2024.

API Governance

API under Governance: APIs identified by the selection criteria of at least one of the governance profiles

If an API is governed, all versions of that API are considered one governed API. Instances of API Governance are aggregated using a Max Concurrent model. The usage for a month is the highest number of APIs governed in a single given hour during a month.

Omni Gateway

Omni Gateway API call: Any access request received by Omni Gateway regardless of whether the response to the request is successful

Omni Gateway requests are aggregated as a total of all requests during a month.

Model Proxy

Prompt tokens: Number of tokens a Model Proxy in the prompts a Model Proxy sends to a specific LLM Model

These tokens are the sum of all prompt tokens a specific Model Proxy sends to a specific LLM Model during a month. A prompt sent to a Model Proxy are considered an Omni Gateway API call and count towards the Omni Gateway API call metric.

Completion tokens: Number of tokens in the responses that a Model Proxy receives from a specific LLM Model

These tokens are the sum of all response tokens a specific Model Proxy receives from a specific LLM Model during a month.

Total tokens: Total number of tokens used in interactions between a Model Proxy and a specific LLM Model

Some LLM Providers, such as Gemini, use thinking tokens. Total tokens are the sum of prompt tokens, completion tokens, and thinking tokens if applicable.

Anypoint MQ

Anypoint MQ API request: A request made to retrieve one or more messages from the Anypoint MQ APIs

Anypoint MQ uses API requests to calculate billing. Anypoint MQ API requests are calculated in the aggregate across all environments (including production, pre-production, sandbox, and design). Anypoint MQ API requests are available via API and aggregated on usage reports.

Object Store

Object Store API request: A request made to retrieve one or more messages from the Object Store APIs as further defined in the Object Store documentation

Each Object Store API request includes up to 100 KB of data. Object Store API requests over 100 KB count as multiple requests with no fractional units. Object Store API requests are available via API and aggregated on usage reports.

DataGraph

DataGraph orchestration: An API request made by Anypoint DataGraph to the source APIs to get data for the GraphQL API request made to Anypoint DataGraph

Orchestrations are not currently aggregated on usage reports.

## Anypoint MQ Usage Anypoint MQ usage reports show this information in tables and cards: Business Group Business group that owns the resources where the app with the queue is deployed Environment Environment within the business group where the app with the queue is deployed Region id Region where the app with the queue is deployed Object type Queue or message exchange Object name Name of the queue or message exchange Message units Number of encoded characters in a message, used to determine the size of message data in the response for rate limiting (not billing) Messages bytes Size of the message data in the response, based on message units API requests Number of API calls via the connector or API, used to calculate monthly quota for billing Messages received Number of messages received Total Message units Sum of message units across all queues in the organization Total Messages bytes Sum of message data across all queues in the organization Total API requests Sum of API calls across all queues in the organization Total Messages received Sum of messages received across all queues in the organization Sideloaded apps for hybrid standalone deployments are shown with the ⓘ icon in usage reports. Redeployments of sideloaded apps result in multiple records appearing in usage reports. ## API Experience Hub Usage API Experience Hub usage reports show this information in tables and cards: Salesforce Organization ID OrgID for the Salesforce organization where the API is deployed Salesforce Portal Name Name of the Salesforce portal where the API is deployed \# of Approved Request Access Sum of approved access requests for the API Total # of Approved Request Access Sum of approved access requests across all Salesforce organizations ## API Governance Usage API Governance usage reports show this information in tables and cards: Business Group Business group that contains governed APIs \# of APIs Governed Sum of APIs governed in the specified business group Maximum Number of Governed APIs Highest number of APIs governed in a single given hour during a month ## API Manager Usage Data for API Manager is available starting in October 2024. API Manager usage reports show this information in tables and cards: Business Group Business group where the API is managed Environment Environment type where the API is managed Runtime Runtime type for the API \# of APIs Managed Sum of APIs managed in the specified business group, environment, and runtime Maximum Number of Managed APIs API instances in production, preproduction, and unclassified APIs (not associated with an environment) ## Omni Gateway Usage Omni Gateway usage reports show this information in tables and cards: Business Group Business group in which the Omni Gateway is registered. Gateway Type Gateway type of the Omni Gateway registered. Data for this metric is available starting in March 2025. Environment Environment in which the Omni Gateway is registered. Registration Name of the registered Omni Gateway. Data Egress (GB) Total amount of outbound data in gigabytes (GB) transmitted by the Omni Gateway egress to upstream services. Data for this metric is available starting in March 2025. \# of API Calls Sum of API calls made by APIs that are deployed within the Omni Gateway. Total # of API Calls Sum of API calls across all registered Omni Gateways in the organization. ## Model Proxy Usage Model Proxy usage reports show this information in tables and cards: Model Proxy Name of the Model Proxy Business Group Business group where the Model Proxy is deployed Client app The client application or integration that sent requests to the Model Proxy Provider The external LLM provider used by the proxy Model The specific LLM models used by the proxy Prompt tokens The sum of tokens in prompts the Model Proxy sends to the model in the given time period Completion tokens The sum of tokens in responses the Model Proxy receives from the model in the given time period Total tokens Total tokens used in interactions between the Model Proxy and the model in the given time period. This includes prompt tokens, completion tokens, and any provider-specific thinking tokens when applicable. ## Intelligent Document Processing (IDP) IDP usage reports show this information in tables and cards: Business Group Business group the document is processed in Action ID ID associated with the processed action Action Version Version associated with the processed action Execution Type Execution types associated with the processed action Processed Pages Total pages processed ## Mule Runtime Usage MuleSoft captures usage data for Mule flows, Mule messages, and data throughput, but not all of this data is aggregated in usage reports. To track Mule message usage, the runtime report counts the number of times a Mule event source triggers a Mule message. You can view the number of these messages in a given day or month by business group, environment, and application. To calculate usage, MuleSoft meters and aggregates the number of messages daily and monthly. After a message is triggered, the report doesn’t track changes to the message because the message is processed within the application’s flows. Data throughput is the total network I/O bytes produced by the infrastructure of the Mule runtime engine running the Mule application. To calculate usage, MuleSoft tracks usage and aggregates the total daily and monthly GBs. For some customers in the US control plane, MuleSoft offers a pricing and packaging model for Anypoint Platform that allots a number of Mule flows, Mule messages, and data throughput (measured as network I/O bytes). Not all types of Mule flows and messages count toward the allotments in a package. ### Mule Runtime Usage Tables The usage information shown in the usage report tables changes depending on your view. #### Usage by Business Group Select the **Usage by Business Group** tab to view:
FieldDescription

Business Group

Business group that owns the resources. For Runtime Fabric, it’s the business group used when creating the Runtime Fabric instance.

Environment Type

Environment the resources are associated with.

For Runtime Fabric, it’s the environment the Runtime Fabric instance is associated with. If any production environment is associated with a Runtime Fabric instance, it is considered a production instance. Cluster capacity is not split within a Runtime Fabric instance between preproduction (sandbox) and production environments.

Cluster

Name of the cluster or Runtime Fabric instance containing the applications, workers, and nodes.

Cluster Capacity (Millicores)

Allocatable CPU capacity of each node within the Runtime Fabric instance.

vCore Peak

Highest hourly vCore consumption for applications in the selected business group and time period.

#### Usage by Application Select the **Usage by Application** tab to view:
FieldDescription

Application

Name of the Mule application

Business Group

Business group that owns the resources. For Runtime Fabric, it’s the business group used when creating the Runtime Fabric instance.

Deployment Type

Runtime plane the Mule app is deployed to: CloudHub (abbreviated as CH), CloudHub 2.0 (abbreviated as CH2), or Runtime Fabric (abbreviated as RTF)

Environment Type

Preproduction (sandbox) or production environment the Mule app is deployed to.

Cluster

The Runtime Fabric instance that contains the nodes and applications

CPU Limit (Millicores)

Maximum amount of CPU allocated by the user that the application can burst to within the shared cluster or Runtime Fabric instance

CPU Reserve (Millicores)

Amount of CPU allocated by the user to reserve for applications within the Runtime Fabric cluster or instance

HPA Status

Indicates whether Horizontal Pod Autoscaling (HPA) is enabled for the application. Displays Enabled or N/A.

vCore Peak

Highest hourly vCore consumption for the application within the selected time period.

vCore Min

Guaranteed base vCore allocation for the application, based on the minimum replica configuration. For CloudHub (CH1) applications, vCore Min equals vCore Peak.

Mule Flows

Total number of flows in the Mule app, calculated by multiplying flows by the number of workers (CH1) or replicas (CH2 and RTF).

Mule Messages

Total number of inbound and outbound Mule messages in the Mule app

Data Throughput (GB)

Total amount of inbound and outbound data in gigabytes (GB) transmitted by the Mule app

#### CloudHub vCore Usage For vCore-specific usage interpretation, including CloudHub vCore peak rollups, see [vCore Pricing Usage and Rates](https://docs.mulesoft.com/general/vcore-pricing-usage-and-rates). ### Mule Runtime Usage Cards MuleSoft usage reports cards include: - [Maximum Mule Flows](#max-mule-flows) - [Total Mule Messages](#mule-messages) - [Maximum CPU Limit in Production](#max-cpu-prod) - [Maximum CPU Limit in Preproduction](#max-cpu-preprod) - [Maximum Cluster Capacity in Production](#max-cluster-prod) - [Maximum Cluster Capacity in Preproduction](#max-cluster-preprod) ### Maximum Mule Flows A Mule flow is a sequence of logical operations configured within the XML `` element of a Mule application. The runtime report tracks the Mule flows within a deployed and running Mule application that contains a Mule event source or APIkit route requests. Mule apps in production environments typically use multiple Mule flows and subflows to divide the app into functional modules or for error-handling purposes. For example, one Mule flow might receive a record and transform data into a given format that another flow processes. To calculate usage, MuleSoft tracks the number of Mule flows for all business groups, environments, and applications. The maximum number of Mule flows within a day or month is identified based on the peak-hour usage across the day or month. For the detailed breakdown, MuleSoft shows the peak hour usage per business group, environment, and application. In a usage report, flow counts are calculated by multiplying the number of flows in an app by the number of workers (CloudHub) or replicas (CloudHub 2.0 and Runtime Fabric). #### Mule Flow Scenarios That Count Toward Your Anypoint Platform Package Allotment These Mule flows count toward your allotment: - Flows that contain a [Mule event source](https://docs.mulesoft.com/mule-runtime/latest/about-mule-event) - [Flows generated by APIkit](https://docs.mulesoft.com/apikit/latest/) that process API requests Mule flows are charged only when the application containing the Mule flow is deployed and running. #### Mule Flow with an Event Source This Mule flow contains an event source as the first element. In this case, the `listener` counts towards your allotment. ```xml ``` #### Examples of Event Sources
ConnectorSource

aggregators

aggregator-listener

amqp

listener

apikit-odata

request-entity-collection-listener

request-entity-listener

as2-mule4

as2-listener

as2-mdn-listener

non-repudiation-listener

azure-service-bus-messaging

message-listener

core

scheduler

db

listener

email

listener-imap

listener-pop3

file

listener

ftp

listener

ftps

listener

google-sheets

new-row-listener

new-spreadsheet-listener

updated-row-listener

http

listener

ibm-mq

listener

jms

listener

kafka

batch-message-listener

message-listener

mllp

mllp-listener

netsuite

deleted-object-listener

modified-object-listener

modified-record-listener

new-record-listener

pubsub

message-listener

salesforce

deleted-object-listener

modified-object-listener

new-object-listener

replay-channel-listener

replay-topic-listener

subscribe-channel-listener

subscribe-topic-listener

sap

document-listener

function-listener

servicebus

listener

sftp

listener

sockets

listener

solace

queue-listener

topic-listener

sqs

receive-messages

receivemessages

stripe

citizen-on-new-charge-listener

on-new-charge-listener

on-new-event-listener

vm

listener

websocket

inbound-listener

outbound-listener

#### Mule Flows Generated by APIkit and Used for Routing APIkit Requests APIkit is a tool that simplifies API implementation by automatically generating a minimal set of Mule flows based on the API specification. Each APIkit router endpoint counts as a distinct Mule flow. These Mule flows don’t have an event source and are used to HTTP requests for a particular API method and path. This flow routes APIkit requests and handles the GET request in the `/reservation` path: ```xml ``` #### Mule Flows That Don’t Count Against Your Anypoint Platform Package Allotment Mule flows that don’t have an event source and aren’t used for routing APIkit requests aren’t charged against your Anypoint Platform package allotment. These Mule flows are primarily used to modularize code. For example: ```xml 2.a - Flow with only a logger component ``` ### Total Mule Messages A Mule message is the data (the payload and its attributes) that passes through one or more Mule flows in an application. A Mule message is part of a Mule event, which is generated when the event source within a Mule flow is triggered. For example, a Mule event that consists of a Mule message is created when an HTTP Listener receives a request or each time the Scheduler component triggers an execution of the Mule flow. Mule message processors in a Mule flow (such as core components, file read operations, or the HTTP request operations) can then retrieve, set, and process Mule message data that resides in the Mule event according to their configurations. A Mule message is immutable, so every change to a Mule message results in the creation of a new instance. Each processor in a flow that receives a Mule message returns a new Mule message that consists of a message payload (the body of the message) and message attributes (metadata associated with the message). #### Mule Message Scenarios That Count Toward Your Anypoint Platform Package Allotment When an event source within a flow of a Mule application is triggered, the event source such as HTTP Listener or Scheduler, generates a Mule event that encapsulates a Mule message. The Mule message generated by the event source counts toward your Anypoint Platform package allotment. Any new instances of that message created during the processing of the original message as it moves through other processors in connected Mule flows, don’t count toward your Anypoint Platform package allotment. ### Total Data Throughput Data throughput is all of the network I/O bytes produced by the infrastructure for the Mule runtime server that runs a Mule application. This includes the data that the application produces to execute its business logic, as well as internal operational network traffic such as logs, health checks, and monitoring traffic. For example, data throughput includes inserting a record into a database and the network traffic associated with the app infrastructure, such as log forwarding, control plane connection, and monitoring metrics transfer. ## Object Store Usage Object Store v2 usage reports show this information in tables and cards: Business Group Business group that owns the resources where the app with the object store is deployed Environment Environment within the business group where the app with the object store is deployed Region id Region where the app with the object store is deployed Store Name of the object store associated with the API requests Effective API requests API requests along with the payload size and number of keys returned, used to calculate units against the quota Total Effective API requests Sum of effective API requests that return a 2xx (success) response across all object stores in the organization ## Runtime Fabric Usage Metrics The usage dashboard for Runtime Fabric lets you track, monitor, and govern core usage in hybrid environments and provides detailed metrics and analysis for Runtime Fabric instances and application deployments. You can see your cluster capacity metrics refined by business group. To see CPU limit aggregates at the business group level, [export the usage report as a CSV](https://docs.mulesoft.com/general/usage-reports#export-usage-reports). The CPU limit is shown at the application level on the usage dashboard, along with the associated business groups, which helps you identify which applications use the most CPU, so you can adjust your application configurations if needed. The dashboard helps you understand your usage and associated pricing by letting you compare cores and flows consumed by each application side-by-side. You can visualize core and flows consumed by each application alongside each other. Export the usage report to a CSV file to visualize cores and flows consumed by each app and drill down per environment ID and business group. If you’re using the cluster capacity metric for billing, this translation from core usage to flow usage enables you to make the necessary changes to applications so you can transition to usage-based pricing iteratively, which gives you a more flexible pricing model that scales with your integration needs and isn’t tied to your infrastructure. ### Mule Version Requirements for Flow Metrics Alongside the cluster capacity and CPU limit, you can also view other usage metrics (such as flow, messages, and data throughput). Ensure that the Mule applications are using the compliant [Supported Mule Runtime Versions](https://docs.mulesoft.com/general/usage-reports#supported-mule-runtime-versions). ### Runtime Fabric Agent Version and Configuration Requirements If you are using the cluster capacity metric for tracking, additional configuration requirements apply. These requirements don’t apply for accurate tracking of the CPU limit metric. - The Runtime Fabric agent must be version 2.7.0 or later. For more information, see [Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index). - If you are using a Helm-based Runtime Fabric installation, ensure that the `NODE_WATCHER` parameter is enabled. For more information about enabling `NODE_WATCHER`, see [Optional Parameters](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#optional-parameters). These configurations only apply to the Runtime Fabric agent and have no impact on applications. You don’t need to take any action on applications (redeployment or restarts) for tracking the cluster capacity and CPU limit metrics. ### Runtime Fabric Compliance Tracking With Usage Metrics You must adjust your clusters and application configurations for accurate usage-metric measurement. You can still use the CPU limit metric or cluster capacity metric at the root organization level for contract governance depending on your use case. These recommendations can help you accurately measure metrics:
CPU LimitCluster Capacity

  • Each application requires variable CPU allocation depending on its workload requirements. Use Anypoint Monitoring to analyze the CPU usage of your application during development to identify the right CPU limit and CPU reserve configurations.

  • Runtime Manager sets the CPU limit configuration to the available cluster capacity of the underlying Runtime Fabric instance by default, which can result in a higher CPU limit usage reported for applications if the CPU limit configuration isn’t explicitly modified during deployment. For an accurate CPU limit metric, ensure that the application’s CPU limit configurations are updated with the appropriate values based on the app’s performance.

  • You can install Runtime Fabric instances in a shared Kubernetes cluster, with both namespace isolation and node isolation for applications and Runtime Fabric core service workloads. These isolations aren’t reflected by the cluster capacity metric captured from the Kubelet server. To use this metric for compliance, use a dedicated cluster for Runtime Fabric instances for accurate measurements.

  • If a cluster is reconfigured with hyper-threading, virtualization of compute cores, or has system nodes for advanced cluster management, MuleSoft can’t account for the usage impact of these configurations on the cluster capacity metric. If you must have these configurations and use the cluster-capacity metric, contact your account team for accurate compliance audits.

For more information, see [MuleSoft License Compliance](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#license-compliance). ### Maximum CPU Limit in Production You can drill down and track CPU limit based usage per application ID and group them using this metadata: - Runtime Fabric cluster name Tracks whether the underlying cluster has enough capacity to scale. - Business group Shows usage per business group. - Root organization Monitor core usage to stay under the total entitlement. The cluster-capacity metric is available only at the root organization level. The maximum CPU limit in production is the maximum amount of CPU an app can use when deployed and running in the production runtime plane. The CPU amount is shared on the worker node. Each member of a set of workers for the same app can have a different value for the CPU limit. Autoscale policies, if implemented, can execute every 30 minutes, which can impact the worker or replica count and CPU limit of an app deployment. Data is captured every hour but the max metric is tracked on a daily and monthly basis as shown in this example. ### Example Here is an example with two apps: App1 has a CPU limit of one each and a worker count range of 1 - 3. App2 has a CPU limit of one each and a worker count range of 2 - 5. Data captured at 00:00 minutes: - App1: sum(1,1,1) = 3 - App2: sum(1,1,1,1,1) = 5 - Max metric captured = 8 CPU limit aggregated Redeployment of App1 with a CPU limit of 2 and worker range of 1 - 6 at 00:45 minutes: - App1: sum(1,1,1,2,2,2) = 9 - App2: sum(1,1,1,1,1) = 5 Time 01:00 min: - App1: sum(2,2,2,2,2,2) = 12 - App2: sum(1,1,1,1,1) = 5 - Max metric captured = 17 CPU limit aggregated - For the root organization in a given hour (not reported on the usage dashboard): Max concurrent limit CPU = 17 - For the root organization in a given day: Max concurrent limit CPU = 17 - For the root organization in a given month: Max concurrent limit CPU = 17 App2 auto scales down to three workers after 02:00 min: - App1: sum(2,2,2,2,2,2) = 12 - App2: sum(1,1,1) = 3 - Max metric = 15 CPU limit aggregate - For the root organization in a given hour (not reported on the usage dashboard): Max concurrent limit CPU = 15 - For the root organization in a given day: Max concurrent limit CPU = 17 - For the root organization in a given month: Max concurrent limit CPU = 17 ### Maximum CPU Limit in Preproduction The maximum CPU limit in preproduction (sandbox) is the maximum amount of CPU an app can use when deployed and running in preproduction. You can drill down and track CPU limit-based usage per application ID and group them using metadata, including: - Runtime Fabric cluster name Tracks whether the underlying cluster has enough capacity to scale. - Business group Shows usage per business group. - Root organization Monitor core usage to stay under the total entitlement. The cluster capacity metric is available only at the root organization level. Data is captured every hour, but the max metric is tracked daily and monthly as shown in this [Example](#example). When an application is moved from a preproduction to a production environment, the CPU limit configuration for that application is accounted for in the daily max meter of both preproduction and production environments. ### Maximum Cluster Capacity in Production Your maximum cluster capacity depends on your cluster configuration. Data is captured every hour, but the max metric is tracked daily and monthly as shown in this [Example](#example). Note that the CPU capacity of a single node is derived from the `Allocatable:cpu:` field when you describe the node. The total cluster CPU capacity is the sum of all these `Allocatable:cpu:` values in millicores from the worker nodes. These worker nodes are those that don’t have these labels `node-role.kubernetes.io/master`, `node-role.kubernetes.io/control-plane`, `node-role.kubernetes.io/ingress`, or `rtf.mulesoft.com/ingress`. See [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-k8s-practices). ### Maximum Cluster Capacity in Preproduction Your maximum cluster capacity depends on your cluster configuration. Data is captured every hour, but the max metric is tracked daily and monthly as shown in this [Example](#example). Note that the CPU capacity of a single node is derived from the `Allocatable:cpu:` field when you describe the node. The total cluster CPU capacity is the sum of all these `Allocatable:cpu:` values in millicores from the worker nodes. These worker nodes are those that don’t have these labels `node-role.kubernetes.io/master`, `node-role.kubernetes.io/control-plane`, `node-role.kubernetes.io/ingress`, or `rtf.mulesoft.com/ingress`. See [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-k8s-practices). ### Exclude Nodes From Runtime Fabric Cluster Capacity For nodes not intended to run Mule apps, exclude the nodes from your Runtime Fabric cluster’s capacity report by following these steps: 1. Apply the label `rtf.mulesoft.com/non-worker` to the node. This prevents further Mule apps to be scheduled on that node. 2. Make sure that no Mule apps are currently running on the node. The node is excluded from the capacity report if no Mule apps are detected. 3. Make sure the Runtime Fabric agent version is 2.10.0 or higher. > [!NOTE] Use a dedicated cluster for Runtime Fabric instances for accurate measurements ## See Also - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) --- product: Getting Started keywords: mulesoft documentation, ai tools, llms.txt, llms-full.txt, ai integration, mulesoft docs, large language models --- # Use MuleSoft Documentation with AI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft documentation is optimized for AI. Whether you’re a human pasting context into an LLM or an AI agent ingesting documentation autonomously, our content is structured to save tokens, stay grounded, and maximize technical accuracy. ## Page Options Every page of MuleSoft documentation includes a dropdown menu for AI consumption. ![Dropdown menu with options Copy page URL, Copy page content, and Download page content for AI use](/mulesoft/current/en-us/general/_images/ai-context-menu.png) Use these options to quickly grab clean text or jump straight into your workflow: - **Copy as Markdown**: Copies the Markdown version of the page to your clipboard to streamline your prompt engineering. - **View as Markdown**: Opens the Markdown version of the page in a new tab for sharing or inspecting. - **View on GitHub**: Opens the page’s source on GitHub to review, suggest changes, or log issues. - **View llms.txt**: Opens the sitewide `llms.txt` index file. See [llms.txt and llms-full.txt](#llms-txt). - **Open in ChatGPT / Claude / Perplexity**: Opens a conversation with the current page as context so the LLM can answer your questions instantly. ## llms.txt and llms-full.txt MuleSoft documentation publishes `llms.txt` and `llms-full.txt` index files, which are machine-readable Markdown catalogs that let AI tools and RAG pipelines cleanly discover, search, or bulk-ingest our documentation without crawling raw HTML. For example, you can point an AI coding assistant to the sitewide or product `llms.txt` URL for real-time integration context, or import the `llms-full.txt` file into a vector database to ground AI agents. Depending on your data scope, you can target three types of endpoints: - Sitewide `llms.txt` Spans the entire MuleSoft documentation library and links to every product’s `llms.txt`. - URL: [docs.mulesoft.com/llms.txt](https://docs.mulesoft.com/llms.txt) - Product `llms.txt` Narrows to a single product and links to each of that product’s pages. - URL pattern: `docs.mulesoft.com/[product-name]/llms.txt` - Example: [docs.mulesoft.com/a2a-connector/llms.txt](https://docs.mulesoft.com/a2a-connector/llms.txt) - Product `llms-full.txt` Consolidates a single product’s full documentation into one file. - URL pattern: `docs.mulesoft.com/[product-name]/llms-full.txt` - Example: [docs.mulesoft.com/a2a-connector/llms-full.txt](https://docs.mulesoft.com/a2a-connector/llms-full.txt) --- product: Getting Started keywords: external vaults, secrets manager, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, authentication method, model proxy, anypoint platform --- # Using Credentials Stored in External Vaults > For the full documentation index, see: https://docs.mulesoft.com/llms.txt An external vault connects your third-party secrets manager to the enhanced experience. API keys and other credentials stay in that vault. MuleSoft stores only metadata (zero-copy), such as secret names and paths, and reads the value from the vault when a model proxy or other service needs the value. MuleSoft never stores, displays, or logs secret values. A vault isn’t a scanner. Scanners discover services and add them to Portfolio catalogs. A vault only syncs secret metadata, so it doesn’t add items to Portfolio. > [!NOTE] Automate vault onboarding and management using the MuleSoft MCP Platform Server. For > details, see [onboard\_vault](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#onboard-vault) > and related Secrets Manager tools in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin To register an external vault, you need: - An Anypoint Platform account. - Access to the external secrets manager you want to connect, including its endpoint URL and credentials. - You can’t change a vault’s name after you create it. - These Anypoint Platform permissions: - Exchange: Exchange Administrator - Exchange: Exchange Contributor - API Manager: API Creator - API Manager: Manage Policies - Secrets Manager: View Vault Integrations - Secrets Manager: Manage Vault Integrations For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). For a list of vault credentials and setup fields, see [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference). ## Authentication Methods When you register a vault, you select an **Authentication Method**. Select the method that your secrets manager already uses for applications. The method that you select at registration is the method that this connection uses. ### AWS Secrets Manager Authentication **AWS Static** MuleSoft authenticates with a long-lived **Access Key ID** and **Secret Access Key**. Choose **AWS Static** when that access key is allowed to read Secrets Manager directly. **AWS Assume Role** MuleSoft authenticates with an access key ID and secret access key, then uses a role ARN so the connection runs as that role instead of as the access key’s identity. Choose **AWS Assume Role** when a role controls access to secrets, such as a role in another AWS account or a role that has only Secrets Manager permissions. **External ID** is a value that you set on the role so that only this MuleSoft connection can assume the role. ### Azure Key Vault Authentication Both Azure methods authenticate as a Microsoft Entra app registration (a service principal) that you create for MuleSoft. The difference is how that app proves its identity. **Azure Sp Secret** (Microsoft Entra Service Principal Secret) The app proves its identity with a client secret, which is a string such as a password. Choose **Azure Sp Secret** when your directory issues client secrets for apps. **Azure Sp Certificate** (Microsoft Entra Service Principal Certificate) The app proves its identity with a client certificate and private key in PEM format, instead of a secret. Choose **Azure Sp Certificate** when your company requires certificate-based authentication for apps. ### HashiCorp Vault Authentication **HashiCorp AppRole** AppRole is the only authentication method that HashiCorp Vault supports. Applications log in to HashiCorp Vault with a role ID that identifies the role and a secret ID that is the credential. Provide a TLS CA certificate in PEM format when your HashiCorp Vault server uses a certificate that MuleSoft doesn’t trust by default. ## Register AWS Secrets Manager Choose **AWS Static** or **AWS Assume Role** to match how your applications already reach Secrets Manager. See [AWS Secrets Manager Authentication](#aws-secrets-manager-authentication). 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. From **Platform** > **Providers**, select Amazon. 3. Select **Add Provider**, then select **AWS Secrets Manager**. 4. Select the Anypoint environment whose services will use this vault. 5. Select the authentication method, then provide the identity that method uses: - **AWS Static**: an access key ID and secret access key that can read Secrets Manager directly. - **AWS Assume Role**: an access key that can call STS AssumeRole, the ARN of the role that is allowed to read secrets, and the external ID that you set on that role so only this connection can assume it. 6. Enter the Secrets Manager endpoint as the **Vault URL**, for example `https://secretsmanager.us-east-1.amazonaws.com`. Set the AWS region to match that endpoint. 7. To sync only secrets whose names start with a given string, set a secret name prefix. Leave it empty to discover every secret these credentials can read. 8. (Optional) Select **Test Connection** to verify the connection before you save it. The test runs a live handshake between the MuleSoft control plane and your vault, so it can take a moment. 9. Select **Connect**. ## Register Azure Key Vault Both methods sign in as a Microsoft Entra app registration (a service principal). Choose **Azure Sp Secret** or **Azure Sp Certificate** for how that app proves its identity. See [Azure Key Vault Authentication](#azure-key-vault-authentication). 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. Select **Platform** > **Providers**, then select **Microsoft**. 3. Select **Add Provider**, then select **Azure Key Vault**. 4. Select the Anypoint environment whose services will use this vault. 5. Select the authentication method, then provide the proof that method uses: - **Azure Sp Secret**: the client secret issued for the app registration. - **Azure Sp Certificate**: the client certificate and private key, both in PEM format. 6. Enter the Key Vault URL, for example `https://my-vault.vault.azure.net`. Identify the app with its client ID and your Microsoft Entra directory with the tenant ID. 7. (Optional) Select **Test Connection** to verify the connection before you save it. 8. Select **Connect**. ## Register HashiCorp Vault HashiCorp Vault authenticates with AppRole only. The role ID identifies the role. The secret ID is the credential. See [HashiCorp Vault Authentication](#hashicorp-vault-authentication). 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. From **Platform** > **Providers**, select HashiCorp. 3. Select the Anypoint environment whose services will use this vault. 4. Select **HashiCorp AppRole**. 5. Enter the Vault address, for example `https://vault.example.com:8200`. 6. Enter the role ID and secret ID. If your Vault server uses a certificate that MuleSoft doesn’t trust by default, also provide a TLS CA certificate in PEM format. 7. Under **Connection Configuration**, set the values for: - **KV Version**: for a `kv` engine, which KV API that engine uses in Vault. Version 1 and version 2 list and read secrets on different paths, so copy the version that is enabled on the engine. The wrong version makes discovery fail. Version 2 also keeps secret history in Vault. MuleSoft still syncs names and reads the current value. - **Engine Type**: `kv` or `pki`. Use `kv` when this mount stores static secrets such as API keys. Use `pki` when this mount is Vault’s certificate engine and the credentials you need are certificates. - **Mount**: the path where that engine is enabled in Vault, for example `secret` or `pki`. Ask your Vault admin for this value. Don’t put folders that live under the engine here. - **Path**: the folder under the mount to discover, for example `prod/mulesoft`. Use this to limit what MuleSoft imports from that engine. For HashiCorp Vault Enterprise, set **Namespace** to the namespace that contains this engine. A namespace is a separate Vault environment on the same cluster. Open-source Vault has no namespaces, so leave this empty. 8. (Optional) Select **Test Connection** to verify the connection before you save it. 9. Select **Connect**. ## Review Secrets and Connection Health After you connect, the vault detail page opens. Confirm that MuleSoft can reach the vault and that secret metadata appeared. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. From **Platform** > **Providers**, open the vault. The header shows the creation date and the last scan time. 3. Select **Overview** to review sync activity. - A health check confirms that MuleSoft can still reach the vault. It doesn’t add, remove, or update secrets. - A metadata sync records secrets that are added, removed, or updated. 4. To refresh secret metadata after secrets are added, removed, or renamed in the vault, select **Sync Now**. The sync runs in the background. Each run appears in **Sync Activity**. 5. Select **Secrets** to review the secret names and paths that MuleSoft discovered. MuleSoft doesn’t show the secret values. **Used By** shows which MuleSoft resources reference a secret. A dash means that no resource in the enhanced experience references the secret yet. Search by name when the list is long. To change credentials or delete the vault, use **Settings**. See [Edit or Delete a Vault](#edit-or-delete-a-vault). ## Edit or Delete a Vault To update connection details or rotate a credential: 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. From **Platform** > **Providers**, open the vault and select **Settings**. The tab shows the provider, Anypoint environment, and authentication method. 3. Select **Edit Settings**, make your changes, and select **Save**. 4. Optionally, select **Test Connection** before you save. 5. To remove the vault, select **Delete Integration** and confirm. Deleting the integration removes its stored credentials and discovered secrets. ## Use a Vault Secret in a Model Proxy When you configure authentication for a model proxy, select a secret in your registered vault instead of pasting a key into MuleSoft. The proxy resolves the value from the vault at runtime. 1. Log in to the MuleSoft enhanced experience with an account that has the required permissions. 2. From **Portfolio** > **Model Proxies**, select **Add Model Proxy**. 3. In **Authentication**, select **From Vault**. 4. From **Credential from Vault**, select the secret. 5. Select **Save**. For model proxy setup, see [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy). ## See Also - [Securing Services in Your Portfolio](https://docs.mulesoft.com/general/exp-securing-services) - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Scanner Prerequisites by Provider](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference) - [Creating and Managing Model Proxies](https://docs.mulesoft.com/general/model-proxy) --- product: Getting Started keywords: mulesoft agent, ai assistant, anypoint platform, integration automation, ask questions, ai-powered assistant --- # Using the MuleSoft Agent > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The enhanced experience includes an AI assistant called MuleSoft Agent that helps you navigate, search, and manage your portfolio through natural language conversations. Access the assistant from any page to get guidance, perform tasks, and discover features without navigating through menus. ## Before You Begin > [!IMPORTANT] The MuleSoft Agent is available on request. To get access, contact your account > executive or MuleSoft representative to request enablement. Before getting started, make sure you have: - An Anypoint Platform account with access to the enhanced experience. - Generative AI enabled in your Anypoint Platform and Salesforce organizations by your administrator. See [Enabling or Disabling Generative AI for Anypoint Platform](https://docs.mulesoft.com/access-management/enabling-generative-ai). - The **MuleSoft Agent AI User** permission assigned to each user who needs to send prompts to the agent. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). To assign the **MuleSoft Agent AI User** permission across business groups: 1. Log in to Anypoint Platform and open **Access Management**. 2. Select the business group where you want to assign the permission. 3. Find the user and assign the **MuleSoft Agent AI User** permission. 4. Repeat for each business group that requires access. ## MuleSoft Agent Capabilities The AI assistant provides context-aware help based on where you are in the enhanced experience: Portfolio Management - Search for agents, APIs, MCP servers, Model proxies, and gateways. - Get details about specific services. - Find services by capability or description. - Register new services with guided workflows. - Create and manage instances. Governance - Create and manage governance strategies. - Review conformance reports. - Apply policies to services and instances. - Check compliance status. - Configure automated policies. Monitoring and Observability - Review performance metrics for services. - Analyze error rates and latency trends. - Check service health and availability. - Set up alerts and notifications. - View monitoring dashboards. Cost Management - Review token usage and spending. - Identify cost optimization opportunities. - Analyze usage patterns. - Get recommendations for reducing costs. - Apply cost control policies. Navigation and Discovery - Navigate to specific pages and catalogs. - Find features and capabilities. - Get step-by-step guidance for tasks. - Learn about enhanced experience features. Platform Configuration - Connect and manage providers. - Configure scanners for service discovery. - Set up integrations (Slack, Claude Desktop). - Manage business group settings. Customer Support - Search official MuleSoft documentation for product and configuration guidance. - Look up known issues, root causes, and available workarounds. - Find relevant Knowledge Articles for troubleshooting and error messages. - Get help from a human agent when the assistant can’t answer your question or when you ask to escalate. Human Agent Escalation The assistant hands off to a human support agent when it can’t answer your question, or when you ask directly—for example, "talk to support," "I need to speak to someone," or "escalate this." When a handoff happens, the assistant gives you a summary of your conversation to copy into a support case, along with a link to open one at [help.salesforce.com](https://help.salesforce.com). The assistant doesn’t create a support case for you automatically—you still submit it yourself. This capability is currently available only through the AI assistant panel in the enhanced experience. ## Access the MuleSoft Agent Once enabled as described in [Before You Begin](#before-you-begin), open the assistant from the panel available on any page in the enhanced experience. The MuleSoft Agent uses your Access Management permissions and can only perform actions you’re authorized to do. Tasks like creating governance strategies or managing services require specific permissions. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Ask Questions Ask the AI assistant questions in natural language. The assistant understands context from the page you’re on and provides relevant answers. ### Example Portfolio Questions ```text Show me all agents in production ``` ```text Which APIs have governance violations? ``` ```text Find MCP servers that expose payment tools ``` ```text What instances are deployed to the staging gateway? ``` ### Example Governance Questions ```text What governance strategies are active? ``` ```text How do I create a new governance strategy? ``` ```text Show me all services with security violations ``` ```text Which policies are applied to my API instance? ``` ### Example Monitoring Questions ```text What's the error rate for my agent today? ``` ```text Show me latency trends for the last week ``` ```text Which services have the highest token usage? ``` ```text Are there any service health alerts? ``` ### Example Cost Questions ```text What's my total token spend this month? ``` ```text Which agents are using the most tokens? ``` ```text How can I reduce costs for my Model proxies? ``` ```text Show me cost trends over time ``` ### Example Navigation Questions ```text How do I register a new API? ``` ```text Show me the governance strategies page ``` ```text Take me to monitoring for my agent ``` ```text Where do I configure scanners? ``` ### Example Customer Support Questions ```text How do I configure OAuth 2.0 in Mule 4? ``` ```text Are there known issues with CloudHub 2.0 deployments? ``` ```text What does a MULE:CONNECTIVITY error mean? ``` ```text Can I talk to a support agent? ``` ## Use Suggestions After the AI assistant responds, it might show suggestion chips with related follow-up actions you can take. If you don’t see any suggestions, ask the assistant to suggest actions. 1. Review the suggestion chips below the assistant’s response. 2. Select a chip to ask that follow-up question or perform that action. 3. The assistant executes the suggestion and shows the results. Suggestions are context-aware and change based on: - The page you’re currently viewing - The question you just asked - The services and features available to you - Common next steps for your current task > [!TIP] Suggestions help you discover related capabilities and complete multistep workflows more > efficiently. ## Perform Actions with Confirmation The AI assistant can perform actions on your behalf with your confirmation. When the assistant proposes an action that modifies data or navigates to a new page, it shows a confirmation prompt. ### Navigation Actions When the assistant wants to navigate you to a different page: 1. The assistant shows a confirmation banner with the navigation target. 2. Review where the assistant wants to take you. 3. Confirm to proceed. ### Data Modification Actions When the assistant wants to create, update, or delete services or configurations: 1. The assistant shows a confirmation banner with details of the proposed action. 2. Review what the assistant will do. 3. Select **Confirm** to execute the action, or **Cancel** to reject it. If you confirm, the assistant performs the action and shows the results. Examples of actions that require confirmation: - Creating new services (agents, APIs, MCP servers) - Applying or removing policies - Creating or modifying governance strategies - Running or deleting scanners - Creating or deleting alerts - Updating service configurations > [!IMPORTANT] Always review confirmation prompts carefully before approving actions. This tool uses > generative AI, which can produce inaccurate or harmful responses and actions. ### Form Assistance When you have a form open (such as creating an instance or configuring a policy), the assistant can help fill in fields: 1. Ask the assistant for help with the form (for example, "Fill in the instance details for my production API"). 2. The assistant proposes changes to specific form fields. A confirmation banner shows which fields will be updated and with what values. 3. Review the proposed changes. 4. Select **Confirm** to apply the changes to the form, or **Cancel** to reject them. If you confirm, the form fields update, but the form itself isn’t submitted—you still need to review and submit the form manually. ## Get Guided Workflows Ask the AI assistant to guide you through complex tasks: ```text How do I create a governance strategy for my APIs? ``` ```text Walk me through registering a new agent ``` ```text Help me set up monitoring for my MCP server ``` ```text Guide me through connecting a provider ``` The assistant provides step-by-step instructions and can perform actions at each step with your confirmation. ## Best Practices Follow these practices for effective interactions with the AI assistant: Be Specific Instead of "Show me APIs," try "Show me production APIs with governance violations." Provide Context If asking about a specific service, mention its name: "What’s the error rate for Payment Processing API?" Use Follow-Up Questions Build on previous responses with follow-up questions like "Show me more details" or "Apply a rate limit policy to that instance." Review Confirmations Always review confirmation prompts carefully before approving actions. Use Suggestions Explore the suggestion chips to discover related capabilities and next steps. Ask for Help If you’re unsure how to do something, ask: "How do I…​" or "Show me how to…​" Correct Mistakes If the assistant misunderstands, clarify: "No, I meant the staging environment, not production." ## Limitations Be aware of these limitations when using the AI assistant: - The assistant can’t perform actions outside the enhanced experience or access external systems directly. - Some actions require specific permissions. If you don’t have permission, the assistant informs you but can’t grant permissions. - The assistant works with data available in the enhanced experience. For services not yet registered in your portfolio, the assistant has limited information. - Complex multistep workflows may require you to confirm each step individually. - The assistant can’t modify Access Management permissions or subscription tiers. ## Privacy and Security The AI assistant operates within your organization’s security and privacy controls: - All interactions respect your Access Management permissions. - The assistant only accesses data you have permission to view. - Conversations are associated with your user session and aren’t shared with other users. - The assistant doesn’t store sensitive data like API keys or credentials in conversation history. - All actions performed by the assistant are logged and auditable. ## See Also - [Troubleshoot the MuleSoft Agent](https://docs.mulesoft.com/general/exp-ai-assistant-troubleshoot) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [View Your Portfolio Overview](https://docs.mulesoft.com/general/exp-portfolio-overview) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [Working with Governance Strategies](https://docs.mulesoft.com/general/exp-governance-work-with-strategies) --- product: Getting Started keywords: vcore usage, cloudhub vcore, runtime fabric usage, usage reports, pricing rates --- # vCore Pricing Usage and Rates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt vCore pricing tracks core-based consumption for Mule Runtime and related API capabilities. ## Subscription Plan The available usage types depend on your Anypoint pricing plan.
Subscription PlanAvailable Usage Types

Integration Gold Edition, Integration Platinum Edition, Integration Titanium Edition

Production Cores/vCores, Pre-production Cores/vCores, API Manager Pre-Production, API Manager Production, APIs Under Governance, API calls through Omni/Flex Gateway, Anypoint MQ API request, Object Store API request

## Usage Types
ProductMetric DescriptionUsage Details

Mule Runtime

vCore Usage in Production: Virtual processing capacity allocated to run Mule applications and APIs in Production environments.

Calculated based on the peak allocated virtual cores assigned to CH and CH2.0’s active application workers in Production.

vCore Usage in Pre-Production: Virtual processing capacity allocated to run Mule applications and APIs in non-production environments (for example, Sandbox, QA, Staging, and Development).

Calculated based on the peak allocated virtual cores assigned to CH and CH2.0’s active application workers in non-production environments.

Cluster capacity: A set of workers or nodes that act as a single deployment target for a given Runtime Fabric instance.

Allocatable CPU capacity of each node within the Runtime Fabric instance.

CPU Limit (Millicores): Maximum amount of CPU resources a worker node in Runtime Fabric can use.

The amount of CPU usage is aggregated over a specific period of time, such as an hour or a day. The CPU limit configuration of each application is summarized at each environment ID, then at each business group, and then at the root organization ID for preproduction (sandbox) and production environment types separately.

CPU Reserve (Millicores): A guaranteed minimum amount of CPU resources allocated to a worker node in the Runtime Fabric instance.

CPU reserve is aggregated by calculating the total amount of CPU resources allocated by the user to reserve for applications within the cluster or Runtime Fabric instance.

API Manager

API instances: API instances in production, preproduction, and unclassified APIs (not associated with an environment) that are managed by API Manager after they are created using add, promote, or import options.

API instances remain under management until they are deleted. Instances of API Manager are aggregated using a Max Concurrent model with three separate metrics for production, preproduction, and unclassified (APIs that aren’t associated with an environment).

API Governance

API under Governance: APIs identified by the selection criteria of at least one of the governance profiles.

If an API is governed, all versions of that API are considered one governed API. Instances of API Governance are aggregated using a Max Concurrent model. The usage for a month is the highest number of APIs governed in a single given hour during a month.

Omni Gateway

Omni Gateway API call: Any access request received by Omni Gateway regardless of whether the response to the request is successful.

Omni Gateway requests are aggregated as a total of all requests during a month.

LLM Proxy

Prompt tokens: Number of tokens an LLM Proxy in the prompts an LLM Proxy sends to a specific LLM Model.

These tokens are the sum of all prompt tokens a specific LLM Proxy sends to a specific LLM Model during a month. A prompt sent to an LLM Proxy are considered an Omni Gateway API call and count towards the Omni Gateway API call metric.

Completion tokens: Number of tokens in the responses that an LLM Proxy receives from a specific LLM Model.

These tokens are the sum of all response tokens a specific LLM Proxy receives from a specific LLM Model during a month.

Total tokens: Total number of tokens used in interactions between an LLM Proxy and a specific LLM Model.

Some LLM Providers, such as Gemini, use thinking tokens. Total tokens are the sum of prompt tokens, completion tokens, and thinking tokens if applicable.

Anypoint MQ

Anypoint MQ API request: A request made to retrieve one or more messages from the Anypoint MQ APIs.

Anypoint MQ uses API requests to calculate billing. Anypoint MQ API requests are calculated in the aggregate across all environments (including production, pre-production, sandbox, and design). Anypoint MQ API requests are available via API and aggregated on usage reports.

Object Store

Object Store API request: A request made to retrieve one or more messages from the Object Store APIs as further defined in the Object Store documentation.

Each Object Store API request includes up to 100 KB of data. Object Store API requests over 100 KB count as multiple requests with no fractional units. Object Store API requests are available via API and aggregated on usage reports.

DataGraph

DataGraph orchestration: An API request made by Anypoint DataGraph to the source APIs to get data for the GraphQL API request made to Anypoint DataGraph.

Orchestrations are not currently aggregated on usage reports.

## CloudHub vCore Usage MuleSoft samples vCore usage every hour and uses the peak hourly value to calculate the daily and monthly maximum: - **Hourly**: Peak vCore consumption captured each hour - **Daily**: Highest hourly peak within the day - **Monthly**: Highest hourly peak within the month MuleSoft calculates production and preproduction vCore usage separately by using this same peak-rollup model. For CloudHub 2.0 applications with HPA enabled, an application can scale beyond its guaranteed base allocation, so **vCore Peak** can exceed **vCore Min** during scaling events. Conversely, **vCore Min** can be higher than **vCore Peak** when the guaranteed base allocation exceeds actual consumption during the selected time period. HPA is available to customers on the new pricing and packaging model. ## Mule Runtime vCore Usage Cards These cards summarize peak CloudHub vCore usage in production and preproduction for the selected reporting period. ### Maximum CloudHub vCore Usage in Production This card shows the highest peak cloud vCore consumption across CloudHub (CH1) and CloudHub 2.0 (CH2) applications in production for the selected month. It includes the UTC date and time when the peak occurred, which reflects a true peak in consumption rather than an average. ### Maximum CloudHub vCore Usage in Preproduction This card shows the highest peak cloud vCore consumption across CloudHub (CH1) and CloudHub 2.0 (CH2) applications in preproduction for the selected month. It includes the UTC date and time when the peak occurred, which helps you accurately track and attribute usage spikes. ## See Also - [Usage Reports](https://docs.mulesoft.com/general/usage-reports) - [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) --- product: Getting Started keywords: detailed metrics, service metrics, anypoint platform, monitoring, metrics best practices, experience services, performance monitoring --- # View Detailed Metrics for Your Services > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Detailed metrics go beyond high-level status to show time series, breakdowns, and dimensions your observability stack forwards into the enhanced experience. Use them to debug incidents, validate policy changes, and compare behavior across instances or environments. Available metric time series depend on the gateway or runtime path, whether the deployment is managed through Omni Gateway, and what your organization connected under **Platform** and **Observability**. > [!NOTE] Automate detailed metrics retrieval using the MuleSoft MCP Platform Server. For details, > see > [fetch\_monitoring\_instance](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-monitoring-instance) > in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Any of these permissions: - Anypoint Monitoring: Monitoring Viewer - Anypoint Monitoring: Monitoring Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Open Detailed Views - From **Portfolio**, open a service and go to the **Monitoring** tab for charts scoped to that service or instance when the product exposes them. - From **Observability**, open dashboards or explorers your administrator pinned for the organization. If you need a metric that doesn’t appear, ask your platform team whether the integration or retention policy supports it. ## Metrics Best Practices - Baseline after changes Capture before-and-after windows when you deploy instances or change policies so you can attribute shifts. - Align with alerts Pair detailed charts with [alert notifications](https://docs.mulesoft.com/general/exp-alerts-configure-notifications) so on-call engineers go to the right place. - Respect data boundaries Some dimensions might be redacted or aggregated for privacy. Follow your organization’s data-handling standards. ## See Also - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [Configuring Notifications for Alerts](https://docs.mulesoft.com/general/exp-alerts-configure-notifications) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) --- product: Getting Started keywords: portfolio overview, anypoint platform, api management, integration monitoring, portfolio dashboard, mulesoft --- # View Your Portfolio Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use portfolio-level views to see how your agents, APIs, MCP servers, Model proxies, and gateways fit together before you drill into a single service. These summaries help you spot gaps in registration, policy coverage, and health signals. The exact layout depends on how your administrator configured your tenant and which catalogs they enabled. Navigation labels can vary by catalog, enabled features, and release. Watch this video to see how to navigate your portfolio: ![](https://play.vidyard.com/FjPDA8GLmA5wdzMV7RerT4.jpg) ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Viewer - Exchange: Exchange Contributor - Exchange: Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Access Portfolio Overview - **Home** After you log in, **Home** shows an overview of services discovered, consumed, and governed, as well as a list of scanners and actions to add a service. - **Portfolio** Browse catalogs for **Agents**, **APIs**, **MCP Servers**, **Model Proxies**, and **Gateways** in **Portfolio**. Each catalog lists the services that your team registered or imported. To find a specific service, use search and filters, and then select the service to view its details. If you don’t see an expected catalog or summary, confirm product access and permissions with your Anypoint Platform organization administrator. See [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) for more information. ## See Also - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Get Started with the Enhanced Experience](https://docs.mulesoft.com/general/exp-home-start) - [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) --- product: Getting Started keywords: providers, scanners, providers page, provider list, view providers, manage providers, anypoint platform --- # Viewing and Managing Provider Connections > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The **Providers** page shows which cloud platforms and API management systems are connected to the enhanced experience. From **Platform** > **Providers**, you can view connected providers, filter scanners by provider, and connect new providers to begin discovering services. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - Exchange Administrator permission. For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Access the Providers Page 1. Sign in to the enhanced experience through your organization’s entry point. 2. In the navigation, select **Platform** > **Providers**. The **Providers** page displays the provider list and scanner list. ### Provider List The side panel shows providers organized into two groups: Connected Providers that have active scanner connections. Each connected provider card shows the provider name, logo, number of discovered services, and number of configured scanners. Not Connected Providers available for connection but not yet configured. Select a not-connected provider to begin the scanner setup workflow. The workflow guides you through the process of connecting the provider and configuring the scanner. ### Scanners List Select **All Providers** to view all scanners across all connected providers. The main panel displays the scanner list. The scanner list shows: - **Scanner Name**: The scanner identifier and provider platform - **Services**: Count of services discovered by this scanner - **Last Scanned**: Time since the last successful scan - **Scan Trigger**: Schedule type (Scheduled, Manual, or On-Demand) ## Filter Scanners by Provider To view scanners for a specific provider, select the provider from the sidebar. The scanner list updates to show only scanners configured for that provider. ## View Scanner Details To see detailed information about a scanner, including scan history, activity log, and configuration, select the scanner name in the scanner list. The scanner detail page includes **Overview**, **Services**, and **Settings** tabs. For detailed tab behavior and scanner-type differences, see [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details). For information about managing scanners, see [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage). For Akamai-specific setup and result interpretation, see [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation). ## Connect a New Provider To add a provider connection: 1. From **Platform** > **Providers**, select a provider from the **Not Connected** section. 2. Follow the connection workflow to authenticate and configure scanner settings. The wizard walks through three steps: **Choose Provider**, **Connect to Provider**, and **Connection Setup**. For Microsoft Copilot Studio scanners, select **OAuth (Authorization Code)** and complete authorization in the Microsoft sign-in popup before you continue. For details, see [exp-scanners-add-from-providers.adoc#microsoft-copilot-studio-scanner-oauth-authorization](https://docs.mulesoft.com/general/exp-scanners-add-from-providers#microsoft-copilot-studio-scanner-oauth-authorization). For detailed scanner setup instructions, see [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers). > [!NOTE] Amazon, Microsoft, and HashiCorp also support registering an external vault instead of a > scanner. A vault syncs secret metadata rather than discovering services, so it doesn’t populate a > **Portfolio** catalog. For the vault registration flow, see > [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage). ## Akamai API Security Data in Portfolio When Akamai API Security is connected and scans have completed, security risk data appears on the detail pages of scanned APIs: - A **Security Risk** column in the **Instances** tab shows a color-coded risk level per instance: Low, Medium, High, or Critical. - An **Akamai** section in the **Conformance Report** tab shows full findings and incidents from the scan. In list and card views, the numeric value shows Akamai correlation policy coverage (applied policies compared to total required policies), while the color-coded **Security Risk** label (Low, Medium, High, or Critical) shows the severity level of correlated security findings. ## Supported Providers The enhanced experience supports connections to these providers: - Akamai - Amazon - Anthropic - Databricks - GoDaddy - Google - HashiCorp - Kong - LangChain - Microsoft - Salesforce - ServiceNow - Snowflake > [!NOTE] When scanning Kong, the enhanced experience discovers gateway-level plugin information in > addition to services. > > **Akamai API Security** is available only when your administrator has enabled the feature for your > organization. When enabled, it appears in the **Not Connected** section of the Providers sidebar. Of these providers, the API gateway providers Google (Apigee), Kong, and Microsoft (Azure API Management) support policy write. APIs discovered by a connection that has only read access to the provider 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 [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). The specific providers available depend on your organization’s enabled products and enhanced experience configuration. ## See Also - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) - [Viewing Scanner History and Settings](https://docs.mulesoft.com/general/exp-scanners-view-details) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [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) - [Using Credentials Stored in External Vaults](https://docs.mulesoft.com/general/exp-vaults-manage) --- product: Getting Started keywords: scanner detail tabs, scanner overview tab, scanner services tab, scanner settings tab, provider scanners --- # Viewing Scanner History and Settings > For the full documentation index, see: https://docs.mulesoft.com/llms.txt View details about a scanner and its scan history by selecting a configured scanner from the provider list. Scanner details show information about the provider, when it was created, last completed scan, and scan history. After you select a configured scanner, use the **Overview**, **Services**, and **Settings** tabs to review scanner state and configuration. Tab content varies by scanner type and provider capabilities. ## Open Scanner Detail Tabs 1. From **Platform** > **Providers**, open a connected provider. 2. Select a configured scanner from the scanner list. 3. Use the tabs to review scanner results and configuration. ## Overview Tab Use **Overview** to check scanner summary information, such as: - Services and instances counts. - Scan history and run status. - Last scan time and scanner health indicators. - Activity Log with a real-time timeline of scan progress events. For Akamai API Security scanners, the overview represents correlation and security enrichment activity for existing services. Akamai scanners don’t import new services. When a scan starts, the **Activity Log** appears between **Scan Details** and **Scan Results**. It’s a real-time timeline of the events a scanner run emits, such as connecting to the provider, resolving credentials, processing pages, and completing the scan. Each entry shows a timestamp, a log level (`INFO` or `DEBUG`), and a message. The log also reports the total event count. - Log detail: By default, the log includes `DEBUG` entries. Select **Hide Debug** to show only `INFO` events; select it again to show `DEBUG` events. - Audit trail: When you view scan history, the Activity Log shows which assets were added and which already existed (for example, `5 discovered, 5 added`). ## Services Tab Use **Services** to review services linked to the scanner and open service details for investigation. The tab reflects scanner-managed output for those services. For import scanners, this tab reflects discovered services imported by scan runs. For Akamai API Security scanners, it reflects existing services associated with correlated security data. ## Settings Tab Use **Settings** to review and update scanner configuration values, such as provider connection details, run schedule, and scanner metadata. You can also delete the scanner from this tab. For API gateway providers that support policy write, the scanner uses a single connection, and what you can do depends on the permissions granted to that connection’s identity on the provider. Read access enables discovery and policy read; the provider’s write scope additionally enables policy write (apply, enable, disable, and remove). Use **Settings** to review and update the connection credentials—for example, after you grant the connection the provider’s write scope. For provider-specific read and write scopes, see [Policy Write Prerequisites](https://docs.mulesoft.com/general/exp-scanners-prerequisites-reference#_policy_write_prerequisites). ## Tab Content by Scanner Type Import scanner Shows imported discovery activity in scanner tabs, including newly discovered services. Akamai API Security scanner Shows correlation and governance enrichment activity for existing services, including risk and findings signals. API gateway scanner For providers that support policy write (Azure API Management, Google Apigee, and Kong Gateway), the **Settings** tab is where you review and update the connection credentials used for policy write on discovered APIs. ## See Also - [Viewing and Managing Provider Connections](https://docs.mulesoft.com/general/exp-providers-manage) - [Adding Scanners from Providers](https://docs.mulesoft.com/general/exp-scanners-add-from-providers) - [Correlating Risk Using Akamai API Security](https://docs.mulesoft.com/general/exp-akamai-risk-correlation) - [Running and Managing Scanners](https://docs.mulesoft.com/general/exp-scanners-manage) --- product: Getting Started keywords: view service details, service detail page, anypoint exchange, exchange services, service tabs, mulesoft exchange --- # Viewing Service Details in the Portfolio > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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. > [!NOTE] Automate service lookups using the MuleSoft MCP Platform Server. For details, see > [fetch\_services](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-services) and related > Search and Discovery tools in the MuleSoft MCP Platform Server Tool Reference. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - One of these permissions: - Exchange: Exchange Viewer - Exchange: Exchange Contributor - Exchange: Exchange Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Service Detail Tabs The page is organized into tabs. The table lists tabs, what they show, and whether they appear on the detail page for each catalog type: - **Yes** means the tab appears in typical configurations. - **No** means the tab is omitted or you use another area of the experience for the same job (see the note after the table). Labels and fields inside a tab can differ by service type and release. For end-to-end portfolio tasks that reference these tabs, see [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview). tab can differ by service type and release. For end-to-end portfolio tasks that reference these tabs, see [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview).
TabWhat You SeeAPIAgentMCP ServerModel ProxyGateway

Overview

Short summary of what the service does and its specification.

Yes

Yes

Yes

Yes

Yes

Instances

Deployed instances, environments (for example production or sandbox), and gateways when that catalog type supports instances. When Akamai API Security is enabled and scan data is available for this service, the table also shows a Security Risk column with a color-coded risk level per instance (Low, Medium, High, or Critical). Risk levels are per-instance — the same API can show different risk levels across environments.

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). 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. On supported gateways, you can also manage native policies from this tab. See Applying and Managing Policies.

Yes

Yes

Yes

Yes

No

Monitoring

Runtime metrics and analytics for health and usage when the system surfaces them for the service or gateway you are viewing.

Yes

Yes

Yes

Yes

No

Conformance

Compliance score and rule-level analysis for conformance reporting where that tab is available. When Akamai API Security is enabled, the tab includes an Akamai section with a risk score overview, a findings table (endpoint-level vulnerabilities with severity, OWASP API Top-10 tags, and compliance framework tags), and an incidents table (aggregated security incidents). Select a finding to view details and see recommended remediation policies you can apply directly from this page.

Yes

Yes

Yes

No

No

> [!NOTE] > > - **Instances** tab is available on **Agents**, **MCP Servers**, and **APIs**; **Model Proxies** > and **Gateways** do not include an **Instances** tab. See > [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview). > > - **Conformance** on the detail page aligns with **Agents**, **APIs**, and **MCP Servers**; for > gateways, compliance work is framed through **Governance** and related flows at the scope the > system supports. See [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview). ## Open a Service Detail Page 1. In **Portfolio**, open the catalog for the service type (for example **APIs** or **Agents**). 2. Use the search box to find the service by name or description, or scan the list or grid. 3. 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. 1. In **Portfolio**, open **APIs** and select an API discovered by a provider scanner. 2. Open the **Policies** tab on the service detail page. 3. Review read policies imported from Amazon API Gateway, Google Apigee, Azure API Management, or Kong Gateway. 4. 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**. Reading policies is view-only. To create, edit, enable, disable, or remove policies on Anypoint and external gateway providers from this tab, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage) and [Managing Policies on Gateway Providers](https://docs.mulesoft.com/general/exp-policies-overview). ## Manage Native Policies On supported gateways, the **Policies** tab also lets you manage the native policies applied to an instance. Depending on the gateway and your permissions, you can edit, remove, or enable and disable a policy directly from this tab. Policies that are outside your instance’s scope appear in a read-only (view-only) state, without edit, remove, or enable/disable actions. Policy write actions are tracked. To confirm whether an apply, edit, enable, disable, or remove completed on the gateway, review the **Activity log** tab of the instance detail page. See [Tracking Policy Operations in the Activity Log](https://docs.mulesoft.com/general/exp-policies-activity-log). For the full apply and management workflow, see [Applying and Managing Policies](https://docs.mulesoft.com/general/exp-policies-apply-manage). ## See Also - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Adding Services to Your Portfolio](https://docs.mulesoft.com/general/exp-services-add-to-portfolio) - [Create a Scanner for Provider Services](https://docs.mulesoft.com/general/exp-services-connect-providers-to-add) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Configuring Semantic Routing Services](https://docs.mulesoft.com/general/model-proxy-semantic-service) - [Creating and Managing Instances of Services](https://docs.mulesoft.com/general/exp-instances-add) - [Monitoring Services in Your Portfolio](https://docs.mulesoft.com/general/exp-services-monitoring) - [View Detailed Metrics for Your Services](https://docs.mulesoft.com/general/exp-services-view-detailed-metrics) --- product: Getting Started --- # Viewing Token Usage and Model Proxy Metrics > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Token Usage reports and API Manager insights help you monitor how your model proxies consume resources and perform over time. Token Usage reports show the number of API tokens consumed per model, broken down by business group or application. The API Manager LLM Summary page provides hourly metrics including request volume, policy violations, errors, and average response time. For deeper analysis, you can build custom dashboards in Anypoint Monitoring. > [!NOTE] Automate token usage reporting using the MuleSoft MCP Platform Server. For details, see > [fetch\_cost\_instances](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-cost-instances) > and > [fetch\_cost\_instance\_timeseries](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform#fetch-cost-instance-timeseries) > in the MuleSoft MCP Platform Server Tool Reference. ## View Token Usage Reports for Model Proxies With Token Usage reports, you can view the amount of API tokens each Model Proxy uses for individual models. > [!NOTE] To limit token usage, apply the > [LLM Token Based Rate Limit Policy](https://docs.mulesoft.com/gateway/latest/policies-included-llm-token-rate-limit) to > your Model Proxy. To view token usage reports: 1. In Anypoint Platform, click your Anypoint Platform profile icon (with your initials). 2. Click **Usage Reports**. 3. Select **Model Proxy** for **Product**. 4. Filter between **Usage by Business Group** and **Usage by Application** to see how tokens are consumed. To learn more about Usage Reports, see [Usage Reports](https://docs.mulesoft.com/general/usage-reports). > [!NOTE] Gemini models use reasoning tokens. This number is included in **Total tokens** but isn’t > individually listed. ## View Model Proxy Metrics in API Manager The API Manager LLM Summary page provides these metrics for your Model Proxy: - Total requests per hour - Total policy violations per hour - Total errors per hour - Average response time per hour To view the LLM Summary page for a Model Proxy: 1. From API Manager, click **Model Proxies**. 2. Click the name of the Model Proxy you want to view. To view more detailed metrics and build custom dashboards, click **View more metrics in Anypoint Monitoring dashboard**. --- product: Getting Started keywords: governance strategies, api governance, governance workflows, mulesoft governance, strategy management, anypoint platform --- # Working with Governance Strategies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use governance strategies to apply conformance rules and policies across agents, APIs, and MCP servers. When your tenant includes **Governance** and your account has the required role, you can create, manage, and monitor these strategies to validate service design compliance, automate runtime enforcement, and maintain visibility as your portfolio grows. > [!NOTE] Automate governance strategies using the MuleSoft MCP Platform Server. For details, see > [the Governance tools](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools-platform) in the MuleSoft MCP > Platform Server Tool Reference. Watch this video to see how to govern your portfolio with strategies: ![](https://play.vidyard.com/5yeeQCuwvyyhbZWKViK2U2.jpg) > [!NOTE] The MuleSoft interface uses two terms for strategy types: **controls** (for > guardrail-based strategies) and **automated policies**. In this documentation, "strategy" refers > to both types unless otherwise specified. ## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - These permissions: - To create governance strategies, either: - API Governance: Governance Administrator - API Manager: Manage Policies - To view governance reports, either: - API Governance: Governance Viewer - API Governance: Governance Administrator For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). ## Access Governance Strategy Workflows Log in through your organization’s entry path and go to **Governance**. From **Governance** > **Governance Strategies**, create strategies and map them to approved services or scopes. You can also edit, enable, disable, reorder, or delete existing strategies. Work with your governance lead when strategy changes affect production or compliance workflows. ## Governance Strategy Workflows - Create strategies for compliance validation or runtime enforcement. See [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy). - Manage strategies by updating scope, rules, status, and priority. See [Managing Governance Strategies](https://docs.mulesoft.com/general/exp-governance-manage-strategies). - Monitor token usage in **Governance** > **Cost Management**. See [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage). - Review conformance reporting for [supported catalog types](https://docs.mulesoft.com/general/exp-overview). - Apply policies to services from **Portfolio**. See [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details). ## Akamai Security Findings in Conformance Reports When Akamai API Security is connected as a provider, the **Violations**, **Warnings**, and **Info** counts in the conformance report include Akamai security findings alongside governance rule results. A service can show a **Non-Conformant** status even when no governance rules are violated, if Akamai findings contribute violations. The Conformance tab includes a dedicated Akamai section with two tables: - **Security Findings**: Individual security issues detected by Akamai through live traffic inspection, broken down per instance and per endpoint. - **Incidents**: Recurring threats aggregated over time, with first- and last-seen timestamps and occurrence counts. Both tables have these sortable columns: **Finding**, **Instance**, **Endpoint**, and **Risk**. Akamai severity levels map to conformance tiers as follows: - Critical and High map to violations. - Medium maps to warnings. - Low and Info map to informational findings. The **Severity** filter at the top of the Conformance tab applies to both the governance rule results and the Akamai tables. ### Review a Finding Select a row in the **Security Findings** table to open the finding detail panel, which shows: - **Triggered On**: The endpoint path where the issue was detected. - **Risk**: The severity level. - **Exposure**: Whether the endpoint is internet-facing. - **Remediation Opportunities**: Curated recommended policies for this finding type. Select **Apply This Policy** to open the policy-apply flow with the policy pre-selected. Select **Browse in Policy Library** if no curated policy is listed. After a policy is applied, Akamai re-inspects live traffic and updates the finding status automatically. ### Review an Incident Select a row in the **Incidents** table to open the incident detail panel, which shows: **Detection Time**, **Type**, **Triggered On**, **Severity**, **Occurrences**, **Exposure**, OWASP tags, and Compliance Frameworks. ### Refresh Conformance Results After a scan runs, the API listing and API detail pages don’t automatically reflect the updated conformance status. To see the latest results, manually refresh in one of these ways: - Refresh a single API: On the API detail page, open the **Conformance** tab and select **Refresh**. - Refresh all APIs: On the **Governance Strategies** page, select **Refresh Report**. ## See Also - [Create Governance Strategies](https://docs.mulesoft.com/general/exp-governance-create-strategy) - [Managing Governance Strategies](https://docs.mulesoft.com/general/exp-governance-manage-strategies) - [Managing Costs and Token Usage](https://docs.mulesoft.com/general/exp-governance-view-cost-and-token-usage) - [Enhanced MuleSoft Experience Overview](https://docs.mulesoft.com/general/exp-overview) - [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details)