Human-in-the-loop is a design feature: enforcing approval gates for AI agents on MuleSoft

Companion to Part 1 · Building an Agentic Change-Approval MVP on MuleSoft

When people demo agentic systems, the human approval step is often treated as an embarrassment: the bit we'll automate away later.

In a regulated process it's the opposite. The approval is the product. Auditors, quality teams and your change advisory board rely on it. The question isn't how to remove it, but how to design it so it's fast, hard to bypass and fully traceable.

This post walks through the pattern we use in our change-approval MVP for promoting SAP changes to production. (Background: Part 1 and the 2x2 for deciding what to automate.)

The flow

1. The agent builds the approval package. It gathers the change summary, transport contents, test evidence and a risk summary into one place.
2. It calls a request_approval tool. This is an MCP tool over a Mule API that creates an approval task in the ITSM system. The agent can't approve anything itself.
3. A person reviews and approves. Their identity and the timestamp are recorded in the ITSM system, which issues an approval_id.
4. The agent calls import_to_prod with the change ID and the approval ID.
5. Omni Gateway applies policy first. The MCP tool allow-list decides whether this agent may see the tool at all, and attribute-based access control checks the caller's claims.
6. The Mule API verifies the approval. Does the approval ID exist, match this change, and is it unexpired and unused? Only then does it call SAP to import the transport.
7. An audit record is written. It captures who approved, what they saw and what was executed.

If any check fails, the tool refuses with a clear error and nothing touches SAP.

Three design rules

1. Enforce, don't instruct

"Always ask the user before importing to production" in a system prompt is a hope, not a control. Prompts can be ignored, misread or injected around.

The gate belongs where agents can't argue with it: in the API that performs the action, and in gateway policy in front of it. The agent's job is to request; the integration layer decides.

2. Make approving easy

Approval gates slow processes down mostly because approvers get incomplete information. They have to open five screens, read a raw log and chase someone for test evidence.

The agent's most valuable work here is preparing a single, complete package. A fast "yes" from a well-informed approver beats a slow one every time, and so does a confident "no".

3. Leave a trail

Every gate should answer, after the fact: who approved, when, what they were shown, and what was executed as a result. That's what turns an agentic workflow from "interesting" into something a validated environment can actually accept.

Who owns what

This pattern splits cleanly by team:

• Agent team: building the package and handling refusals gracefully.
• Integration team: the request_approval and import_to_prod tools, approval verification and the audit record.
• Platform team: gateway policies, identities and environments.

Next

In Part 2 I'll zoom out to the full reference architecture: Agent Fabric, Omni Gateway, MCP tools and the SAP and ITSM back ends on one page.

How do you enforce approvals in your agentic workflows today? Prompt, API, gateway, or something else?

---

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of September 2026.