Execution Authorization-gate component for Dify workflows exposed as MCP servers (uses aiyoplane-mcp-authz)

[rashonmassey]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hello!

So there’s work that's happening (like in #39240) showing that Dify workflows can be exposed as MCP servers, turning every workflow into a tool that an MCP client can call autonomously ....which is awesome, but when one of those workflow nodes performs a data write, deploy, payment, outbound API or any Consequential Action, the per-invocation authorization decision isn’t addressed inside the workflow itself.

That being said, my team over at Aiyoplane shipped a Python middleware, aiyoplane-mcp-authz (source, Apache 2.0, zero credentials to run locally), that attaches a Runtime Decision Point above the tool-invocation point. ALLOW / ESCALATE / BLOCK, with a cryptographically-signed Execution Receipt attached to flow context on ALLOW. The spec is at github.com/aiyoplane/aeap.

Rough shape of what a Dify execution authorization-gate wrapping it would look like, and we intentionally kept it thin:

from aiyoplane_mcp_authz import create_aiyo_mcp_authz, create_local_rdp, BlockedByPolicy

authz = create_aiyo_mcp_authz(
    rdp=create_local_rdp(policy=load_policy("policy.yaml")),
    tool_config={
        "send_payment": {"aiyo_gated": True, "action": {"type": "payment"}},
    },
)

@authz.wrap("send_payment")
def send_payment(args, ctx):
    # Runs only on ALLOW. ctx.receipt is the verified Execution Receipt.
    return perform_payment(args)
# ESCALATE / BLOCK raise typed exceptions the Dify node can catch.

So now we just have a question for the maintainers: what distribution shape would fit Dify best? A plugin in the Dify Marketplace (like #39210), a custom tool, or a workflow-node extension?

AEAP is an open protocol, so we're happy to build to whichever shape makes sense!

Repo: github.com/aiyoplane/mcp-authz-python · Spec: github.com/aiyoplane/aeap · Trust: aiyoplane.com/trust

Thanks a lot!

2. Additional context or comments

No response

3. Can you help us with this feature?

• I am interested in contributing to this feature.

[send21io]

One distinction that might help with the distribution question: for some consequential actions the gate can be structural rather than a decision point, and it's worth separating the two before choosing plugin vs node vs custom tool.

Two kinds of "payment" node

• The workflow holds spend authority (a key, a card token, an API that moves money). Then you need what you describe: a decision at invocation, bound to the exact parameters, with the receipt checked again at execution time.
• The workflow only produces an instruction someone else authorizes (an invoice, a pay link, an unsigned transaction a person signs in their own wallet). Here the wallet is the gate. A prompt-injected node can at worst produce an instruction that a human declines. A policy layer (amount caps, allowlisted receivers) is still useful, but it isn't the last line of defence.

Dify-specific details that matter either way (from building the second kind):

1. Bind the external call to the run. Use something like workflow_run_id + node id as the idempotency key. With node retries on, or an MCP client retrying a tool call, an un-keyed call gives you two invoices (or two payments) for one approval.
2. Keep receiving addresses out of model output. Pass them from workflow/environment variables into the tool call; they're the field an injection most wants to change.
3. Don't let a tool result say "paid". Confirmation should arrive at your own server: verify the HMAC over the raw body with a timestamp, reject stale deliveries, dedupe on the delivery id, check amount + asset + order id against your own order, and only then continue the business flow (resume the paused run or start a follow-up run).
4. Make "different amount" a human step. Exchange withdrawals often arrive short. A Human Input node is a natural place for accept/reject with a stored reason, instead of letting an agent node "fix" it by paying the difference; that's how caps get exceeded.
5. When the workflow is published as an MCP server, the caller is someone else's client. Put the gate inside the workflow (or inside the tool it calls); you can't rely on the client's own confirmation UI.

On shape: for the first kind, a tool-plugin wrapper seems natural, because the policy travels with the tool. The second kind needs nothing Dify-specific, since Dify already connects HTTP MCP servers with a custom Authorization header (we haven't published a tested Dify DSL for this yet).

Disclosure: we run a non-custodial payment-draft / pay-link API whose remote MCP server uses keys that can't move funds (https://send21.io/docs/mcp). There is no Dify plugin; the above is the generic MCP-tool path.

- send21