diff --git a/modules/ROOT/assets/image-source-files/model-proxy.graffle b/modules/ROOT/assets/image-source-files/model-proxy.graffle deleted file mode 100644 index b0d766894..000000000 Binary files a/modules/ROOT/assets/image-source-files/model-proxy.graffle and /dev/null differ diff --git a/modules/ROOT/assets/images/model-proxy.png b/modules/ROOT/assets/images/model-proxy.png deleted file mode 100644 index 09df0320b..000000000 Binary files a/modules/ROOT/assets/images/model-proxy.png and /dev/null differ diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 09b106a5c..39cc4131b 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -1,68 +1,7 @@ .xref:index.adoc[Anypoint Platform] * xref:index.adoc[Documentation] -* xref:agent-fabric-overview.adoc[Agent Fabric] - ** xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] - ** xref:agent-fabric-release-notes.adoc[] -* xref:learning-map-exp.adoc[] - ** xref:exp-overview.adoc[Overview] - *** xref:exp-compare.adoc[Comparison: Enhanced Experience and Anypoint Platform] - *** xref:exp-glossary.adoc[Glossary] - ** xref:exp-release-notes.adoc[Release Notes] - ** xref:exp-home-start.adoc[] - *** xref:exp-portfolio-overview.adoc[] - *** xref:exp-ai-assistant-use.adoc[] - ** xref:exp-services-add-to-portfolio.adoc[] - *** xref:exp-services-connect-providers-to-add.adoc[] - *** xref:exp-services-register-manually.adoc[] - *** xref:exp-services-create-mcp-server.adoc[] - *** xref:exp-services-create-a2a-bridge.adoc[] - *** xref:exp-instances-add.adoc[] - *** xref:exp-services-view-details.adoc[] - ** xref:exp-playground-overview.adoc[] - *** xref:exp-playground-api.adoc[] - *** xref:exp-playground-mcp.adoc[] - ** xref:model-proxy.adoc[] - *** xref:model-proxy-create-model-proxy.adoc[] - *** xref:model-proxy-policies.adoc[] - *** xref:model-proxy-request.adoc[] - *** xref:model-proxy-semantic-service.adoc[] - *** xref:model-proxy-semantic-caching-service.adoc[] - *** xref:model-proxy-try-out.adoc[] - ** xref:exp-scanners-add-from-providers.adoc[] - *** xref:exp-scanners-prerequisites-reference.adoc[] - *** xref:exp-scanners-view-details.adoc[] - *** xref:exp-scanners-manage.adoc[] - *** xref:exp-providers-manage.adoc[] - ** xref:exp-policies-overview.adoc[] - *** xref:exp-policies-universal.adoc[] - *** xref:exp-policies-apply-manage.adoc[] - *** xref:exp-policies-activity-log.adoc[] - *** xref:exp-policies-provider-reference.adoc[] - ** xref:exp-securing-services.adoc[] - *** xref:exp-akamai-risk-correlation.adoc[] - *** xref:exp-vaults-manage.adoc[] - *** xref:exp-detect-and-contain-rogue-agents.adoc[] - ** xref:exp-governance-view-cost-and-token-usage.adoc[] - *** xref:model-proxy-token-reports.adoc[] - *** xref:exp-models-manage-costs.adoc[] - *** xref:exp-model-wallets-manage.adoc[] - *** xref:exp-governance-create-strategy.adoc[] - *** xref:exp-governance-policy-library-apply.adoc[] - *** xref:exp-governance-manage-strategies.adoc[] - *** xref:exp-governance-govern-third-party-apis.adoc[] - *** xref:exp-governance-monitor-cross-gateway-conformance.adoc[] - ** xref:exp-services-monitoring.adoc[] - *** xref:exp-services-view-detailed-metrics.adoc[] - *** xref:exp-alerts-configure-notifications.adoc[] - ** xref:exp-connect-with-external-systems.adoc[] - *** xref:exp-slack-integrate.adoc[] - // *** xref:exp-teams-integrate.adoc[] - *** xref:exp-claude-desktop-connect.adoc[] - ** xref:exp-troubleshoot.adoc[] - *** xref:exp-ai-assistant-troubleshoot.adoc[] * xref:learning-map-mulesoft-ai.adoc[] * xref:learning-map-mulesoft-vibes.adoc[MuleSoft Vibes] - * xref:usage-reports.adoc[Usage Reports] ** xref:usage-reports-release-notes.adoc[Release Notes] ** xref:automation-credits-usage-and-rates.adoc[] diff --git a/modules/ROOT/pages/_partials/exp-navigation-labels.adoc b/modules/ROOT/pages/_partials/exp-navigation-labels.adoc deleted file mode 100644 index 4d52825d9..000000000 --- a/modules/ROOT/pages/_partials/exp-navigation-labels.adoc +++ /dev/null @@ -1,4 +0,0 @@ -// Partial reused across all pages in the Enhanced Experience were needed. -// tag::ExpNavigationLabels[] -Navigation labels can vary by catalog, enabled features, and release. -// end::ExpNavigationLabels[] diff --git a/modules/ROOT/pages/agent-fabric-overview.adoc b/modules/ROOT/pages/agent-fabric-overview.adoc deleted file mode 100644 index 6883767b2..000000000 --- a/modules/ROOT/pages/agent-fabric-overview.adoc +++ /dev/null @@ -1,362 +0,0 @@ -= Agent Fabric Overview -:keywords: mulesoft agent fabric, mcp bridge, mcp connector, enterprise actionability, ai agents, mulesoft integration, model context protocol - - -Agent Fabric helps you turn agent sprawl into a governed, coordinated, intelligent network. Regardless of the platform where your AI agents were built or are running, Agent Fabric provides the infrastructure to discover, orchestrate, govern, and observe agents across your enterprise. Agent Fabric enables you to build intelligent agent networks where multiple agents work together, access enterprise systems securely, and operate under consistent governance and observability. - -[[how-agent-fabric-works]] -== How Agent Fabric Works - -Every organization has systems, agents, LLMs, and data sources scattered across platforms and teams. Left unmanaged, this creates agent sprawl: siloed agents that can't work together, inconsistent experiences, security gaps, and costs that are difficult to control. Agent Fabric solves this by providing a unified control plane for the agentic era. - -Agent Fabric starts with enterprise actionability, bridging the gap between your existing enterprise stack and the agentic world. It makes every system, agent, LLM, and data source directly usable in agentic workflows without rebuilding them, giving the entire fabric a foundation to build on. - -MuleSoft supports Agentforce and Agent Fabric, which can be used together for agentic enterprises. Each serves a distinct role in building and managing your organization's AI agent strategy: - -* Agentforce -+ -Build and deploy Salesforce-native agents for use within the Salesforce ecosystem. -* Agent Fabric -+ -The agent control plane for managing and governing agents across any platform, including Salesforce Agentforce, Amazon Bedrock, Google Vertex AI, Microsoft Copilot Studio, and others. Use Agent Fabric when you need to discover, catalog, and govern agents built anywhere, orchestrate multi-vendor workflows where agents from different platforms must work together, or apply consistent security, compliance, and cost controls across your entire agent ecosystem. - -Agentforce and Agent Fabric are core components of Salesforce's Agentic Enterprise Architecture, a four-layer platform model designed for the era of AI agents and headless operations. This architecture separates the data foundation, business logic, orchestration, and experience layers. - -Agent Fabric operates in the orchestration layer, providing the control plane for multi-vendor agent coordination. - -image::agent-fabric-pillars.png["Five colored pillars labeled Discovery, Governance, Security, Operations, and Runtime labeled as the foundation of Agent Fabric", discover, govern, orchestrate, and observe] - -As the agent control plane for your enterprise, Agent Fabric delivers four core capabilities that work together, whether you're managing Agentforce agents, third-party agents, or both: - -* <> -+ -A central registry, supported with automated discovery, where every agent and MCP server — regardless of where it's built — can be cataloged, discovered, and reused. This eliminates duplication and makes it easy to compose solutions from existing assets. -* <> -+ -Enterprise-grade guardrails ensuring every agent, MCP server, and LLM interaction is secure, compliant, and cost-controlled, so teams can innovate with confidence. -* <> -+ -The coordination of agents and tools across ecosystems with guided determinism, so multi-step processes run smoothly and every agent works together to deliver reliable business outcomes. -* <> -+ -End-to-end visibility into how agents make decisions and perform, turning black-box AI into transparent, accountable systems. - -Together, these capabilities transform disconnected agents and MCP servers into a unified, trusted, high-performing digital workforce. - -[[enterprise-actionability]] -== Enterprise Actionability - -Before agents can orchestrate across your enterprise, your existing systems need to be accessible to them. Enterprise actionability bridges the gap between what you have today, including APIs, data sources, LLMs, and existing services, and the agentic world, without requiring you to rebuild anything. MuleSoft provides a set of tools to make any asset directly actionable inside agentic workflows. - -=== MCP Bridge - -* What it is: MCP Bridge enables you to create MCP servers from your existing API instances, exposing their operations as MCP tools that agents can discover and call, without modifying the underlying API. - -* Role in Agent Fabric: MCP Bridge is one of the most important and accessible entry points into Agent Fabric. APIs your organization has already built and governed can become immediately available to any agent in your network through simple configuration, with no rewriting required. - -* What you can do: -** Convert any existing API instance into an agent-ready MCP server through simple configuration -** Select which API operations to expose as discrete MCP tools -** Apply governance policies to the resulting MCP server from the same portfolio - -* When you need it: Use MCP Bridge when you want agents to call your existing APIs without needing API-specific details, or when you want to make a large API surface agent-ready quickly without custom development. - -* Learn more: xref:exp-services-create-mcp-server.adoc[] - -=== MCP Connector - -* What it is: Anypoint Connector for MCP (MCP Connector) lets you build Mule applications that act as MCP servers and clients, giving you full programmatic control over what tools and resources you expose to agents and enabling Mule apps to connect to external MCP servers. - -* Role in Agent Fabric: MCP Bridge converts existing APIs automatically through configuration. MCP Connector is for teams that need to build custom MCP server logic, compose multiple systems, apply transformation, orchestrate interactions with external MCP services, or expose capabilities that don’t map directly to a single existing API. - -* What you can do: -** Build Mule applications that expose tools and resources to MCP clients -** Connect Mule applications to external MCP servers -** Compose multiple backend systems into a single MCP server -** Define custom logic for how agent requests are handled -** Orchestrate workflows that incorporate AI agents and external MCP services -* When you need it: Use MCP Connector when you need to expose capabilities to agents that require custom logic, multi-system composition, orchestration with external MCP services, or transformation that configuration-based tools like MCP Bridge don’t cover. -* Learn more: xref:mcp-connector::index.adoc[MCP Connector] - -=== A2A Bridge - -* What it is: An A2A bridge is an A2A-compliant protocol server that presents an A2A facade in front of an existing non-A2A agent (the source agent). Implemented as a chain of policies—inbound authentication plus the bridge policies—running on an Omni Gateway instance, it translates between the A2A protocol and the agent's native protocol, manages the task lifecycle, and serves A2A task management methods, all without modifying the source agent. Agent Fabric derives an A2A card from the source agent, publishes it to your Portfolio, and deploys the bridge instance from a single wizard. - -* Role in Agent Fabric: Agent Fabric can only orchestrate A2A-compliant agents, but many enterprise agents—such as Salesforce Agentforce agents—aren't A2A-compliant on their own. A2A Bridge closes the gap between what your scanners can discover and what Agent Fabric can orchestrate, making non-A2A agents first-class participants in your agent network through configuration alone. - -* What you can do: -** Make a non-A2A source agent A2A-compliant without rebuilding it -** Customize the advertised A2A card and skills before publishing -** Deploy the bridge instance to a managed or self-managed Omni Gateway with inbound and upstream authentication -** Manage the A2A task lifecycle so operations such as `GetTask`, `ListTasks`, and `CancelTask` return correct results -** Discover, govern, monitor, and orchestrate the bridged agent like any native A2A agent - -* When you need it: Use A2A Bridge when you have agents on platforms that aren't yet A2A-compliant (such as Agentforce) and you need Agent Fabric to orchestrate them now. Use A2A Connector instead when you need custom Mule application logic or want to bridge a platform that isn't natively supported. - -* Learn more: xref:exp-services-create-a2a-bridge.adoc[] - -=== A2A Connector - -* What it is: Use Anypoint Connector for A2A (A2A Connector) to add A2A protocol support to Mule applications so they can act as both A2A servers and A2A clients. You can also use A2A Connector to make agents built on other platforms A2A-compliant. - -* Role in Agent Fabric: A2A Connector brings existing Mule applications into the orchestrated agent world without rebuilding them as native agents. It standardizes agent communication so that any application can become a first-class participant in multi-agent workflows, capable of receiving tasks from a broker and delegating to other agents. - -* What you can do: -** Make any Mule applications A2A-compliant -** Enable Mule applications to receive and delegate tasks within an agent network -** Participate in broker-orchestrated workflows without rebuilding existing applications - -* When you need it: Use A2A Connector when you have existing Mule applications that need to participate in agent networks as A2A-compliant agents. - -* Learn more: xref:a2a-connector::index.adoc[A2A Connector] - -=== Other AI Connectors - -* What it is: AI Connectors provide pre-built integrations to LLMs and vector databases, making them directly accessible inside Mule-based agentic workflows. - -* Role in Agent Fabric: AI Connectors ensure that the LLMs and knowledge stores your organization already uses are available to agents without custom integration work. They connect your agentic workflows to the models and data that power agent reasoning and context. - -* What you can do: -** Connect LLMs and vector databases to agentic workflows without custom integration -** Unlock existing AI infrastructure for use inside agent networks -** Enrich agent reasoning with organizational knowledge stores - -* When you need it: Use AI Connectors when your agents need to reason with LLMs or retrieve context from vector databases your organization already operates. - -* Learn more: -** xref:agentforce-connector::index.adoc[Agentforce Connector] -** xref:amazon-bedrock-connector::index.adoc[Amazon Bedrock Connector] -** xref:einstein-ai-connector::index.adoc[Einstein AI Connector] -** xref:mulesoft-ai-chain-connector::index.adoc[MuleSoft AI Chain Connector] -** xref:mulesoft-inference-connector::index.adoc[MuleSoft Inference Connector] -** xref:mulesoft-vectors-connector::index.adoc[MuleSoft Vectors Connector] -** xref:mulesoft-webcrawler-connector::index.adoc[MuleSoft WebCrawler Connector] - - -=== B2B (Partner Manager) - -* What it is: Anypoint Partner Manager enables bidirectional Business-to-Business message exchanges with external trading partner ecosystems through configuration-driven integration. Partner Manager handles technical partner onboarding, message flow orchestration, and transaction monitoring across multiple transport protocols (AS2, SFTP, HTTP/S, FTP) and message formats (X12, EDIFACT, CSV, JSON, XML). - -* Role in Agent Fabric: Partner Manager makes B2B trading partner networks directly actionable for agents without requiring them to understand complex EDI standards or protocol-specific integration patterns. Agents can initiate B2B transactions, query partner message flows, monitor transmission status, and respond to partner interactions as part of multi-step workflows, turning manual B2B operations into automated agent-driven processes. -* What you can do: -** Enable agents to send and receive B2B transactions with trading partners -** Query message flow status, transmission tracking, and acknowledgment statuses -** Access partner profile information and endpoint configurations -** Monitor B2B transaction activity and custom message attributes -** Integrate B2B workflows into broader agentic orchestration patterns - -* When you need it: Use Partner Manager when agents need to participate in B2B ecosystems for use cases like order to cash, procure to pay, logistics planning, warehouse management, or transportation execution where automated B2B message exchange with external partners is required. -* Learn more: xref:partner-manager::index.adoc[] - -=== IDP (Intelligent Document Processing) - -* What it is: MuleSoft Intelligent Document Processing (IDP) uses multimodal large language models to extract structured data from unstructured or semi-structured documents like invoices, purchase orders, receipts, and custom document types. IDP creates document actions—configurable schemas with AI-powered extraction instructions—that are published as APIs for consumption by agents, RPA, and Mule applications. - -* Role in Agent Fabric: IDP makes document data directly actionable for agents by transforming locked information in PDFs, images, and paper documents into structured, queryable data that agents can reason over and act upon. Instead of requiring manual document review or rigid OCR templates, agents can process documents intelligently, extract key fields with confidence scoring, and route documents for human review when needed, seamlessly blending AI extraction with agent-driven workflows. - -* What you can do: -** Enable agents to extract structured data from invoices, purchase orders, and custom document types -** Configure document actions with pre-built or custom schemas using natural language prompts -** Leverage Einstein for complex document analysis that requires reasoning beyond simple field extraction -** Apply confidence thresholds and human-in-the-loop review workflows for quality assurance -** Integrate document processing results into agent workflows through published APIs - -* When you need it: Use IDP when agents need to extract and act on data trapped in documents as part of procurement, accounts payable, order processing, or any workflow where unstructured document data must become structured, actionable information within your agent network. - -* Learn more: xref:idp::index.adoc[] - - -[[discover]] -== Discover - -Agent Fabric provides a central registry and automated discovery tools that surface every agent in your organization, regardless of platform. Before you can govern, orchestrate, or observe agents, you need a complete picture of what exists. Discovery gives you that foundation and enables coordinated control across your entire agent ecosystem. - -=== Registry (Exchange) - -* What it is: The registry is the central catalog for all agentic assets across your organization. In the enhanced MuleSoft experience, your Portfolio serves as the registry, organized into catalogs for Agents, MCP Servers, Model Proxies, APIs, and Gateways. Each catalog holds the services your organization has registered or discovered, so you can govern, monitor, and manage them from one place, regardless of which platform or provider built them. MuleSoft also provides access to a curated set of public MCP servers from the Official MCP Registry and Informatica, giving teams a starting point for common integrations without building from scratch. -* Role in Agent Fabric: The registry is where Agent Fabric makes every agent, tool, and model visible and reusable. The registry gives teams a trusted source of truth for all agentic assets, so they can reuse what already exists instead of duplicating work. The registry forms the foundation of discovery. -* What you can do: -** Browse and search registered agents, MCP servers, Model proxies, APIs, and gateways -** View service details, conformance status, and instance health at a glance -** Manage lifecycle, governance, and monitoring for each asset from its catalog page -** Register assets manually or through automated provider discovery -** Publish agent networks and MCP servers for organizational reuse - -* When you need it: Whenever you are starting a new agentic project and want to find existing assets before building from scratch, or when you want to share what your team built with the rest of the organization. -* Learn more: xref:exp-portfolio-overview.adoc[] - -=== Scanners - -* What it is: A scanner connects the enhanced MuleSoft experience to a supported cloud provider. When a scanner runs, it discovers services on that platform, such as agents, APIs, and MCP servers, and registers them automatically in the matching portfolio catalog. -* Role in Agent Fabric: Scanners enable continuous, automated discovery across a multi-provider landscape. Teams configure scanners once, and the scanners keep the registry current as services are added, changed, or retired on external platforms. A scanner monitors connected platforms for new and updated agents and pulls them automatically into the registry, providing a real-time, single source of truth for every agent across your enterprise. -* What you can do: -** Connect cloud providers as scanner sources -** Automatically discover and register agents, MCP servers, and APIs across ecosystems -** Schedule scans to run continuously or trigger them on demand -** View scanner status, last-run results, and the number of assets discovered -** Manage scanners from *Platform* > *Providers* in the enhanced MuleSoft experience - -* When you need it: When your organization has agents built across multiple platforms and you need a continuous, automated way to keep your registry current without manually registering every asset. -* Learn more: xref:exp-scanners-add-from-providers.adoc[] - -[[govern]] -== Govern - -Without governance, orchestration turns to chaos. Agent Fabric provides enterprise-grade guardrails that ensure every agent, MCP server, and LLM interaction is secure, compliant, and cost-controlled, so teams can innovate with confidence. - -=== Omni Gateway - -* What it is: Omni Gateway is the runtime governance layer that sits between agents and the systems they call, applying security, compliance, and cost controls to every interaction across APIs, agents, MCP servers, and LLMs. -* Role in Agent Fabric: Omni Gateway makes governance real at runtime. Defining policies in a governance strategy sets the intent. Omni Gateway enforces that intent on live traffic. It ensures that no agent interaction bypasses security controls, regardless of which platform the agent was built on or which system it is calling. Omni Gateway serves as the enterprise policy framework for your agent network, ensuring agents act responsibly, securely, and in alignment with business objectives. -* What you can do: -** Apply rate limiting, authentication, and authorization to all agent, API, and MCP server requests -** Enforce runtime policies for data privacy, compliance, and cost -** Control agent access to specific tools and APIs -** Log and audit agent traffic for security and compliance purposes - -* When you need it: Use Omni Gateway for any production deployment where agents handle sensitive data, call external APIs, or need consistent security and compliance enforcement across your organization. -* Learn more: xref:exp-governance-create-strategy.adoc[] - -=== Governance Strategies - -* What it is: Governance strategies bundle design-time rules and runtime policies into a coherent governance posture applied across targeted services. In the enhanced MuleSoft experience, governance strategies are managed under *Governance > Governance Strategies*. -* Role in Agent Fabric: Governance strategies turn compliance intent into systematic enforcement across your portfolio. A governance strategy lets you define rules once, spanning access and security, data privacy, performance and cost, and compliance, and apply them consistently across every agent, MCP server, API, and Model proxy in scope. -* What you can do: -** Create strategies spanning access and security, data privacy, performance and cost, and compliance and observability domains -** Apply policies at the service or instance level so runtime traffic reflects the defined strategy -** Review conformance scores, violations, and warnings via Conformance Reports on each service -** Monitor governance coverage to identify which services lack active strategies -** Block or flag non-compliant actions at design time or runtime -* When you need it: Use governance strategies when your organization needs consistent, auditable enforcement of security, compliance, or cost rules across a portfolio of agents and services. -* Learn more: xref:exp-governance-work-with-strategies.adoc[] - -=== Cost Management - -* What it is: Cost Management surfaces token usage, daily spend signals, and cost optimization controls across your portfolio. -* Role in Agent Fabric: As LLMs become central to agentic workflows, token consumption becomes a significant operational cost. Cost Management gives organizations the visibility and controls to keep that cost predictable. It connects governance directly to economics. The same governance strategy framework that enforces security and compliance can also reduce unnecessary token spend through tool mapping and tool sanitization controls. -* What you can do: -** Monitor token usage and spend trends across Model proxies and agents -** Apply tool mapping to restrict which tools an LLM or agent can invoke, reducing unnecessary token consumption -** Apply tool sanitization to filter inputs and outputs before they reach a model -** Identify high-cost services and tune them through governance controls -** Keep every agent action authenticated and attributable to the user who initiated it -** Maintain a complete audit trail of agent actions tied to real user authorization -* When you need it: Use Cost Management when LLM token consumption is a significant operational concern, or when you need to enforce spending limits and audit agent interactions across your organization. -* Learn more: For more information, see xref:exp-governance-view-cost-and-token-usage.adoc[] and xref:exp-governance-create-strategy.adoc[] - -//// -=== Trusted Agent Identity - -* What it is: Trusted Agent Identity is a set of identity and authorization policies that ensure agents act with a specific user's identity and proper authentication on every interaction, so access follows the calling user's permissions rather than granting blanket agent access. -* Role in Agent Fabric: Without identity controls, agents can become a governance gap, calling systems with elevated or opaque permissions that bypass the controls applied to human users. Trusted Agent Identity closes that gap, ensuring every agent interaction is authenticated, attributable, and auditable. This is what makes agent governance meaningful in regulated environments. -* What you can do: -** Ensure agents act under a specific user's identity rather than with generic or elevated agent-level access -** Keep every agent action authenticated and attributable to the user who initiated it -** Maintain a complete audit trail of agent actions tied to real user authorization - -* When you need it: Use Trusted Agent Identity any time agents call APIs or services on behalf of users, or when compliance requires knowing not just that an agent made a call, but who authorized it. -* Learn more: -//// - - -[[orchestrate]] -== Orchestrate -Coordinate agents and tools across ecosystems with guided determinism, so multi-step processes run smoothly and every agent works together to deliver reliable business outcomes. - -=== Agent Broker - -* What it is: An intelligent routing service that coordinates task delegation across A2A-compliant agents in your agent network. You define a broker and its nodes in Agent Script. Nodes are connected in a graph that encapsulates all steps that describe the orchestration of agents, tools, and LLMs. A graph-based approach to agent brokers ensures that connected paths guarantee a specific order of operations and enable more complex orchestration that combines deterministic and non-deterministic elements. -* Role in Agent Fabric: The broker is the orchestration intelligence in your agent network. When a request arrives, the broker determines which agent or other broker is best suited to handle it and delegates accordingly, generating a contextId and taskId to track task state across the interaction. -* By dynamically matching tasks with other agents and enabling seamless collaboration across ecosystems, the broker transforms scattered agents into a coordinated workforce. Brokers appear in your portfolio and can be discovered and reused by other brokers across your organization. -* What you can do: -** Build hierarchical orchestration by delegating tasks to specialized A2A-compliant agents or other brokers -** Publish brokers to your portfolio for discovery and reuse across your organization -** Define brokers in Agent Script -** Configure the broker's routing logic and orchestration patterns -** Deploy the full agent network (including the broker) to CloudHub 2.0 -** Monitor broker routing decisions and performance using Agent Visualizer - -* When you need it: when your agent network includes multiple agents with different specializations and you need a component to intelligently route work to the right agent based on context. Add a broker when routing logic needs to go beyond a single agent. - -* Learn more: xref:agent-network::af-define-your-agent-network-specification.adoc[] - -=== Agent Network - -* What it is: An agent network is a coordinated group of agents, brokers, LLMs, and MCP servers that acts as a central hub for defining, validating, and running agentic processes across your enterprise. You configure an agent network in a human-readable YAML file that details the required structure and properties that define your project's assets, connections, and policies. If your network project uses brokers, you define them and their nodes in Agent Script. Agent Script enables you to build predictable, context-aware agent workflows between nodes. -* Role in Agent Fabric: The agent network is the configuration and infrastructure layer that brings all the components of your agentic solution together. It defines the composition of your network, specifying which agents are available, which brokers orchestrate them, which LLMs provide reasoning, and which MCP servers connect agents to backend systems. Without an agent network, agents operate in isolation. With one, they become a coordinated system capable of handling complex, multi-step workflows. -* What you can do: -** Define the composition of a multi-agent system in a single YAML configuration -** Connect agents to backend systems and data sources via MCP servers -** Use LLMs for reasoning and planning across the network -** Deploy the full agent network, including agents, brokers, and MCP servers -** After publishing, network assets are registered in your portfolio for discovery and reuse - -* When you need it: Use an agent network any time you are building an agentic solution that involves multiple agents, LLMs, or MCP servers working together. Agent networks do not require a broker. You can start with just agents and MCP servers and add a broker when you need intelligent routing across specialized agents. - -* Learn more: xref:agent-network::af-agent-networks.adoc[] - -[[observe]] -== Observe - -Agent Visualizer provides a detailed visual graph of your agent network so you can see, understand, and interact with your enterprise’s evolving network of agents, Model Context Protocol (MCP) servers, and large language models (LLMs), including agents created in external platforms. - -=== Agent Visualizer - -* What it is: Agent Visualizer is a visualization and monitoring tool that displays agent network structure, real-time request flows, and performance metrics. -* Role in Agent Fabric: Agent Visualizer makes the agent network legible, both during development, where you need to verify that routing logic and agent connections are configured correctly, and in production, where you need to identify bottlenecks, trace failures, and optimize performance. It turns multi-agent interactions into clear, interactive maps so you can trace decisions, monitor real-time health, and detect issues before they impact outcomes. Without this visibility, multi-agent systems are opaque and difficult to operate with confidence. -* Key capabilities: -** Visual network topology showing agents, brokers, MCP servers, and their connections -** Performance metrics including latency, throughput, and error rates -** Historical analysis for identifying patterns over time - -* When you need it: Use Agent Visualizer during development to verify your network is wired correctly, at deployment to confirm traffic is routing as expected, and in production to troubleshoot. - -* Learn more: xref:agent-visualizer::index.adoc[] - -=== Monitor - -* What it is: In the enhanced MuleSoft experience, monitoring is available at both the service level and the organization level. At the service level, each agent, API, MCP server, Model proxy, and gateway has a Monitoring tab showing runtime health signals and detailed time-series breakdowns, depending on your gateway, runtime path, and platform connections. At the organization level, observability aggregates dashboards, reports, and alerts when your administrator has connected the observability backend for your business group. -* Role in Agent Fabric: Monitoring closes the loop between governance and operations. Governance strategies define what should happen; monitoring tells you whether it is happening. It surfaces latency, error rates, request volume, and other runtime signals so you can catch regressions early, triage incidents quickly, and make informed decisions about policy changes and capacity. -* What you can do: -** View runtime health metrics such as latency, error rates, and request volume, including detailed time series and dimensions per service on its Monitoring tab -** Compare signals across instances or environments to attribute changes to deployments or policy updates, allowing you to baseline behavior after changes. -** Configure alert notifications to route API and runtime alerts to Slack, email, or other channels your team monitors -** Access organization-wide dashboards and reports through Observability, using filters to narrow your investigation down to a specific service, environment, or route. - -* When you need it: Use monitoring during development for performance validation, and continuously in production to ensure reliability, meet SLAs, and catch issues before they affect users. - -* Learn more: xref:exp-services-monitoring.adoc[] - -[[supporting-tools]] -== Supporting Tools - -=== Anypoint Code Builder - -* What it is: Anypoint Code Builder is the development environment for building agent networks, configuring agent interactions, and developing custom MCP servers. -* Role in Agent Fabric: Anypoint Code Builder is where agent networks come to life. It provides the visual canvas and tooling to define an agent network YAML and develop custom MCP servers, all before deploying to production. -* Key capabilities: -** 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 -* Learn more: xref:anypoint-code-builder::index.adoc[] - -=== MuleSoft Vibes - -* What it is: MuleSoft Vibes is the AI assistant built into Anypoint Code Builder, trained on industry best practices for graph-based agent architecture. -* Role in Agent Fabric: Vibes accelerates the process of building agent networks by letting you describe what you want in natural language and generating robust broker and network configurations from those descriptions. Vibes validates that the resulting architecture is sound and aligned with best practices before you deploy. -* What you can do: -** Describe your desired agent network in natural language and generate YAML configurations -** Validate network structure and routing logic against architecture best practices -** Accelerate development from initial design through testing and refinement -* When you need it: Use MuleSoft Vibes throughout the development lifecycle, from initial network design through iterating on routing logic and agent configurations. -* Learn more: xref:anypoint-code-builder::vibes-get-started.adoc[] - -== What's Next - -* For a guided path through discovering assets, building your first agent network, and deploying it with governance and monitoring, get started with the xref:learning-map-agent-fabric.adoc[]. - -* For a comprehensive guide to the technical foundations, capability pillars, and architectural best practices that power enterprise agentic transformation, explore the https://www.mulesoft.com/lp/ebook/mulesoft-agent-fabric-technical-overview[Agent Fabric Technical Overview]. - -* Learn about the technical foundations, capability pillars, and architectural details https://architect.salesforce.com/docs/architect/fundamentals/guide/mulesoft-agent-fabric-deep-dive.html#Agent_Orchestration_Design_Patterns[Agent Fabric Deep Dive]. diff --git a/modules/ROOT/pages/agent-fabric-release-notes.adoc b/modules/ROOT/pages/agent-fabric-release-notes.adoc deleted file mode 100644 index 3506faca8..000000000 --- a/modules/ROOT/pages/agent-fabric-release-notes.adoc +++ /dev/null @@ -1,2 +0,0 @@ -:keywords: runtime fabric agent, release notes, anypoint runtime fabric, agent updates, fabric agent versions, mulesoft runtime fabric -include::release-notes::partial$agent-fabric/agent-fabric-rn-landing-page.adoc[] diff --git a/modules/ROOT/pages/agent-networks-get-started.adoc b/modules/ROOT/pages/agent-networks-get-started.adoc deleted file mode 100644 index 906b45217..000000000 --- a/modules/ROOT/pages/agent-networks-get-started.adoc +++ /dev/null @@ -1,4 +0,0 @@ -= Get Started with Agent Networks -:keywords: agent networks, ai agents, mulesoft, get started, agent orchestration, setup, configuration - -include::agent-network::partial$af-shared.adoc[tag=get-started] diff --git a/modules/ROOT/pages/exp-ai-assistant-troubleshoot.adoc b/modules/ROOT/pages/exp-ai-assistant-troubleshoot.adoc deleted file mode 100644 index 82c1efba5..000000000 --- a/modules/ROOT/pages/exp-ai-assistant-troubleshoot.adoc +++ /dev/null @@ -1,225 +0,0 @@ -= Troubleshoot the MuleSoft Agent -:keywords: ai assistant troubleshooting, ai assistant errors, incorrect answers, search results, mulesoft ai assistant, anypoint platform - -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: - -. Verify that you have an active internet connection. -. Refresh the browser page. -. Try sending a simple message like "Hello" to test if the assistant responds. - -Check session status: - -. Verify that you're still signed in to the enhanced experience. -. If your session expired, sign in again. -. Check for any error messages in the browser console (if you have developer tools access). - -Try a different browser or clear cache: - -. Clear your browser cache and cookies. -. Try using a different browser or incognito/private mode. -. 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: - -. Include specific names, IDs, or identifiers in your questions. -. Mention the environment, business group, or scope if relevant. -. Add details about what you're trying to accomplish. - -Example: -[%header,cols="1,1"] -|=== -|Instead of |Try - -|"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: - -. Try asking the same question using different words. -. Break complex questions into smaller, focused questions. -. Use follow-up questions to narrow down the information you need. - -Verify the assistant has access to the data: - -. Check that the service is registered in your portfolio. -. Verify that monitoring or governance data has been collected for the service. -. 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: - -. Verify your Access Management permissions in xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. -. Ask your administrator to review your role assignments. -. The assistant may suggest actions available in the product, but your specific permissions determine what you can do. - -Check your subscription tier: - -. Verify whether you have API Portfolio Access or Agent + API Portfolio Access. -. Some features (like agents, MCP servers, Model proxies) require Agent + API Portfolio Access. -. Contact your administrator or account team about upgrading your subscription if needed. - -Check service state: - -. The service may need to be in a specific state (active, registered, etc.) before certain actions are available. -. 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: - -. Include the service type: "Find agents that handle payments" instead of "Find payment services." -. Specify attributes: "Show me REST APIs with OAuth policies" instead of "Show me APIs." - -Check the scope: - -. Verify you're searching in the right business group or environment. -. Ask the assistant to filter: "Show me only production services." - -Verify service metadata: - -. Search results depend on how services are described in their metadata. -. If a service doesn't appear, check whether its description includes the terms you're searching for. -. 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: - -. During peak usage times, responses may be slower. -. If using monitoring or cost queries, large datasets may take longer to process. - -Simplify your question: - -. Break complex questions into smaller parts. -. Ask for summaries first, then drill into details. - -Check your connection: - -. Slow network connections can delay streaming responses. -. Try refreshing the page or reconnecting to your network. - -== MuleSoft Agent Conversation History Is Lost - -If your conversation history disappears: - -Session expiration: - -. Conversation history is tied to your session. If your session expires, history may be cleared. -. Sign in again and start a new conversation. - -Browser storage: - -. Clearing browser cache or cookies may remove conversation history. -. Conversation history is stored locally in your browser for the current session. - -Intentional behavior: - -. For privacy and security, conversation history may not persist across sessions. -. 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: - -. The assistant should display any error messages from the system. -. Look for specific error details (validation errors, permission issues, etc.). - -Check prerequisites: - -. Verify that all required fields and configurations are complete. -. For instance creation, ensure the target gateway is available. -. For policy application, ensure the service instance is active. - -Verify data: - -. Double-check that URLs, names, and identifiers are correct. -. Ensure referenced services, gateways, or environments exist. - -Try manually: - -. Perform the action manually through the UI to see if the same error occurs. -. 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: - -. Newly registered services may take a few minutes to appear in search results. -. Refresh the page and try again after a few minutes. - -Verify registration completed: - -. Check that the service registration or configuration change was saved successfully. -. Look for confirmation messages or check the relevant catalog. - -Be specific: - -. Use exact service names or IDs rather than relying on search. -. For example: "Show me details for service ID 12345." - -== Get Additional Help - -If these troubleshooting steps don't resolve your issue: - -. Check with your administrator. -+ -Your administrator can verify your permissions, subscription tier, and feature availability. - -. Review documentation. -+ -See xref:exp-ai-assistant-use.adoc[] for complete AI assistant usage guidance. - -. Review system status. -+ -Ask your administrator to check whether there are any known issues or maintenance windows. - -. 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 - -. Contact support. -+ -Reach out to your internal IT support or MuleSoft support with the diagnostic information. - -== See Also - -* xref:exp-ai-assistant-use.adoc[] -* xref:exp-troubleshoot.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-overview.adoc[] -include::release-notes::partial$release-notes/rn-known-issues.adoc[tag=knownIssuesSeeAlsoLink] diff --git a/modules/ROOT/pages/exp-ai-assistant-use.adoc b/modules/ROOT/pages/exp-ai-assistant-use.adoc deleted file mode 100644 index efff7fdab..000000000 --- a/modules/ROOT/pages/exp-ai-assistant-use.adoc +++ /dev/null @@ -1,384 +0,0 @@ -= Using the MuleSoft Agent -:keywords: mulesoft agent, ai assistant, anypoint platform, integration automation, ask questions, ai-powered assistant - -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]] -== 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 xref:access-management::enabling-generative-ai.adoc[]. -* The *MuleSoft Agent AI User* permission assigned to each user who needs to send prompts to the agent. -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -To assign the *MuleSoft Agent AI User* permission across business groups: - -. Log in to Anypoint Platform and open *Access Management*. -. Select the business group where you want to assign the permission. -. Find the user and assign the *MuleSoft Agent AI User* permission. -. 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 https://help.salesforce.com[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 <>, 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 - -[source,text] ----- -Show me all agents in production ----- - -[source,text] ----- -Which APIs have governance violations? ----- - -[source,text] ----- -Find MCP servers that expose payment tools ----- - -[source,text] ----- -What instances are deployed to the staging gateway? ----- - -=== Example Governance Questions - -[source,text] ----- -What governance strategies are active? ----- - -[source,text] ----- -How do I create a new governance strategy? ----- - -[source,text] ----- -Show me all services with security violations ----- - -[source,text] ----- -Which policies are applied to my API instance? ----- - -=== Example Monitoring Questions - -[source,text] ----- -What's the error rate for my agent today? ----- - -[source,text] ----- -Show me latency trends for the last week ----- - -[source,text] ----- -Which services have the highest token usage? ----- - -[source,text] ----- -Are there any service health alerts? ----- - -=== Example Cost Questions - -[source,text] ----- -What's my total token spend this month? ----- - -[source,text] ----- -Which agents are using the most tokens? ----- - -[source,text] ----- -How can I reduce costs for my Model proxies? ----- - -[source,text] ----- -Show me cost trends over time ----- - -=== Example Navigation Questions - -[source,text] ----- -How do I register a new API? ----- - -[source,text] ----- -Show me the governance strategies page ----- - -[source,text] ----- -Take me to monitoring for my agent ----- - -[source,text] ----- -Where do I configure scanners? ----- - -=== Example Customer Support Questions - -[source,text] ----- -How do I configure OAuth 2.0 in Mule 4? ----- - -[source,text] ----- -Are there known issues with CloudHub 2.0 deployments? ----- - -[source,text] ----- -What does a MULE:CONNECTIVITY error mean? ----- - -[source,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. - -. Review the suggestion chips below the assistant's response. -. Select a chip to ask that follow-up question or perform that action. -. 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: - -. The assistant shows a confirmation banner with the navigation target. -. Review where the assistant wants to take you. -. Confirm to proceed. - -=== Data Modification Actions - -When the assistant wants to create, update, or delete services or configurations: - -. The assistant shows a confirmation banner with details of the proposed action. -. Review what the assistant will do. -. 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: - -. Ask the assistant for help with the form (for example, "Fill in the instance details for my production API"). -. The assistant proposes changes to specific form fields. -+ -A confirmation banner shows which fields will be updated and with what values. -. Review the proposed changes. -. 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: - -[source,text] ----- -How do I create a governance strategy for my APIs? ----- - -[source,text] ----- -Walk me through registering a new agent ----- - -[source,text] ----- -Help me set up monitoring for my MCP server ----- - -[source,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 - -* xref:exp-ai-assistant-troubleshoot.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-overview.adoc[] -* xref:exp-portfolio-overview.adoc[] -* xref:exp-services-monitoring.adoc[] -* xref:exp-governance-work-with-strategies.adoc[] diff --git a/modules/ROOT/pages/exp-akamai-risk-correlation.adoc b/modules/ROOT/pages/exp-akamai-risk-correlation.adoc deleted file mode 100644 index cf8fbe6cc..000000000 --- a/modules/ROOT/pages/exp-akamai-risk-correlation.adoc +++ /dev/null @@ -1,167 +0,0 @@ -= Correlating Risk Using Akamai API Security -:keywords: akamai api security scanner, akamai integration, security risk, vulnerability findings, incident correlation, portfolio catalogs - -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 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 xref:exp-scanners-prerequisites-reference.adoc[]. - -== 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: - -. 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. -. 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 <>. -. 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. -. 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]] -== Set Up the Akamai Scanner - -Before you set up the scanner, review the prerequisites for Akamai scanners in xref:exp-scanners-prerequisites-reference.adoc[]. - -. From *Platform* > *Providers*, select *Akamai*. -. Click *Add Scanner* and enter the connection values. -. Test the connection. -. Enter scanner metadata, such as scanner name, description, frequency, and time. -. Apply the Akamai correlation policy to selected environments. -. 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 scanner detail tabs to monitor scanner status, related services, and configuration values. - -For common tab behavior across scanners, see xref:exp-scanners-view-details.adoc[]. -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 correlation policy isn't applied, you can apply missing policies from the scanner detail page: - -. Open *Platform* > *Providers* and select the configured Akamai scanner. -. In *Overview*, check the *Akamai Correlation Policy* status. -. If the status shows missing environments, click *Check again* to apply policy only to those environments. -. 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: - -. Open the API from the *APIs* catalog in *Portfolio*. -. Select *Conformance* and review the *Akamai* section, including findings and incidents. -. Select a finding to open details, such as endpoint, severity, and mapped standards. -. Apply recommended remediation policies directly from the finding detail view when available. -. 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. -* Re-run the scanner after connection or policy changes. - -== See Also - -* xref:exp-securing-services.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-providers-manage.adoc[] -* xref:exp-scanners-view-details.adoc[] -* xref:exp-scanners-manage.adoc[] diff --git a/modules/ROOT/pages/exp-alerts-configure-notifications.adoc b/modules/ROOT/pages/exp-alerts-configure-notifications.adoc deleted file mode 100644 index cf2a81c7a..000000000 --- a/modules/ROOT/pages/exp-alerts-configure-notifications.adoc +++ /dev/null @@ -1,128 +0,0 @@ -= Configuring Notifications for Alerts -:keywords: alerts, notifications, configure alerts, alert target, manage alerts, anypoint platform, monitoring - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -* The MuleSoft Slack app installed in your workspace (see xref:exp-slack-integrate.adoc[] for installation steps), or the MuleSoft for Teams app installed in your Microsoft Teams tenant (see xref:exp-teams-integrate.adoc[] for installation steps) - -== View and Manage Alerts - -The enhanced experience provides a unified view of all your alerts: - -. Navigate to the *Notifications* tab in the enhanced experience. -. View all alerts for APIs, MCPs, Agents, and LLMs in one place. -. 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: - -. Navigate to the *Notifications* page in the enhanced experience at omni.mulesoft.com. -. Click *Create Alert*. - -=== Select Alert Target - -. Select your *Environment* from the dropdown. -. Choose a *Service Type*: -** *API* -** *LLM* -** *MCP* -** *Agent* -. In the *Target Service* field, search for and select the specific service to monitor. -. If available for your service type, select an *API instance* from the dropdown. - -=== Specify Alert Configuration - -. Select an *Alert Metric* from the dropdown (Request Count, Response Time, Response Code, or Policy Violation). -. 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 - -. Select a *Severity* level: -** *Critical* -** *Warning* -** *Info* -. Enter an *Alert Name* (minimum 4 characters). -+ -This name appears in the notification list and email subjects. -. 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. -. If *Slack* is enabled, select your delivery destination: -** Choose a Slack channel from your workspace. -** Or select a direct message recipient. -. If *Microsoft Teams* is enabled, select your delivery destination: -** Choose a Teams channel from your tenant. -** Or select a direct message recipient. -. Click *Create Alert* to save. - -== Edit an Existing Alert - -To modify an existing alert: - -. Navigate to the *Notifications* page in the enhanced experience. -. Locate the alert you want to modify. -. Click to edit the alert. -. 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). -. 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 - -* xref:exp-services-monitoring.adoc[] -* xref:exp-services-view-detailed-metrics.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-overview.adoc[] -* xref:exp-teams-integrate.adoc[] -* xref:exp-slack-integrate.adoc[] diff --git a/modules/ROOT/pages/exp-claude-desktop-connect.adoc b/modules/ROOT/pages/exp-claude-desktop-connect.adoc deleted file mode 100644 index 758177314..000000000 --- a/modules/ROOT/pages/exp-claude-desktop-connect.adoc +++ /dev/null @@ -1,41 +0,0 @@ -= Connect the Enhanced Experience to Claude Desktop -:keywords: claude desktop, mulesoft mcp server, enhanced experience, administrator configuration, mcp integration, ai integration, mulesoft claude - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:mulesoft-mcp-server::getting-started-platform.adoc[]. - -== See Also - -* xref:exp-home-start.adoc[] -* xref:exp-slack-integrate.adoc[] -* xref:exp-overview.adoc[] diff --git a/modules/ROOT/pages/exp-compare.adoc b/modules/ROOT/pages/exp-compare.adoc deleted file mode 100644 index bd949b757..000000000 --- a/modules/ROOT/pages/exp-compare.adoc +++ /dev/null @@ -1,74 +0,0 @@ -= Enhanced MuleSoft Experience and Anypoint Platform Comparison -:keywords: enhanced mulesoft experience, anypoint platform comparison, task management, platform benefits, mulesoft migration, platform differences - -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. - -[cols="1,1,2a,2a",options="header"] -|=== -| Task | Preferred Experience | Why | Example for Dual Use - -| API design and documentation -| Anypoint Platform -a| -Anypoint Platform offers powerful tools like Anypoint Code Builder for crafting APIs with RAML or OAS and publishing detailed documentation. -a| -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 xref:exp-services-add-to-portfolio.adoc[]. - -| Policy enforcement and governance -| Enhanced MuleSoft experience -a| -The new experience excels in applying and managing governance policies across agents, APIs, and other services with detailed compliance tracking and reporting features. -a| -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 -a| -Anypoint Code Builder is specifically designed for developing integrations and flows, offering seamless tools for connecting systems and designing workflows. -a| -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 -a| -The new experience monitors and optimizes interactions between AI agents to maintain cohesive operation across the ecosystem. -a| -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 -a| -The new experience provides cost management, token usage tracking, and performance metrics across agents, APIs, MCP servers, and related services in the portfolio. -a| -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 -a| -Use Anypoint Runtime Manager to deploy, manage, and monitor Mule applications during runtime operations. -a| -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 - -* xref:exp-overview.adoc[] -* xref:exp-home-start.adoc[] diff --git a/modules/ROOT/pages/exp-connect-with-external-systems.adoc b/modules/ROOT/pages/exp-connect-with-external-systems.adoc deleted file mode 100644 index 1acb7f1f2..000000000 --- a/modules/ROOT/pages/exp-connect-with-external-systems.adoc +++ /dev/null @@ -1,19 +0,0 @@ -= Connect the Enhanced Experience with External Systems -:keywords: external systems, slack integration, claude desktop, mcp, mulesoft enhanced experience, integrations - -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: - -* xref:exp-slack-integrate.adoc[] -+ -Install the MuleSoft for Slack app to receive notifications, run shortcuts, and deep-link into the enhanced experience from your Slack workspace. - -* xref:exp-claude-desktop-connect.adoc[] -+ -Connect Claude Desktop to the enhanced experience so developers can move between conversational AI workflows and governed catalogs. - -== See Also - -* xref:exp-slack-integrate.adoc[] -* xref:exp-claude-desktop-connect.adoc[] diff --git a/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc b/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc deleted file mode 100644 index 44747f204..000000000 --- a/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc +++ /dev/null @@ -1,159 +0,0 @@ -= Detect and Contain Rogue Agents -:keywords: quarantine agent, contain rogue agent, 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 - -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: This feature 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, so 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. -//* Get notified, through email or Slack, the moment the platform flags an agent. -* Review flagged activity before you act. Nothing quarantines automatically without your review. -* 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 IdP, and 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 xref:gateway::policies-included-jwt-validation.adoc[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. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. In *Portfolio*, select *Model Proxies*. -. Select the model proxy you want to monitor. -. Select *Policies* and then select *+Apply Policy*. -. Select the *Rogue Agent Detection* policy and click *Next*. -. Configure the policy settings: -+ -.. 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. -.. 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. -.. Under *Anomalies to Detect*, add at least one rule. For each rule, select an *Anomaly Type* and, optionally, enter a *Detection Prompt*: -+ -* *PII Leak*, *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. -.. 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 3600. This field is required. -.. (Optional) Expand *Advanced Configuration* to customize the *System Evaluation Prompt*. Most deployments don't need to change this setting. -.. (Optional) Expand *Policy Details* to set a *Policy Label*, *Policy Version*, and *Application Conditions*. -. 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 the model proxy. Apply it to every model proxy where you want to be able to contain an agent. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. In *Portfolio*, select *Model Proxies*, then select the model proxy to protect. -. Select *Policies* and then select *+Apply Policy*. -. Select the *Agent Kill Switch* policy and click *Next*. -. Configure the policy settings: -+ -.. 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. -.. (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. -.. (Optional) Expand *Policy Details* to set a *Policy Label*, *Policy Version*, and *Application Conditions*. -. Select *Apply Policy*. - -Repeat these steps for each model proxy to protect. - -//// -== Set Up Notifications for Flagged Agents - -Configure alerts so you're notified as soon as an agent is flagged. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. Navigate to *Observability* > *Notifications* and select *New Notification*. -. Under *Select Alert Target*, complete the fields: -.. *Environment* -+ -Select the environment to monitor, for example, *Production* or *Sandbox*. -.. *Service Type* -+ -Select *Model Proxy*. -.. *Target Service* -+ -Search for and select the model proxy to receive alerts about. -. Under *Specify Alert Configuration*, select the *Alert Metric*, then set the comparison operator, threshold value, and time window. -.. *Alert Metric* -+ -Select *Policy Violation* and then select the policy. -.. *Alert When* -+ -Select the operator to use in the alert condition, for example, the policy violation occurs greater than 10 times in 5 minutes. -. Under *Set Alert Delivery*: -.. For *Severity*, select *Critical*, *Warning*, or *Info*. -.. In *Alert Name*, enter a descriptive name (four or more characters). -.. In *Delivery Channels*, select *Email*, *Slack*, or both. -. Select *Create Alert*. -//// - -== 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. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. Navigate to *Governance* > *Security*. -+ -The *Security* page shows flagged and reviewed agents from the last 90 days. -. Select *Needs Review*, then find the flagged agent. -. Select *Review* to open the agent's flag history. -. 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. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. Navigate to *Governance* > *Security*. -. Select *Reviewed* and then find the quarantined agent. -. Select *Review* to review the agent's details. -. Select *Restore Model Access*. -. In the confirmation window, select *Restore Model Access* to return the agent to service. -. Select *Close* to close the view with no changes. -+ -After reactivation the audit log records the action. - -== See Also - -* xref:exp-securing-services.adoc[] -* xref:exp-alerts-configure-notifications.adoc[] -* xref:exp-instances-add.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-services-monitoring.adoc[] -* xref:gateway::policies-included-jwt-validation.adoc[] \ No newline at end of file diff --git a/modules/ROOT/pages/exp-glossary.adoc b/modules/ROOT/pages/exp-glossary.adoc deleted file mode 100644 index 20f720423..000000000 --- a/modules/ROOT/pages/exp-glossary.adoc +++ /dev/null @@ -1,129 +0,0 @@ -= Enhanced MuleSoft Experience Glossary -:keywords: enhanced mulesoft experience, glossary, terminology, definitions, mulesoft platform, key terms - -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 xref:exp-services-create-a2a-bridge.adoc[]. - -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 xref:exp-vaults-manage.adoc[]. - -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 xref:exp-vaults-manage.adoc[]. - -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. - -Universal (canonical) policy:: -A provider-agnostic policy you configure once and apply across a mix of gateway providers. Anypoint translates a universal policy into each provider's native policy. Universal 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, universal policies carry a *Universal* 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 universal-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled. diff --git a/modules/ROOT/pages/exp-governance-create-strategy.adoc b/modules/ROOT/pages/exp-governance-create-strategy.adoc deleted file mode 100644 index a8e4e246f..000000000 --- a/modules/ROOT/pages/exp-governance-create-strategy.adoc +++ /dev/null @@ -1,110 +0,0 @@ -= Create Governance Strategies -:keywords: governance strategies, create strategy, strategy workflow, governance scope, strategy type, api governance, mulesoft - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 - -. Log in and go to *Governance* > *Governance Strategies*. -. 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-with-ide] -== 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 https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html[Author a Governance Ruleset] skill in the MuleSoft Developer Hub. - -== See Also - -* xref:exp-governance-work-with-strategies.adoc[] -* xref:exp-governance-manage-strategies.adoc[] -* xref:exp-governance-view-cost-and-token-usage.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-governance-govern-third-party-apis.adoc b/modules/ROOT/pages/exp-governance-govern-third-party-apis.adoc deleted file mode 100644 index 6f576a02c..000000000 --- a/modules/ROOT/pages/exp-governance-govern-third-party-apis.adoc +++ /dev/null @@ -1,23 +0,0 @@ -= Govern Third-Party Provider APIs -:keywords: third-party apis, cross-gateway governance, provider governance, api compliance, policy enforcement - -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: - -. Connect and create a scanner. When the scanner runs, it discovers and catalogs APIs and their read-only policies. See xref:exp-services-view-details.adoc[] - -. 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. - -. 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 https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html[Author a Governance Ruleset] 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`. - -. Create a xref:exp-governance-create-strategy.adoc#create-with-ide[governance strategy] 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. - -. 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 - -* xref:exp-services-view-details.adoc[] -* xref:exp-governance-create-strategy.adoc[] -* https://dev-portal.mulesoft.com/skills/author-governance-ruleset.html[Author a Governance Ruleset] -* xref:exp-governance-monitor-cross-gateway-conformance.adoc[] diff --git a/modules/ROOT/pages/exp-governance-manage-strategies.adoc b/modules/ROOT/pages/exp-governance-manage-strategies.adoc deleted file mode 100644 index fc560a865..000000000 --- a/modules/ROOT/pages/exp-governance-manage-strategies.adoc +++ /dev/null @@ -1,67 +0,0 @@ -= Managing Governance Strategies -:keywords: governance strategies, api governance, strategy metrics, filter strategies, anypoint platform, strategy actions, api management - -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. - -== 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 - -* xref:exp-governance-work-with-strategies.adoc[] -* xref:exp-governance-create-strategy.adoc[] -* xref:exp-governance-view-cost-and-token-usage.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-governance-monitor-cross-gateway-conformance.adoc b/modules/ROOT/pages/exp-governance-monitor-cross-gateway-conformance.adoc deleted file mode 100644 index 601def58d..000000000 --- a/modules/ROOT/pages/exp-governance-monitor-cross-gateway-conformance.adoc +++ /dev/null @@ -1,45 +0,0 @@ -= Monitoring Cross-Gateway Conformance -:keywords: cross-gateway conformance, provider conformance, governance monitoring, compliance tracking, multi-gateway governance - -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: - -* xref:exp-services-view-details.adoc[Connect to one or more third-party providers] to enable cross-gateway governance. -* xref:exp-governance-create-strategy.adoc[Create a governance 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 - -. Log in and go to *Governance* > *Governance Strategies*. -. Select an active strategy. The strategy opens on the *Configuration* tab, which shows the scope and rules. -. 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: - -. On the *Governed Services* tab, locate the *Any provider* filter. -. 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 - -* xref:exp-governance-create-strategy.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-governance-govern-third-party-apis.adoc[] diff --git a/modules/ROOT/pages/exp-governance-policy-library-apply.adoc b/modules/ROOT/pages/exp-governance-policy-library-apply.adoc deleted file mode 100644 index 6df1bea7b..000000000 --- a/modules/ROOT/pages/exp-governance-policy-library-apply.adoc +++ /dev/null @@ -1,81 +0,0 @@ -= Apply Universal Policies -:keywords: policy library, universal policies, canonical policies, governance policies, apply policy, policy catalog - -Governance provides two entry points for applying *universal policies*: the *Apply Policy* flow on the Governance Strategies page, and the *Policy Library* on an individual API instance. A universal 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 universal policy model, the apply and management workflow, activity tracking, and per-provider support, see xref:exp-policies-overview.adoc[] and xref:exp-policies-universal.adoc[]. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-policies-apply-manage.adoc[]. -==== - -== Browse Universal Policies - -You can start applying a universal 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 a Universal Policy - -The apply steps vary depending on where you start. - -=== From the Governance Strategies Page - -. On the Governance Strategies page, select *Add Strategy*, then *Apply Policy*. -. On the *Select Policy* step, select the policy you want to apply. -. On the *Configure Policy* step, set the policy parameters. Required and optional fields vary by policy type. -. On the *Scope* step, choose whether to apply the policy globally or to specific API instances. -. On the *Name & Description* step, name the policy. This step appears only when you apply the policy globally. -. On the *Review* step, review the summary, then apply the policy. - -=== From an API Instance - -. On the API instance, select the *Apply Policy* action to open the Policy Library. -. On the *Select Policy* step, select the policy you want to apply. -. On the *Configure Policy* step, set the policy parameters. Required and optional fields vary by policy type. -. On the *Select Instances* step, select the API instances where you want to apply the policy. -. 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 xref:exp-policies-activity-log.adoc[]. - -For how universal policies map to each provider's native policy, and which policies you can then edit, enable, disable, or remove afterward, see xref:exp-policies-universal.adoc[] and xref:exp-policies-apply-manage.adoc[]. - -== See Also - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-policies-provider-reference.adoc[] -* xref:exp-governance-create-strategy.adoc[] -* xref:exp-governance-work-with-strategies.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-governance-view-cost-and-token-usage.adoc b/modules/ROOT/pages/exp-governance-view-cost-and-token-usage.adoc deleted file mode 100644 index 89c3733cf..000000000 --- a/modules/ROOT/pages/exp-governance-view-cost-and-token-usage.adoc +++ /dev/null @@ -1,193 +0,0 @@ -= Managing Costs and Token Usage -:keywords: cost management, token usage, ai governance, usage metrics, anypoint platform, cost tracking, ai services - -Use cost and token metrics to understand usage, control spend, and identify optimization opportunities. - -Available metrics depend on your tenant configuration and role. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 - -include::partial$exp-navigation-labels.adoc[tag=ExpNavigationLabels] - -== Open Cost Management - -. Log in and go to *Governance* > *Cost Management*. -. 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. --- -. 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. -. Use the *Tokens*/*Cost* toggle to choose how metrics display. See <>. - -[[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 xref:exp-models-manage-costs.adoc[Setting Model Costs for Spend Tracking]. - -=== 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 <>. - -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 - -. In the *Budgets* tab, select *New Budget*. -. 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. --- -. 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 xref:exp-model-wallets-manage.adoc[]. - -== 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: - -. In the *Optimizations* tab, select the sub-tab for the instance type: *Model Proxies*, *Agents*, or *MCP Servers*. -. Locate the instance you want to optimize, and select *View optimizations*. -. In the instance's optimizations view, locate the policy you want to apply. -. Review the policy's *Potential savings*, and expand *Why this policy?* for details. -. 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 - -* xref:exp-model-wallets-manage.adoc[] -* xref:exp-governance-work-with-strategies.adoc[] -* xref:exp-governance-create-strategy.adoc[] -* xref:exp-governance-manage-strategies.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-services-monitoring.adoc[] -* xref:exp-services-view-detailed-metrics.adoc[] diff --git a/modules/ROOT/pages/exp-governance-work-with-strategies.adoc b/modules/ROOT/pages/exp-governance-work-with-strategies.adoc deleted file mode 100644 index c42d357a1..000000000 --- a/modules/ROOT/pages/exp-governance-work-with-strategies.adoc +++ /dev/null @@ -1,89 +0,0 @@ -= Working with Governance Strategies -:keywords: governance strategies, api governance, governance workflows, mulesoft governance, strategy management, anypoint platform - -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: 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-governance-create-strategy.adoc[]. -* Manage strategies by updating scope, rules, status, and priority. See xref:exp-governance-manage-strategies.adoc[]. -* Monitor token usage in *Governance* > *Cost Management*. See xref:exp-governance-view-cost-and-token-usage.adoc[]. -* Review conformance reporting for xref:exp-overview.adoc[supported catalog types]. -* Apply policies to services from *Portfolio*. See xref:exp-services-view-details.adoc[]. - -== 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 - -* xref:exp-governance-create-strategy.adoc[] -* xref:exp-governance-manage-strategies.adoc[] -* xref:exp-governance-view-cost-and-token-usage.adoc[] -* xref:exp-overview.adoc[] -* xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-home-start.adoc b/modules/ROOT/pages/exp-home-start.adoc deleted file mode 100644 index 45deeb6e9..000000000 --- a/modules/ROOT/pages/exp-home-start.adoc +++ /dev/null @@ -1,105 +0,0 @@ -= Get Started with the Enhanced Experience -:keywords: enhanced experience, get started, permissions, workflow, access, anypoint platform, setup -:page-aliases: - -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. - -== 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. -// * Slack -// + -// If your organization integrates the new experience with Slack, use the new experience Slack app to receive notifications and alerts, and follow links back into the product. Your workspace can also offer shortcuts or slash commands your admin configures. -* 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*. - - -[[permissions]] -== Enhanced Experience Permissions -// make this a partial in access management and include there as well. - -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. - -include::access-management::partial$include-permissions-enhanced-exp.adoc[tag=experiencePermissionsTable] - -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. - -//// -== High-Level Enhanced Experience Workflow - -Manage and tune your AI portfolio by registering assets, applying security policies, and monitoring 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 - -. Complete onboarding and access -+ -Confirm your credentials and the permissions your administrator assigned, as described in <>. Finish integration setup for supporting systems, such as connected providers under *Platform* > *Providers*, before you depend on the new experience in production. -. Learn the layout -+ -Sign in through your entry path and land on *Home*. Scan *Portfolio* catalogs, *Governance*, *Observability*, and *Platform* so you know where to register assets, apply policies, read health signals, and manage providers. -. Register assets in Portfolio -+ -Under *Portfolio*, open *Agents*, *MCP Servers*, *Model Proxies*, *APIs*, or *Gateways*. Add assets to work with. Register manually or use connected providers under *Platform* > *Providers* if your organization enables discovery flows. -. Create and manage instances -+ -On *Agents*, *MCP Servers*, *Model Proxies*, and *APIs*, open *Instances* 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. -. Configure policies -+ -On the *Policies* tab for a service or instance, apply governance policies that match access control, data privacy, performance, and compliance goals. Use *Governance* for gateway-wide policy work, organization strategies, and cost tools. -. Review compliance -+ -On *Agents*, *APIs*, and *MCP Servers*, open *Conformance Report* to review scores, violations, and warnings, then address the findings your governance team prioritizes. For gateways, use *Governance* for the same compliance story at the scope the new experience supports. -. Monitor runtime health -+ -On *Monitoring*, review live metrics such as latency, error rates, and request volume when the new experience surfaces Omni Gateway data for managed paths. Compare what you see with dashboards, reports, or notifications under *Observability* when your administrator enabled those views for your team. -. Manage cost -+ -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. -. 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. -. Improve on each cycle -+ -Feed findings from monitoring and governance back into planning for the next change window. -//// - -== See Also - -* xref:exp-overview.adoc[] -* xref:exp-compare.adoc[] diff --git a/modules/ROOT/pages/exp-instances-add.adoc b/modules/ROOT/pages/exp-instances-add.adoc deleted file mode 100644 index 74f125d4e..000000000 --- a/modules/ROOT/pages/exp-instances-add.adoc +++ /dev/null @@ -1,75 +0,0 @@ -= Creating and Managing Instances of Services -:keywords: api instances, apis catalog, create instance, manage instances, anypoint platform, api management, instance configuration - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Open the Service Catalog - -. In *Portfolio*, open the catalog for the service type, such as *APIs*, *Agents*, *MCP Servers*, or *Model Proxies*. -. Select a service to open its detail page. -. 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 - -. In the *Instances* tab, click *Add Instance*. -. 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. --- -. 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. --- -. Under *Target*, enter the *Target URL* where the instance proxies requests. -. 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[Policy Write Prerequisites]. For the apply and management workflow, see xref:exp-policies-apply-manage.adoc[]. - -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 - -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-services-monitoring.adoc[] diff --git a/modules/ROOT/pages/exp-model-wallets-manage.adoc b/modules/ROOT/pages/exp-model-wallets-manage.adoc deleted file mode 100644 index 88bcad659..000000000 --- a/modules/ROOT/pages/exp-model-wallets-manage.adoc +++ /dev/null @@ -1,142 +0,0 @@ -= Capping Spend for Callers of Model Proxies -:keywords: model wallets, model wallet, budgets, token budget, spend limit, model proxies, jwt claims, cost management, anypoint platform - -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. - -[[before-you-begin]] -== Before You Begin - -To manage model wallets, you need: - -* An Anypoint Platform account. -* At least one configured model proxy. See xref:model-proxy-create-model-proxy.adoc[]. -* A configured identity provider (IdP) that issues JWTs for callers. -* Policies configured on each model proxy that callers reach through the wallet. See <>. -* 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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]] -== 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*. - -. From *Portfolio* > *Model Proxies*, open the model proxy. -. Select the *Policies* tab. -. From the actions menu for *DataWeave Headers Transformation*, select *Disable Policy*. -. From the actions menu for *Client ID Enforcement*, select *Disable Policy*. -. Select *Apply Policy*. -. Select *JWT Validation*, and then select *Next*. -. 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 xref:gateway::policies-included-jwt-validation.adoc[JWT Validation policy]. -. Select *Apply Policy*. -. Select *Reorder Instance Policies*. -. Move *JWT Validation* to the second position. -+ -The xref:gateway::policies-included-cors.adoc[CORS] policy remains first. JWT Validation in the second position validates the token before later policies read the claims. -. Select *Save Order*. -. From the actions menu for *LLM Proxy Core Policy*, select *Edit Configuration*. -. In *Client ID*, enter: -+ ----- -#[authentication.properties.claims.client_id] ----- -+ -This expression reads the `client_id` claim after JWT Validation publishes the verified claims. -. 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 - -Create a model wallet to define the client ID, JWT claims, and optional budgets for a caller. - -. From *Portfolio* > *Model Proxies* > *Model Wallets*, select *New Model Wallet*. -. In *Name*, enter a name for the wallet, for example, `Finance Analytics Bot`. -. (Optional) Enter a *Description* of the wallet's purpose. -. Under *Authentication*, copy the system-generated *Client ID*. -+ -The Client ID is read-only. Callers send the Client ID as the `X-Client-Id` request header to select the wallet. -. Select *Add Claim* and enter at least one required claim: -+ --- -** In *Required Claims*, enter one or more claim keys, for example, `group`. -** 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. -. (Optional) To cap spend or token usage, add one or more budgets. See <>. -. Select *Create Model Wallet*. - -[[view-model-wallets]] -== 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]] -== Edit a Model Wallet - -. From *Portfolio* > *Model Proxies* > *Model Wallets*, open the wallet and select *Edit*. -. Change the *Name*, *Description*, or *Required Claims*. -+ -The *Client ID* is read-only. -. 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 - -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. - -. Open the model wallet from *Portfolio* > *Model Proxies* > *Model Wallets*, or open the budgets view in *Governance* > *Cost Management*. -. In the *Budgets* section, select *Add Budget*. -. 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. --- -. 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 xref:exp-models-manage-costs.adoc[Setting Model Costs for Spend Tracking]. - -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 - -* xref:model-proxy-create-model-proxy.adoc[] -* xref:model-proxy-policies.adoc[] -* xref:gateway::policies-included-jwt-validation.adoc[] -* xref:gateway::policies-included-client-id-enforcement.adoc[] -* xref:gateway::policies-included-dataweave-headers-transformation.adoc[] -* xref:exp-governance-view-cost-and-token-usage.adoc[] -* xref:exp-services-register-manually.adoc[] diff --git a/modules/ROOT/pages/exp-models-manage-costs.adoc b/modules/ROOT/pages/exp-models-manage-costs.adoc deleted file mode 100644 index a73f7b6e3..000000000 --- a/modules/ROOT/pages/exp-models-manage-costs.adoc +++ /dev/null @@ -1,48 +0,0 @@ -= Setting Model Costs for Spend Tracking -:keywords: models, model costs, cost per token, input tokens, output tokens, spend tracking, budgets, model proxies, cost management, anypoint platform - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== View Models - -The *Models* page lists available models, the proxies that use them, and any costs you have set. - -. From *Portfolio* > *Model Proxies* > *Model Wallets*, select *Models*. -. Review the list of available models. -. 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. - -[[edit-model-costs]] -== Edit Model Costs - -Model costs drive spend and budget calculations. Set a cost per token for each model that you use. - -. From *Portfolio* > *Model Proxies* > *Model Wallets*, select *Models*. -. Select a model, for example, `Claude 3.5 Haiku`. -. Select *Edit model costs*. -. Enter the *Cost per 1M input tokens*, for example, `0.001`. -. Enter the *Cost per 1M output tokens*, for example, `0.005`. -. 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 xref:exp-model-wallets-manage.adoc[Capping Spend for Callers of Model Proxies]. - -== See Also - -* xref:exp-model-wallets-manage.adoc[Capping Spend for Callers of Model Proxies] -* xref:exp-governance-view-cost-and-token-usage.adoc[] diff --git a/modules/ROOT/pages/exp-overview.adoc b/modules/ROOT/pages/exp-overview.adoc deleted file mode 100644 index 840d052e0..000000000 --- a/modules/ROOT/pages/exp-overview.adoc +++ /dev/null @@ -1,64 +0,0 @@ -= Enhanced MuleSoft Experience Overview -:keywords: enhanced mulesoft experience, enhanced experience, capabilities, workflow, mulesoft overview, experience features - -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 xref:exp-vaults-manage.adoc[]. - -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. - -. Complete onboarding and access the enhanced experience. -+ -Confirm your credentials and the permissions that your administrator assigned, as described in xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-home-start.adoc[]. -. 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 xref:exp-portfolio-overview.adoc[]. -For AI assistant usage, see xref:exp-ai-assistant-use.adoc[]. -. 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 xref:exp-services-add-to-portfolio.adoc[]. -. 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 xref:exp-instances-add.adoc[]. -. 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[Policy Write Prerequisites]. Use top-level *Governance* for gateway-wide policy work, organization strategies, and cost tools. For governance policy workflows, see xref:exp-governance-work-with-strategies.adoc[]. -. 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 xref:exp-services-view-details.adoc[]. -. 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 xref:exp-services-monitoring.adoc[]. -. 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 xref:exp-governance-view-cost-and-token-usage.adoc[]. -. 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 xref:exp-services-view-details.adoc[]. -. Improve on each cycle. -+ -Feed findings from monitoring and governance back into planning for the next change window. For strategy refinement workflows, see xref:exp-governance-work-with-strategies.adoc[]. - -== See Also - -* xref:exp-home-start.adoc[] -* xref:exp-compare.adoc[] -* xref:learning-map-exp.adoc[] diff --git a/modules/ROOT/pages/exp-playground-api.adoc b/modules/ROOT/pages/exp-playground-api.adoc deleted file mode 100644 index 89ca1f088..000000000 --- a/modules/ROOT/pages/exp-playground-api.adoc +++ /dev/null @@ -1,85 +0,0 @@ -= Testing APIs in the API Playground -:keywords: api playground, test api, api endpoints, api authentication, request snippet, api response, anypoint platform, enhanced experience - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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. - -. In *Portfolio*, open the *APIs* catalog and select the REST API you want to test. -. 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 - -. In the endpoint list, select the endpoint you want to test (for example, a *POST* endpoint that creates a new record). -. 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. - -. In the authentication section, select an authentication method. If the API owner enabled only one method (for example, API key), use that method. -. 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. - -. Select the format you want for the snippet. -. Copy the snippet to use it outside the playground. - -== Send the Request and Review the Response - -. After configuring the request, select *Send*. -. 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 - -* xref:exp-playground-overview.adoc[] -* xref:exp-playground-mcp.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-instances-add.adoc[] diff --git a/modules/ROOT/pages/exp-playground-mcp.adoc b/modules/ROOT/pages/exp-playground-mcp.adoc deleted file mode 100644 index cfba301a6..000000000 --- a/modules/ROOT/pages/exp-playground-mcp.adoc +++ /dev/null @@ -1,45 +0,0 @@ -= Exploring MCP Server Tools in the MCP Playground -:keywords: mcp server playground, test mcp server, mcp tools, tool invocation, anypoint platform, enhanced experience - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Open the MCP Server Playground - -. In *Portfolio*, open the *MCP Servers* catalog and select the MCP server you want to test. -. 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. - -. In the tool list, select the tool you want to test. -. If you aren't already authenticated to the MCP server, configure authentication. If you're already authenticated, you don't need to authenticate again. -. Configure the tool's parameters in form or JSON format. -. (Optional) Copy the request snippet, which reflects your configuration. -. Select *Execute* to invoke the tool. -. 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 - -* xref:exp-playground-overview.adoc[] -* xref:exp-playground-api.adoc[] -* xref:exp-services-create-mcp-server.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-claude-desktop-connect.adoc[] diff --git a/modules/ROOT/pages/exp-playground-overview.adoc b/modules/ROOT/pages/exp-playground-overview.adoc deleted file mode 100644 index b5fc6cc0b..000000000 --- a/modules/ROOT/pages/exp-playground-overview.adoc +++ /dev/null @@ -1,51 +0,0 @@ -= Testing Services with Playgrounds -:keywords: playground, api playground, mcp server playground, test api, test mcp server, anypoint platform, enhanced experience - -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. - -== 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 xref:exp-playground-api.adoc[]. - -MCP server playground:: -+ -Test an MCP server by exploring and invoking individual tools and inspecting their responses. See xref:exp-playground-mcp.adoc[]. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Open the Playground - -. In *Portfolio*, open the catalog for the service type (for example *APIs* or *MCP Servers*). -. Use the search box to find the service by name or description, or scan the list or grid. -. Select the service to open its detail page. -. Select the *Playground* tab. - -The playground opens with the endpoints or tools available for the service you're viewing. - -== See Also - -* xref:exp-playground-api.adoc[] -* xref:exp-playground-mcp.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-instances-add.adoc[] - diff --git a/modules/ROOT/pages/exp-policies-activity-log.adoc b/modules/ROOT/pages/exp-policies-activity-log.adoc deleted file mode 100644 index 52700a986..000000000 --- a/modules/ROOT/pages/exp-policies-activity-log.adoc +++ /dev/null @@ -1,46 +0,0 @@ -= Tracking Policy Operations in the Activity Log -:keywords: activity log, policy operations, asynchronous operations, policy status, api manager, anypoint platform - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 *Universal* (a universal 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 - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-universal.adoc[] -* xref:exp-policies-provider-reference.adoc[] diff --git a/modules/ROOT/pages/exp-policies-apply-manage.adoc b/modules/ROOT/pages/exp-policies-apply-manage.adoc deleted file mode 100644 index 31a4138f5..000000000 --- a/modules/ROOT/pages/exp-policies-apply-manage.adoc +++ /dev/null @@ -1,72 +0,0 @@ -= Applying and Managing Policies -:keywords: apply policy, edit policy, remove policy, enable policy, disable policy, external gateways, api manager, anypoint platform - -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 xref:exp-policies-provider-reference.adoc[]. - -== Before You Begin - -Before getting started, make sure you have: - -* An Anypoint Platform account. -* The API Manager: Manage Policies permission. -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-policies-provider-reference.adoc[]. - -[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 - -. In *Portfolio*, open the API and select the instance. -. Open the *Policies* tab and select *Apply Policy*. -. Choose the policy and configure it. -. 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 <>. -. Apply the policy. Anypoint accepts the request and performs it in the background. Confirm the outcome in the *Activity log* tab. See xref:exp-policies-activity-log.adoc[]. - -To apply a universal policy across multiple providers at once, use the *Policy Library* instead. See xref:exp-policies-universal.adoc[]. - -[[policy-edit-restrictions]] -== 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 universal use cases, plus several additional native Kong policies (see xref:exp-policies-universal.adoc[]); other recognized policies are view-only. Native policies created from a universal 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 xref:exp-policies-provider-reference.adoc#supported-actions-by-provider[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 xref:exp-policies-provider-reference.adoc#instance-locking-during-operations[Instance Locking During Operations]. - -[[policy-naming-and-identity]] -== 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 - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-policies-provider-reference.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-policies-overview.adoc b/modules/ROOT/pages/exp-policies-overview.adoc deleted file mode 100644 index c988f88dc..000000000 --- a/modules/ROOT/pages/exp-policies-overview.adoc +++ /dev/null @@ -1,40 +0,0 @@ -= Managing Policies on Gateway Providers -:keywords: policies, gateway policies, external gateways, apigee, azure api management, kong, api manager, anypoint platform - -Manage policies not only on Anypoint 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 Anypoint UI, 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. -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-scanners-add-from-providers.adoc[]. - -== 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 xref:exp-services-view-details.adoc#view-read-policies-discovered-by-scanners[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 - -Anypoint recognizes and displays every policy it discovers, but you can create and edit only a curated set: the policies that back the universal use cases, plus several additional native Kong policies. See xref:exp-policies-universal.adoc[]. 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 xref:exp-policies-apply-manage.adoc[] and xref:exp-policies-provider-reference.adoc[]. - -== How Policy Operations Work - -Every policy change on an external provider, such as apply, edit, enable, disable, or remove, runs asynchronously: Anypoint 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 xref:exp-policies-activity-log.adoc[]. - -== See Also - -* xref:exp-policies-universal.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-policies-provider-reference.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] diff --git a/modules/ROOT/pages/exp-policies-provider-reference.adoc b/modules/ROOT/pages/exp-policies-provider-reference.adoc deleted file mode 100644 index b9cd6119b..000000000 --- a/modules/ROOT/pages/exp-policies-provider-reference.adoc +++ /dev/null @@ -1,143 +0,0 @@ -= Provider Support and Limitations for Policies -:keywords: policy provider support, apigee, azure api management, kong, aws, injection points, policy permissions, anypoint platform - -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 xref:exp-scanners-add-from-providers.adoc[]. - -[[supported-actions-by-provider]] -== Supported Actions by Provider - -[cols="2,^1,^1,^1,^1",options="header"] -|=== -|Provider |Apply |Edit |Remove |Enable/Disable - -|Anypoint -|Yes |Yes |Yes |Yes - -|Kong Gateway -|Yes |Yes |Yes |Yes - -|Google Apigee -|Yes |Yes |Yes |No (no native concept) - -|Azure API Management -|Yes |Yes |Yes |No (no native concept) - -|Amazon API Gateway -|No |No |No |No (not supported yet) -|=== - -[NOTE] -==== -* Apply and Edit are further limited to the supported (universal-backed) policies. A Yes in the Edit column means the provider supports editing, not that every policy is editable. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[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. -==== - -== 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: Anypoint checks the connected Google service account's actual permissions on Google Cloud. See <>. -* Azure API Management: Anypoint 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. -* Anypoint: 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 Anypoint. -* Kong Gateway: the injection point is informational only; Kong's plugin phase is fixed, so it doesn't change placement. - -[[instance-locking-during-operations]] -== 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. -* Anypoint 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 xref:exp-policies-activity-log.adoc[]. - -[[apigee-required-permissions-and-roles]] -== 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. Anypoint checks the account's effective permissions, not the role name. - -[[supported-policies-and-native-equivalents]] -== Supported Policies and Native Equivalents - -At launch, Anypoint supports five universal 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. - -[cols="1,1,1,1,1",options="header"] -|=== -|Universal Use Case |Anypoint |Google Apigee |Azure API Management |Kong 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 Anypoint's Header Manipulation is two policies (injection and removal). -==== - -Beyond the universal use cases, Anypoint also supports 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 - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-universal.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] diff --git a/modules/ROOT/pages/exp-policies-universal.adoc b/modules/ROOT/pages/exp-policies-universal.adoc deleted file mode 100644 index a5d9966c1..000000000 --- a/modules/ROOT/pages/exp-policies-universal.adoc +++ /dev/null @@ -1,67 +0,0 @@ -= Universal Policies -:keywords: universal policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform - -A universal policy is a provider-agnostic authoring experience. You configure one policy once, and Anypoint 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 Anypoint instances at the same time. In the UI, universal policies carry a *Universal* badge, indicating that they work across all gateways. - -You apply universal policies from the *Policy Library*, which walks you through four steps: *Select Policy*, *Configure Policy*, *Select Instances*, and *Review & Apply*. - -== Universal Use Cases - -At launch, there are five universal use cases. Each maps to a specific native policy per provider. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[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. Anypoint also supports several additional native Kong policies. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[Supported Policies and Native Equivalents]. Other recognized policies are view-only. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[Policy Edit Restrictions]. - -== Universal Is a Creation Experience - -Use a universal policy to implement a use case across multiple native gateways from a single starting point. Only native policies remain on each provider. No separate universal 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 universal object to manage separately. - -== Confirming What Happened - -Because universal is only a creation experience, there is no dedicated universal activity view. To see the outcome on each target, open that instance's *Activity log* tab. Universal applies appear there with the *Universal* action type. See xref:exp-policies-activity-log.adoc[]. - -[NOTE] -==== -When a universal policy targets Anypoint instances, there is currently no Activity log record for those targets, so there's no in-product way to confirm the outcome on Anypoint targets. This is a known limitation. For external providers (Apigee, Azure, and Kong), you can follow the outcome in each instance's *Activity log*. -==== - -== Universal vs. Automated vs. Governance - -These three are easy to confuse. Use this comparison to choose the right tool: - -[cols="1,2,2,2",options="header"] -|=== -| | Universal | Automated Policies | Governance - -|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 universal 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. -|Anypoint native (Omni and Mule), applied automatically by matching rules. -|Across APIs and instances. -|=== - -For automated policies and governance strategies, see xref:exp-governance-work-with-strategies.adoc[]. - -== See Also - -* xref:exp-policies-overview.adoc[] -* xref:exp-policies-apply-manage.adoc[] -* xref:exp-policies-activity-log.adoc[] -* xref:exp-policies-provider-reference.adoc[] -* xref:exp-governance-work-with-strategies.adoc[] diff --git a/modules/ROOT/pages/exp-portfolio-overview.adoc b/modules/ROOT/pages/exp-portfolio-overview.adoc deleted file mode 100644 index 7b9bf2f3e..000000000 --- a/modules/ROOT/pages/exp-portfolio-overview.adoc +++ /dev/null @@ -1,40 +0,0 @@ -= View Your Portfolio Overview -:keywords: portfolio overview, anypoint platform, api management, integration monitoring, portfolio dashboard, mulesoft - -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. -include::_partials/exp-navigation-labels.adoc[tag=ExpNavigationLabels] - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions] for more information. - -== See Also - -* xref:exp-overview.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-providers-manage.adoc b/modules/ROOT/pages/exp-providers-manage.adoc deleted file mode 100644 index 33f5bb5ad..000000000 --- a/modules/ROOT/pages/exp-providers-manage.adoc +++ /dev/null @@ -1,117 +0,0 @@ -= Viewing and Managing Provider Connections -:keywords: providers, scanners, providers page, provider list, view providers, manage providers, anypoint platform - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Access the Providers Page - -. Sign in to the enhanced experience through your organization's entry point. -. 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 xref:exp-scanners-view-details.adoc[]. - -For information about managing scanners, see xref:exp-scanners-manage.adoc[]. -For Akamai-specific setup and result interpretation, see xref:exp-akamai-risk-correlation.adoc[]. - -== Connect a New Provider - -To add a provider connection: - -. From *Platform* > *Providers*, select a provider from the *Not Connected* section. -. 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 xref:exp-scanners-add-from-providers.adoc#microsoft-copilot-studio-scanner-oauth-authorization[]. - -For detailed scanner setup instructions, see xref:exp-scanners-add-from-providers.adoc[]. - -[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 xref:exp-vaults-manage.adoc[]. -==== - -== 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 -* 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[Policy Write Prerequisites]. - -The specific providers available depend on your organization's enabled products and enhanced experience configuration. - -== See Also - -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-akamai-risk-correlation.adoc[] -* xref:exp-scanners-view-details.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-scanners-manage.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-vaults-manage.adoc[] diff --git a/modules/ROOT/pages/exp-release-notes.adoc b/modules/ROOT/pages/exp-release-notes.adoc deleted file mode 100644 index db9ebdce3..000000000 --- a/modules/ROOT/pages/exp-release-notes.adoc +++ /dev/null @@ -1,2 +0,0 @@ -:keywords: experience hub release notes, api experience hub, new features, bug fixes, known issues, version history, mulesoft experience hub -include::release-notes::partial$enhanced-mulesoft-experience/enhanced-mulesoft-exp-rn-landing-page.adoc[] diff --git a/modules/ROOT/pages/exp-scanners-add-from-providers.adoc b/modules/ROOT/pages/exp-scanners-add-from-providers.adoc deleted file mode 100644 index a9419f54e..000000000 --- a/modules/ROOT/pages/exp-scanners-add-from-providers.adoc +++ /dev/null @@ -1,127 +0,0 @@ -= Adding Scanners from Providers -:keywords: scanners, providers, add scanner, scanner configuration, workflow, anypoint platform, security scanning - -A scanner is the configured link between the system and a supported cloud provider that lets discovery jobs find services—such as APIs, agents, and MCP servers—and register them in the right *Portfolio* catalogs, and to discover and read policies from API configurations. Scanners enable automated discovery so your catalogs stay current without manual registration. Configure a scanner once to turn on discovery for a provider, then extend it as your organization adds catalogs or enabled features. - -For how provider connection and catalogs fit together, see xref:exp-services-connect-providers-to-add.adoc[] and xref:exp-services-add-to-portfolio.adoc[]. - -== Before You Begin - -Before getting started, make sure you have: - -* An Anypoint Platform account. -* Exchange Administrator - - -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. -For provider-specific roles, credentials, and permission scopes, see xref:exp-scanners-prerequisites-reference.adoc[]. - -== 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[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. - - -include::_partials/exp-navigation-labels.adoc[tag=ExpNavigationLabels] - - -== 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 xref:exp-akamai-risk-correlation.adoc[]. - -=== 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. - -== Microsoft Copilot Studio Scanner OAuth Authorization - -Microsoft Copilot Studio scanners support two authentication schemes. Create, authorize, and test the provider connection before you continue scanner setup. - -* *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`. - -. From *Platform* > *Providers*, select *Microsoft*. -. In *Connect to Provider*, under *Platform*, select *Microsoft Copilot Studio*. -. Under *Authentication*, select *OAuth* or *OAuth (Authorization Code)*. -. Enter connection values: -* *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`. Required for *OAuth (Authorization Code)*; optional for *OAuth*. -. Complete the connection: -* For *OAuth*, click *Test Connection* and confirm the connection succeeds. -* For *OAuth (Authorization Code)*, click *Create & Authorize Connection*. In the Microsoft popup window, sign in and grant consent, then wait for status to progress through *Connection created*, *Authorized*, and *Tested*. -. Confirm the connection succeeds or the message *Connected to Microsoft* appears, then click *Continue*. - -[NOTE] -==== -The OAuth (Authorization Code) flow opens a Microsoft sign-in popup. If your browser blocks popups, authorization can't complete and scanner setup stays in the authorizing state. -==== - -== 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 xref:exp-scanners-prerequisites-reference.adoc[]. - -== 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 xref:exp-scanners-manage.adoc[]. - -== See Also - -* xref:exp-scanners-prerequisites-reference.adoc[] -* xref:exp-akamai-risk-correlation.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-scanners-prerequisites-reference.adoc[] -* xref:exp-scanners-manage.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-scanners-manage.adoc b/modules/ROOT/pages/exp-scanners-manage.adoc deleted file mode 100644 index eb60a2fc5..000000000 --- a/modules/ROOT/pages/exp-scanners-manage.adoc +++ /dev/null @@ -1,39 +0,0 @@ -= Running and Managing Scanners -:keywords: scanners, managing scanners, scanner actions, security scanning, mulesoft, vulnerability detection - -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. - -== 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[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 - -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc b/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc deleted file mode 100644 index f636f39f1..000000000 --- a/modules/ROOT/pages/exp-scanners-prerequisites-reference.adoc +++ /dev/null @@ -1,337 +0,0 @@ -= Scanner Prerequisites by Provider -:keywords: scanner prerequisites, exchange scanners, provider scanners, required roles, required credentials, scanner setup, vaults - -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 xref:_policy_write_prerequisites[]. Write scopes are noted in the matrix as *Write scope (policy apply)*. - -== Before You Begin - -Before adding any scanner, make sure you have: - -* Exchange Administrator permission. -* Access to, and active context in, the business group where you want to add the scanner. - -== Scanner Prerequisite Matrix - - -[cols="1,1,3",options="header"] -|=== -| Provider -| Type -| Required Credentials, Roles, and Setup - -| Amazon Bedrock -| Agent -a| -*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 -a| -*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 -a| -*Credentials:* Claude API key - -*Account:* Paid Anthropic account - -| Databricks Agent Bricks -| Agent -a| -*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 -a| -*Credentials:* API key and API secret - -| Google Gemini Agent Enterprise Platform -| Agent -a| -*Credentials:* GCP project ID; service account email; private key - -*Role:* Vertex AI Viewer - -| LangChain LangSmith -| Agent -a| -*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 -a| -*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:///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://.crm.dynamics.com` - -For setup steps, see xref:exp-scanners-add-from-providers.adoc#microsoft-copilot-studio-scanner-oauth-authorization[]. - -| Microsoft Foundry -| Agent -a| -*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 -a| -*Connection:* xref:access-management::managing-connected-salesforce-orgs.adoc#enable-disable-connection[Enable the connection to a Salesforce organization] that has an established tenant relationship with your Anypoint Platform organization. - -*Setup:* xref:access-management::enabling-generative-ai.adoc#enable-einstein-anypoint[Enable generative AI in Anypoint Platform], accept the terms and conditions, and set a default Salesforce organization - -*Permissions:* Exchange Administrator permission - -| Snowflake Cortex AI -| Agent -a| -*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 (``) - -| Amazon API Gateway -| API -a| -*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/*` - -// TODO: Amazon API Gateway policy write is deferred to a later release. Restore the write scope below when AWS write support ships. -//// -*Write scope (policy apply):* IAM write permissions for API Gateway, in addition to the read permissions: - -* `apigateway:PUT` -* `apigateway:POST` -* `apigateway:DELETE` -//// - -[NOTE] -For web application firewall (WAF) policies, the scanner also uses `software.amazon.awssdk:wafv2` and `software.amazon.awssdk:route53`. - -| Azure API Management -| API -a| -*Credentials:* Tenant ID; client ID; client secret; subscription ID; resource group; service name - -*Role:* API Management Service Reader - -* *Read role scope:* API Management Service Reader at the API Management resource or resource group scope -* *Read OAuth scope:* `https://management.azure.com/.default` - -*Write scope (policy apply):* API Management Service Contributor role (ARM) at the API Management resource or resource group scope - -| Google Apigee -| API -a| -*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 -a| -*Credentials:* Personal access token (PAT); Kong Gateway region - -*Role:* Kong Control Plane Viewer - -* *Apply read scope:* Admin API read permission required to read policy in target environments - -*Write scope (policy apply):* Admin API write permission required to apply, enable, disable, or remove policy in target environments - -| Akamai Security -| API Security -a| -*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 xref:exp-akamai-risk-correlation.adoc[]. - -| Amazon Bedrock AgentCore MCP -| MCP -a| -*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 -a| -*Credentials:* Tenant ID; client ID; client secret; subscription ID; resource group; service name - -*Role:* API Management Service Reader - -| Snowflake MCP Server -| MCP -a| -*Credentials:* Snowflake account URL; programmatic access token (PAT) - -*Account:* Snowflake Enterprise account with MCP servers enabled - -*Role:* `ACCOUNTADMIN` - -| Amazon (AWS Secrets Manager) -| Vault -a| -*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 -a| -*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 -a| -*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. - -// TODO(W-23907611): Credential-model discrepancy to confirm with PM/eng. This section was -// grounded in the Omni-app code (separate read vs. write credentials, an explicit Read-Only -// state until write credentials are added). The External Policies Documentation Guide instead -// describes policy write as reusing the SAME scanner connection, with write gated only by the -// permissions granted to that connection's identity on the provider. The text below follows -// the guide (single reused connection). Confirm which model ships before publishing. - -Policy write reuses the same connection you configure for scanning; there's no separate policy-write connection. Before you can write policies, confirm these prerequisites in addition to the discovery prerequisites in the matrix: - -* *Write permissions on the connection:* The scanner connection's identity must have the provider's write scope, not just read access. A connection with read-only access to the provider can discover and read policies, but policy actions remain unavailable. -* *Write scope:* The write scope covers enabling, disabling, and removing existing vendor-native policies, and creating and editing universal (canonical) policies, at both the instance and service scope. Creating and editing native vendor policies isn't supported. -* *Provider write permissions:* Grant the provider-specific *Write scope (policy apply)* listed for each API gateway provider in the xref:_scanner_prerequisite_matrix[]. - -The following table summarizes the read and write scopes for each API gateway provider that supports policy write. - -[cols="1,1,1",options="header"] -|=== -| Provider -| Read Scope -| Write Scope - -// TODO: Amazon API Gateway policy write is deferred to a later release. Restore this row when AWS write support ships. -//// -| Amazon API Gateway -| `apigateway:GET` -| `apigateway:PUT`, `apigateway:POST`, `apigateway:DELETE` -//// - -| Azure API Management -| Reader role (ARM) -| API Management Service Contributor role (ARM) - -| Google Apigee -| Viewer role (Management API) -| API Admin role (Management API) - -| Kong Gateway -| Admin API read -| Admin API write -|=== - -=== Read-Only APIs - -When a scanner connection has only read access to a gateway, its API instances appear as *Read-Only* and policy actions are unavailable. To enable policy write, grant the connection's identity the provider's write scope, then update the connection from the API instance. - -=== Tracked Applies - -Every policy write is tracked and records an applied or failed state alongside the scanner-read configuration. Anypoint logs each write as compliance evidence, including the policy, the target, the vendor, the timestamp, and the result. To follow the outcome of a policy operation, use the *Activity log* tab on the API instance. See xref:exp-policies-activity-log.adoc[]. - -// NOTE(W-23907611): The Activity log records action, policy, status, and time only — it does -// not record an actor ("who"). Do not describe it as a full who-did-what audit trail. - -[NOTE] -Anypoint doesn't manage vendor policy lifecycle, versioning, or CI/CD. - -== See Also - -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-providers-manage.adoc[] -* xref:exp-scanners-manage.adoc[] -* xref:exp-akamai-risk-correlation.adoc[] diff --git a/modules/ROOT/pages/exp-scanners-view-details.adoc b/modules/ROOT/pages/exp-scanners-view-details.adoc deleted file mode 100644 index e934f3531..000000000 --- a/modules/ROOT/pages/exp-scanners-view-details.adoc +++ /dev/null @@ -1,60 +0,0 @@ -= Viewing Scanner History and Settings -:keywords: scanner detail tabs, scanner overview tab, scanner services tab, scanner settings tab, provider scanners - -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 - -. From *Platform* > *Providers*, open a connected provider. -. Select a configured scanner from the scanner list. -. 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 xref:exp-scanners-prerequisites-reference.adoc#_policy_write_prerequisites[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 - -* xref:exp-providers-manage.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-akamai-risk-correlation.adoc[] -* xref:exp-scanners-manage.adoc[] diff --git a/modules/ROOT/pages/exp-securing-services.adoc b/modules/ROOT/pages/exp-securing-services.adoc deleted file mode 100644 index d5055aa1f..000000000 --- a/modules/ROOT/pages/exp-securing-services.adoc +++ /dev/null @@ -1,24 +0,0 @@ -= Securing Services in Your Portfolio -:keywords: securing services, external vaults, secrets manager, credentials, Akamai API Security, risk correlation, rogue agents, Azure Key Vault, HashiCorp Vault, portfolio, anypoint platform - -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. - -* xref:exp-akamai-risk-correlation.adoc[Correlate Risk Using Akamai API Security] -+ -See risk scores, findings, and incidents on the APIs and MCP services you already govern, so teams can triage and remediate from one place. - -* xref:exp-vaults-manage.adoc[Use Credentials Stored in External Vaults] -+ -Authenticate model proxies without storing API keys in MuleSoft. Credentials stay in your external vault. - -* xref:exp-detect-and-contain-rogue-agents.adoc[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 - -* xref:exp-akamai-risk-correlation.adoc[] -* xref:exp-vaults-manage.adoc[] -* xref:exp-detect-and-contain-rogue-agents.adoc[] -* xref:exp-providers-manage.adoc[] -* xref:model-proxy.adoc[] diff --git a/modules/ROOT/pages/exp-services-add-to-portfolio.adoc b/modules/ROOT/pages/exp-services-add-to-portfolio.adoc deleted file mode 100644 index 3fea7422e..000000000 --- a/modules/ROOT/pages/exp-services-add-to-portfolio.adoc +++ /dev/null @@ -1,74 +0,0 @@ -= Adding Services to Your Portfolio -:keywords: add services, portfolio, service registration, service types, workflow, anypoint platform - -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. - -[cols="1,2",options="header"] -|=== -|Approach |What Happens - -|xref:exp-services-connect-providers-to-add.adoc[] -|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. - -|xref:exp-akamai-risk-correlation.adoc[] -|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. - -|xref:exp-services-register-manually.adoc[] -|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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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. - -include::_partials/exp-navigation-labels.adoc[tag=ExpNavigationLabels] - -== 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 xref:exp-services-register-manually.adoc[] and xref:exp-services-connect-providers-to-add.adoc[]. - -== See Also - -* xref:exp-scanners-prerequisites-reference.adoc[] -* xref:exp-akamai-risk-correlation.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-services-connect-providers-to-add.adoc b/modules/ROOT/pages/exp-services-connect-providers-to-add.adoc deleted file mode 100644 index 08ceb0f3d..000000000 --- a/modules/ROOT/pages/exp-services-connect-providers-to-add.adoc +++ /dev/null @@ -1,67 +0,0 @@ -= Create a Scanner for Provider Services -:keywords: scanner, provider services, create scanner, entry points, experience services, mulesoft integration, service discovery - -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 xref:exp-services-add-to-portfolio.adoc[]. To create and tune scanners, see xref:exp-scanners-add-from-providers.adoc[]. - -[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 xref:exp-vaults-manage.adoc[]. -==== - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 - -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-vaults-manage.adoc[] diff --git a/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc b/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc deleted file mode 100644 index a9709813b..000000000 --- a/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc +++ /dev/null @@ -1,162 +0,0 @@ -= Make an Agent A2A-Compliant -:keywords: a2a bridge, agent2agent, agentforce bridge, a2a compliant, agent fabric, non-a2a agent, omni gateway, source agent - -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-it-works]] -== 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-platforms]] -== Supported Source Platforms - -[cols="1,1,2a", options="header"] -|=== -| Source platform | Bridge availability | Notes - -| Salesforce Agentforce -| Available -| Bridge translates A2A to the Agentforce Einstein AI Agent v1 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 xref:exp-services-register-manually.adoc[]. - -| Other platforms -| Extensible -| Build a custom bridge policy with the Policy Development Kit (PDK), or use xref:a2a-connector::index.adoc[A2A Connector]. -|=== - -[[before-you-begin]] -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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-a2a-bridge]] -== Create an A2A Bridge - -You create a bridge from the source agent's detail page. - -. In *Portfolio*, open the *Agents* catalog and select the source agent you want to bridge. -. On the *Overview* tab, select *Configure A2A Bridge & Deploy First Instance*. -. 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. -. Add custom skills or hide skills as needed. Each skill must have a unique ID. -. Click *Continue: Deploy Instance*. -. 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. --- -. 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. Select *None* to leave the endpoint unauthenticated. -. 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. -. Expand *Advanced* to review or adjust the generated policy configuration. -. 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-instance]] -== 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]] -== 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. - -[[migration]] -== 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 - -* xref:agent-fabric-overview.adoc[] -* xref:exp-services-create-mcp-server.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:a2a-connector::index.adoc[] diff --git a/modules/ROOT/pages/exp-services-create-mcp-server.adoc b/modules/ROOT/pages/exp-services-create-mcp-server.adoc deleted file mode 100644 index 378839ff1..000000000 --- a/modules/ROOT/pages/exp-services-create-mcp-server.adoc +++ /dev/null @@ -1,57 +0,0 @@ -= Create MCP Servers -:keywords: mcp server, create mcp server, model context protocol, anypoint platform, mcp configuration, api integration - -Create MCP servers to define identity, runtime connectivity, and the tools and resources exposed to MCP clients. - -Creating an MCP server defines a new MCP implementation—for example, by transcoding an existing REST API or creating a runtime deployment—and establishes the server identity, runtime connectivity, and the MCP capabilities (tools and resources) exposed to clients. - -When you create an MCP server in Enhanced Experience, the server is added to *Portfolio* automatically. - -During creation, you define: - -* *Service definition* -+ -Name, description, and ownership metadata so teams can identify the server in catalogs and governance views. -* *Connection and runtime details* -+ -Endpoint and access settings Enhanced Experience uses at runtime to connect to underlying SaaS systems. -* *Capability surface* -+ -The MCP tools and resources clients can discover and invoke. -* *Validation and readiness* -+ -Checks that confirm the server is reachable and that the declared MCP capabilities are usable. - -== 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 --- -* This API Manager permission on at least one environment: -+ -** API Manager: Manage APIs Configuration -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Create an MCP Server - -. Open *MCP Servers* and select *Add MCP Server* > *Create MCP Server*. -. In *Select Source, Instance & Tools*, select the APIs or SaaS systems you want to expose. Select the source instance or version, then select the tools to publish, including optional read-only filtering. Click *Next*. -. In *SaaS Credentials*, provide the credentials required for the selected sources so the MCP server can call them securely. Click *Next*. -. In *Review*, validate the selected sources, tools, and credential mappings, then complete creation. - -After saving, the MCP server is automatically added to the *MCP Servers* catalog in *Portfolio*. No additional action is required. - -== See Also - -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-services-monitoring.adoc b/modules/ROOT/pages/exp-services-monitoring.adoc deleted file mode 100644 index 5c2734cec..000000000 --- a/modules/ROOT/pages/exp-services-monitoring.adoc +++ /dev/null @@ -1,55 +0,0 @@ -= Monitoring Services in Your Portfolio -:keywords: service monitoring, monitoring signals, access monitoring, mulesoft services, monitoring use cases, api monitoring - -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*. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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. - -include::partial$exp-navigation-labels.adoc[tag=ExpNavigationLabels] - -== 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 - -* xref:exp-overview.adoc[] -* xref:exp-home-start.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] diff --git a/modules/ROOT/pages/exp-services-register-manually.adoc b/modules/ROOT/pages/exp-services-register-manually.adoc deleted file mode 100644 index 427687631..000000000 --- a/modules/ROOT/pages/exp-services-register-manually.adoc +++ /dev/null @@ -1,89 +0,0 @@ -= Register Services Manually -:keywords: register services manually, mcp servers, agents, service registration, mulesoft, anypoint platform, manual configuration - -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 xref:exp-services-add-to-portfolio.adoc[]. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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. -include::_partials/exp-navigation-labels.adoc[tag=ExpNavigationLabels] - -== 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 xref:exp-services-connect-providers-to-add.adoc[]. - -=== 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. - -. In the navigation pane, select *APIs*. -. Click *Add API*. -. Select *Register manually*. -. Enter a name for the API. -. Select the API type. -. Upload the specification file. -. 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 - -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-view-details.adoc[] diff --git a/modules/ROOT/pages/exp-services-view-detailed-metrics.adoc b/modules/ROOT/pages/exp-services-view-detailed-metrics.adoc deleted file mode 100644 index 604df5c72..000000000 --- a/modules/ROOT/pages/exp-services-view-detailed-metrics.adoc +++ /dev/null @@ -1,46 +0,0 @@ -= View Detailed Metrics for Your Services -:keywords: detailed metrics, service metrics, anypoint platform, monitoring, metrics best practices, experience services, performance monitoring - -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*. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-alerts-configure-notifications.adoc[alert 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 - -* xref:exp-services-monitoring.adoc[] -* xref:exp-alerts-configure-notifications.adoc[] -* xref:exp-services-view-details.adoc[] -* xref:exp-overview.adoc[] diff --git a/modules/ROOT/pages/exp-services-view-details.adoc b/modules/ROOT/pages/exp-services-view-details.adoc deleted file mode 100644 index 95624b787..000000000 --- a/modules/ROOT/pages/exp-services-view-details.adoc +++ /dev/null @@ -1,101 +0,0 @@ -= Viewing Service Details in the Portfolio -:keywords: view service details, service detail page, anypoint exchange, exchange services, service tabs, mulesoft exchange - -View scanner read policies, deployments, monitoring, and conformance for a service from one detail page in *Portfolio*. Open any service, including an API, agent, MCP server, Model Proxy, or gateway, to review current status, cost, and relationships. Use this page to validate applied controls and track changes without switching contexts. - -== Before You Begin - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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 xref:exp-overview.adoc[]. -tab can differ by service type and release. For end-to-end portfolio tasks that reference these tabs, see xref:exp-overview.adoc[]. - -[cols="2,3,^.^,^.^,^.^,^.^,^.^",options="header"] -|=== -|Tab |What You See |API |Agent |MCP Server |Model Proxy |Gateway - -|*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 xref:exp-policies-apply-manage.adoc[]. -|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 xref:exp-overview.adoc[]. - -* *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 xref:exp-overview.adoc[]. -==== - -== Open a Service Detail Page - -. In *Portfolio*, open the catalog for the service type (for example *APIs* or *Agents*). -. Use the search box to find the service by name or description, or scan the list or grid. -. Select the service card to open its detail page. - -[[view-read-policies-discovered-by-scanners]] -== View Read Policies Discovered by Scanners - -If a provider scanner has policy-read scopes configured, the *Policies* tab shows discovered policy entries for that API instance. The tab lists policy names and mapped governance context, such as category and apply level, when the provider returns that metadata. For providers that expose policy status, the tab also shows whether a policy is enabled so teams can validate scanner coverage and conformance inputs from the latest scan snapshot. - -. In *Portfolio*, open *APIs* and select an API discovered by a provider scanner. -. Open the *Policies* tab on the service detail page. -. Review read policies imported from Amazon API Gateway, Google Apigee, Azure API Management, or Kong Gateway. -. Use the policy list to confirm applied controls before governance reviews or conformance analysis. - -Policy visibility depends on the last successful scanner run, not on a live provider query. If required provider scopes or roles are missing, policy results can be incomplete or unavailable. Policy fields such as status, apply level, and detail can vary by provider. If expected policies are missing, check scanner run status and history in *Providers*. - -Reading policies is view-only. To create, edit, enable, disable, or remove policies on Anypoint and external gateway providers from this tab, see xref:exp-policies-apply-manage.adoc[] and xref:exp-policies-overview.adoc[]. - -== 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 xref:exp-policies-activity-log.adoc[]. - -For the full apply and management workflow, see xref:exp-policies-apply-manage.adoc[]. - -== See Also - -* xref:exp-overview.adoc[] -* xref:exp-services-add-to-portfolio.adoc[] -* xref:exp-services-connect-providers-to-add.adoc[] -* xref:exp-services-register-manually.adoc[] -* xref:exp-services-create-mcp-server.adoc[] -* xref:exp-services-add-semantic.adoc[] -* xref:exp-instances-add.adoc[] -* xref:exp-services-monitoring.adoc[] -* xref:exp-services-view-detailed-metrics.adoc[] diff --git a/modules/ROOT/pages/exp-slack-integrate.adoc b/modules/ROOT/pages/exp-slack-integrate.adoc deleted file mode 100644 index 72bc187ef..000000000 --- a/modules/ROOT/pages/exp-slack-integrate.adoc +++ /dev/null @@ -1,113 +0,0 @@ -= Integrate the Enhanced Experience with Slack -:keywords: slack integration, mulesoft agent, slackbot, mcp server, slash commands, slack workspace, enhanced experience - -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 to answer questions about the MuleSoft platform. -* <>: 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 xref:exp-alerts-configure-notifications.adoc[]. - -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-slack-workspace]] -== 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. - -. Log in and go to *Notifications* > *Settings*. -. In *Slack Setup*, click *Install*. -. Select the Slack workspace you want to connect to your MuleSoft organization. -. 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. -. 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-mcp]] -== Connect Slackbot to the MuleSoft Platform MCP Server - -After installing the Slack app app, connect Slackbot to the xref:mulesoft-mcp-server::getting-started-platform.adoc[] to answer questions about the MuleSoft platform. - -. Open Slackbot. -. Click the Slackbot logo again. -. Click *Integrations*. -. Click *Connect* for *MuleSoft Platform - MCP* and sign in to Anypoint Platform. -+ -Slackbot can now access information from the MCP Platform Server. - -[[begin-using-agent]] -== 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 xref:access-management::enabling-generative-ai.adoc[]. -* The *MuleSoft Agent AI User* permission assigned to your user. -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -To assign the *MuleSoft Agent AI User* permission across business groups: - -. Log in to Anypoint Platform and open *Access Management*. -. Select the business group where you want to assign the permission. -. Find the user and assign the *MuleSoft Agent AI User* permission. -. Repeat for each business group that requires access. - -To start using the agent in Slack: - -. Open Slack in the workspace your company uses for MuleSoft or platform notifications. -. Open the MuleSoft app your administrator added. -. 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. -. If it is your first time using the agent, follow the authentication flow when prompted to connect your Anypoint account to Slack. - -[[available-slash-commands]] -== 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]] -== 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 xref:exp-alerts-configure-notifications.adoc[]. -* 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]] -== See Also - -* xref:exp-home-start.adoc[] -* xref:exp-overview.adoc[] -* xref:exp-claude-desktop-connect.adoc[] diff --git a/modules/ROOT/pages/exp-teams-integrate.adoc b/modules/ROOT/pages/exp-teams-integrate.adoc deleted file mode 100644 index f639ede1b..000000000 --- a/modules/ROOT/pages/exp-teams-integrate.adoc +++ /dev/null @@ -1,182 +0,0 @@ -= Integrate the Enhanced Experience with Microsoft Teams -:keywords: microsoft teams integration, mulesoft agent, teams bot, mcp server, anypoint platform, enhanced experience - -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: - -* <>: Bind your Microsoft Teams tenant to your Anypoint organization so the app can send alerts and notifications directly to channels and DMs. -* <>: 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 xref:exp-alerts-configure-notifications.adoc[]. - -NOTE: This tool uses generative AI, which can produce inaccurate or harmful responses. Review for accuracy and safety before using. - -[[before-you-begin]] -== 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 xref:access-management::enabling-generative-ai.adoc[]. -* *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-teams-tenant]] -== 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. - -. Log in and go to *Notifications* > *Settings*. -. 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. -. Select your Microsoft Teams admin account. -. 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 -+ -. 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. -. Click *Grant Access* to allow the app to browse your Teams directory for channel and team member access. -. 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: - -. Click *Disconnect* in the *Microsoft Teams Setup* section. -. 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-agent]] -== 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 xref:access-management::enabling-generative-ai.adoc[]. -* The *MuleSoft Agent AI User* permission assigned to your user. -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -To assign the *MuleSoft Agent AI User* permission across business groups: - -. Log in to Anypoint Platform and open *Access Management*. -. Select the business group where you want to assign the permission. -. Find the user and assign the *MuleSoft Agent AI User* permission. -. Repeat for each business group that requires access. - -To start using the agent in Teams: - -. Open Microsoft Teams and go to *Apps*. -. Under *Built for your organisation*, find *MuleSoft Agent* and click *Add*. -. Click *Open* or select a channel where you want to use the app. -. The agent sends a welcome message. Select a prompt suggestion or type a message to start. -. If prompted, click *Connect to MuleSoft* and sign in with your Anypoint Platform credentials. -. 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-prompts]] -== 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]] -== 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 xref:exp-alerts-configure-notifications.adoc[]. -* *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]] -== 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. - -[cols="2,1,3", options="header"] -|=== -|Permission |Type |Purpose - -|`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-compliance]] -== 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 https://www.salesforce.com/company/legal/trust-and-compliance-documentation/[Salesforce Trust and Compliance Documentation]. - -[[see-also]] -== See Also - -* xref:exp-home-start.adoc[] -* xref:exp-overview.adoc[] -* xref:exp-slack-integrate.adoc[] -* xref:exp-claude-desktop-connect.adoc[] diff --git a/modules/ROOT/pages/exp-troubleshoot.adoc b/modules/ROOT/pages/exp-troubleshoot.adoc deleted file mode 100644 index 57b2bed9d..000000000 --- a/modules/ROOT/pages/exp-troubleshoot.adoc +++ /dev/null @@ -1,414 +0,0 @@ -= Troubleshoot the Enhanced Experience -:keywords: enhanced experience, troubleshooting, authentication errors, 403 forbidden, 401 unauthorized, permission errors, mulesoft - -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: - -. Check your permissions: -.. Review your Access Management permissions in xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. -.. Verify that you have the required permission for the action: -+ -See xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions] for more information. -.. Ask your administrator to review your role assignments if needed. - -. Check business group access: -.. Verify that you're working in the correct business group. -.. Confirm that you have permissions in the selected business group, not just at the organization level. -.. Ask your administrator to grant access to the specific business group if needed. -//// -. Check subscription tier: -.. Verify whether you have API Portfolio Access or Agent + API Portfolio Access. -+ -Some features (such as agents, MCP servers, and Model proxies) require Agent + API Portfolio Access. -.. Contact your administrator or account team about upgrading your subscription if needed. -//// - -=== 401 Unauthorized Errors - -If you receive a 401 Unauthorized error: - -. Check session status: -.. Verify that you're still signed in to the enhanced experience. -+ -If your session expired, sign in again. -.. Check the browser console for authentication errors (if you have developer tools access). - -. Clear cached credentials: -.. Sign out of the enhanced experience. -.. Clear your browser cache and cookies. -.. Sign in again. - -. Try a different browser: -.. Test with a different browser or incognito/private mode. -.. Disable browser extensions that might interfere with authentication. - -=== Permission Errors for Specific Actions - -If you can't perform a specific action: - -. Verify prerequisites: -+ -Some actions require specific service states (such as active or registered). -+ -.. Check that required configurations are in place (for example, a gateway must be configured before creating instances). -.. Verify that the service exists and hasn't been deleted. - -. Check feature availability: -.. Confirm that the feature is available in your environment. -+ -Some features might be in preview or require specific product access. -.. 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: - -. Verify credentials: -.. Check that you entered valid credentials for the provider. -.. Confirm that the credentials haven't expired. -.. Test the credentials directly with the provider's console or API. - -. Check network connectivity: -.. Verify that your network allows outbound connections to the provider. -.. Check for firewall rules that might block connections. -.. Confirm that proxy settings are correct if your organization uses a proxy. - -. Review provider permissions: -.. Verify that the credentials have the required permissions on the provider side. -.. Check that the account has access to the resources you want to discover. -.. Review the provider's documentation for required IAM roles or permissions. - -. Check provider status: -.. Verify that the provider's API is available and not experiencing outages. -.. Check the provider's status page for known issues. -.. Try connecting to the provider again after a few minutes. - -=== Scanner Connection Failures - -If a scanner fails to connect or discover services: - -. Check scanner authentication: -.. Verify that the scanner's authentication credentials are valid. -.. Refresh credentials if they've expired. -.. Reauthenticate with the provider if needed. - -. Review scanner permissions: -.. Confirm that the scanner has permissions to access the target resources. -.. Check that the account has list or describe permissions for the resource types you want to discover. -.. Verify that the scanner can access all regions or zones if applicable. - -. Check scanner configuration: -.. Review the scanner's settings in *Platform* > *Providers* > scanner name > *Settings*. -.. Verify that the scanner is targeting the correct resources or namespaces. -.. Check that filters are not excluding the resources you expect to discover. - -. Review scan history: -.. From *Platform* > *Providers*, select the scanner to view its scan history. -.. Look for error messages in recent scan attempts. -.. 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: - -. Verify gateway endpoint: -.. Check that the gateway URL is correct and accessible. -.. Test the gateway endpoint from your network (for example, using curl or a browser). -.. Confirm that the gateway is running and accepting connections. - -. Check SSL/TLS certificates: -.. Verify that the gateway's SSL certificate is valid and not expired. -.. Check that the certificate chain is complete. -.. If using a self-signed certificate, verify that it's trusted by your organization's certificate authority. - -. Review gateway credentials: -.. Confirm that you're using valid credentials for the gateway. -.. Check that the credentials have the required permissions. -.. Verify that authentication is configured correctly on the gateway side. - -. Check network path: -.. Verify that your network allows connections to the gateway's port (typically 443 for HTTPS). -.. Check for firewall rules that might block connections. -.. 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: - -. Wait before retrying: -+ -Rate limits typically reset after a short period (usually 1–5 minutes). -+ -.. Check the error message for retry-after information. -.. Wait at least 60 seconds before retrying the operation. - -. Reduce request frequency: -.. Avoid running multiple scanners simultaneously if they target the same provider. -.. Space out manual scan runs rather than triggering them in quick succession. -.. Reduce the frequency of scheduled scans if you're hitting limits regularly. - -. Review operation patterns: -.. Check whether automated processes or scripts are making excessive requests. -.. Review scanner schedules to avoid overlapping runs. -.. Contact your administrator if rate limits don't align with your usage needs. - -. Provider rate limits: -+ -Provider rate limits (AWS, Azure, GCP) are separate from enhanced experience rate limits. -+ -.. Check the provider's rate limit documentation for their specific limits. -.. 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: - -. Check scanner results: -.. From *Platform* > *Providers*, select the scanner to view its scan history. -.. Verify that the scan reported discovering new services. -.. Check for any error messages in the scan history. - -. Review catalog filters: -.. From *Portfolio*, check that you're viewing the correct catalog (APIs, Agents, MCP Servers, Model Proxies, or Gateways). -.. Clear any filters that might be hiding the services. -.. Try using the search function to find specific services by name. - -. Verify service type mapping: -.. Confirm that the discovered services are of the expected type. -.. 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. - -. Check business group context: -.. 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. -.. Switch business groups if needed to find the services. - -=== Metrics Not Displaying - -If you expect to see metrics but they're not appearing: - -. Verify monitoring is enabled: -.. Check that monitoring is configured for the service or instance. -.. From the service detail page, select *Monitoring* to verify that monitoring is active. -.. Contact your administrator if monitoring needs to be enabled. - -. Check time range: -.. Verify that you're viewing an appropriate time range for the data. -.. Expand the time range to see if data exists outside the current window. -+ -New services might not have historical data. - -. Allow time for data collection: -+ -Metrics might take several minutes to appear after an event occurs. -+ -.. Wait at least 5–10 minutes after creating or updating a service before expecting metrics. -.. Check again after the next monitoring collection cycle. - -. Verify service activity: -.. Confirm that the service is receiving traffic or requests. -.. Check that the service is deployed and running. -.. 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: - -. Check governance strategy scope: -.. From *Governance* > *Strategies*, verify that a governance strategy targets the service. -.. Confirm that the strategy is active and not in draft state. -.. Check that the strategy includes cost or token tracking. - -. Allow time for data aggregation: -.. Cost and token usage data can take several hours to appear after usage occurs. -.. Check again after 24 hours for the most complete data. -+ -Historical data might not be available for newly registered services. - -. Verify service type: -.. Cost and token usage tracking applies primarily to Model proxies and agents. -+ -APIs and other service types might not generate cost data. -.. 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: - -. Check operation type: -+ -Governance insights and conformance scoring run asynchronously and can take several minutes. -+ -.. Large scanner runs discovering many services can take 10–30 minutes or longer. -+ -Policy application to multiple instances might process in the background. - -. Review status indicators: -.. Look for progress indicators or status messages in the UI. -.. Check the service or scanner detail page for updated status. -.. Refresh the page to see if the operation has completed. - -. Wait for background processing: -.. 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. - -. Check for errors: -.. Review the browser console for error messages (if you have developer tools access). -.. Check notification areas for error alerts. -.. 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: - -. Scanner runs: -.. From *Platform* > *Providers*, select the scanner. -.. View the scan history on the *Overview* tab. -+ -The most recent entry shows the current or last completed scan. - -. Governance operations: -.. From *Governance* > *Strategies*, select the strategy. -.. Check the status indicator next to the strategy name. -.. Review conformance reports for completion status. - -. Service operations: -.. From *Portfolio*, select the service. -.. Check for status messages or progress indicators on the detail page. -.. 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: - -. Clear browser cache: -.. Clear your browser cache and cookies. -.. Hard refresh the page (Ctrl+Shift+R on Windows/Linux, Cmd+Shift+R on Mac). -.. Try accessing the enhanced experience in incognito/private mode. - -. Check browser compatibility: -.. Verify that you're using a supported browser (Chrome, Firefox, Safari, or Edge). -.. Update your browser to the latest version. -.. Check xref:browser-support.adoc[] for specific version requirements. - -. Disable browser extensions: -.. Temporarily disable browser extensions that might interfere with the enhanced experience. -+ -Ad blockers, privacy extensions, or script blockers can prevent features from working. -.. Test with extensions disabled to identify conflicts. - -. Check browser console: -.. Open browser developer tools (F12 or Cmd+Option+I). -.. Review the console for error messages. -.. Share error messages with your administrator or support team if needed. - -=== Session Timeout Issues - -If your session expires frequently or unexpectedly: - -. Adjust session settings: -.. Check your organization's session timeout policy. -.. Ask your administrator about extending session duration if needed. -+ -Security policies can limit maximum session duration. - -. Stay active: -.. Keep a tab or window with the enhanced experience open and active. -+ -Periodic interaction prevents session timeouts. -.. Refresh the page if you've been idle for an extended period. - -. Re-authenticate: -.. Sign out and sign in again to start a fresh session. -.. Clear browser cache if re-authentication fails. -.. 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: - -. Check certificate validity: -.. Verify that the certificate hasn't expired. -.. Confirm that the certificate is issued by a trusted certificate authority. -.. Check that the certificate's common name or subject alternative name matches the hostname. - -. Review certificate chain: -.. Verify that the complete certificate chain is present. -.. Check that intermediate certificates are installed correctly. -.. Confirm that the root certificate is trusted by your system. - -. Self-signed certificates: -.. If using self-signed certificates, verify that they're trusted by your organization. -.. Ask your administrator about adding the certificate to your system's trusted store. -.. Consider using certificates from a trusted certificate authority for production systems. - -. Contact your administrator: -.. Share certificate error details with your administrator or security team. -+ -Your organization might need to update certificate trust settings. -.. Work with your administrator to resolve certificate trust issues. - -== Get Additional Help - -If these troubleshooting steps don't resolve your issue: - -. Contact your administrator: -.. Share specific error messages and steps to reproduce the problem. -.. Provide details about what you were trying to accomplish. -.. Include screenshots if they help illustrate the issue. - -. Check documentation: -.. Review feature-specific documentation for additional guidance. -.. Check xref:exp-release-notes.adoc[Release Notes] for known issues. -.. Review xref:exp-ai-assistant-troubleshoot.adoc[] for AI assistant-specific issues. - -. Gather diagnostic information: -.. Note exact error message and error code if provided. -.. Record the steps to reproduce the issue. -.. Check browser console for technical error details (F12 or Cmd+Option+I). -.. Note the time the error occurred and any patterns (happens consistently or intermittently). - -== See Also - -* xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions] -* xref:exp-ai-assistant-troubleshoot.adoc[] -* xref:exp-providers-manage.adoc[] -* xref:exp-scanners-manage.adoc[] -* xref:browser-support.adoc[] -include::release-notes::partial$release-notes/rn-known-issues.adoc[tag=knownIssuesSeeAlsoLink] diff --git a/modules/ROOT/pages/exp-vaults-manage.adoc b/modules/ROOT/pages/exp-vaults-manage.adoc deleted file mode 100644 index 24bac6db4..000000000 --- a/modules/ROOT/pages/exp-vaults-manage.adoc +++ /dev/null @@ -1,176 +0,0 @@ -= Using Credentials Stored in External Vaults -:keywords: external vaults, secrets manager, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, authentication method, model proxy, anypoint platform - - -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. - -== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -For a list of vault credentials and setup fields, see xref:exp-scanners-prerequisites-reference.adoc[]. - -[[authentication-methods]] -== 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 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]] -=== 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 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]] -== Register AWS Secrets Manager - -Choose *AWS Static* or *AWS Assume Role* to match how your applications already reach Secrets Manager. See <>. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. From *Platform* > *Providers*, select Amazon. -. Select *Add Provider*, then select *AWS Secrets Manager*. -. Select the Anypoint environment whose services will use this vault. -. 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. -. 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. -. 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. -. (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. -. Select *Connect*. - -[[register-azure-key-vault]] -== 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 <>. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. Select *Platform* > *Providers*, then select *Microsoft*. -. Select *Add Provider*, then select *Azure Key Vault*. -. Select the Anypoint environment whose services will use this vault. -. 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. -. 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. -. (Optional) Select *Test Connection* to verify the connection before you save it. -. Select *Connect*. - -[[register-hashicorp-vault]] -== Register HashiCorp Vault - -HashiCorp Vault authenticates with AppRole only. The role ID identifies the role. The secret ID is the credential. See <>. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. From *Platform* > *Providers*, select HashiCorp. -. Select the Anypoint environment whose services will use this vault. -. Select *HashiCorp AppRole*. -. Enter the Vault address, for example `\https://vault.example.com:8200`. -. 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. -. 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. -. (Optional) Select *Test Connection* to verify the connection before you save it. -. Select *Connect*. - -[[view-and-sync-a-vault]] -== 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. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. From *Platform* > *Providers*, open the vault. -+ -The header shows the creation date and the last scan time. -. 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. -. 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*. -. 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 - -To update connection details or rotate a credential: - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. From *Platform* > *Providers*, open the vault and select *Settings*. -+ -The tab shows the provider, Anypoint environment, and authentication method. -. Select *Edit Settings*, make your changes, and select *Save*. -. Optionally, select *Test Connection* before you save. -. To remove the vault, select *Delete Integration* and confirm. Deleting the integration removes its stored credentials and discovered secrets. - -[[use-vault-secrets-in-a-model-proxy]] -== 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. - -. Log in to the MuleSoft enhanced experience with an account that has the required permissions. -. From *Portfolio* > *Model Proxies*, select *Add Model Proxy*. -. In *Authentication*, select *From Vault*. -. From *Credential from Vault*, select the secret. -. Select *Save*. - -For model proxy setup, see xref:model-proxy.adoc[]. - -== See Also - -* xref:exp-securing-services.adoc[] -* xref:exp-providers-manage.adoc[] -* xref:exp-scanners-add-from-providers.adoc[] -* xref:exp-scanners-prerequisites-reference.adoc[] -* xref:model-proxy.adoc[] diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 4922e0ce2..46c55ed0a 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -99,10 +99,10 @@ Monitor your APIs and integrations using dashboards, metrics, and visualization. // Updated 2026/06/17 - sathya * xref:general::use-mulesoft-docs-with-ai.adoc[] -* xref:learning-map-exp.adoc[] +* xref:agent-fabric::learning-map-exp.adoc[] * xref:monitoring::integration-intelligence.adoc[] * xref:general::learning-map-mulesoft-ai.adoc[] -* xref:general::learning-map-agent-fabric.adoc[] +* xref:agent-fabric::learning-map-agent-fabric.adoc[] * xref:agent-network::af-get-started.adoc[] * xref:exchange::importing-agentforce-agents.adoc[] // * xref:gateway::flex-gateway-managed-ingress-egress.adoc[] diff --git a/modules/ROOT/pages/learning-map-agent-fabric.adoc b/modules/ROOT/pages/learning-map-agent-fabric.adoc deleted file mode 100644 index 66da2db02..000000000 --- a/modules/ROOT/pages/learning-map-agent-fabric.adoc +++ /dev/null @@ -1,95 +0,0 @@ -= Get Started with Agent Fabric -:keywords: agent fabric, mulesoft, getting started, ai agents, learning map, anypoint platform -:page-aliases: agent-fabric::agent-fabric-get-started.adoc, agent-fabric::index.adoc -:page-article-style: learning-map - -Agent Fabric helps you turn your agent sprawl into a governed and highly coordinated, intelligent network. - -* Discover agents and MCP servers with Anypoint Exchange, a centralized catalog for all your AI assets. -* Orchestrate agents across ecosystems with agent brokers, an intelligent routing agent that plans and delegates work based on context (request intent, policies, identity, and runtime state) of agents, MCP servers, and assets. -* Govern any agent with Omni Gateway support for Model Context Protocol (MCP) and Agent2Agent (A2A), a high-performance gateway for policies and controls. -* Observe every agent interaction with Agent Visualizer, a visual map for your agent network. -+ -View metrics, logs, and traces in Anypoint Monitoring. - -The end-to-end journey for Agent Fabric consists of various tasks, each with links to relevant content to assist you in completing them. - -[.lm-table, cols="1a,1a,1a", grid="none"] -|=== -| image::lm_start.png[""] -[.lm-bold]##Learn About Agent Fabric## - -Agent Fabric helps you design and orchestrate a network of agents, brokers, and MCP servers to achieve complex goals across your enterprise. - -- https://www.youtube.com/watch?v=GAqwPie16ic[Watch a Video to Learn About Agent Fabric] -- https://www.mulesoft.com/lp/demo/agent-fabric-interactive-demo[Watch an Interactive Demo of Agent Fabric] - -| image::lm_explore_1.png[""] -[.lm-bold]##Discover Agentic Assets## - -Use Anypoint Exchange to discover agentic assets for reuse across your enterprise. - -- https://www.mulesoft.com/platform/exchange[Discover Assets in Anypoint Exchange] -- xref:exp-portfolio-overview.adoc[View Your Portfolio] -- xref:exp-services-add-to-portfolio.adoc[Add Services to Your Portfolio] -- xref:exp-scanners-add-from-providers.adoc[Discover and Catalog External Agents With Scanners] -- https://videos.mulesoft.com/watch/GJxX42uWd1gGComp3KQqEB[Watch a Video to Learn About Agent Fabric and GoDaddy ANS Integration] -- https://blogs.mulesoft.com/news/agent-scanners/[Learn How to Catalog Agents Automatically With Scanners] -- https://videos.mulesoft.com/watch/fqPcAHf5h7RYdfdSqhY9ju[Watch a Video to Learn About New Scanners for Agent Management] -- xref:exchange::importing-agentforce-agents.adoc[Import Agentforce Agents] -- xref:exchange::to-create-an-asset.adoc#create-agent[Create and Publish an Agent in Exchange] -- xref:exp-services-create-mcp-server.adoc[Create an MCP Server] -- https://videos.mulesoft.com/watch/Dn9QXJKDzTxSJPNgra9LoM[Watch a Video to Learn About MCP Bridge] -- xref:exp-services-create-a2a-bridge.adoc[Make an Agent A2A-Compliant] -- xref:exchange::to-create-an-asset.adoc#create-llm[Create and Publish an LLM in Exchange] - -| image::lm_build_1.png[""] -[.lm-bold]##Build and Orchestrate Agent Networks## - -Build your agent network and coordinate brokers and agents using a declarative YAML approach. - -- xref:agent-network::af-get-started.adoc[Get Started with Agent Networks] -- xref:agent-network::af-create-agent-network.adoc[Build an Agent Network Project in Anypoint Code Builder] -- xref:agent-network::af-define-your-agent-network-specification.adoc[Define the Agent Network in a YAML File] -- xref:agent-network::af-publish-agent-network-assets.adoc[Publish the Agent Network Project to Exchange] -- xref:agent-network::af-deploy-agent-network-targets.adoc[Deploy the Agent Network Assets to Exchange] -|=== - -[.lm-table, cols="1a,1a", width="66%", grid="none"] -|=== -| image::lm_build_1.png[""] -[.lm-bold]##Govern and Secure the Agent Network## - -Apply policies to your agents, brokers, Model proxies, and MCP servers to help manage security and control traffic. - -- xref:api-manager::create-instance-task-agent-tool.adoc[Add an Omni Gateway Agent or Tool Instance in API Manager] -- https://videos.mulesoft.com/watch/2E2PkqzMnLEjoDhL5YkywT[Watch a Video to Learn About AI Gateway from MuleSoft] -- https://videos.mulesoft.com/watch/uQtoaAv9AUGmZQteNTTZF1[Watch a Video to Learn About Governing Headless 360 with Agent Fabric] -- xref:gateway::flex-gateway-managed-ingress-egress.adoc[Deploy Agent Fabric Ingress and Egress Managed Omni Gateways] -- xref:gateway::flex-gateway-secure-apis.adoc[Secure Omni Gateway Instances with Policies] - -| image::lm_analyze_1.png[""] -[.lm-bold]##Observe and Gain Actionable Insights## - -Visualize your agent network and monitor performance and behavior. - -- xref:agent-visualizer::index.adoc[Visualize Your Agent Network in Agent Visualizer] -- xref:monitoring::anypoint-insights-agentic.adoc[View Agent Metrics in Anypoint Monitoring] -- xref:exp-services-view-detailed-metrics.adoc[View Detailed Metrics for Your Services] -- xref:monitoring::logs-search-hf.adoc#search-agentic[Get Logs for Agentic Assets] -- xref:monitoring::traces.adoc[View Traces in Anypoint Monitoring] - - -|=== - - -[discrete] -== See Also - -* xref:agent-fabric-overview.adoc[Agent Fabric Overview] -* xref:exp-overview.adoc[] -* xref:anypoint-code-builder::index.adoc[Anypoint Code Builder] -* xref:exchange::index.adoc[Anypoint Exchange] -* xref:monitoring::index.adoc[Anypoint Monitoring] -* xref:api-manager::index.adoc[API Manager] -* xref:agent-visualizer::index.adoc[Agent Visualizer] diff --git a/modules/ROOT/pages/learning-map-exp.adoc b/modules/ROOT/pages/learning-map-exp.adoc deleted file mode 100644 index a8d970cd8..000000000 --- a/modules/ROOT/pages/learning-map-exp.adoc +++ /dev/null @@ -1,123 +0,0 @@ -= Enhanced MuleSoft Experience -:keywords: enhanced mulesoft experience, learning map, mulesoft training, getting started, mulesoft resources -:page-article-style: learning-map - -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. - -image::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. - -[.lm-table, cols="1a,1a,1a", grid="none"] -|=== -| image::reuse::lm_start.png[""] -[.lm-bold]##Learn About Enhanced MuleSoft Experience## - -The experience helps you manage, optimize, and govern a multi-agent ecosystem from one place. - -//- ToDo [Video] -- xref:exp-overview.adoc[] -- xref:exp-compare.adoc[] -- xref:exp-glossary.adoc[] -- xref:exp-home-start.adoc[] -- xref:exp-portfolio-overview.adoc[] -- xref:exp-ai-assistant-use.adoc[] -- https://trailhead.salesforce.com/content/learn/modules/enhanced-mulesoft-experience-quick-look[Get to Know the Enhanced MuleSoft Experience] -// - placeholder for video - - -| image::reuse::lm_explore_1.png[""] -[.lm-bold]##Populate Your Portfolio## - -Register agents, MCP servers, and APIs from any provider or registry, add model proxies and gateways, and create MCP servers. - -- xref:exp-services-add-to-portfolio.adoc[] -- xref:exp-services-connect-providers-to-add.adoc[] -- xref:exp-services-register-manually.adoc[] -- xref:exp-services-create-mcp-server.adoc[] -- xref:exp-services-create-a2a-bridge.adoc[] -- xref:exp-services-add-semantic.adoc[] -- xref:exp-instances-add.adoc[] -- xref:exp-services-view-details.adoc[] -- xref:exp-scanners-add-from-providers.adoc[] -- xref:exp-scanners-manage.adoc[] -- xref:exp-providers-manage.adoc[] - - -| image::reuse::lm_develop_1.png[""] -[.lm-bold]##Create and Manage Model Proxies## - -Create model proxies to route, govern, and test LLM traffic from a single endpoint. - -- xref:model-proxy.adoc[] -- xref:model-proxy-create-model-proxy.adoc[] -- xref:model-proxy-policies.adoc[] -- xref:model-proxy-request.adoc[] -- xref:model-proxy-semantic-service.adoc[] -- xref:model-proxy-try-out.adoc[] - -|=== - -[.lm-table, cols="1a,1a,1a", grid="none"] -|=== -| image::reuse::lm_test_1.png[""] -[.lm-bold]##Test Services in Playgrounds## - -Test APIs and MCP servers in playgrounds without leaving the portfolio. - -- xref:exp-playground-api.adoc[] -- xref:exp-playground-mcp.adoc[] - -| image::reuse::lm_optimize_1.png[""] -[.lm-bold]##Monitor Usage and Manage Costs## - -Monitor usage and performance, and apply optimization policies to manage costs. - -- xref:exp-services-monitoring.adoc[] -- xref:exp-governance-view-cost-and-token-usage.adoc[] -- xref:model-proxy-token-reports.adoc[] -- xref:exp-services-view-detailed-metrics.adoc[] -- xref:exp-alerts-configure-notifications.adoc[] - -| image::reuse::lm_build_1.png[""] -[.lm-bold]##Apply Governance Rules and Policies## - -Monitor and enforce policies, block noncompliant activity, and connect your existing Akamai account to protect services. - -- xref:exp-governance-work-with-strategies.adoc[] -- xref:exp-governance-create-strategy.adoc[] -- xref:exp-governance-manage-strategies.adoc[] -- xref:exp-governance-govern-third-party-apis.adoc[] -- xref:exp-governance-monitor-cross-gateway-conformance.adoc[] -- xref:exp-akamai-risk-correlation.adoc[] - -|=== - - -// Maybe combine with Monitor and Manage Costs section - -[.lm-table, cols="1a", width="33%", grid="none"] -|=== -| image::reuse::lm_integrate_end_1.png[""] -[.lm-bold]##Connect to External Systems## - -Connect the enhanced experience to Slack and Claude Desktop. - -- xref:exp-slack-integrate.adoc[] -- xref:exp-claude-desktop-connect.adoc[] - -|=== - - -== See Also - -* xref:exp-home-start.adoc[] -* xref:exp-compare.adoc[] -* xref:exp-troubleshoot.adoc[] -* xref:exp-ai-assistant-troubleshoot.adoc[] diff --git a/modules/ROOT/pages/learning-map-mulesoft-ai.adoc b/modules/ROOT/pages/learning-map-mulesoft-ai.adoc index a56066977..1b8046418 100644 --- a/modules/ROOT/pages/learning-map-mulesoft-ai.adoc +++ b/modules/ROOT/pages/learning-map-mulesoft-ai.adoc @@ -24,7 +24,7 @@ MuleSoft AI is a set of capabilities for building, orchestrating, governing, dep Kick off your agentic journey with quickstarts and templates. - https://www.youtube.com/watch?v=GAqwPie16ic[Watch an Intro to Agent Fabric] -- xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] +- xref:agent-fabric::learning-map-agent-fabric.adoc[Get Started with Agent Fabric] - https://trailhead.salesforce.com/content/learn/trails/design-and-implement-ai-agents-with-agentforce[Design and Implement AI Agents with Agentforce] - https://help.salesforce.com/s/articleView?id=ai.agent_plan.htm&type=5[Plan Your AI Agent] @@ -94,7 +94,7 @@ Apply policies and secure agent network traffic. [discrete] == See Also -* xref:learning-map-agent-fabric.adoc[Agent Fabric] +* xref:agent-fabric::learning-map-agent-fabric.adoc[Agent Fabric] * xref:agent-visualizer::index.adoc[] * xref:anypoint-code-builder::index.adoc[] * xref:monitoring::index.adoc[] diff --git a/modules/ROOT/pages/model-proxy-create-model-proxy.adoc b/modules/ROOT/pages/model-proxy-create-model-proxy.adoc deleted file mode 100644 index fef87be18..000000000 --- a/modules/ROOT/pages/model-proxy-create-model-proxy.adoc +++ /dev/null @@ -1,88 +0,0 @@ -= Creating Model Proxies -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-create-llm-proxy.adoc, gateway::flex-gateway-llm-proxy-create-llm-proxy.adoc - -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. - -== Before You Begin - -Before getting started, make sure you have: - -* An Anypoint Platform account -* API Manager: API Creator permission -+ -For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -* A deployed Omni Gateway version 1.11.4 -+ -See xref:gateway::flex-gateway-managed-set-up.adoc[]. -* API keys to authenticate with your LLM Providers. -* A xref:model-proxy-semantic-service.adoc[configured semantic routing service] if you want to use semantic routing. -* A xref:model-proxy-semantic-caching-service.adoc[configured 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 xref:exp-vaults-manage.adoc[]. - -[[create-a-model-proxy]] -== Create a Model Proxy - -. In the navigation pane, select *Model Proxies*. -. Click *Add Model Proxy* -. Configure the proxy parameters: -.. *Proxy Name*: Define a name for the Model Proxy. -.. *Description*: Provide a description of what this proxy does. -.. *Base Path*: Define a base path for the proxy endpoint (for example: `/billing-ai`). -.. *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. Doesn't support multi-routing or fallback mechanisms. You can't change this format later. -*** *Gemini*: Select the Gemini API format for native Google Gemini model requests. Doesn't support multi-routing or fallback mechanisms. You can't change this format later. -.. *Environment*: Select the environment for the Model Proxy. -.. *Omni Gateway*: Select an Omni Gateway to deploy the Model Proxy to. -.. *Consumer Endpoint*: Specify the URL where the Model Proxy will be accessible. -.. *Port*: Enter the port number for the Model Proxy (for example, `8081`). -.. Optionally, 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 xref:gateway::conn-tls-config.adoc#add-a-tls-context[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. -. Click *Continue*. -. Configure the routing strategy: -.. 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. -. Configure at least one route: -.. Provide a route name (for example, `Route A`). -.. Optionally, click *Add headers* to add routing headers that filter requests by region, SLA, or custom rules. For example, `Region: US` -.. Configure the target: -*** *Provider*: Select your LLM provider from these options: -**** *OpenAI* -**** *Gemini* -**** *Azure OpenAI* -**** *Bedrock Anthropic* -**** *NVIDIA Nemotron* -**** *Anthropic* -*** *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. -.. Optionally, under *TLS Configuration*, click *Add TLS Context* to secure the connection to the provider endpoint with a TLS context. -.. 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 xref:exp-vaults-manage.adoc[]. -. Click *Add Route* to add additional routes. Complete the previous steps to configure each new route -. Optionally, 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 xref:model-proxy-semantic-caching-service.adoc[]. -. Click *Add Model Proxy*. - -== Edit a Model Proxy - -To edit a Model Proxy: - -. In the navigation pane, select *Model Proxies*. -. Click the name of the Model Proxy you want to edit. -. Click *Edit Configuration*. -. Make the necessary edits. -. Click *Save Changes*. \ No newline at end of file diff --git a/modules/ROOT/pages/model-proxy-policies.adoc b/modules/ROOT/pages/model-proxy-policies.adoc deleted file mode 100644 index 11102ace7..000000000 --- a/modules/ROOT/pages/model-proxy-policies.adoc +++ /dev/null @@ -1,67 +0,0 @@ -= Applying Model Proxy Policies -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-policies.adoc, gateway::flex-gateway-llm-proxy-policies.adoc - -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. - -Model Proxy supports most xref:gateway::policies-included-directory.adoc[included policies], but doesn't support outbound policies. - -NOTE: Model Proxy doesn't support xref:gateway::policies-included-rate-limiting-sla.adoc[]. - -These policies are specific and useful for Model Proxies: - -* xref:gateway::policies-included-bedrock-guardrails.adoc[] -* xref:gateway::policies-included-azure-content-safety.adoc[] -* xref:gateway::policies-included-llm-pii-detection.adoc[] -* xref:gateway::policies-included-llm-proxy-request-compression.adoc[] -* xref:gateway::policies-included-llm-token-rate-limit.adoc[] -* xref:gateway::policies-included-regex-prompt-guard.adoc[] - -== Apply Policies to Model Proxies - -. From API Manager, click *Model Proxies*. -. Click the name of the Model Proxy you want to apply a policy to. -. Click *AI Policies*. -. Click *Add inbound policy*. -. Select the policy to apply. -. Configure the required parameters. -+ -For policy configuration parameters, see xref:gateway::policies-included-directory.adoc[]. -. If necessary, configure *Advanced options*. -. 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`: -+ -** xref:gateway::policies-included-client-id-enforcement.adoc[] -** xref:gateway::policies-included-rate-limiting-sla.adoc[] -** xref:gateway::policies-included-oauth-token-introspection.adoc[] (If Client ID enforcement is configured, `skipClientIdValidation=false`) -** xref:gateway::policies-included-openid-token-enforcement.adoc[] (If Client ID enforcement is configured, `skipClientIdValidation=false`) -** xref:gateway::policies-included-jwt-validation.adoc[] (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 - -* xref:gateway::flex-gateway-secure-apis.adoc[] -* xref:gateway::policies-included-directory.adoc[] diff --git a/modules/ROOT/pages/model-proxy-request.adoc b/modules/ROOT/pages/model-proxy-request.adoc deleted file mode 100644 index 8039f6cbf..000000000 --- a/modules/ROOT/pages/model-proxy-request.adoc +++ /dev/null @@ -1,802 +0,0 @@ -= Sending Requests to Model Proxies -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-request.adoc, gateway::flex-gateway-llm-proxy-request.adoc - -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. - -* *<>*: Supports all LLM providers with multi-routing and fallback mechanisms. Supports both Chat Completions (`/chat/completions`) and Responses (`/responses`) endpoints. -* *<>*: Native Gemini API format. Doesn't support multi-routing or fallback mechanisms. -* *<>*: Native Anthropic API format. Doesn't support multi-routing or fallback mechanisms. - -[[retrieve-the-request-configuration-parameters]] -== 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: - -. Find your public endpoint: -.. From Anypoint Platform, navigate to *Runtime Manager* > *Omni Gateways*. -.. Click the name of the Omni Gateway where your Model Proxy is deployed. -.. Copy the *Public Endpoint*. -. Find your base path: -.. From the enhanced experience, select *Model Proxies*. -.. Click the name of the Model Proxy whose base path you want to find. -.. From *Configuration*, copy the *Base path*. -. Retrieve your client ID and client secret: -.. From the *Overview* page of your Model Proxy, click *Actions* > *View Model Proxy in Exchange*. -.. Click *Request access*. -.. Select the *API Instance* you want to request access to. -.. Select the *Application* you want to request access to. -.. Select the *SLA tier*. -.. Click *Request access*. -.. Copy the *Client ID* and *Client Secret*. - -[[openai-format]] -== OpenAI Format - -Learn more about the OpenAI request types: - -* https://developers.openai.com/api/reference/resources/chat[Chat Completions] API is designed for conversational multi-turn interactions rather than simple text continuation. -* https://developers.openai.com/api/reference/resources/responses[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 - -https://developers.openai.com/api/reference/resources/chat[Chat Completions] (/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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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" } - ] -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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 -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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?" } - ] -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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 -}' ----- - -Model-Based Routing:: -+ -[source,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. - -[tabs] -==== -Semantic Routing:: -+ -[source,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 -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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 ----- - -Model-Based Routing:: -+ -[source,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. - - -[tabs] -==== -Semantic Routing:: -+ -[source,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"] - } - } - } - ] -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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"] - } - } - } - ] -}' ----- - -Model-Based Routing:: -+ -[source,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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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"] - } - } - } -}' ----- - -Model-Based Routing:: -+ -[source,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 - -https://developers.openai.com/api/reference/resources/responses[OpenAI Responses API] (/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: - -[tabs] -==== -Semantic Routing:: -+ -[source,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" - } - ] -}' ----- - -Model-Based Routing:: -+ -[source,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:: - -[tabs] -==== -Semantic Routing:: -+ -[source,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 -}' ----- - -Model-Based Routing:: -+ -[source,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:: - -[tabs] -==== -Semantic Routing:: -+ -[source,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 -}' ----- - -Model-Based Routing:: -+ -[source,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-request-example]] -== 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. - -[source,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: - -[source,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-request-example]] -== 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. - -[source,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: - -[source,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 ----- - -[[amazon-bedrock-model-names]] -== 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 https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html[Supported Regions and models for inference profiles]. diff --git a/modules/ROOT/pages/model-proxy-semantic-caching-service.adoc b/modules/ROOT/pages/model-proxy-semantic-caching-service.adoc deleted file mode 100644 index 770e6ee54..000000000 --- a/modules/ROOT/pages/model-proxy-semantic-caching-service.adoc +++ /dev/null @@ -1,71 +0,0 @@ -= Configuring Semantic Caching Services -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images - -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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -== Configure a Semantic Caching Service - -. In the navigation pane, select *Model Proxies* > *Semantic Services*. -. Click *Add Semantic Service* > *Semantic Caching Service*. -. 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. -. Click *Next*. -. 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`). -. Click *Next*. -. 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`). -. Click *Next*. -. 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* -. Click *Next*. -. On the *Review Configuration* page, review your configurations. To change a section, click *Edit*. -. 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: - -. From *Semantic Service Setup*, click the three-dots menu (image:gateway::image$three-dots-menu.png[3%,3%]) of the semantic caching service you want to edit. -. Make the necessary edits. -. Click *Save Config & Download Script*. -+ -If you edit the vector database connection, you must download and run the cache warmup scripts again. diff --git a/modules/ROOT/pages/model-proxy-semantic-service.adoc b/modules/ROOT/pages/model-proxy-semantic-service.adoc deleted file mode 100644 index 060b8789a..000000000 --- a/modules/ROOT/pages/model-proxy-semantic-service.adoc +++ /dev/null @@ -1,100 +0,0 @@ -= Configuring Semantic Routing Services -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-semantic-service.adoc, gateway::flex-gateway-llm-proxy-semantic-service.adoc, exp-services-add-semantic.adoc - -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: - -* <>: -+ -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. -* <>: -+ -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 xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. - -[[configure-an-advanced-scale-semantic-service]] -== Configure an Advanced Scale Semantic Routing Service - -. In the navigation pane, select *Model Proxies* > *Semantic Services*. -. Click *Add Semantic Service* > *Semantic Routing Service*. -. Select *Advanced Scale*. -+ -Advanced scale supports large utterance sets per topic and requires a dedicated external vector database connection. -. 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. -. 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. -. Define prompt topics: -+ -Supports up to 2000 utterances per topic. -+ -.. Click *Create Prompt Topic*. -.. Define a *Prompt topic name*. -.. Define prompt utterances or click *Upload utterances* to upload a plain text file containing your prompt utterances. -.. 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. -. Click *Save & Download Script*. -. Open the downloaded `.sh` script file in your database to populate it with your scaled vectors. - -[[configure-a-basic-scale-semantic-service]] -== Configure a Basic Scale Semantic Routing Service - -. In the navigation pane, click the *Model Proxies* dropdown arrow. -. Select *Semantic Services*. -. Click *Add Semantic Service* > *Semantic Routing Service*. -. Select *Basic Scale*. -+ -Basic scale supports up to six topics and 10 utterances per topic. Managed via internal Model Proxy configuration. -. 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. -. Click *Save*. - -== Edit a Semantic Routing Service - -To edit a semantic routing service: - -. From *Semantic Service Setup*, click the three-dots menu (image:gateway::image$three-dots-menu.png[3%,3%]) of the semantic routing service you want to edit. -. Make the necessary edits. -. 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. \ No newline at end of file diff --git a/modules/ROOT/pages/model-proxy-token-reports.adoc b/modules/ROOT/pages/model-proxy-token-reports.adoc deleted file mode 100644 index 463a59ddd..000000000 --- a/modules/ROOT/pages/model-proxy-token-reports.adoc +++ /dev/null @@ -1,44 +0,0 @@ -= Viewing Token Usage and Model Proxy Metrics -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-token-reports.adoc, gateway::flex-gateway-llm-proxy-token-reports.adoc - - -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. - -[[view-token-usage-reports]] -== 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 xref:gateway::policies-included-llm-token-rate-limit.adoc[] to your Model Proxy. - -To view token usage reports: - -. In Anypoint Platform, click your Anypoint Platform profile icon (with your initials). -. Click *Usage Reports*. -. Select *Model Proxy* for *Product*. -. Filter between *Usage by Business Group* and *Usage by Application* to see how tokens are consumed. - -To learn more about Usage Reports, see xref:general::usage-reports.adoc[]. - -NOTE: Gemini models use reasoning tokens. This number is included in *Total tokens* but isn't individually listed. - -[[view-api-manager-insights]] -== 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: - -. From API Manager, click *Model Proxies*. -. 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*. diff --git a/modules/ROOT/pages/model-proxy-try-out.adoc b/modules/ROOT/pages/model-proxy-try-out.adoc deleted file mode 100644 index 43ee51fa2..000000000 --- a/modules/ROOT/pages/model-proxy-try-out.adoc +++ /dev/null @@ -1,27 +0,0 @@ -= Test a Model Proxy -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy-try-out.adoc, gateway::flex-gateway-llm-proxy-try-out.adoc - -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 xref:model-proxy-request.adoc[] to test your proxy. - -To test your model proxy: - -. From API Manager in Anypoint Platform, click *Model Proxies*. -. Click the name of the model proxy you want to test. -. Click *Try out*. -. Configure any authentication or other headers your request requires. -. Enter your test prompt. -. Click *Run test*. -. View the *LLM response*, *Response headers*, and *Test result* for details about your test request. diff --git a/modules/ROOT/pages/model-proxy.adoc b/modules/ROOT/pages/model-proxy.adoc deleted file mode 100644 index cb4c9d0ac..000000000 --- a/modules/ROOT/pages/model-proxy.adoc +++ /dev/null @@ -1,99 +0,0 @@ -= Creating and Managing Model Proxies -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] -:imagesdir: ../assets/images -:page-aliases: gateway::llm-proxy.adoc, gateway::flex-gateway-llm-proxy.adoc - -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. - -image::model-proxy.png["A Model Proxy with a single endpoint routing requests to multiple LLM providers"] - -[[supported-endpoint-formats]] -== 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. Doesn't support multi-routing or fallback mechanisms. -* *Anthropic*: The native Anthropic API format for direct Anthropic Claude model requests. Doesn't support multi-routing or fallback mechanisms. - -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: - -* <>: Static routing. The user specifies what model the Model Proxy should send the request to. -* <>: Dynamic routing. The Model Proxy chooses which model to send the request to based on the request content. - -[[supported-llm-providers]] -== Supported LLM Providers - -Model Proxy supports these LLM Providers and API endpoints: - -[%header%autowidth.spread,cols="a,a,a,a"] -|=== -| LLM Provider | Model | `/chat/completions` | `/responses` -.8+|OpenAI and Azure OpenAI -|gpt-5.2 | Yes | Yes -|gpt-5.2-pro | Yes | Yes -|gpt-5-mini | Yes | Yes -|gpt-5.2-codex | Yes | Yes -|gpt-5-nano | Yes | Yes -|gpt-5 | Yes | Yes -|gpt-4.1 | Yes | Yes -|gpt-4o-mini | Yes | Yes - -.4+|Gemini -|gemini-3-flash-preview | Yes | Yes -|gemini-2.5-flash | Yes | Yes -|gemini-2.5-flash-preview-09-2025 | Yes | Yes -|gemini-2.5-flash-lite | Yes | Yes - -.10+| Anthropic and Bedrock Anthropic -| Claude Sonnet 4.6 | Yes | Yes -| Claude Opus 4.6 | Yes | Yes -| Claude Opus 4.5 | Yes | Yes -| Claude Haiku 4.5 | Yes | Yes -| Claude Sonnet 4.5 | Yes | Yes -| Claude Opus 4 | Yes | Yes -| Claude Sonnet 4 | Yes | Yes -| Claude Sonnet 3.7 | Yes | Yes -| Claude Sonnet 3.5 | Yes | Yes -| Claude Haiku 3.5 | Yes | Yes - -.3+| NVIDIA Nemotron -| Nemotron 3 Nano 30B A3B | Yes | Yes -|Nemotron 3 Super 120B A12B | Yes | Yes -|Llama Nemotron Ultra 253B | Yes | Yes -|=== - -[[model-based-routing]] -== 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 - -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 - -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 xref:model-proxy-semantic-caching-service.adoc[]. - -[[connections-and-model-proxies]] -== 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]] -== Model Proxy Limits - -Up to 50 Model Proxies are supported per Large Omni Gateway.