Part 5 of 10 · Building an Agentic Change-Approval MVP on MuleSoft
Part 4 ended with an uncomfortable point: a tool's description guides the agent, but it doesn't protect anything. This part covers the layer that does: Omni Gateway, sitting in front of every MCP server, every agent-to-agent call and every request to an LLM.
Three kinds of traffic, one gateway
An agent network produces three kinds of traffic, and each one has its own risks:
- Agent → MCP tools. Can this agent call this tool? Is the request well formed? Is personal data coming back in the response?
- Agent → agent (A2A). Is the request valid, and is personal data being passed between agents?
- Agent → LLM. Is personal data going to the model provider? Is anyone trying to talk the model out of its instructions? How many tokens is each agent burning?
Omni Gateway has policy sets for all three. Here's the chain we use in the MVP:
The order shown is the order we apply them, cheapest and most decisive first. A malformed request should fail before anything inspects its content.
MCP traffic: who can see which tool
Two policies decide tool access, and they work at different levels.
MCP Support comes first: it's the required policy that makes the gateway treat the API as an MCP server. Then MCP Global Access sets the baseline. It defines allow and block rules for which tools the MCP server exposes at all. We allow exactly the five tools from Part 4. Anything the integration team adds later stays invisible until someone adds it to the list on purpose.
MCP Attribute-Based Access Control narrows that down per caller. Rules use attributes of the request, such as token claims, headers, IP or tiers. Each agent calls the gateway with its own identity, so the rules can say which agent gets which tool:
| Tool | Intake | Planner | Approval |
|---|---|---|---|
create_change |
✅ | ||
read_transport |
✅ | ||
request_approval |
✅ | ||
create_sap_change_doc |
✅ | ||
import_transport_to_qa |
✅ |
The Intake agent never sees import_transport_to_qa. It isn't refused when it tries; the tool simply isn't in its list. A tool an agent can't see is a tool it can't be talked into calling.
Two more MCP policies are worth switching on early:
- MCP Schema Validation rejects requests that don't conform to the MCP specification before they reach a flow.
- MCP PII Detector blocks responses that contain personal data. ITSM records carry requester names and contact details. The agents don't need them, so they never leave the integration layer.
If your tool list grows, look at MCP Tools Progressive Disclosure, which exposes tools on demand through search instead of sending every description in every prompt. MCP Tool Mapping lets you rename tools and rewrite descriptions at the gateway without redeploying the Mule app.
A2A traffic: agents talking to agents
In our network the broker coordinates the agents, so agent-to-agent calls are fewer than you might expect. They still go through the gateway:
- A2A Schema Validation checks requests against the A2A specification.
- A2A PII Detector catches personal data passed between agents.
- A2A Prompt Decorator adds context to every request, such as "this is a regulated change process; never skip an approval step".
LLM traffic: what leaves the building
Every agent's model calls go out through the gateway too. Three policies matter most:
- Regex Prompt Guard blocks requests that match a deny-list. Ours includes common prompt-injection phrasing and any attempt to name a production system.
- LLM PII Detection finds personal data in prompts before they reach the model provider.
- LLM Token Based Rate Limit caps token use per agent. Part 3 gave every loop a retry limit; this is the budget behind it. An agent stuck in a loop hits the token limit long before it hits the invoice.
Defense in depth, not a single wall
The gateway is one of three layers, and none of them trusts the others:
- The tool contract (Part 4) makes the right call easy and rejects malformed input.
- The gateway decides who can see which tool and what data crosses the boundary.
- The Process API checks the approval ID against the approval record before any import, whoever calls it.
Remove the tool contract or the gateway and the system is weaker, but the approval still holds. Remove the Process API check and it doesn't, which is why that check never moves out of the integration layer.
Who owns what
- Platform team: the gateway, every policy on it, the agent identities the ABAC rules depend on, and the token budgets.
- Integration team: asks for a tool to be added to the allow-list and explains who needs it.
- Agent team: gets a clear error when a policy blocks something, and adjusts the agent instead of asking for the policy to be removed.
Next
Part 6 moves to the developer side: building all of this with MuleSoft Vibes, using skills, rules and workflows, plus hooks as guardrails for the AI developer.
Which policy would you switch on first: tool access, PII or token limits?
This series describes a reference model built on a fictional company. Policy names are from the Omni Gateway agent policies documentation as of October 2026; check current docs before you build.
Top comments (0)