The Pawsome Pets Predicament

You are the AI platform team at Pawsome Pets, a mid-market retailer. Despite that scale, a growing IT landscape is becoming a challenge in the world of AI. Agents and APIs already run on hyperscaler platforms and on-premises, and teams are now calling models from AI labs. The CIO is concerned with three things: no centralized visibility into the assets they have, no consistent governance across those assets, and spiralling AI cost.

The CIO mandate

1. Cross Platform Registry. One catalog of agents, APIs, MCP servers, and models as first-class assets — not a dashboard per runtime.
2. Consistent governance with central enforcement points. The same controls apply no matter which vendor built the agent or where it runs.
3. Attributable costs and spend limits. Model usage must be visible in real time and capped before the bill arrives.
4. Stay platform-agnostic. Governance must travel with the asset so Pawsome Pets is not locked into a single vendor.
5. Do not waste existing API investments. Agents should inherit APIs already built, not force a second governance stack.

What is already running

Current landscape and future architecture

Today callers reach every backend directly. Agent Fabric puts a Cross Platform Registry, Omni Gateway, and cost & guardrails in front of the same runtimes — without rewriting them.

Our solution

Start Setup

Download accompanying assets

Before you set up Omni Gateway, download the accompanying assets you will use to perform these exercises.

• Postman collection
• OpenAPI file (swagger.json)
• Credentials file

Keep these files handy. You will import the Postman collection, upload the OpenAPI file when you register PetStore API, and copy values from the credentials file when a step asks for instructor values.

Set up Omni Gateway

Overview

Every later section uses this gateway. Create it first, then copy the public endpoint.

Step 1 — Navigate to MuleSoft Platform

1. Log in at anypoint.mulesoft.com using the credentials provided by your workshop instructor
2. Create the gateway in the legacy UI (not the enhanced experience). You will switch to the enhanced experience after the gateway is running
3. In the top bar, confirm you are in the business group assigned to you

Step 2 — Navigate to Omni Gateways

1. From the top navigation, go to Runtimes → Runtime Manager
2. Choose Environment — select Sandbox (or the environment your instructor names)
3. In the left sidebar, click Omni Gateways

Step 3 — Add a Managed Omni Gateway

Click Add Managed Omni Gateway. Defaults are not the workshop values — change Release Channel and Version before you save.

1. Click Save & deploy

You land on the gateway dashboard. Status starts as Starting... with Public endpoint N/A. Provisioning typically takes 2–3 minutes (sometimes under a minute).

Step 4 — Verify the gateway is running

1. Wait for the gateway status to change to Running
2. If the status remains Disconnected or Pending after 5 minutes, refresh the page

Step 5 — Note your Public Endpoint

Once Status is Running, copy Public endpoint from the dashboard (it is a link). Do not include a trailing slash. The URL looks like:

Keep this URL handy. You will use it as the base URL when configuring MCP Servers, Model Proxies, and API instances in every section throughout the workshop.

Step 6 — Switch to Enhanced Experience

Gateway create stays in the legacy Runtime Manager. The rest of the workshop is in the enhanced experience.

1. In Anypoint, click Switch to enhanced (opens a new tab), or open omni.mulesoft.com
2. In the lower-left corner, open the Business group selector. Enhanced experience may default to a nested group such as anypoint-cbp-…. Select the business group assigned to you (the same name as your Anypoint org)

Verify your setup

• Gateway status shows Running
• Public Endpoint URL copied and saved
• Enhanced experience is open (Switch to enhanced or omni.mulesoft.com) and the correct business group is selected

Set up Postman Postman

You will use Postman to call gateway endpoints later in the workshop.

1. Open Postman.
2. Import the collection (File → Import, then choose the Postman collection .json file you downloaded — not the swagger.json).
3. Navigate to Variables and verify the following required variables have been imported:

   Variable	Expected value
   gateway	GATEWAY_URL_HERE — update it with your Omni Gateway URL
   token_url	https://lemur-14.cloud-iam.com/auth/realms/mulesoft2026/protocol/openid-connect/token
   client_id	df-user
   client_secret	Pre-populated secret — confirm it is present
   bedrock_model	bedrockanthropic/us.anthropic.claude-sonnet-4-5-20250929-v1:0
   openai_model	openai/gpt-5-mini

• Collection imported
• All required variables are present
• gateway variable set to your Public Endpoint URL

Scan hyperscaler assets into the catalog

Pawsome Pets already has agents and APIs in AWS. Scanners pull those into one catalog so you do not hunt them in the AWS console.

You will add two Amazon scanners, run a discovery scan on each, and confirm the assets show up. IAM keys are on the instructor sheet. Confirm your business group is selected in the lower-left before you start.

Add Amazon Bedrock AgentCore Runtime (Agents) Scanner

This scanner finds agents already running in AgentCore.

Step 1 — Navigate to Providers

1. If you are still in Anypoint, click Switch to enhanced, or log in at omni.mulesoft.com
2. In the lower-left corner, confirm you are in the business group assigned to you
3. In the left navigation, click Providers

Step 2 — Add an Amazon scanner

1. Click Amazon
2. Click Add Scanner. The page is Connect to a Provider
3. Under Platform, the default is Amazon API Gateway. Select Amazon Bedrock AgentCore Runtime (Agents) instead (click the label)

Step 3 — Configure the connection

Fill in the following fields using the credentials from your instructor:

Leave Trace scanning at its default value. Click Test Connection. After it succeeds, click Continue.

Step 4 — Name the connection

Leave Frequency (Every 24 hours) and Time (2 AM) as they are. Click Connect, then Test Scanner → (there is no Done button).

Step 5 — Run Discovery Scan

1. On the scanner page, click Run Discovery Scan
2. Wait for Scan History to show a run. Overview Services can still say 0 while Agents already has assets — open Agents to confirm. To see only your discovered agents, click Filters in the top right corner, choose your business group, and click Apply Filters

The scanner writes discovered agents into Agent Registry. Confirm these four (other org agents can appear too):

Add Amazon API Gateway Scanner

Repeat the same flow for Amazon API Gateway so Pet Shopping List API lands next to the agents.

Step 1 — Navigate to Providers

1. If you are not already there, switch to the enhanced experience (Switch to enhanced or omni.mulesoft.com)
2. In the left navigation, click Providers

Step 2 — Add an Amazon scanner

1. Click Amazon
2. Click Add Scanner
3. Under Platform, leave (or select) Amazon API Gateway — it is the default radio

Step 3 — Configure the connection

Fill in the following fields using the credentials from your instructor:

Leave Trace scanning at its default value. Click Test Connection, then Continue.

Step 4 — Name the connection

Leave Frequency (Every 24 hours) and Time (2 AM) as they are. Click Connect, then Test Scanner →.

Step 5 — Run Discovery Scan

1. On the scanner page, click Run Discovery Scan. Wait for Scan History. A good run is Success with 2 discovered. Last Scanned can still say Never — open the Services tab

Step 6 — View the discovered API

1. On this scanner, open Services. You should see Pet Shopping List API. It also appears under APIs

Rescan if you need to

Open the connection under Providers and click Run Discovery Scan again. Confirm the same assets still appear.

Register the on-prem PetStore API

Pawsome Pets already has a working REST backend. You are not rewriting it. Put a governed instance on Omni Gateway so it can later become an MCP server.

1. Open APIs → Add API → Register Manually
2. Name: PetStore API. Type: REST. Upload swagger.json. Click Create
3. On Instances, click Create Instance and keep Managed Instance

Click Create Instance. Status should be Active. Consumer endpoint: https://{{gateway}}/pet-store

Prove the instance in Postman Postman

In Postman this is Exercise 1.

Auth: No Auth. These paths stay open for the workshop.

Convert the PetStore API into an MCP server

Agents call tools, not OpenAPI. MCP Bridge turns PetStore operations into named tools.

1. On PetStore API, click Expose as MCP Server
2. Filter the catalog to APIs. Keep PetStore selected — skip Pet Shopping List API
3. In the tool selection window, uncheck the checkbox above the Method column to deselect all operations at once. Then manually select only the two tools listed in the table below: GET /inventory and GET /pet/{id}
4. On each kept tool, Actions → Edit. Set AI tool name and Description from the table, then Save
5. Skip SaaS Credentials. On Review, add a Description and click Create & Deploy
6. Copy Path from the Details tab of the MCP server you just created

Published names stay prefixed, for example {asset-id}_get_inventory. Use those names when you call the server.

Call the MCP server from Postman Postman

1. New → MCP Request. Server URL: the Path you copied from the MCP server — ensure this is the full URL including your gateway URL (e.g., https://<your-gateway>/<mcp-path>). Transport: Streamable HTTP. Connect.
2. Tools tab should list get_inventory and get_pet_details.
3. Run get_inventory with no args — same JSON as the REST call.
4. Run get_pet_details with id=1

Apply JWT Validation Policy to the MCP server

Same inbound identity as the rest of the control plane: JWT Validation Policy on the MCP instance.

1. From Instances → Apply Policy
2. Select JWT Validation, then Next

Change JWT Key origin from Text to JWKS. Check Skip Client Id Validation.

Use the following values from the table:

Click Apply Policy.

Prove the instance in Postman Postman

Re-send the request to the MCP server. Use the same MCP Request as in Call the MCP server from Postman: Server URL is the Path you copied from the MCP server, Transport Streamable HTTP, then run the tools.

Proxy Pawsome Agent

For this exercise you will proxy only one agent: Pawsome Agent. Callers will hit Omni Gateway instead of AWS URLs.

1. Go to Agents in the left navigation menu and search for Pawsome
2. Open Pawsome Agent (tag Amazon Bedrock Agentcore). Ignore extra catalog agents
3. Do not paste Overview Environment URL as the target — use the URL from this guide as is
4. On Instances you may already see a Production row on Amazon Bedrock Agentcore. Leave it. Click Create Instance → Managed Instance

Target URL:

Click Create Instance. Open the new row with a numeric Id on attendee-gateway (not the Amazon Bedrock UUID). Consumer endpoint: https://{{gateway}}/pawsome-agent

Inject IAM credentials with AWS Request Signature

AWS still needs IAM credentials on the way out. Apply them on the Omni Gateway instance.

1. Open the numeric instance → Apply Policy
2. Select AWS Request Signature (the applied list later shows Native Aws Signature), then Next

Click Apply Policy.

Verify AWS is receiving traffic

Before applying JWT Validation Policy, prove the proxy can reach AWS. In Postman, run Exercise 2 - 01 Send Agent Request No Auth. You should get a pet-care welcome, not a signing error.

Apply JWT Validation Policy to the agent

Apply the JWT Validation Policy on the Omni Gateway instance (the numeric Id, not the Amazon Bedrock row).

1. Open that instance → Apply Policy
2. Select JWT Validation, then Next

Change JWT Key origin from Text to JWKS. Check Skip Client Id Validation.

Click Apply Policy. Without a bearer token the A2A POST returns 400 JWT Token is required.

Send Agent Request JWT Auth

Repeat the A2A POST with Authorization: Bearer and a fresh token (they last about five minutes).

In Postman: This is Exercise 2 - 02 Send Agent Request JWT Auth.

In Postman, navigate to the Authorization tab, click Get New Access Token, and use it before sending your request.

Create a Model Proxy

Apps at Pawsome Pets still call OpenAI with a shared key. A Model Proxy is the OpenAI-compatible URL they will call instead. The key stays in the platform. Client libraries do not change.

1. Expand Model Proxies and stay on Model Proxies
2. Click Add Model Proxy

On Configure Gateway:

Click Continue. Routing may take a moment to open.

On Configure Routing Strategy, leave Model-based. Skip Add Route and Semantic Cache.

Click Add Model Proxy. Status should be Active. Consumer URL: https://{{gateway}}/llm-proxy

Check the default policies

Open llm-proxy → Policies. You should see CORS, DataWeave Headers Transformation, Client ID Enforcement, LLM Proxy Core, Model Based Routing, and outbound Openai Transcoding. You may also see Find Model Wallet and Model Wallet Token Rate Limit. Extra defaults can appear — leave them.

Create a Model Wallet

A Model Wallet names a caller and caps what they can spend. Incoming JWTs must match the claim you set. You apply the JWT Validation Policy in the next lesson. Spend tracking only works after the model has a cost — set that first.

Set GPT 5 Mini costs

1. Expand Model Proxies → Models
2. Search gpt-5-mini. You get two rows: Azure and OpenAI. Both costs start as –
3. Open the OpenAI row (purple icon) — not Azure
4. Actions → Edit. Set Cost per 1M Input Tokens and Cost per 1M Output Tokens to 100
5. Save

New Model Wallet

1. Expand Model Proxies → Model Wallets
2. Click New Model Wallet

Add a budget

Click + Add Budget. Period defaults to Monthly and Metric to Spend. Click the Daily label (the radio itself is hidden). Leave Spend selected. Spend Limit only tracks models that have costs (the 100 / 100 you just saved).

The JWT claim you set is client_id = df-user.

Apply JWT Validation Policy to the Model Proxy

Disable Client ID Enforcement and DataWeave Headers Transformation

Leave both policies on the instance. Disable them. They stay in the list as disabled so the JWT Validation Policy can replace that contract path.

1. Model Proxies → llm-proxy → Policies
2. On DataWeave Headers Transformation, open the overflow menu (More actions) → Disable Policy
3. On Client ID Enforcement, open the overflow menu (More actions) → Disable Policy

Both cards should now show as disabled. CORS, LLM Proxy Core, Find Model Wallet, Model Based Routing, Model Wallet Token Rate Limit, and outbound Openai Transcoding stay enabled.

Apply JWT Validation Policy

1. Still on Policies, click Apply Policy
2. Search JWT Validation, select it, then Next

The form opens on Configure Policy. Work top to bottom. Keycloak publishes keys at a JWKS URL.

Click Apply Policy at the bottom of the form.

Reorder policies

Policies run top to bottom inbound, then outbound on the way to the model. The JWT Validation Policy often lands at the bottom of inbound. Click Reorder Instance Policies and save this order so claims exist before Core, wallet, routing, and rate limit run:

Disabled policies can still appear in the list. Leave them disabled. Extra defaults can appear after those — leave them, still with CORS first and JWT Validation Policy second.

Verify LLM Proxy Core Policy

The JWT Validation Policy puts claims on the request. LLM Proxy Core reads them for usage metrics. Open the policy, set these fields, and save.

1. Model Proxies → llm-proxy → Policies
2. Open LLM Proxy Core Policy
3. Confirm or set the fields below
4. Click Save Changes

Verify Completions and Responses Postman

In Postman this is Exercise 3 03 - LLM Proxy Chat Completions JWT Auth and Exercise 3 04 - LLM Proxy Responses JWT Auth.

Mint a fresh token if yours is older than about four minutes. Without a bearer token, both calls should fail. With a bearer token, both should return 200.

Chat Completions body

Responses body

If Completions 401s and Responses 200s, the JWT Validation Policy is not on the whole proxy. Tokens expire in about five minutes. 502 usually means the Destination URL or API Key is wrong.

Verify cost attribution

Send the Completions and Responses calls with a bearer token again. Then open Cost Management → Budgets (not Optimizations) — this is the FinOps Dashboard, the place where you can see exactly what each agent costs. MuleSoft's AI cost management enriches this view with per-wallet, per-model, and per-agent attribution so you know precisely where every dollar is going. Leave the metric on Spend (or Cost). Environment Sandbox. Use 1H right after traffic, or 30D if 1H looks empty.

You should see spend on OpenAI and wallet Pawsome Pets storefront against the $10 / day cap.

Walkthrough of additional features Not hands-on

You already have identity (JWT Validation Policy), spend (the wallet), and a catalog. The rest of class is explanation only — we will not apply these policies.

Two more controls sit on the same Omni Gateway path: Amazon Bedrock Guardrails filters what the model is allowed to see or say. Agent Kill Switch contains an agent that already has a valid token but starts behaving badly. Kill Switch is a pair: Rogue Agent Detection flags the agent, then Kill Switch blocks that same ID. Finally, Akamai Integration surfaces security insights from Akamai's continuous traffic analysis directly in Agent Fabric, so you can discover shadow APIs and MCPs and act on their risk posture without leaving the platform.

Amazon Bedrock Guardrails

JWT Validation Policy is who. The wallet is how much. Guardrails are what content is allowed. You would apply this policy on llm-proxy. The guardrail itself lives in AWS; Omni Gateway only calls Bedrock to check the prompt and, optionally, the model output.

Docs: Amazon Bedrock Guardrails policy.

A blocked call typically returns 403. Response headers tell you what happened: x-llm-proxy-bedrock-guardrail-action (allow / reject), …-phase (request or response), and …-reason (for example pii, denied_topic, or content_filter). Clean storefront prompts still return 200 — the filter is not meant to break legitimate traffic.

Agent Kill Switch

A valid JWT still lets an agent call. Kill Switch is runtime containment when that agent starts asking for the wrong thing — PII, extra privileges, and similar. It is two policies on the same instance, typically Pawsome Agent, which already has the JWT Validation Policy. Detection flags the agent; Kill Switch blocks that ID. Both must use the same Agent Identity Selector so the ID you flag is the ID you block.

Rogue Agent Detection

The policy identifies the calling agent, the person it is acting for, and which anomalies to look for.

Example rules you would add:

You can add more rows (prompt injection, custom wording, and so on). Remove any rule you do not want evaluated.

Agent Kill Switch policy

This is the block list. It does not detect — it only compares the resolved agent ID to a list of agents that are quarantined and does not allow them to access the LLM.

The loop is: Detection emits an agent_id → that instance is flagged → you add the ID to Killed Agent IDs → later requests from that agent are blocked.

Flagged agents in Security

When Rogue Agent Detection flags an agent instance, it shows up under Governance → Security in the MuleSoft console. Until something is flagged, the page is empty: No flagged agents, with the note that a flagged instance appears here.

That list is the operational view of Kill Switch. You do not hunt through policy events to find the ID — Security is where the flagged agent is listed so you can add it to Killed Agent IDs.

Akamai Integration

MuleSoft's partnership with Akamai brings API security insights directly into Agent Fabric, giving you a single place to discover shadow APIs and MCPs, then protect and govern them.

Configure the Akamai API Security scanner

Add an Akamai API Security scanner under Providers. Once connected, Agent Fabric runs a discovery scan that pulls in every API Akamai already knows about — including shadow APIs that were never formally registered — and reports on their security posture. This is the automated governance strategy the scanner creates: every discovered asset gets a risk rating derived from Akamai's continuous traffic analysis.

Conformant vs. non-conformant APIs

After the scan, the registry shows which APIs are conformant and which are non-conformant. Click into any non-conformant API to see what triggered the flag — for example, endpoints that deviate from your governance strategy's design rules or that exhibit elevated risk behavior in live traffic. From here you can see the available actions: apply a policy, rotate credentials, or escalate for review.

Enriched API details from Akamai

Clicking into an individual API surfaces the enriched information Akamai shares with Agent Fabric. A typical example shows a medium risk rating with the contributing reasons broken out: design-time violations surfaced by other governance strategies, and an elevated risk posture from Akamai's traffic signals. In this demo environment no vulnerabilities or severe threats were found — but if they existed, they would appear in this same view alongside policy options to rotate or govern the affected API. The result is a closed loop: discover, assess, and act without leaving Agent Fabric.

What you learned

You stood up a control plane in front of assets Pawsome Pets already runs. Nothing upstream was rewritten.

1. Setup. You downloaded the accompanying assets. Omni Gateway attendee-gateway is the shared public endpoint.
2. Registry. Scanners found the AWS agents and Pet Shopping List API. You registered PetStore by hand.
3. APIs and MCP. PetStore is now tools plus JWT Validation Policy.
4. Agents. Pawsome Agent is proxied: SigV4 out, JWT Validation Policy in.
5. LLM. llm-proxy, a $10/day wallet, JWT Validation Policy, Core mapping, and cost attribution.
6. Additional features (walkthrough). Bedrock Guardrails on the LLM path; Rogue Agent Detection plus Agent Kill Switch; flagged agents in Security; Akamai Integration for shadow API discovery and risk posture.

Value of Agent Fabric

Same backends. One catalog, one enforcement point, one place for spend and content policy.